PMsoop: Глава №28: Продолжаем в том же духе

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

Артефакты – все, в зависимости от ситуации

Суть – делаем то же что в гл. Х – 27 пока не сдадим финальную версию

В этой главе хочется ещё раз перечислить важные моменты, которые не стоит игнорировать при переходе от версии к версии. Итак:

1. При поступлении новой информации касательно требований – уточнений, изменений и т.п. – необходимо объединять новую информацию со «старыми» требованиями. Либо обновляем основной документ с требованиями (SRS), либо добавляем информацию к таскам. Если этого не делать – повышается риск неверной интерпретации требований и «забывчивости» как у разработчиков, (сделали по неверной версии требований) так и у Заказчика (приёмка по не той версии требований). После обновления требования надо утверждать с Заказчиком – чтобы потом не было «а я такого не просил». Удобный момент для обновления требований – после сдачи очередной версии, перед стартом следующей.

2. При поступлении новой информации по требованиям также необходимо проверять и обновлять архитектуру проекта (концепцию). Если в проекте есть отдельный архитектурный документ – не забывайте вносить обновления. Если нету – как минимум, необходимо собрать разработчиков и проверить, как изменения влияют на уже написанный код, и планы на будущую разработку.

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

4. Release Notes является кумулятивным документом. При выпуске новой версии просто добавляем новую информацию в Release Notes о прошлой версии. В результате – имеем полный лог проекта, в котором понятно когда и в каком билде были добавлены новые функции, исправлены дефекты, внесены изменения и т.п.

5. При тестировании новой версии весьма полезно проверять работоспособность функционала прошлых версий. Не забываем регрессионное тестирование – и избегаем множества проблем и «ляпов».

6. После сдачи каждой версии необходимо проверять актуальность дат (milestones) в плане проекта. Даже если не было никаких изменений. В вопросе соблюдения запланированных дат сдачи версий луче «перебдеть, чем недобдеть» – это помогает сохранить хорошие отношения с Заказчиком.

7. По возможности, не стоит начинать новую версию до получения всех платежей за предыдущие версии. Соблюдайте правило «сдача в срок – платежи в срок», приучайте к нему Заказчика.

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

9. После приёмки версии Заказчиком полезно устроить с командой проекта «разбор полётов», на котором рассмотреть и оценить вклад каждого сотрудника и подвести итоги работы + сделать выводы на будущее.

10. Успешная сдача версии – хороший повод устроить небольшой праздник для команды проекта. Тимбилдинг рулит. Также, за сверхурочную работу, трудовые подвиги и досрочное выполнение задач сотрудников полезно премировать.