PMsoop: Глава №25: Приёмка версии

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

Артефакты – требования, план проекта, акт приёмки

Суть – Получаем подтверждение приёмки версии от Заказчика

После того, как в готовой версии устранены все критичные багги и выполнены критичные изменения, и Заказчик признал, что реализованный функционал соответствует требованиям и плану проекта, необходимо получить от Заказчика формальное подтверждение приёмки версии. В зависимости от условий Контракта (или других предстартовых договорённостей) сделать это можно по-разному: Заказчик может подписать акт приёмки версии (лично или прислать скан), либо достаточно подтверждения приёмки в email. Важен сам факт признания Заказчиком версии «годной», а значит, возможности старта работ по следующей версии.

Вне зависимости от способа получения подтверждения приёмки, есть следующие условия, которые рекомендуется соблюдать:

1. Важно указать номер сборки (билда) и дату выпуска принятой версии. То есть, не просто «версия норм», а «версия №1234 от 15 марта 2010 норм».

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

3. Желательно в этом же документе (письме) перечислить те дефекты и ченджи, исправление/реализация которых отложена на следующие версии. Тоже с привязкой к номерам дефектов и ченджей.

Выполнение этих рекомендаций является страховкой от плохой памяти или махинаций Заказчика типа «это не так, все переделывайте, в той версии, что я принял, этот чендж уже был сделан, почему его теперь нет?» (хотя такого ченджа вообще не было).

В простом случае для небольшого проекта приёмка может выглядеть следующим образом. Менеджер проекта пишет Заказчику письмо подобного содержания:

«Уважаемый Заказчик. На данный момент мы обсуждаем версию номер 1234 от 15.03.2010, в которой реализованы следующие требования: _список_

В процессе сдачи версии мы исправили следующие дефекты: _список_

А также реализовали ченджи: _список_

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

Поэтому, прошу вас формально подтвердить приёмку данной версии, после чего мы сможем начать подготовительные работы по следующей версии».

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

Без наличия формального подтверждения приёмки текущей версии переходить к работам по следующим версиям можно только в том случае, если вы доверяете Заказчику на 100%.

Следующим важным моментом перед стартом следующей версии является получение платежей за выполненные работы. Если вы работаете по схеме fixed cost, то скорее всего платежи по вашему проекту привязаны к приёмке версий. В таком случае, получение платежа за сданную версию должно являться обязательным условием для старта следующей. Если вы работаете по схеме time&material – сдача версии является удобным поводом напомнить Заказчку про задержанные платежи, если таковые были.

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

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

После выполнения всего, описанного выше, желательно официально зафиксировать дату старта подготовительных работ по следующей версии. Это важно для планирования сроков сдачи следующих версий и проекта в целом. Уведомите Заказчика о том что «с сегодня, 16.03.2010, стартуем работы по версии №Х» и внесите эту дату в план проекта.