PMsoop: Глава №22: Подготовка к сдаче версии Заказчику

В ролях - Менеджер Проекта, команда проекта

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

Суть – Проверяем что всё готово

Предположим, что версия готова, проверена, протестирована, и признана командой проекта годной для сдачи Заказчику. Что делать дальше?

Сначала надо установить версию в среду показа Заказчику, проверить доступность версии и записать параметры доступа к ней. Если показ происходит в среде разработки – обязательно проверьте что к ней есть доступ «извне», т.е. что заказчик сможет пройти по указанной ссылке. Иногда полезно сразу создать для заказчика тестового пользователя. Если вы сдаёте консольное приложение – убедитесь в том что оно упаковано в общепринятом формате (изестно, что формат .RAR не особо распространён за пределами СНГ, лучше использвать .ZIP). Если есть некий help – полезно не забыть его прикрепить к архиву или вывесить на тестовой версии сайта. Если вы отдаёте Заказчику только код, а сборка приложения происходит на его стороне – рекомендую сделать дополнительную проверку сборки и установки, для которой привлечь разработчика, не знакомого с проектом – так сказать, проверить «на кошечках», что с этим делом справится любой грамотный технический специалист. Да, ещё – если вы отдаёте Заказчику консольное приложение, или код, или что-то ещё что нужно скопировать на сторону Заказчика – рекомендую на всякий случай проверить доступность выбранного способа передачи данных, например, доступность FTP-сервера и наличие на нём пользователя для Заказчика, или что электронная почта пропустит файл такого объёма. По результату описанных действий – имеем «пакет» данной версии, собранный и готовый к показу/отправке.

Теперь поработаем над сопроводительной документацией. Начнём с обновления плана проекта. Следует отметить все выполненные задачи, и проследить, что сроки соответствуют реальным. План проекта полезно отправлять Заказчку вместе с показываемой версией, для усиления положительного эффекта «вот смотри как мы классно работаем!» и наглядного отображения выполненных задач.

Далее, так как план проекта всё таки не содержит раскрытого описания выполненных задач, а так же учитывая что у нас есть куча интересной информации в документе Release Notes, где, как известно, должен быть перечислен весь реализованный в версии функционал с привязкой (ссылками) на соотвествтующие разделы требований – готовим Release Notes в версии для Заказчика. При этом не забываем что документы Заказчику нужно отправлять на том же языке, на котором написана документация J В принципе, если Заказчик не участвует в тестировании – вместо release notes (где, как помним, есть ещё и список дефектов обнаруженных и исправленых в этой версии) можно подготовить некоторый облегчённый вариант документа, в котором присутствует только список выполненных задач (с названиями более понятными чем в ПП, с привязкой к требованиям) и список known issues – известных проблем версии которые либо не смогли устранить, либо считаем не существенными для её сдачи.

Наконец, готовим сопроводительное письмо к данной версии. В письме, кроме слов о том что «Ура! Версия готова можно проверять!», обязательно указываем параметры доступа к версии (URL тестового сайта, логин/пароль для FTP, etc). Иногда полезно в вежливой форме напомнить Заказчику про оговоренные в Контракте сроки на проверку версии (если такое было оговорено) и важность соблюдения этих сроков для своевременной сдачи следующих версий. К письму можно прикрепить план проекта и release notes (или его аналог).

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

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

Дальше – ждём рецензий и комментариев.