Читать «Управление проектом разработки сайта или веб-приложения. От идеи до внедрения» онлайн - страница 25
Руслан Раянов
Мы обсудили первый из специальных этапов, которые завершают проект. Рассматривайте ввод в эксплуатацию именно как отдельный этап со своей последовательностью действий, иначе могут возникнуть проблемы, о которых мы говорили в начале главы.
Переходим к последней главе – к завершению проекта. Честно признаюсь, мы очень часто упускаем этот момент в виду быстрого перехода на следующие проекты. Правильно завершить проект – это значит повысить качество будущих проектов. Об этом мы и будем говорить в следующей главе.
Глава 8. Завершение проекта
Самое важное, что вам нужно сделать на этапе завершения проекта – это ретроспектива. По сути, ретроспектива – это взгляд в прошлое. Обычно, – это небольшое совещание между участниками проекта, на котором обсуждаются следующие вопросы:
Что было сделано хорошо?
Что можно улучшить?
Анализ метрик проекта.
С какими проблемами мы столкнулись и как решили?
Какие практики надо сделать постоянными?
Получение обратной связи для каждого члена команды в плане участия в проекте.
Результаты подобного совещания лучше документировать для последующей оптимизации ведения проектов. Ретроспектива вам помогает расти как команде и повышает общую культуру ведения проекта и понимание этого вопроса всей команды, а не только менеджера.
Какие метрики можно документировать:
Оценочные часы / Фактические часы. Насколько мы отклоняемся от оценки?
% брака по задачам.
Вклад в проект исполнителей (количество часов/задач).
% выхода за сроки.
Соблюдение параметров проекта (сроки, объем, бюджет).
Следующий момент – это освобождение ресурсов, связанных с проектом. В первую очередь, – это разработчики. Обычно они перекидываются на другой проект, поэтому, чем быстрее вы это сделаете, тем лучше будет для других проектов. Также вы освобождаете тестовую площадку – сайт, базу, пул в IIS, чтобы не расходовать ресурсы тестового сервера. При этом обязательно уведомите всех участников проекта об этом, чтобы не было недопонимания. Например, заказчик будет и дальше взаимодействовать с разработчиком, который уже перешел на другой проект.
Очень важной частью завершающего этапа является определение режима поддержки проекта после ввода в эксплуатацию. Очень мало проектов, которые один раз разработали, и они так и работает в неизменном виде. Уже по ходу проекта возникают новые идеи, как можно улучшить проект. В период эксплуатации системы реальными пользователями таких идей будет гораздо больше. Поэтому необходимо выделить некоторые ресурсы на развитие проекта. В первую очередь надо определиться с программистами, которые будут ответственны за сопровождение проекта. Также надо иметь договоренности с клиентом о режиме, в котором будет проходить поддержка. Очень часто бывает так, что проект закончили, программист переходит на новый проект, и не хватает временных ресурсов на доработку существующего проекта. Необходимо сразу предвидеть, какой объем доработок будет у проекта в период эксплуатации.
Для этого составляется ориентировочный план развития проекта, в котором прописываются модули и подсистемы, которые будут реализованы по мере развития проекта. Сюда может войти все, что не вошло в проект по каким-то соображениям (обычно это либо бюджет, либо сроки).