[Из песочницы] Горящий дедлайн: как проджект-менеджеру не лишиться пальцев
Все знают, что такое дедлайн, но не все знают, как правильно его ставить. Для разговора о срыве дедлайна на проекте можно подобрать много красивых метафор. Юбицумэ — одна из таких. Это ритуальное отрезание фаланги пальца в Японии. В частности к юбицумэ прибегают, чтобы принести извинения перед руководителем или хозяином за оплошность. Если вы смотрели фильмы про якудза, то поняли, о чём речь.
Ритуал пошёл из среды бакуто — игроков в азартные игры, и рассматривался как адекватная замена выплате долга. Должник пускал в расход фалангу мизинца, и это осложняло его дальнейшую жизнь: он больше не мог надёжно держать меч и в бою сильнее зависел от своих компаньонов, в том числе от хозяина.
Неважно, в каком времени и месте ты живёшь и чем занимаешься — командные отношения должны быть крепкими, а сроки нужно соблюдать. Менеджеры нашей студии хоть и не отрезают себе пальцы, но всё равно несут ответственность за данное клиенту слово. Опыт позволил мне сформулировать шесть ошибок, допустив которые, вы точно рискуете сдать работу не вовремя, и что делать, чтобы соблюдать дедлайны. Перестав допускать эти ошибки, вы заметите, как вырастет качество ваших проектов, сколько времени освободится на отдых и как улучшатся отношения между членами команды и с клиентом.
Вы не знаете, с кем работаете
Каждый член команды разработки — как персонаж в ролевой игре: у кого-то в избытке умение вовлекаться в проект, но недостаёт усидчивости и сосредоточенности, а кто-то хорошо оценивает время, которое займёт выполнение задачи. Из последних получаются тимлиды, которые обычно хороши во всём.
Со всеми этими, такими разными, людьми нужно работать в разном стиле. Одни нуждаются в стимуле, будь то жёсткий контроль или подбадривающие слова; другие ждут, что вы им расскажете о клиентском бэкграунде, его идеалах и взглядах на жизнь, чего он ждёт от команды и как на неё надеется; третьи просто работают. Если вы не будете делать поправку на характер члена вашей команды, то он окажется предоставленным самому себе и своим худшим привычкам, а срок выполнения задачи, вероятно, будет сорван.
Не менее важен опыт специалиста. Распределяйте задачи по способностям и коэффициенту производительности, иначе джун или мидл провалят задачу, которая изначально им не по силам.
Вы не поняли целей проекта
Работа над сайтом или приложением начинается с этапа проектирования. Этап серьёзный: предстоит осознать, кто будет пользоваться продуктом, для достижения каких целей он предназначен и как он будет приносить деньги своему владельцу. Результаты этого этапа прописываются в функциональном задании, а функциональное задание служит основой для формулирования задач дизайнерам и разработчикам.
У функциональности приложения должно быть чёткое предназначение. Если менеджер его не понял, это значит, что проектирование сделано плохо, и правильно поставить задачу перед исполнителем не получится. Результат непредсказуем, потому что разработчик может начать додумывать роль функциональности, раздувать её, и в итоге потратит кучу времени на написание и переписывание кода.
Чтобы этого избежать, мы проводим дизайн-ревью: вся команда тщательно и итеративно отсматривает получившийся прототип или дизайн и находит как можно больше пробелов, ошибок и недостающих экранов. Качественное выполнение дизайн-ревью сильно влияет на сроки.
Чем точнее и полнее составлена документация, тем меньше у разработчиков будет недопонимания и багов во время разработки, что гарантирует соблюдение дедлайнов.
Члены вашей команды неверно оценили задачи
Неверная оценка — причина большинства сгоревших дедлайнов. Каждый случай неверной оценки нужно обсуждать на ретроспективе, находить причины и выработать тактику по их устранению в будущем.
Переоценивать свои силы склонны некоторые джуниоры и мидлы. С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Senior-разработчик — не тот, кто старше остальных, а кто знает, что времени на выполнение задачи может уйти больше, чем ожидается, и смело признаётся в этом себе и менеджеру. Senior-разработчик знает о рисках, и вы должны. Этому посвящена следующая ошибка.
Вы и ваш клиент не знаете о рисках
Риски — это всё, чего вы не планировали и что затормозит работу над задачами. Они бывают внешние и внутренние. Отключение интернета, ураган или наводнение, изменение требований к продукту — это внешние причины, на которые исполнители никак не могут повлиять. Долгий поиск решения задачи, нервный срыв у разработчика — это внутренние причины и они поддаются контролю.
Снизить вероятность рисков можно за счёт декомпозиции, или дробления большой задачи на маленькие. 40 часов — это не всегда четыре задачи по 10 часов; при декомпозиции может оказаться, что для интеграции до боли знакомой платёжной системы в незнакомый проект готовых коробочных решений не хватит, и придётся писать свои. Декомпозиция поможет правильно оценить сроки и упростить контроль над их соблюдением.
На некоторые из внешних причин тоже можно влиять, особенно когда они кроются в клиенте. Чем раньше клиент даст доступ к текстам, логотипу, документации, API (в случае, если серверную часть делает команда на стороне клиента), тем лучше. А ещё лучше будет, если вы соберёте риски, связанные с клиентом, вместе и включите их в договор. Это будет отличным напоминанием клиенту, что он тоже часть проекта.
Если клиент в тонусе, то проект будет идти легко. Информируйте его о статусе задач, рассказывайте обо всём, что может пойти не так и что приведёт к просрочке, рассказывайте о том, что вы пробуете для решения проблемы. Во-первых, вы можете удивиться тому, как это сблизит вас и подтолкнёт к максимально конструктивному диалогу. Во-вторых, возможный выход за срок и его переназначение уже не станут для клиента сюрпризом. Грамотная коммуникация — это залог успеха.
У вас нет плана Б
Хороший менеджер, как шахматист, просчитывает варианты событий наперёд. Но если шахматист смотрит в будущее лишь на несколько минут, то менеджер — на пару месяцев до дедлайна точно. За это время все риски должны вылезти наружу.
На такой случай для ряда особенно сложных задач нужно подобрать более бюджетный вариант их решения, от которого не пострадает пользовательский опыт, а общий результат останется адекватным. Это называется флексом. Вариант флекса — отказаться от кастомного дизайна и всё-таки воспользоваться гайдлайнами Apple и Google. Только не забудьте объяснить клиенту, что сейчас это лучший вариант для того, чтобы уложиться в дедлайн.
Вы не можете придать просрочке ценность в глазах клиента
Начать с извинений всё-таки нормально, это базовая вежливость. Другое дело, что извинения нужно подкрепить чем-то прикладным. Будет здорово, если вы:
- разберёте проблему на митинге с командой, сделайте выводы и пообещаете клиенту, что так больше не случится;
- обоснуете, что сорвать срок имело для проекта смысл в перспективе. За эти лишние 16 часов вы наверняка щепетильно протестировали приложение и устранили баги, которые бы непоправимо испортили продукту и клиенту имидж, попади он в руки пользователю.
Если не хотите чувствовать вину и внести сбой в размеренный темп своей жизни, не допускайте ни одной из этих ошибок. Я перечислила самые основные и думаем, что специфика вашей работы располагает к другим ошибкам. Будет здорово, если вы расскажете о них в комментариях.
