На прошлой неделе нашему дизайнеру Кате нужно было сделать две большие задачи по двум разным проектам. Один проект студийный, один — клиентский. Мы обсудили детали в пятницу, и с понедельника Катя приступила к работе…
Обычно я пишу о том, какие ошибки совершают авторы и дизайнеры при поиске работы. Сегодня про обратное: ошибки руководителей, которые мешают людям работать.
Тайм-трекинг, менеджеры, которые стоят над душой, нескончаемые созвоны и планёрки по три часа без цели. Всё это убивает доверие, а главное отнимает огромное количество времени и пространства в голове. У людей попросту не остаётся времени на то, чтобы делать работу.
Я исхожу из того, что все люди, которых я беру на работу, ответственные, умеют держать слово и предупреждают о проблемах. Если я кого-то нанял, то доверяю ему до тех пор, пока он не докажет обратное и не даст мне повод сомневаться. Если человек оказался ненадёжным, то это и моя ошибка тоже. Ведь я сам выбрал его и доверил ему работу.
В классических компаниях у команды или проекта есть менеджер — человек, который решает проблемы. На деле я много раз наблюдал ситуацию, когда от менеджеров требуют согласовывать все решения с руководством. В итоге, работа менеджера сводится к тому, чтобы передавать информацию между клиентом и дизайнером, обновлять статусы задач и кивать головой на встречах.
Общение с менеджером, который не обладает властью принимать решения, выглядит как сломанный телефон: заказчик говорит одно, менеджер слышит другое. При этом дизайнерам не дают общаться с клиентом, задавать вопросы, запрашивать материалы. Приходится действовать вслепую.
У исполнителя должна быть возможность в любой момент задать вопрос и уточнить что-то у клиента напрямую. Проект не должен начинаться, пока дизайнер или автор не составят понимание задачи на основе личной беседы с заказчиком. Иначе это не работает.
Однако самое подлое — это бросать людей на задачи, которые никому не нужны. Это задачи, которые переносятся уже в пятый раз, за которые никто не хочет браться и которые ни на что не влияют. Если бы это было не так, то эти задачи уже были бы сделаны или хотя бы были в работе.
Нанимать людей, чтобы спихнуть на них ненужную работу — это как дарить вещи, которые тебе не нужны. Это опустошает, ведёт к выгоранию и текучке. В конце концов, человек будет чувствовать себя обманутым и уйдёт не с лёгким сердцем.
Если вы руководитель или собственник, понаблюдайте, не сталкиваются ли ваши сотрудники с чем-то из этого списка. Руководители часто говорят о том, что их роль — защищать команду и её интересы, но при этом не защищают самое ценное: время и внимание людей.
Если вы дизайнер или автор в команде, где есть эти проблемы, перешлите этот пост вашему руководителю. Возможно, этот текст заставит его усомниться в эффективности данных методов управления.
Частый косяк исполнителей, который иногда встречается даже у опытных и зрелых ребят — пропадать без предупреждения. Это всех бесит и хреново влияет на результат. В проекте возникает напряжение, пропадает доверие, всё скатывается в говно и мочилово. Этот пост — инструкция о том, как не быть мудаком и пропадать правильно.
Бывает, что человек заболел или в проекте затык, и работа встала. Уже ясно, что к дедлайну не успеть. Как обычно действуют люди в таких ситуациях:
Чаще всего они мямлят что-то вроде:
— У меня заболела бабушка, прорвало трубу, я заболел…
— Мне казалось, что я успею…
— Я не хотел тебя тревожить по мелочам…
Такое поведение — признак хуйни. Причины не важны, важен факт: человек не предупреждает о проблемах, не предлагает решения, а врёт и оправдывается. Вы только что вычислили мудака. Я допускаю, что человек может быть мудаком один раз. Но если ситуация повторяется дважды — это системная ошибка. С такими людьми просто не нужно работать.
Как следует поступать, если у вас проблема: вы заболели, буксуете с задачей или ещё по какой-то причине не успеваете сдать работу в срок.
1. Сообщить о проблеме. Расскажите коллеге, руководителю или клиенту о проблеме в тот же момент, как она возникла. Не надо ждать завтра или пока всё разрешится само собой. Дайте знать, что есть ситуация, которая может навредить проекту, если ничего с ней не делать.
2. Описать ситуацию и предложить решение. Если работаете в команде — делегировать задачу кому-то, кто может подменить вас на время жопы. Такая опция есть не всегда, поэтому скорее всего придётся проявить смекалочку и найти решение самому.
3. Сформировать ожидания. Сообщите клиенту и остальным коллегам, сколько времени вас не будет, как с вами связаться и к кому обратиться, пока вас нет. Большая часть проектной работы с заказчиком или в команде — это управление. Не обязательно самим проектом или людьми, а, в первую очередь, собой, своим процессом, задачами и ожиданиями других людей.
4. Отвечать на сообщения и звонки. Гасятся только мудаки. Ну и все эти отмазки про «не было связи» звучат смешно в 2023 году, когда связь есть уже в любой деревне.
5. Решить проблему. Без спешки и с чистой совестью перед командой и клиентом. Помните: спешка ебёт горячку.
Ситуаций, когда что-то идёт не так, в каждом проекте — десятки. Если научиться их решать и предупреждать о проблемах заранее, то ни вы, ни клиент их даже не заметите. А если забить и продолжать мириться с хуйнёй, то каждый проект будет похож на новый круг ада. Выбор за вами.
Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:
Заметил, что почти все дизайнеры спешат ответить на замечания клиента после презентации макета или логотипа. Они начинают накидывать идеи и предлагать решения, как всё исправить, или ещё хуже — перерисовывать макет прямо на встрече…
Презентация дизайна: ошибка, из-за которой ваш дизайн не принимают. Часть I…
У меня есть пост о том, почему писать «всем привет» в чате на десять человек — идиотская затея. Вот наглядная иллюстрация двухдневной давности, как это выглядит в жизни…
Есть два способа, как люди ведут проекты: договариваются о каждой встрече с отдельно и встречаются раз в неделю в одно и то же время. Очень долго я работал по первому сценарию, но последние два года полностью перешёл на второй. Рассказываю, почему.
Подход даёт гибкость в планировании, но если в проекте больше двух человек, согласовывать день и время встречи становится нудно и утомительно. Однако это не самое страшное.
В начале проекта встречи проходят более-менее регулярно, но чем дольше идёт проект, тем реже встречи. Иногда между двумя встречами возникают перерывы в две-три недели, иногда — в месяцы. Я называю их «дырами». Чем больше «дыра», тем хуже взаимопонимание и коммуникация, тем меньше доверия в проекте.
Долгие перерывы между встречами завышают ожидания клиента и значимость проделанной работы дизайнера. Представим, что клиент и дизайнер не виделись три недели.
Заказчик думает: «Раз они три недели молчали, значит, скорее всего что-то очень долго делали. Наверное, сейчас покажут мне крутые дизайны!»
Дизайнер в свою очередь думает: «Мы три недели рисовали макет, тут всё идеально. Сейчас его примут без правок!»
Так возникают ситуации, когда заказчик ожидал сразу увидеть кликабельный прототип с анимацией, а исполнитель принёс статичный макет. Это те самые встречи, на которых заказчик говорит: «Всё не то, дизайн — говно». Все, кто бывал на таких встречах, мечтают, чтобы они никогда не повторялись. Второй подход помогает избежать таких ситуаций.
Еженедельные встречи снижают гибкость в планировании, зато повышают управляемость и снижают трение в коммуникации. Главный принцип этого подхода: встречи должны быть несдвигаемыми. Не важно, какая погода за окном, все приходят, рассказывают новости, обсуждают результат.
Большинство никогда не работали по этому сценарию, и почти всегда предложение встречаться раз в неделю встречает дикое сопротивление. Возникает куча «зачем», «в чём смысл» и других вопросов. Отвечаю.
Встречи каждую неделю в одно и то же время решают проблемы, присущие хаотичному планированию:
Еженедельные встречи позволяют делать проект поступательно, без стресса. И вы и клиент знаете, что в понедельник, в 15:00 будет встреча и вы принесёте макет, а клиент даст замечания. Даже если вы ничего принесёте, то обсудите, почему не получилось принести. Это будет честно и открыто, без утайки.
Подход с хаотичным планированием подходит для коротких проектов, когда есть только вы и заказчик. Однако риск, что что-то может пойти не так, по-прежнему высок.
Подход с еженедельными встречами работает всегда. А большие и сложные проекты вроде разработки интерфейса или масштабного редизайна вообще нельзя делать по-другому.
Регулярные встречи с клиентом — пульс проекта. Без него проект либо не двигается вперёд, либо двигается не в том направлении. Регулярные встречи решают эту проблему и двигают проект всегда в нужном направлении.
Пост вдохновлён постом Лиды Поповой «Пациент скорее жив, чем мёртв»
Лучший момент на встрече, когда клиент говорит, что ему нихуя непонятно. Если вы слышите такое, это хороший знак, и вот почему:
В такие моменты не нужно ничего делать и говорить. Тем более не стоит спорить и возражать, что «у вас всё понятно». Не выставляйте заказчика идиотом: если он не понял, значит не понял, надо разобраться.
Сделайте паузу. Как правило она длится не долго, и заказчик сам начинает изливать душу. В этот момент заткнитесь и слушайте. Скорее всего узнаете что-то важное о продукте и ожиданиях от результата.
Так на одной из недавних встреч мы узнали, что нет смысла показывать клиенту текстовые черновики: без визуальной структуры он ничего не понимает. Ему важно увидеть черновой эскиз, чтобы представить, где будет заголовок, где картинка, где кнопка. Ещё выяснилось, что сейчас горят не те страницы, что мы принесли, а другие, которые изначально отложили.
Не пугайтесь, если клиенту ничего непонятно. Это идеальный момент, чтобы разобраться в проекте и выяснить, чего от вас хотят.
Фраза «мы не можем» и всё, что идёт после этих слов гораздо глубже, чем кажется. Вариантов, что означает «не можем», сотни, тысячи — все не перечислить.
Обычно это означает что-то из следующего:
— мы не хотим делать так, как вы просите
— нам это неудобно: дорого, долго, нудно и пр.
— мы такое никогда не делали, и нам страшно
— мы такое не умеем и не хотим учиться
— раз такие умные может сами всё и сделаете?!
— нам неинтересно решать эту задачу, мы хотим поскорее получить деньги и пойти дальше
— мы пообещали одно, а теперь нам надо идти к начальству на ковёр и договариваться заново
— вы ущемили нашу самооценку, поэтому идите на хуй с вашими предложениями
— у нас горят задницы, потому что мы проебались с важным отчётом, поэтому давайте через неделю
Когда вы слышите «не можем» от коллеги, исполнителя или заказчика, ваша задача — разобраться, что именно скрывается за этими словами. Есть ли реальная проблема или это просто какой-то внутренний барьер? Вопрос ли это бюджета или хотелка позиция гендиректора? На самом ли деле проблема в навыках, а не в том, что у вас конфликт с исполнителем? Или может просто у человека аврал и нужна помощь?
Можно ходить вокруг да около, а можно прямо спросить: «Давайте поговорим вот про это… Нам важно, чтобы было вот так. Да, это отличается от прежних договорённостей. Что будет, если мы выберем это решение? На что это повлияет? С какими проблемами мы столкнёмся?»
Часто оказывается, что «мы всё можем», но не хотим, потому что: боимся, зазнались, встали в позу, обиделись, заебались и так далее. Зная истинную причину, гораздо проще найти выход из тупика.
Прежде чем договариваться о встрече, я задаю себе вопрос: «А можно ли обойтись без встречи? Можно ли решить это без созвона? Как ещё я могу решить этот вопрос?»
В половине случаев встречу можно заменить письмом, отложенным сообщением, скринкастом, голосовым, коротким звонком на телефон.
Ситуации, когда встреча не нужна:
— получить однозначный ответ «да» или «нет»
— обновить статус задач
— запросить материалы или информацию
— дать обратную связь по макету или черновику
— внести правки
— рассказать, как пользоваться новой админкой
Ситуации, когда встреча необходима:
— установочная встреча в начале проекта
— презентация логотипа, сайта или любого результата
— разрешить конфликт в проекте
— поделиться знаниями и опытом: один на один, обучение команды
— обсудить вопросы, которые требуют много уточнений: понимание задачи
Понять, нужна встреча или нет, помогает следующий принцип. Если от моего текста и сообщения больше вреда, чем пользы, нужна встреча. Если текст позволяет решить задачу без вреда для проекта и отношений, можно обойтись без встречи.
Например, если в проекте нарастает трение, не стоит препираться в переписке. Лучше обсудить разногласия устно, чтобы успокоить собеседника. Если нужно прокомментировать очередной макет, достаточно оставить комментарии в Фигме, а созвон провести по требованию.
Главный секрет успевать больше заключается в том, чтобы сократить количество встреч. Половина встреч, которые проводят люди, на хуй не нужны.