Зачем и как подводить итоги проекта в заказной разработке: наш опыт и советы

Hola, Amigos! С вами команда по заказной разработке Amiga и руководитель проектного офиса Маша Воробьева.

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

Давайте начнем с простых фактов:

Но что происходит в реальности, и в чем тут проблема?

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

Как правило, заказчик приходит за сайтом и/или приложением, которые выполняют задачи бизнеса. Значит, есть бизнес, в котором задействованы люди, процессы, задачи. Мы как компания-разработчик не видим этого в полном объеме. Кроме сайта/приложения заказчик тратит много времени на управление производством и товарооборотом, поиском инвесторов и специалистов, планирует рекламу, акции, SMM, инстор, наружку, что угодно еще.

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

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

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

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

А очень хорошие руководители находят несколько часов, чтобы проанализировать завершенный проект и подвести итоги.

Очень хороший РП для меня – не значит самый опытный. Это концептуальное явление. Джун, который провел такую работу, уже очень хороший РП, просто он маленький:) Пока что может вести несложные проекты.

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

РП собирает всю информацию, отсматривает ее с РПО, а дальше назначается встреча, на которой РП показывает презентацию. На встречу мы зовем участников команды (для их развития, а также для их минуты славы), других РП, тимлидов и руководителей направлений (для обмена опыта). Было бы здорово звать вообще всех, но это уже слишком дорогая встреча, хоть нас и не 100, а пока 60+ человек.

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

Для подготовки материалов у нас есть специальная напоминалка для руководителей проекта, делимся ей с вами.

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

Это работа РП. Если он как минимум хороший РП, большая часть информации у него давно есть, просто надо собрать все вместе:

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

Важные моменты

1. Не все обнаруженные факты могут быть приятны. Превращайте их из «все ужасно» в форму «в следующий раз нам нужно поступить иначе».

2. Не любой вывод нужно озвучивать при всех. Редко, но случается , что кто-то из сотрудников крайне плохо себя показал и будет уволен. Или клиент чем-то резко недоволен.

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

Кроме с трудом находящегося времени и стоимости часа каждого пришедшего на встречу сотрудника, остальное – плюсы для всех.

Вывод

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

Резюмируем общий алгоритм:

Расскажите, а вы подводите итоги? Как находите на это время? Может, нам стоит что-то добавить в анализ завершенного проекта?