Управление

Про хуйню ★ 

На сайте студии написано, что наш подход заключается в двух словах: «без хуйни». Некоторых эта фраза смущает и мне время от времени задают вопрос: «Непонятно, что такое „хуйня“. Что имеется в виду? Каждый ведь может трактовать это понятие по-разному». Отвечаю.

Хуйня — это всё, что противоречит здравому смыслу, логике и договорённостям.

Примеры хуйни в работе и жизни:

  • Не предупредить о проблеме в проекте и ждать, что всё разрешится само
  • Не прийти на встречу и не сообщить другим участниками, что планы изменились
  • Потратить две недели на переговоры, получить от клиента согласие, а не следующий день — отказ без объяснения причины
  • Обсуждать человека у него за спиной
  • Сорваться на постороннем человек из-за личных проблем
  • Закатить истерику, чтобы получить желаемое

Ни один человек не хочет оказаться в такой ситуации. Никто не хочет, чтобы в его проекте были проблемы, о которых он не догадывается. Никто не хочет жить с человеком, который психует и срывается по мелочам. Никто не хочет, чтобы его обсуждали за спиной. Никто не хочет потратить две недели на переговоры с мудаками.

Не бывает так, чтобы кто-нибудь проснулся и подумал: «Вот бы на меня сегодня начальник наорал. И ещё бы сроки в проекте сорвались. Как же скучно жить, когда тобой никто не манипулирует!» Никто не хочет иметь дело с хуйнёй.

Самое удивительное, что, хуйню чувствуют все. Люди могут не знать, как должно быть в идеале, но точно знают, как быть не должно. Хуйня — универсальное явление. Когда случается хуйня, не все могут встать и сказать вслух: «Ребята, творится какая-то хуйня». Но точно все это чувствуют и понимают.

Ошибка на старте. Не сообщать о проблемах ★ 

Частый косяк исполнителей, который иногда встречается даже у опытных и зрелых ребят — пропадать без предупреждения. Это всех бесит и хреново влияет на результат. В проекте возникает напряжение, пропадает доверие, всё скатывается в говно и мочилово.

Ниже инструкция о том, как не быть мудаком и пропадать правильно.

Кратко

Как только вы поняли, что у вас проблема, сообщите о ней руководителю или заказчику. Предупредите, что у вас что-то идёт не по плану, и нужен новый. Хорошо, если вы не просто придёте со словами «у меня проблема, помогите», но ещё и предложите решение и возьмёте на себя ответственность. Иначе пользы от вашего предупреждения мало.

Подробно

Бывает, что человек заболел или в проекте затык, и работа встала. Уже ясно, что к дедлайну не успеть. Как обычно действуют люди в таких ситуациях:

  1. Не сообщают никому о ситуации.
  2. Пропадают с радаром и не выходят на связь.
  3. Не отвечают на сообщения и звонки.
  4. Появляются в день дедлайна с оправданиями.

Чаще всего они мямлят что-то вроде:
— У меня заболела бабушка, прорвало трубу, я заболел…
— Мне казалось, что я успею…
— Я не хотел тебя тревожить по мелочам…

Если человек пропал без объяснений, а потом пришёл, когда его помощь не нужна — это признак хуйни. Причины не важны, важен факт: человек не предупреждает о проблемах, не предлагает решения, а врёт и оправдывается. Поздравляю, вы только что вычислили мудака. Я допускаю, что человек может быть мудаком один раз. Но если ситуация повторяется дважды — это системная ошибка. С такими людьми просто не нужно работать.

