Умная среда — блог про совместную работу и коммуникации

Зачем проекту дневник

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

Дневник хорош для того, чтобы:

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

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

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

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

Что надо вносить в дневник:

Где дневник вести:

  • в блокноте, если команда проекта — только вы сами
  • во внутреннем блоге, который виден только команде, например, клубе в Яру или комнате во Friendfeed‘е
  • в вики, если есть вики, и не хочется заводить дополнительный инструмент.

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

Поделитесь ссылкой с друзьями:

  • http://urbansheep.ru urbansheep

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

    По моему опыту вышло, что самыми лучшими дневниками являются три вещи:
    1) Митинг-репорты — после регулярных плановых встреч, о них пишет один из участников, который вел лог решений/выводов, а остальные его поправляют, и после проектных встреч, когда решаются отдельные вопросы, об этом пишет созывавший встречу, в том числе и для того, чтобы раздать задачи/фиксировать ответственность и договорённости.

    2) Чейнджлоги или заметки к релизам — они составляются на две трети из списка фич/фиксов, вытащенного из баг/реквест-трекера. Оставшаяся треть пишется проджектом, продактом, тимлидом или сисархом, если нужно отдельно что-то дополнить/поправить/отметить.

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

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

    Откуда годовой цикл? Потому что обычно за 12-18 месяцев в веб-проекте накапливается критическое число изменений для того, чтобы выпускать новый большой релиз (т.е. проект качественно меняется), или делать апгрейд исходного ТЗ. Правда, ни одного случая, когда бы это исходное ТЗ обновлялось (а это один из основных источников знания для тех, кто приходит в проект, и не имеет доступа прямо ко всему коду), я лично не знаю. Но может где-то бывает. Чаще делают всю документацию заново, с учётом новой реальности.