Управление проектом разработки сайта или веб-приложения

Возникнет напряженность в отношениях заказчика и разработчика. Заказчик в этом случае будет винить в неудаче разработчика. Частично он будет прав, но лишь частично: на стадии эксплуатации риск возникновения ошибок очень велик, и заказчик должен заранее обработать этот риск. Постепенное внедрение в эксплуатацию – и есть мера по борьбе с этим риском. Это уменьшает критичность этого риска.

Мы обсудили первый из специальных этапов, которые завершают проект. Рассматривайте ввод в эксплуатацию именно как отдельный этап со своей последовательностью действий, иначе могут возникнуть проблемы, о которых мы говорили в начале главы.

Переходим к последней главе – к завершению проекта. Честно признаюсь, мы очень часто упускаем этот момент в виду быстрого перехода на следующие проекты. Правильно завершить проект – это значит повысить качество будущих проектов. Об этом мы и будем говорить в следующей главе.

Глава 8. Завершение проекта

Самое важное, что вам нужно сделать на этапе завершения проекта – это ретроспектива. По сути, ретроспектива – это взгляд в прошлое. Обычно, – это небольшое совещание между участниками проекта, на котором обсуждаются следующие вопросы:

Что было сделано хорошо?

Что можно улучшить?

Анализ метрик проекта.

С какими проблемами мы столкнулись и как решили?

Какие практики надо сделать постоянными?

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

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

Какие метрики можно документировать:

Оценочные часы / Фактические часы. Насколько мы отклоняемся от оценки?

% брака по задачам.

Вклад в проект исполнителей (количество часов/задач).

% выхода за сроки.

Соблюдение параметров проекта (сроки, объем, бюджет).

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

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

Для этого составляется ориентировочный план развития проекта, в котором прописываются модули и подсистемы, которые будут реализованы по мере развития проекта. Сюда может войти все, что не вошло в проект по каким-то соображениям (обычно это либо бюджет, либо сроки).

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

План развития проекта очень желательно составить документально и согласовать с клиентом. Тем самым у вас будут договоренности на будущее по развитию проекта.

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

Также немаловажной частью является получение обратной связи от клиента в плане проработки качества. Составьте небольшую анкету для клиента и задайте следующие вопросы:

Вы довольны результатом проекта?

Почему выбрали именно нас?

Что больше всего понравилось на проекте?

Что больше всего не понравилось на проекте?