Вот как следует поступать, если у вас проблема, вы заболели, буксуете с задачей или ещё по какой-то причине не успеваете сдать работу в срок:

  1. Сообщить о проблеме. Расскажите коллеге, руководителю или клиенту о проблеме в тот же момент, как она возникла. Не надо ждать завтра или пока всё разрешится само собой. Дайте знать, что есть ситуация, которая может навредить проекту, если ничего с ней не делать.
  2. Описать ситуацию и предложить решение. Если работаете в команде — делегировать задачу кому-то, кто может подменить вас на время жопы. Такая опция есть не всегда, поэтому скорее всего придётся проявить смекалочку и найти решение самому.
  3. Сформировать ожидания. Сообщите клиенту и остальным коллегам, сколько времени вас не будет, как с вами связаться и к кому обратиться, пока вас нет. Большая часть проектной работы с заказчиком или в команде — это управление. Не обязательно самим проектом или людьми, а, в первую очередь, собой, своим процессом, задачами и ожиданиями других людей.
  4. Отвечать на сообщения и звонки. Гасятся только мудаки. Ну и все эти отмазки про «не было связи» звучат смешно в 2023 году, когда связь есть уже в любой деревне.
  5. Решить проблему. Без спешки и с чистой совестью перед командой и клиентом. Помните: спешка ебёт горячку.

Ситуаций, когда что-то идёт не так, в каждом проекте — десятки. Если научиться их решать и предупреждать о проблемах заранее, то ни вы, ни клиент их даже не заметите. А если забить и продолжать мириться с хуйнёй, то каждый проект будет похож на новый круг ада. Выбор за вами.


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Не сообщать о проблемах — вы здесь
  3. Наврать клиенту про опыт

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Принципы управления дизайн-студией: семь «да» и семь «нет» 

Раз в две недели мы проводим общий созвон студии, где общаемся на разные темы: про книги, фильмы, мемы, бёрдвотчинги другие классные штуки.

На последней встрече я рассказал о принципах студии, которые сложились за пять лет её существования. Некоторые из них появились совсем недавно, а некоторые — с первого дня работы.

Делюсь публично, потому что хорошего должно быть больше. Будет интересно клиентам студии и всем, кто руководит удалёнными командами.

Не правки, а замечания и вопросы 

Правки — это хотелки заказчика, которые следует безропотно принять и согласиться на любые доработки. Те, кто принимают правки, обычно так и мыслят: ну раз пришли правки, мы их сейчас внесём, чего спорить-то. Хотя, возможно, всё уже достаточно хорошо и ничего никуда вносить не надо.

Замечания и вопросы — это ход мысли, приглашение к разговору. Замечания требуют обсуждения: можно задать вопросы, уточнить, поспорить, предложить другое решение. Вопросы — сигнал, что заказчик что-то понимает иначе, чем мы, и нам надо разобраться, как именно он это понимает и почему.

Главное отличие между правками и замечаниями в том, что любые правки можно послать нахуй, а замечания — нет.

Что мы не делаем ★ 

Часто в проект проскакивают задачи, которые вы с клиентом обсуждали на старте, но решили пока не делать. Так происходит потому клиент всегда хочет максимум за минимум денег, а исполнитель не хочет обидеть клиента отказом и прослыть жмотом. Желание клиента вполне понятно и оправдано, однако, и жмотства в этом никакого нет.

Отложить что-то на старте проекта значит освободить время и место в голове для более важных задач, без решения которых проект не запустится. Чем больше задач вы пытаетесь упихнуть в единицу времени, тем дальше вы от цели. И, наоборот, чем меньше объём работы, тем выше вероятность создать работающее решение и запуститься в срок. На практике все это знают, но когда находишься в проекте, очень легко закопаться и согласиться на дополнительную неоплачиваемую работу.

Не сделать лишнего помогает такой приём — добавить в понимание задачи пункт «Что мы не делаем». Не просто обсудить с клиентом, мол, да-да, вот эту интеграцию с ЦРМ пока делать не будем, а прям записать в документ в отдельный пункт с деталями. Многим это кажется странным, мол, я-то точно не забуду. Забудете.

Люди всё забывают и очень быстро.

