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

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

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

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

• Заказчиков мало интересует наша внутренняя кухня – им важен результат. В большинстве случае они не оплачивают разборы и обсуждения, особенно если проект уже завершен. На подобные занятия нужно находить ресурсы самостоятельно.
• Руководителям проектов тоже важен результат. Часто сроки поджимают, и приходится экономить время. А если РП отвечает за рентабельность своих проектов и команды, он старается не тратить лишние часы еще и потому, что каждый час стоит денег.
• И вот наконец результат появляется. Если все получилось удачно (читаем: в заданный срок, с соответствии с бюджетом и с заданными задачами), то и клиент, и команда счастливы. Но если что-то идет не так, то чем хуже ситуация, тем больше всем хочется поскорее ее наладить: усталость команды растет, раздражение заказчика копится, нет времени обсуждать, надо скорее все исправить, наконец-то доделали, ура, распрощались или перешли к следующему проекту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Финансовая отчетность есть в инструментах финансового управления (в нашем случае это огромные гугл-таблички, довольно легко фильтруемые по проектам, датам, видам работ и статусам).

• Трек времени команды есть в таск-трекере (мы понимаем, что он может быть точным не на 100%, но это погрешность, с которой можно мириться).

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

• Настроение и степень удовлетворенности заказчика: время от времени с заказчиком общается РПО (руководитель проектного офиса) или даже сам директор, уточняет, что нравится, что не нравится в работе с нами.

• Все о команде, процессах, ошибках, достижениях и точках роста: обсуждается совместно с полным составом команды на ретро. Ретро проводим не только в ходе проекта, но и после завершения. Информация с последнего ретро становится материалом для подведения итогов. Иногда ретро проводится с клиентом, иногда без, тут мы допускаем разные варианты.

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

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

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

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

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

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

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

• РП, тимлиды и руководители направлений: калибруют свой навык оценки задач и составления смет.

• Команда проекта: мотивируется, получает признание и внимание, отдыхает полчасика в процессе презентации, ощущает завершенность и более обдуманно подходит к новым задачам.

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

• Заказчик: если продолжает с нами работать, заметит со временем, что вместо энтропии и усталости на проекте нарастает порядок и предсказуемость.

Вывод

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

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

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

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