?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Заметки на бегу: усвоенные уроки проекта
psilonsk


В управлении проектами есть чрезвычайно важная и полезная практика - анализ завершенного проекта (по-английски это называется Lessons Learned). Необходимость этой практики так очевидна, что и говорить об этом неловко: она существует для того, чтобы в следующем проекте не сделать ошибок, которые сделали в этом.

Все происходит так:
=> Команда собирается и анализирует проект (очевидно, что анализ можно сделать пока проект не закрыт, - ведь после этого команду не соберешь).
=> Во время этой сессии команда старается ответить на три вопроса:
1) Что нужно точно перестать делать в проекте? (какая практика должна быть изжита)
2) Что нужно начать делать в проекте? (какой практики не хватает, чтобы стать лучше)
3) Что нужно продолжить делать в проекте? (какая практика хорошо себя зарекомендовала и должна быть использована)
=> По результатам сессии ответы на эти три вопроса фиксируются в виде документа "Усвоенные уроки".
=> Обновляется корпоративный репозиторий рисков - с тем, чтобы другие команды и другие проекты не наступили на те же грабли.

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

Существует ли практика проведения подобных сессий для завершающихся проектов в вашей компании? Доступны ли документы "Усвоенные уроки" для всех сотрудников? Пополняется ли корпоративный репозиторий проектных рисков по результатам таких сессий?




promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
У нас - да. Только мы это называем project debrief.

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

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

2. Решение, которое было принято для разрешения проблемы.

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

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

Edited at 2015-08-24 05:25 pm (UTC)

Спасибо, Алекс!
Многие позавидовать могут, как у вас там все грамотно сделано.

А что из себя представляет "мотивация решения"?

Например, был у нас как-то проект по автоматической конвертации нескольких тысяч страниц технической документации в XML.

Часть контента не совсем правильно сконвертировалась и требовала чистки. Можно было написать скрипт, который бы сделал бы эту чистку автоматически, а можно было почистить руками. Плюс скрипта был в том, что он бы все почистил за несколько секунд, минус - результат был бы не вполне точный. При ручной чистке, точность была бы достигнута, но это бы потребовало многих часов кропотливой ручной работы.

В данном конкретном случае, супер-точность нам не требовалась по ряду причин. Поэтому мы решили сделать скрипт.

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

  • 1