Комментарии 16
Думаю, что полезная практика, главное тут — не забрасывать в долгий ящик перечитывание дневника, т.к. человеку свойственно подсознательно не очень приятные вещи откладывать на потом.
Возможно, стоит по окончании проекта делать общий мини-сбор команды с «разбором полетов» и работой над ошибками.
Возможно, стоит по окончании проекта делать общий мини-сбор команды с «разбором полетов» и работой над ошибками.
Использую 4 «днивника»:
— История разработки, чтобы правильно оценивать скорость и направление разработки;
— Найденные и неисправленные баги, чтобы исправить позже;
— Исправленные баги, чтобы не наступать на грабли дважды;
— Новые идеи для проекта, чтобы часть воплотить в будущем.
— История разработки, чтобы правильно оценивать скорость и направление разработки;
— Найденные и неисправленные баги, чтобы исправить позже;
— Исправленные баги, чтобы не наступать на грабли дважды;
— Новые идеи для проекта, чтобы часть воплотить в будущем.
НЛО прилетело и опубликовало эту надпись здесь
Тут самое главное — простота и лёгкость работы. На каждый факт надо одну минуту, чтобы заполнить описание и категорию, ну и минут пять подумать над выводами. Их, кстати, сразу можно скрупулёзно не заполнять — только самые общие мысли, а детализировать со временем, при перечитывании.
Представьте ситуацию: ПМу нужно решить текущие Васины проблемы, пообщаться с заказчиком по поводу новых фич, ответив на десяток писем, составить отчёт руководству. Боюсь, что если fish-bone здесь накрутить и заставить руководителя проводить причинно-следственный анализ, инструмент будет слишком сложен для работы и, по закону Дарвина, вымрет как не приоритетный.
Впрочем, как вариант для одноразового глубокого анализа (например, при подведении итогов проекта), очень даже хорошая идея. Т.е. после окончания проекта брать дневник и организовать его в диаграмму Исикавы.
Представьте ситуацию: ПМу нужно решить текущие Васины проблемы, пообщаться с заказчиком по поводу новых фич, ответив на десяток писем, составить отчёт руководству. Боюсь, что если fish-bone здесь накрутить и заставить руководителя проводить причинно-следственный анализ, инструмент будет слишком сложен для работы и, по закону Дарвина, вымрет как не приоритетный.
Впрочем, как вариант для одноразового глубокого анализа (например, при подведении итогов проекта), очень даже хорошая идея. Т.е. после окончания проекта брать дневник и организовать его в диаграмму Исикавы.
НЛО прилетело и опубликовало эту надпись здесь
Интересная идея, эдакая «незабывайка» важных опытов.
А может еще завести бумажный дневник? И по вечерам с мечтательным лицом, туда вписывать что произошло за день. И так однажды твоя подруга случайно увидит у тебя на полке «дневник», заинтригуется и тайком попытается почитать. А не тут-то было! Там будут сложные и не понятные слова, куски кода и графики >:)
>Вообще, к каждой записи я добавляю три колонки: дата, описание, категория и выводы.
Вообще это четыре колонки :)
Вообще это четыре колонки :)
Вы переизобрели ретроспективы ?) Только в ажайле они на итерацию, а у вас — на проект.
Не соглашусь. В статье речь идёт не о ретроспективах.
Дневник проекта — это средство. Оно, конечно, позволяет кроме того значительно улучшить качество ретроспективы в понимании Agile и ничего не забыть. Но командное обсуждение событий итерации, в принципе, может вестись без дневника (сложно, конечно). Соответственно, и дневник может не предполагать командное обсуждение. Да и вообще — есть вещи, например связанные с конкретными разработчиками, мотивацией, повышением зарплаты и т.д., которые на митинге обсуждать просто нельзя.
Дневник проекта — это средство. Оно, конечно, позволяет кроме того значительно улучшить качество ретроспективы в понимании Agile и ничего не забыть. Но командное обсуждение событий итерации, в принципе, может вестись без дневника (сложно, конечно). Соответственно, и дневник может не предполагать командное обсуждение. Да и вообще — есть вещи, например связанные с конкретными разработчиками, мотивацией, повышением зарплаты и т.д., которые на митинге обсуждать просто нельзя.
Идея хорошая, спм использую дневник, но для багов.
Есть какие нибудь программные решения таких дневников?
Если нет то вот идея для стартапа, или вообще целый сервис сделать, типо «Поделись опытом»
Помоему интересно...)
Есть какие нибудь программные решения таких дневников?
Если нет то вот идея для стартапа, или вообще целый сервис сделать, типо «Поделись опытом»
Помоему интересно...)
Ваш дневник получился один в один как коммиты ПМа в СКВ проекта.
Тоже веду подобный дневник, но сразу по нескольким проектам в одной гугл-таблице (чтобы делиться ссылкой при необходимости)
По горизонтали — рабочие недели с датой начала и окончания, по вертикали — проекты со списком этапов по каждому проекту (ТЗ, дизайн, программинг и т.п.). В ячейки я вписываю планы на будущее по задачам, а когда подходит время задачи, пишу что было сделано по ней с небольшим комментарием или выводом. В итоге получается такой инструмент планирования и последующего анализа.
Да, еще использую заливку ячеек цветом: зеленый — задача выполнена в срок, жёлтый — задача в процессе работы или выполнена с косяками, красный — всё было плохо или задача сверхважная. Ещё есть просто незакрашенные ячейки — чаще всего не определился с типом, либо всё неоднозначно.
По горизонтали — рабочие недели с датой начала и окончания, по вертикали — проекты со списком этапов по каждому проекту (ТЗ, дизайн, программинг и т.п.). В ячейки я вписываю планы на будущее по задачам, а когда подходит время задачи, пишу что было сделано по ней с небольшим комментарием или выводом. В итоге получается такой инструмент планирования и последующего анализа.
Да, еще использую заливку ячеек цветом: зеленый — задача выполнена в срок, жёлтый — задача в процессе работы или выполнена с косяками, красный — всё было плохо или задача сверхважная. Ещё есть просто незакрашенные ячейки — чаще всего не определился с типом, либо всё неоднозначно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пара слов о дневнике проекта