Завершение проектов

В этой статье хотелось бы затронуть тему успешного и эффективного завершения проектов. Я преднамеренно не буду рассматривать случаи провала проектов из-за неправильного планирования, поскольку это отдельный вопрос. А вот проекты, которые, по мнению команды, выполнены в полном объеме и в срок, но почему-то не запущены, лично для меня представляют особый интерес. 

Проблема

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

  • Низкая степень вовлечения заказчика или пользователей в процесс разработки проекта
  • Недостаточно определённые требования
  • Недостаточная поддержка проекта топ менеджментом
  • Нереалистичные ожидания
  • Недостаточно ясные цели
  • Цель проекта перестала быть актуальной

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

Решение

Есть три ключевые вопроса, решение которых способствует успешному завершению проекта:

  • Общение между командой и клиентом
  • Тестирование на протяжении всего проекта
  • Четко определенные, ожидаемые клиентом результаты в самом начале проекта, а также его пожелания к работе ПО (критерии качества)

Общение между командой и клиентом

  • Перед тем, как приступить к работе над проектом, вам совместно с заказчиком необходимо определить первоначальные принципы, средства и методы коммуникации и обязательно зафиксировать их в документе, а лучше всего продублируйте содержание этой договоренности по электронной почте. Нужно стремиться к тому, чтобы общение было эффективным и регулярным. Установите, например, ограничения по времени при ответе по email в один день, а в средстве мгновенного обмена сообщениями 1-2 часа. Но самое главное, если есть возможность общайтесь в живую — назначайте личные встречи, в крайнем случае видео звонки. Это позволит уменьшить недопонимание и решить любые вопросы более эффективно. После того, как вы оговорили формат и способы коммуникации обязательно следите за их исполнением, а так же анализируйте эффективно ли они работают, если нет — опросите заказчика и членов команды и найдите более удачное решение. И, опять же, если произошли какие-то изменения вы должны их зафиксировать точно также, как и первые.
  • Второй очень важный момент, вам необходимо разобраться и утвердить, кто будет отвечать за приемку проекта на стороне заказчика. Это обязательно должно быть задокументировано, что возникающие вопросы по ходу проекта нужно решать с определенными людьми на стороне заказчика, другие же не имеют права голоса. Это важно сделать, чтобы избежать недоразумений в конце проекта, когда сказать что за сдачу проекта отвечает Вася, а вы Васю видите в первый раз и у Васи свое видение проекта, если оно не совпадает с тем, что уже реализовано у вас могут быть проблемы. Здесь же я хотел порекомендовать, причем в качестве правила, любые обсуждение и решения вопросов в устной форме фиксировать по email. Так, вам будет к чему опелировать при возникновении разногласий.
  • В третьих, вы должны, нет обязаны, регулярно, не реже чем раз в 2 дня, общаться с заказчиком — рассказывать ему о статусе, показывать рабочую программу, узнавать его мнение о выполненной работе, проверять и культивировать его заинтересованность в проекте, если она вдруг пропадает.

Тестирование на протяжении всего проекта

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

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

В этом вам помогут гибкие методологии разработки ПО, которые как раз проповедуют короткие итерации и быструю обратную связь.

Четко определенные, ожидаемые клиентом результаты в самом начале проекта + критерии качества

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

  1. Определение потребности заказчика и потребителя
  2. Критерии заказчика по приему продукта
  3. Требования заказчика
  4. Масштаб и границы проекта

Определение потребности заказчика

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

  • Как эта проблема влияет на бизнес?
  • Из-за чего, по вашему мнению, она возникла?
  • Исчезнет ли эта проблема, если мы реализуем предложенное вами решение?

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

Критерии заказчика по приему продукта

Это критерии, с помощью которых клиент оценивает, насколько удовлетворительны результаты проекта. Единственный и лучший способ выяснит их — это диалог с заказчиком, в котором попросите его представить, что вы сдаете ему готовый продукт и он начинает им пользоваться. Потом попросите заказчика назвать 3-4 основные рабочие характеристики продукта, которые сделали бы его полезным заказчику. Эти характеристики обязательно должны быть измеримыми. Например, «Процесс выполнения заказов должен быть хорошо налажен» — это неизмеримая характеристика, которая может доставить вам в будущем много проблем. А вот ее уточнение звучит уже более убедительно и будет работать: «Заказ должен быть собран и упакован менее чем за 60 минут».

