Горящий дедлайн: как проджект-менеджеру не лишиться пальцев

image

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

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

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

Вы не знаете, с кем работаете


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

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

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

Вы не поняли целей проекта


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

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

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

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

Члены вашей команды неверно оценили задачи


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

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

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

Вы и ваш клиент не знаете о рисках


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

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

На некоторые из внешних причин тоже можно влиять, особенно когда они кроются в клиенте. Чем раньше клиент даст доступ к текстам, логотипу, документации, API (в случае, если серверную часть делает команда на стороне клиента), тем лучше. А ещё лучше будет, если вы соберёте риски, связанные с клиентом, вместе и включите их в договор. Это будет отличным напоминанием клиенту, что он тоже часть проекта.

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

У вас нет плана Б


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

На такой случай для ряда особенно сложных задач нужно подобрать более бюджетный вариант их решения, от которого не пострадает пользовательский опыт, а общий результат останется адекватным. Это называется флексом. Вариант флекса — отказаться от кастомного дизайна. А и всё-таки воспользоваться гайдлайнами Apple и Google. Только не забудьте объяснить клиенту, что сейчас это лучший вариант для того, чтобы уложиться в дедлайн.

Вы не можете придать просрочке ценность в глазах клиента


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

  • разберёте проблему на митинге с командой, сделайте выводы и пообещаете клиенту, что так больше не случится;
  • обоснуете, что сорвать срок имело для проекта смысл в перспективе. За эти лишние 16 часов вы наверняка щепетильно протестировали приложение и устранили баги, которые бы непоправимо испортили продукту и клиенту имидж, попади он в руки пользователю.

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

Комментарии 11

    0

    Это конечно здорово, но, гораздо чаще у людей стоит вопрос: что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшить.
    Что грамотные менеджеры делают в этой ситуации?

      0
      что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшит

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

      На моей практике была только одна ситуация, когда у разработчика всегда были нереальные дедлайны: когда мы пилили продукт, разработчик не проектировал и называл сроки задач интуитивно, а когда сроки проходили, говорил: «нууууу… там сложности, ктож знал». При этом когда я спрашивала, а почему сложности не выяснились на берегу, мне говорили «Ну ты же про сроки спрашивала и НАДО БЫЛО БЫСТРЕЕ, а на оценку надо еще времени». Это был косяк обоих, и мой (как менеджера), и разработчика.
      Мой — в том, что я не донесла до разработчика приоритеты и не объяснила, что точность важнее скорости. Разработчика — в том, что он брал задачи без декомпозиции и проектирования и не сказал «Э, погодите, это вне здравого смысла. Я так не работаю.»
        0
        Это хорошо, что вам еще не приходилось оказываться в ситуации, когда «сейлы так продали» или «выиграли тендер» и книжные методы начинают работать очень со скрипом
          0
          В ситуации «выиграли тендер» действительно не оказывались, потому что сознательно их избегаем (и вы тоже можете начать).

          В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
      +1
      Господи, какая жесть )) Особенно это:
      С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
        –1
        Если не вырывать фразу из контекста, то было написано:
        Переоценивать свои силы склонны некоторые джуниоры и мидлы. С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.

        Что из этой фразы кажется жестью?

        Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
          +1
          Простите, но вы явно не видите здесь проблем.
          Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )

          Какой % всех ваших проектов завершился раньше времени?
            0

            В чем состоит проблема, как вам кажется? Пока действительно не улавливаю причину вашего недовольства, раз мы начали обмениваться мнениями, то давайте обсуждать не только то, в чем я (по вашему мнению) неправа но и то, как сделать оптимальнее. Мы гибкие в плане процессов ребята, и если почерпнем что-то полезное из комментов на Хабре, то нам будет не стремно это внедрять).


            Что касается ответов на вопрос: да, на некоторых проектах оценивает только один человек — обязательно тот, кто будет выполнять задачу. Проекты раньше календарного срока почти не завершаются, но это не только из-за коэффициентов, кроме этого стараемся делить работу на маленькие итерации, так проще прогнозировать.

              +1
              Я не недоволен )) Это же просто обмен мнениями
              Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.

              И тут я отошлю себя к nmivan:
              Есть в этом мире два скрама – правильный, и неправильный. Правильный описан в книге Джеффа Сазерленда. Неправильный – в т.н. scrum guide, причем в авторах числится все тот же Джефф Сазерленд.

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

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


              Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.

              Выводы?
              Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.

              P.S. А оценивать задачи разработчики всегда будут посредственно. Оценил и ошибся, и сделал в два раза дольше — хреновый разработчик. Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят. Помните же — задача занимает все отведенное на нее время ))

              В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
                0
                Мы с вами начали обсуждать фразу про поставновку сроков выполнения задачи — смещать фокус из такого контекста на дистрибуцию до пользователя некорректно, т.к. точные оценки — это одно, а то, что тестирование у вас (видимо) в оценку разработки входит, это другое. Мы следим за утилизацией времени разработчиков (сколько тратится непосредственно на код), и у нас на код тратится ~60% времени (кодревью я сюда же включаю, это тоже работа над кодом). Разработчик — достаточно дорогой ресурс, странно, что вы признаетесь, что на 90% используете его не вцелевую, и вам это ок.

                Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят.

                На этом месте загордилась своими коллегами). У нас так не принято. Сделал задачу медленнее — на ретро будем обсуждать, что не учли и как проектировать лучше. Сделал задачу быстрее — берешь следующую, неизрасходованное время потратится на то, чтобы «закрыть» ту задачу, на которой выбились из оценки. Или фиксишь баги. Никто ничего не растягивает.
                Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше

                Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.

                Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
                  0
                  О, здравствуйте! Прям диалог двоих )
                  В целом я вас понял, внешне все выглядит как задумано. А можно подробности, если это конечно не секрет?
                  Например, как вы измеряете time-to-market задачи (название условно, главное чтобы понятно было) — от ее создания до того, как она появится в виде функционала у пользователей? И как это меряется для одного функционала, но на разных платформах (iOS,Android, сайты, может еще что-то) и при этом учитываются проводимые A/B-тесты?

                  Про «утилизацию» времени разработчика — такой показатель попросту невозможен для продуктов с миллионами пользователей на разных платформах. Либо в вашем случае код пишется прямо на продакшне (это смерть бизнесу), либо они роботы, у которых нет личной жизни и времени сходить в туалет (а это тоже смерть бизнесу) ))

                  А вы делаете продукты внутри компании? Которые вам деньги приносят?

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое