В нашем центре разработки существует обязательная практика написания Project Management Plan'а (PMP) для каждого проекта. Под РМР у нас понимают документ объемом около 20-30 страниц следующего содержания:
- Scope проекта (milestones, deliverables, assumptions, constraints и т.д.)
- организационные диаграммы: внутренняя + интерфейсы на стороне заказчика
- планы по управлению рисками, требованиями, изменениями, схема эскалации проблем
- методики оценки проекта, планы верификации и тестирования, процедуры приемки задач и пр.
- план-график проекта
- цели качества и контролирующие их метрики
- план обучения персонала
- и т.д.
От каждого (условно) project manager'а в обязательном порядке требуется:
- составить такой документ (с учетом проектных задач, которые никто не снимает - 2-3 недели)
- провести ревью внутри команды с привлечением инженера по качеству, учесть замечания (если в команде человек 10-15 - 1 неделя)
- провести еще одно ревью с участием руководителя группы качества и сайт-менеджера и утвердить РМР на нашей стороне (с учетом занятости таковых - 2 недели)
- утвердить документ с ПМ'ом на стороне заказчика (с учетом занятости такового - 2 недели)
В общем итоге, составление и утверждение РМР занимает около 2 месяцев. За это время, разумеется:
- изменяется scope проекта, появляются новые задания и активности
- изменяется состав команды (кто-то приходит, кто-то, возможно, уходит)
- сдвигается план-график
- уточняются цели качества, изменяется набор метрик
- люди обучаются, план обучения также эволюционирует.
Все эти изменения требуют обязательного переутверждения РМР с проведением внутрикомандного ревью, что занимает около 6 недель. Таким образом, имеем:
- постоянно отстающий от реальности РМР
- постоянный цейтнот в связи с необходимостью его переутверждения (многие на это забивают, получая в результате другие проблемы: либо необходимость обманывать группу качества, декларируя соответствие реальности фактические устаревшего РМР, либо необходимость отбиваться от руководства, требующего переутверждения РМР).
Пути решения могут быть, например, такими:
- упрощение процедуры переутверждения РМР
- упрощение содержания РМР
- отказ от РМР.
Ага?
Подписаться на:
Комментарии к сообщению
(
Atom
)
Сообщения
"Пути решения могут быть, например, такими:"...
... Как переход к более "легковесным" процессам управления, использование agile практик. Например, SCRUM. Будет больше толку и меньше бюрократии.
Водопадная модель явно не подходит для современных проектов с постоянно меняющимися требованиями. Либо, если уж на то пошло и клиент настаивает на использовании текущего процесса, то одним из пунктов плана проекта в обязательном порядке должно фигурировать "Requirements and spec freeze".
Анонимный
4 февраля 2011 г. в 03:11Артем, как мне кажется, здесь проблема не в процессной модели разработки. У нас никто не настаивает на водопаде - можно использовать гибкие методологии, итеративные подходы и пр. Дело в другом. К примеру, завтра я решаю перевести проект на тот же SCRUM. Первое, что я должен сделать - обновить РМР, расписав в нем то, как мы будем реализовывать все практики SCRUM. Очень может быть, что в таком РМР больше не будет фигурировать план-график, однако даже в самых гибких процессах наличествуют проектная команда, метрики, стейкхолдеры, да тот же scope. Поэтому, спустя неделю после того, как я закончу его переделывать, понадобится снова провести командное ревью, утвердить документ внутри компании и у ПМ-а со стороны заказчика, на что уйдет еще месяц. А спустя этот месяц обязательно появится какая-то новая метрика, которую нужно собирать, под нее - quality goal, в общем - "все опять повторится сначала".
Пока писал, придумал такое описание проблемы: от нас не требуют водопадный процесс разработки, но при этом требуют водопадный Document Approval and Control.
Sergey Borodavkin
6 февраля 2011 г. в 15:22Сережа, я несколько раз перечитывал твой ответ и пытался осмыслить все это в контексте решения проблемы. И я вижу несколько несостыковок. Во-первых, "Пока писал, придумал такое описание проблемы: от нас не требуют водопадный процесс разработки, но при этом требуют водопадный Document Approval and Control."
Но ведь и Document Approval and Control являются частью разработки, не так ли? А является ли этот этап жизненно-необходимым для выпуска качественного продукта? Или же его создание отнимает время у тебя, команды (пересчитываем в $), вынуждает лгать о реально положении дел (которые не стоят на месте и постоянно изменяются и зависят от сотни факторов), усложняют и без того уже сложный процесс создания продукта. На мой взгляд, все это пахнет бюррократией и самообманом. Кстати, такое часто случается, когда штат компании слишком раздут и высокие начальники создают видимость работы и своей нужности (не подумай, что камень в твой огород - напротив).
И вот прямо в конце поста ты сделал правильный вывод, который и я предложил, просто более завуалированно - переход к более гибким agile процессам, в которых по определению отсутствует такая волокита - на нее попросту нет ресурсов в рамках спринтов: "- отказ от РМР.". Просто если ты заявишь заказчику: "А давайте откажемся от PMP", тебя могут неправильно понять. А предложив усовершенствовать процесс разработки, при этом не акцентируя внимания на отказе от всякой требухи, больше шансов. :)
P.S. Я не сторонник ни Scrum, ни XP, ни RUP, ни . Я сторонник здравого смысла и простоты.
Анонимный
15 февраля 2011 г. в 15:47Документ апрувал и контроль (managerial или скорее supporting process) не является частью разработки (engineering process). Можно ли от него отказаться? В маленьких организациях/проектах - да, в больших - нет. Скорее, можно думать над тем, как бы оптимизировать эту унылую цепь, тянущуюся от создания до утверждения документа.
Sergey Borodavkin
20 февраля 2011 г. в 10:00