Масштаб и границы проекта

Масштаб — это описание конечного продукта, способ обмена информацией, гарантирующий, что вы произведете именно то, что необходимо заказчику проекта. Его цель — точно определить результат, который будет получен по завершению проекта.
Охарактеризовав конечный продукт, вы должны уточнить, что входит в проект, а что нет, т.е. задать границы проекта. Это важно сделать насколько возможно подробно, чтобы дать понять заказчику за что вы беретесь, а что не входит в рамки проекта. Так же определение границ проекта может помочь увидеть на стыке с какими проектами находится ваш и наладить взаимодействие с другими командами если понадобится.

Критерии качества

Кроме функциональных требований и определения потребностей и проблем заказчика, необходимо проработать и утвердить нефункциональные требования, от которых зависит качество проекта. Рекомендуется составить отдельный документ или выделить отдельный пункт такой как «Лист качества«, в котором будут описываться эти требования.
Нефункциональные требования обычно разделяют на требования, имеющие значения при выполнении программы, Runtime, и требования, относящиеся к аспектам проектирования программы Designtime.

Runtime

Availability — требования ко времени непрерывной работы.

Reliability — поведение приложения при наступлении нештатных ситуаций.

Durability — требования к долговременному хранению результатов работы.

Scalability — требования к масштабированию.

Usability — требования к удобству использования.

Security — требования к безопасности.

Configurability — требования к конфигурируемости работы.

Performance — требования к производительности.

Restrictions — описание ограничений.

Designtime

Reusability — требования к повторному использованию реализации или компонентов.

Extensibility — требования к расширяемости.

Portability — требования к портируемости.

Interoperability — требования к взаимодействию между компонентами.

Supportability — требования к различным аспектам поддержки приложения.

Modularity — требования к разделению приложения на модули.

Testability — требования к возможности автоматического и ручного тестирования.

Localizability — требования к возможности и простоте локализации.

Compatibility — особые требования к совместимости между версиями.

Выводы

Есть три способа, которые способствуют развитию вас как менеджера:

  • Обучение на своих ошибках :-)
  • Зачастую не менее эффективный способ — обучение на ошибках других.
  • Обучение на успешных решениях других.

Если в вашей организации будет заполняться итоговый отчет по каждому проекту, все три способа будут работать, а менеджеры будут расти в профессиональном плане как на дрожжах. Ниже примерная структура отчета.

Итоговый отчет

  1. Цели проекта (цель проекта, критерий достижения, информация о выполнении критерия)
  2. Результаты проекта (результат, дата план, дата факт, причины отклонений)
  3. Бюджет проекта (название статьи, план, факт, причины отклонений)
  4. Усвоенные уроки и опыт (Какой положительный опыт вы бы хотели передать другим руководителям проектов? Какие ошибки были допущены в проекте? Привлекались ли к работе outsourcing (насколько эффективна работа с ними)? Ваше предложение по системе управления проектами)
  5. Чек-лист (параметр проверки, отметка, примечание)
  6. Ответы на вопросы.

Вопросы для оценки этапа завершения проекта

  1. Получили ли вы искренние ответы от вашего заказчика, членов команды и других участников проекта о произведенных продуктах и о работе над проектом в целом?
  2. Полностью ли закончен итоговый отчет о результатах проекта?
  3. Все ли члены команды дали свою оценку проекта?
  4. Обсудили ли вы выводы, сделанные во время работы над проектом, и составили ли их окончательный список?
  5. Пришла ли команда к единому мнению относительно рекомендаций по улучшению работы в будущем?
  6. Поблагодарил ли лидер проекта членов команды за вклад в работу?
  7. Отпраздновала ли команда свой успех?

И напоследок повторюсь. Есть три ключевые вопроса, которые способствуют успешному завершению проекта:

  • Общение между командой и клиентом
  • Тестирование на протяжении всего проекта
  • Четко определенные, ожидаемые клиентом результаты и критерии качества в самом начале проекта