PMsoop: Глава №30: Поддержка приложения

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

Артефакты – по необходимости

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

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

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

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

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

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

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

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

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

Собственно, это и есть противоречие. Чем больше проходим времени с момента сдачи финальной версии – тем меньше доступность разработчиков, и тем удобнее собрать все ченджи разом. Поэтому, выбор подхода к реализации ченджей в законченно проекте часто требует предварительного обсуждения с руководством Компании важности дальнейших работ с данным Заказчиком и планов на дальнейшее использования разработчиков в других проектах. Решение принимается с точки зрения бизнеса. Иногда выгодно «придержать» команду проекта некоторое время, не давая новых задач, чтобы быстро и эффективно реализовать ченджи (в случае важности Заказчика для Компании и ожидания развития этого проекта либо поступления новых заказов). Иногда команда перебрасывается на новые проекты в течение нескольких дней после сдачи финальной версии, и сроки реализации ченджей (а иногда и устранения всех багов) сильно растягиваются (в случае если для Компании ценность новых проектов и Заказчиков выше чем предыдущего). Nothing personal, just business – не люблю эту фразу, но тут она к месту.

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