Через две-три недели ни вы, ни клиент не вспомните, о чём договорились и что там было с той самой интеграцией. Вроде бы обсуждали, да, но что именно решили, уже не помним. Хм, ну давайте сделаем. С этого момента всё летит в пизду: сроки сдвигаются, приходится перекидывать людей с одних задач на другие, работать по ночам. Всего этого можно избежать, добавив в понимание задачи пару строк.

Вот план действий на случай, если клиент пришёл с задачей, которую вы отложили:

  1. Не бросать текущие задачи и не бежать сломя голову чего-то там делать, рисовать и писать.
  2. Пойти посмотреть, что вы писали в понимании задачи и о чём договорились.
  3. Вернуться к клиенту с ответом: «Да, Иван Иваныч, понимаем, но мы с вами решили пока это не делать. Можем взять в следующий спринт, цикл, вынести в отдельный проект, когда закончим текущий».

Конечно, всё это будет работать, только если вы прикрепляете и подписываете понимание задачи к договору в качестве приложения. Без договора клиент может нагнуть вас как хочет: требовать любую работу, менять условия и в принципе вам не платить.

Не знаешь, что делать — не делай ничего 

Свежий пример из редакторской практики:

Автор присылает на провереку пост, где есть перечень из четырёх пунктов. Три пункта — хорошие, с примерами и фактурой, а четвёртый — дохлый, на одну строчку. Рядом с остальными пунктами перечня он выглядит неуверенно, неполноценно.

Я пишу комментарий, что так не пойдёт: все пункты перечня должны быть равноценны между собой. Автор берёт и доливает в слабый пункт «воды». Становится ещё хуже: теперь у нас в перечне три полезных пункта и один — с притянутыми за уши фактами и обтекаемыми формулировками.

Снова пишу комментарий. Автор начинает двигать слова, но это не помогает. Так продолжается какое-то время, пока я не задаю вопрос: «А какую проблему ты пытаешься этим решить?» Оказалось, автор был уверен, что должен перебрать как можно больше решений. Это частое заблуждение.

Работа исполнителя не в том, чтобы сделать больше: написать больше текста или подвигать пиксели в макете. Иногда работа в том, чтобы не делать ничего. Иногда нужно перестать искать новое решение, и пересмотреть проблему, изменить её, переформулировать.

Вот несколько примеров:

  1. В списке появился куцый пункт, и вы не знаете, что туда дописать — уберите этот пункт. Это лучше, чем оставить прежний список с дохлым пунктом.
  2. В макете есть экран с плохой компоновкой, запуск уже через неделю, и вы понимаете, что со всеми согласованиями разработчики не успеют выкатить эти изменения в срок. Передоговоритесь с клиентом о том, чтобы запустить сайт без этого экрана. Это лучше, чем отложить пуск.
  3. Вы сели писать письмо другу, но слова не складываются в текст. Значит, сегодня явно не тот день, чтобы страдать над белым листом. Отложите письмо, займись другими делами. Это лучше, чем отправлять вымученное письмо.

Если не можете найти решение, возможно, вы решаете не ту проблему. Смените фокус и убедитесь, что дело именно в решении, а не в чём-то ещё. Возможно, лучший вариант — это отступить от намеченного плана и не делать ничего и дать решению созреть.

Ошибка на старте. Отправить клиента заполнять бриф ★ 

Начинаю серию бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Первый — про брифы и техзадания.

Кратко

Бриф — это грабли, которые потом бьют по лбу, а иногда и по яйцам, если они у вас есть, в самый неожиданный момент. Брифы, заполненные без вас — шлак. Не тратьте на брифы ни время клиента, ни своё. Составляйте понимание задачи сами на созвоне или личной встрече.

Подробно

Заставлять клиента заполнять брифы до встречи — дурной тон. Это перекладывание ответственности и своей работы на заказчика. Со стороны выглядит дико: вы там напишите, чего вам надо, а я почитаю и скажу, что я про это думаю. То есть исполнитель скинул свою работу на заказчика и курит бамбук.

