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