Для чего нужны ежедневные отчёты?

Контекст

1.      Команда разработчиков работает над популярной видеоигрой.

2.       Предполагаемый тираж игры – свыше 10 миллионов копий.

3.       Размер команды – 100 человек.

4.       В разработке принимают участие команды из трёх стран.

5.       Разница во времени между командами достигает 12 часов.

6.       Сроки выпуска игры не сдвигаются ни на день.

7.       На проекте заняты специалисты разных – в том числе, творческих – специальностей: маркетологи, менеджеры, программисты, 3D моделлеры, аниматоры, художники, дизайнеры интерфейса и др.

Как координировать работу всех этих людей?

Цели

1.       Выпустить игру в срок.

2.       Сделать игру в заданном качестве.

3.       Уложиться в отведённый бюджет.

Порядок перечисления целей совпадает с их приоритетами. При возникновении проблем начинают жертвовать целью № 3, потому – целью № 2.

Задачи

Чтобы достигнуть перечисленных целей, необходимо решить ряд задач. Среди них есть и такие:

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

2.       Контролировать, чтобы разработчики выполняли задачи за отведённое время.

3.       Отслеживать, чтобы разработчики не придумывали себе новые задачи и не делали того, что делать не надо.

ПРИМЕР. Нередкий случай, когда программист сталкивается с кодом, написанным другим программистом, то у него возникает инстинктивное желание этот код переписать. Почему так происходит? Потому что код некорректен и содержит в себе логические ошибки? Отнюдь. Часто код написан правильно и уже оттестирован и проверен на практике (на реальных задачах). Почему же тогда он не нравится программисту? Во-первых, потому что противоречит субъективному чувству прекрасного этого программиста. Ну, и, во-вторых, потому что писать свой код гораздо приятнее, чем разбираться в чужом.

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

Решения

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

1.       Ежедневный отчёт каждого программиста.

2.       Ежедневный отчёт каждого менеджера.

Эти практики существуют десятилетия. Есть мнение, что они пошли от японской школы менеджмента. Т.е. впервые письменные отчёты стали применяться в японских корпорациях.

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

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

Ежедневный отчёт программиста

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

Ежедневный отчёт оформляется в виде e-mail со специальным заголовком (например, “Daily Report”) и посылается на специальную группу рассылки. На эту группу рассылки подписываются все программисты (в том числе, и ведущий программист), менеджер команды, ведущий программист и менеджер со стороны заказчика.

Ежедневный отчёт программиста состоит из трёх разделов.

Название раздела	Комментарии
Что плохого?(Что мешает мне выполнять мои задачи?)	Перечисление рисков, угроз, препятствий, зависимостей от художников или других разработчиков  – всего того, что мешает данному разработчику выполнять свои задачи в срок и с заданным качеством. Примеры рисков/зависимостей/препятствий: ·         Нужно подготовить экран, но художники его ещё не нарисовали. ·         ИТ-отдел вовремя не предоставил доступ к запрошенным ресурсам – документации, серверам, программному коду. ·         Экран сделан, но работает не так, как нужно, потому что коллега ещё не запрограммировал его логику. ·         После обновления игра падает, так что невозможно дойти до экрана, который нужно сделать.
Что я делал сегодня?	Перечисление номеров и названий задач, над которыми осуществляется работа в данный момент.
Что я собираюсь делать завтра?

Практика показывает, что на написание ежедневного отчёт программист тратит 5 минут своего времени. Его можно писать в конце рабочего дня или же заполнять по ходу работы. Отсылается же он в конце рабочего дня.

Ежедневный отчёт менеджера

В отличие от программиста, отвечающего за реализацию проекта, менеджер проекта отвечает за то, чтобы проект был выполнен в отведённое время, удовлетворял заданному качеству и уложился в заданный бюджет. Кроме того, менеджер отвечает за то, чтобы у программиста было всё необходимое для работы.

Ежедневный отчёт менеджера оформляется в виде e-mail и посылается на ту же группу рассылки, что и ежедневный отчёт программиста.

Ежедневный отчёт менеджера состоит из трёх разделов:

Название раздела	Комментарии
Статус проекта	Возможны три значения: ·         проект идёт, как запланировано; ·         проект находится под наблюдением; ·         проект находится под угрозой. Если менеджер ставит статус «под угрозой», это означает, что есть существенный риск для срыва проекта/запланированных сроков. Если менеджер ставит статус «под угрозой» или «под наблюдением», то он должен предложить решения той части проблем, которые зависят от команды.
Что плохого?	Перечисление рисков, угроз, препятствий, зависимостей от работ на стороне заказчика, проблем в ИТ инфраструктуре (тоже на стороне заказчика) и т.д.
Каков прогресс команды в целом?	Описание прогресса может включать burn down график - это график двух кривых. Обе кривые показывают изменение нагрузки на команду за интервал времени (например, две недели). Фактически, это скорость, с которой команда выполняет объём работы. Первая кривая является идеальной, т.е. показывает плановое изменение нагрузки. Вторая кривая – реалистичная. Она показывает реальное продвижение команды по проекту.

Рисунок. Burn down chart для команды из трёх инженеров

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

Выводы

1.       Если вы разрабатываете программный продукт вместе с другими людьми, то очень хорошо сверять то, что сделано, каждый день. В нашей компании такая сверка происходит 2 раза в день: утром и вечером. Утром – в устном виде, вечером – в письменном виде.

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

3.       Ежедневные отчёты позволяют объективно оценить результаты. Как команде, так и самому человеку. Они играют профилактическую роль, т.к. человеку полезно оставаться в сознании, понимать, каких результатов он добился в реальности (а не в виде деклараций). Некоторые люди любят завираться. Любят обманывать себя и своих коллег. Ежедневные отчёты помогают преодолеть этот порок.