Требуя заполнить бриф, исполнитель лишается главного — возможности построить долгосрочные отношения с будущим клиентом и понять, его ли это проект. Бриф повышает риск ввязаться в проект с дурным контекстом, потому что в тексте невозможно заметить те самые «подводные камни». Нужна встреча, живое общение, контакт.

Другая проблема в том, что в 99% случаев брифы не помогают сделать проект хорошо. Клиенты заполняют их наотъебись, упуская важные детали. И они не со зла: у них нет времени на ещё одну анкету, и они в самом деле не знают, что важно для проекта, а что нет. Потому и пришли к исполнителю, чтобы тот помог разобраться, взял часть ответственности и помог.

То же самое касается техзаданий, который заказчик составил с кем-то до вас. Большая часть этих документов бессмысленная хуйня, где школярским языком описывается, сколько экранов должно быть на сайте, с какой стороны должна стоять кнопка. Всё это не имеет никакого отношения к решению задачи и проекту.

Некоторые клиенты могут использовать техзадания в качестве аргумента в переговорах о стоимости. Мол, вот это нам обещали сделать за пять рублей в студии «Пурпурный карась», давайте и вы так же. Я в такие моменты отвечаю: «Так, а зачем покупать у меня? Идите туда и делайте за пять рублей там. У меня это стоит вот столько».

Чужие договорённости с кем-либо не должны влиять на ваши договорённости с клиентом. Поэтому ТЗ идут нахуй. Их можно читать, но по моему опыту, к ним никто никогда не возвращается, кроме госзаказчиков. Там ТЗ — это священный документ, но этот случай мы не рассматриваем, потому что я про это ничего не знаю.


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф — вы здесь
  2. Не сообщать о проблемах
  3. Наврать клиенту про опыт

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Главный инструмент планирования 

С этого года я перестал планировать жизнь через цели. И вот почему.

Цель — это некий ориентир, куда я бы хотел прийти в идеальной ситуации. Проблема в том, что такой идеальной ситуации никогда не будет. Ничто никогда не идёт так, как мы хотим и планируем. Случаются различные жопы, большие и не очень, а временами приходит пиздец, и тогда вообще все цели идут лесом. Хоть запланируйся.

К тому же, если я не приду к намеченным целям, то в целом ничего страшного не случится. Кто сказал, что я обязательно должен к ним прийти? А что если есть что-то бо́льшее, чем-то, что я себе придумал? Возможно, по пути к своей цели я найду другой, более интересный путь. Возможно, я пойму, что моя цель была ложной. Возможно, я смогу преуспеть в чём-то другом и достичь там большего, чем я изначально планировал.

Вместо целей я ориентируюсь на свои ценности. Они помогают выбирать, на что я хочу сейчас тратить время, делать только то, во что я верю, оставлять самое главное и отсеивать неэффективное, скучное и вредное. Например, одна из моих ценностей — создавать продукты и решения. Значит, я не буду браться за проекты, где на выходе не смогу увидеть законченный продукт, результат.

Ценности помогают принимать решения в самых разных ситуациях и замечать возможности. Цели, наоборот, ограничивают мышление до размера самих себя. Если цель мелкая, то дальше неё ничего и не увидишь.

Ценности определяют, кем ты хочешь быть уже сейчас, а не что ты хочешь получить. В этом их ключевое отличие от целей. Ценности помогают быть человеком, который счастлив несмотря на внешние обстоятельства, тогда как цели лишь усиливают несчастье, потому что напрямую зависят от внешних факторов.

Действенность такого подхода подтвердилась, когда в прошлом году началась война. Все вокруг были растеряны, не знали, что делать, я в том числе. В такие моменты планы и цели летят к чертям: всё решают ценности. Тем, у кого они есть, и кто строит свою жизнь от них, было гораздо легче пережить это время и принимать решения, чем тем, кто опирался на цели.

Планёрки мертвы 

