Пара слов о дневнике проекта

Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.

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

Как не наступать на грабли менеджеру проекта? Вопрос, на самом деле, не очевиден. Понятно, что от этого нет универсального лекарства. Первый и самый простой вариант — «это придёт с опытом». Именно поэтому, опыт — это очень ценный ресурс, потерю которого нужно минимизировать. Один из таких способов максимально сохранить опыт от прошедших проектов я активно применяю и сейчас вам его опишу. Называется он – дневник проекта.

Что я понимаю под «дневником проекта»

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

·         Дал Васе задачу по аналитике. Надеюсь, что справится хорошо. В этом случае смогу сосредоточиться на управлении и взаимодействии с заказчиком, а аналитику частично делегировать ему

·         Отправил Васю в неплановый отпуск на 2 недели. Решение принял спонтанно, глядя на его измученный вид. Это немного задержит проект, но повысит работоспособность Васи

·         Приложение одобрено Apple, но отозвано по инициативе заказчика из-за ошибок в разделе X. Ошибки были найдены на нашими QA в процессе тестирования, но мной было принято решение, не считать их критичными и выпустить приложение (примечание автора: да, мне стыдно про это вспоминать, но факт имел место)

·         Произвели впечатление на заказчиков и получили бонус

В общем, видно, что большинство записей – описание моих решений с комментариями по поводу их эффективности. И видно, что большинство решений – ошибочные. 

Структура записей

Каждая запись состоит из четырёх колонок: дата, описание, категория и выводы. 

• Описание – это развёрнутый текст, где в нескольких предложениях описан факт, возникший в течение проекта. Примеры описаний приведены в предыдущем разделе.
• Категория – простейшая классификация событий. У меня их, собственно, три: win, fail и "???". Очевидно, что первая говорит, что решение или фактор был удачным, вторая – показывает, что мы сильно «пролетели» из-за данного решения, а в случае с третьей категорией – я ещё не определился, считать ли данное событие успешным. Ещё иногда встречается категория draw (событие никак не повлияло на проект), но он появляется крайне редко.
  
  Бывает, что запись из одной категории кочует в другую. Например, запись «Дал добро на рефакторинг секции X. Будем смотреть, окупятся ли те 40 часов, которые он должен занять» кочевала из категории fail, когда рефакторинг затянулся на две недели, в категорию win, когда в результате получили чистую и аккуратную версию, которую тут же успешно сдали заказчику, сэкономив кучу времени на багфиксах в изначально «пластилиновой» реализации.
  
  Или, ещё нагляднее: «Продолжаю задерживать команду допоздна в дни деплоев» сначала имело категорию win, т.к. мы уложились в короткие сроки и получили значительный бонус от заказчиков (естественно, команда была довольна высокой премией). Непосредственно после этого один из ключевых разработчиков начал откровенно «проскальзывать» на пустом месте, и стало очевидно, что он «перегорел». Пришлось отправить его в отпуск, и проект затянулся гораздо сильнее, чем мог бы, если бы мы работали «ровно» всё время. В результате, факт задержки команды по ночам перекочевал из win в fail.
• Выводы – на мой взгляд, наиболее важная колонка. Здесь я максимально полно пытаюсь описать, какие результаты повлекло данное событие, и какие выводы из этого мне надо сделать. Это, конечно же, самое трудное.
  
  Вообще, выводы могут быть самыми простыми и очевидными, например «Необходимо хранить документы в системе контроля версий»
  
  Примечание автора: эта запись появилась после того, как я нечаянно перезаписал файл с оценками на итерацию и вынужден был полдня их восстанавливать.С другой стороны, вывод может занимать много строк, как, например: «На этапе анализа необходимо требовать примеры того, как должен выглядеть результат. Это стимулирует заказчика продумать, что он хочет получить. То же самое для изменений: видимо, нельзя начинать работу до тех пор, пока не будет одобрен интерфейс. Не имеет смысл полагаться на текстовые описания (особенно, плохие) – всегда нужна картинка»
  
  Примечание автора: речь идёт о недостаточно проработанном текстовом ТЗ на изменение части системы, которое мы в спешке приняли, поверив, что заказчик знает, как лучше. Потом, после реализации первой версии, оказалось, что заказчик хотел совсем другое, но не написал это. Пришлось разводить долгую (и, слава Богу, успешную) дипломатию с заказчиком с убеждением его в том что он, на самом деле, хочет совсем другое, а не то, что написал.

Заключение

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

P.S. Хочу заострить внимание, что примеры могут являться вымышленными, а совпадения – случайны