PMsoop: Глава №10: Сверка сроков

В ролях – Заказчик, Менеджер Проекта, Команда Проекта

Артефакты – ТЗ, план сдачи версий

Суть – Команда переоценивает трудозатраты по таск-листу, Менеджер Проекта проверяет сроки и согласовывает их с Заказчиком

В рамках этой главы рассмотрим реализацию следующей цели:

Цель 7. Определить необходимые трудозатраты для выделенных задач и сверить сроки сдачи версий

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

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

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

- в проекте участвуют три разработчика PHP, один из которых обладает квалификацией старшего разработчика и в проекте играет роль ведущего разработчика

- в проекте есть некоторое количество задач разработки на PHP, которые некоторым образом распределены между всеми разработчиками

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

- когда все задачи PHP оценены – ведущий разработчик сверяет сделанные оценки и подтверждает их корректность

В случае, когда разработчики или тестировщики не уверены в своей оценке – рекомендуется обратится к эксперту в данной области, если таковой есть в компании-Разработчике. Получасовая консультация на этом этапе может «спасти» несколько дней разработки после страта проекта.

Оценки рекомендуется ставить в виде диапазона, например 8 – 12 часов, где 8 – это ожидаемый срок выполнения задачи в оптимальном варианте, а 12 – в случае «если что-то пойдет не так». Оценки в таком виде дают Менеджеру Проекта лучшее понимание уверенности участников проектной команды в своих силах и возможных крайних сроков при переоценке сроков сдачи версий.

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

На собрании Менеджер Проекта должен проверить, что:

- все оценки сделаны прошли согласование с ведущими разработчиками и тестировщиками (если они есть в проекте)

- все «места неуверенности» по возможности устранены (проведены необходимые консультации либо исследования), либо возможные риски адекватно оцениваются всеми кого они затрагивают

- сделанные оценки не вызывают споров у участников команды

Затем на этом же собрании следует перейти к расчёту сроков сдачи версий.

В таск-листе задачи записаны в предполагаемой последовательности их выполнения. Однако при этом часто есть задачи, которые могут выполняться «параллельно» друг с другом. Первой задачей, которую надо решить для расчёта срока сдачи версии есть задача выделения «критического пути» этой версии.

Критический пусть есть наиболее длинная (по суммарным оценкам) последовательность взаимосвязанных задач (каждая следующая может выполняться только после завершения предыдущей) среди всех задач данной версии. Определять критический путь нужно с обязательным участием всех членов команды, так как в сопутствующих обсуждениях могут «всплыть» новые неучтённые ранее связи между задачами, новые задачи, неясности понимания требований и т.п.

После определения критического пути для версии следует просуммировать сначала оптимальные, затем пессимистические оценки трудозатрат, и полученные суммы привести к принятым единицам измерения сроков сдачи проекта (дни, недели, месяцы) или возможным датам. В результате получаем оптимистичный и пессимистичный срок сдачи версии. Определение критического пути и расчет оптимального и пессимистичного сроков сдачи повторяем для всех версий проекта.

Затем, важный момент, для каждой версии к полученным срокам добавляем 10 – 20% (в зависимости от сложности проекта и т.п.) «сверху». Это время понадобится на сдачу версии Заказчику и исправление критических дефектов, а также на детальное планирование следующей версии. Также это ваш «буфер» времени для компенсации возможных неожиданностей.

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

Итак, для каждой версии у нас есть минимальный и максимальный расчетный срок сдачи. При этом мы понимаем, что минимальный срок сдачи рассчитан из предположения, что все задачи критического пути будут выполнены в оптимальные сроки, что на практике фактически невозможно. Для добавления «трезвости» в оценках рекомендую взять разницу между минимальным и максимальным сроком сдачи, поделить на 2 и полученное значение прибавить к минимальному сроку. Полученные цифры назовём средним и пессимистичным сроками. И только после этого можно переходить к сверке сроков с Контрактом.

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

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

В случае, если для некоторой версии срок сдачи, установленный в Контракте, меньше чем оптимистичный срок – пересогласование сроков сдачи с Заказчиком является срочной необходимостью. Либо Менеджеру Проекта следует отдавать себе отчёт что сроки сдачи будут сорваны, и готовиться к возможным последствиям.

Исходя из личного опыта и наблюдений за «чужими» проектами замечу, что для 60% проектов сроки сдачи версий весьма близки к пессимистическим, ещё для 30% сроки сдачи превышают пессимистические и только для 10% проектов сроки сдачи близки к средним расчётным. Причина очевидна – даже на этапе подготовки проекта к старту у команды проекта обычно нет всей необходимой информации в ТЗ, сложные задачи воспринимаются командой оптимистично, а «подводные камни» пока не видны. Для сравнения – в области строительства ситуация аналогична, больше 50% новостроев сдаются с задержками и просрочками, и это при том что строительство как отрасль существует уже несколько тысячелетий J

Если отношения с Заказчиком и «буква» Контракта это позволяют – я настоятельно рекомендую Менеджеру Проекта любым способом «уломать» Заказчика на утверждение пессимистичных сроков для всех версий и проекта в целом. Это избавит вас от несбывшихся ожиданий и лишних надежд и упростит общение в процессе разработки проекта. Если в Контракте сроки сдачи до сих пор не были записаны – это сильно облегчает дело.

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

Если вы «подписываетесь» на невыполнимые сроки в надежде на чудо – лучше застрелиться и не мучить почём зря команду проекта. Кстати, есть такое замечание, что шансы разработчика уйти из компании растут с каждым провалившимся проектом, в котором он участвовал.

Пересогласование сроков сдачи версий лучше проводить в формате личной встречи или видео/аудио конференции между Менеджером Проектов и Заказчиком, возможно с привлечением некоторых разработчиков для усиления аргументации. В любом случае, Менеджер Проектов должен наглядно показать Заказчику откуда и каким образом появились новые сроки и почему они отличаются от старых. Не следует стесняться объяснять, что на этапе продажи понимание проекта было одно, а теперь, после выяснения всех вопросов – оно изменилось. Вполне нормально показывать Заказчику таск-лист с оценками и выделенным критическим путём проекта, только в таких случаях следует предупреждать, что оценки делались для расчёта сроков, а не для расчёта общих трудозатрат, особенно в случае если расчёт оплаты идёт почасово. Можно намекнуть Заказчику, что если он заинтересован в успешности проекта, а не «нагнуть Разработчка согласно Контракту» – то лучше согласиться, и рассказать, почему разработка ПО больше похожа на НИОКР чем на штамповку готовых деталей на заводе.

Если вы Менеджер Проекта, и не уверены в своей аргументации – до встречи с Заказчиком проконсультируйтесь с более опытными товарищами и своим руководством.

Если вы Заказчик, и к вам пришёл Менеджер вашего Проекта с объяснениями «почему сроки надо сдвинуть» – будьте к нему благосклонны J

Проверка достижения цели – рассчитаны сроки сдачи для каждой версии по таск-листу, результаты сверены с Контрактом и согласованы с Заказчиком.

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