?

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

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

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

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

  • 1