Ещё прошлой осенью я начал понимать, что слишком много времени трачу на встречи и обсуждения задач. Минимум три-четыре часа в неделю уходило на различного рода планёрки и встречи, на которых мы искали решение отдельной проблемы.

Как выглядит обычная онлайн-планёрка: один человек проговаривает статусы задач, которые уже и так записаны в таск-менеджере, а остальные скучают, тупят в телефоны и думают, как бы поскорее свалить. Тоска смертная!

С января этого года в качестве эксперимента я отменил все планёрки в студии. И ничего страшного не случилось. Работа не встала, дедлайны не сорвались. Наоборот, у людей появилось больше времени на вдумчивую, спокойную работу.

Оказалось, что многие вещи можно решить письменно. А ещё почти всегда лучше сначала написать, а потом обсуждать. Это невероятно сокращает количество и длительность встреч, а ещё повышает качество идей и их проработку.

Формулировка мыслей в письменном виде исключает возможность переложить задачу и её решение кого-то другого, скинуть её с себя. Не то, чтобы у нас это когда-то было нормой, но теперь это в принципе невозможно.

«А как же сплочённость команды, тимбилдинг и вот это всё?» — спросите вы. Я всегда считал, что это надуманная хуйня. Такие вещи не формируются на планёрках. От того, что мы мысленно возьмёмся за руки и помолимся в Зуме, мы не станем командой. Скорее, наоборот, такие вещи вызывают рвотный рефлекс.

Вместо планёрок мы стали проводить неформальные беседы, где болтаем о чём угодно. Например, на первой встрече говорили про велосипеды, теннис и о том, как скоро нас заменят роботы. На второй — про сон, важность отдыха, ошибки при откликах на вакансии и даже немного про политику.

Пока решили, что продолжим делать такие встречи раз в две недели. Это не слишком часто, чтобы надоесть, и не слишком редко, чтобы чувствовать себя оторванным от команды. Главное условие: хочешь приходит, хочешь нет. Никакой обязаловки.

Если вы менеджер или не дай бог основатель, вас не должно быть много на такой встрече. Дайте людям высказаться первыми, комментируйте по делу, но не выпячивайтесь, иначе приятные посиделки превратятся в ваш стендап.

Шаббат 

Лучший отдых — заранее спланированный отдых. Я пришёл к этой мысли пару лет назад и постепенно она превратилась в принцип, который помогает не заебаться от работы и отдыхать вовремя.

Всё просто: один день в неделю должен быть выходным. В этот день запрещено открывать ноутбук, писать посты, редактировать документы или что-то дизайнить. Можно делать всё, что угодно, только не работать. Это похоже на шаббат, только без религиозного подтекста.

Выходным днём я назначил субботу:

  1. К пятнице сил остаётся мало, работаешь на автопилоте. Гораздо проще работать, когда знаешь, что завтра — отдых.
  2. Воскресенье уже рабочее, но без встреч и созвонов. Можно посвятить его всему, на что в будни не остаётся времени: чтению, разбору почты, обучению, рассылке и планированию. Начинать неделю в воскресенье удобнее, чем в понедельник: это помогает въехать в рабочую неделю плавно, без стресса.
  3. В понедельник я уже чётко знаю, что делать, так как всё спланировал заранее: обычно это самый продуктивный день недели. Дальше жизнь вносит свои коррективы, и так до следующей субботы.

Суббота же превратилась в день домашних дел, учёбы, чтения, встреч с друзьями, родными или поездок за город. У меня стали появляться новые впечатления и идеи, я стал меньше уставать и перестал ассоциировать себя только с работой.

Самое главное, несдвигаемый выходной добавляет в жизнь стабильности и спокойствия в трудные времена, повышает ощущение контроля над своей жизнью. Что бы ни случилось, я знаю, в субботу будет выходной и я обязательно найду решение.


П. С. Нарушил правило, чтобы написать этот пост. Ну раз прёт, зачем откладывать. Выпускай, пока есть запал, пока тема горит и волнует. Потом это не будет никому нужно.