Персональная методология проекта

Задаетесь ли вы иногда вопросом, а ту ли методологию я, как руководитель, выбрал для своего проекта? Верной ли дорогой веду проект к успеху?

Насчет успеха — есть очень интересный отчет «Chaos Report» (пока за 2013й год) от известнейшей группы Standish Group о состоянии дел в управлении проектами со списком факторов, приводящих к успеху выполнения проекта и подробным анализом таких факторов с разных сторон и под разными углами. Рекомендую глубоко изучить его на досуге, запланировав для этого как минимум несколько часов в спокойной обстановке. Также ребята из Стратоплана регулярно проводят опрос «Какая методология используется в вашем проекте» и получают очень веселые и показательные результаты. Реальность же такова, что у меня за почти 10 лет управления проектами ни разу не получалось использовать какую-либо методологию в ее каноническом, книжном, классическом виде. Подозреваю, что у вас дела обстоят похожим образом. Всегда есть какие-то обстоятельства, которые заставляют нас из, к примеру, Scrum’а конструировать зверька под названием ScrumBut (Скрам, Но). Про более тяжелые методологии речь даже не идет. Водопад в чистом виде в software development — вообще довольно большая редкость. Периодически встречаю, что на словах он задекларирован, а в реальности по результатам аудита там что угодно, но не водопад.

Расскажу вам одну историю. Руководил я одной программой проектов (группа проектов), где в контракте было указано, что мы работаем с заказчиком по Fixed Price и у нас водопад. Нюанс был в том, что водопад был на каждый релиз, который в свою очередь длился примерно 4-6 месяцев. Такие себе небольшие водопадики, длиной до полугода. Жестокая реальность показала, что если fixed price в такой схеме еще можно сделать прибыльным, то водопад — совсем никак не приживается. Система была настолько сложная, старая, большая, связанная с еще порядка 30 другими системами, ответственная и часто используемая бизнес пользователями заказчика, что изменения приходили пачками каждую неделю. Мы никак не могли заморозить рамки проекта (scope) на срок даже в 1 месяц, не говоря уже про период в 6 месяцев. С другой стороны, более гибкая методология здесь тоже не подходила. Ответственность за корректную и стабильную работу системы настолько высока, а объем кода и модулей внутри системы настолько велик, что никак нельзя обходиться минимумом документации и хаотичной разработкой — дальнейшая поддержка всего этого хозяйства очень скоро стала бы невозможной (почти так и было, когда я пришел в эту программу).

Что же делать? Как управлять проектами, где из-за высокой сложности, объема, ответственности системы перед заказчиком и величины возможных последствий из-за простоя/поломки, требуется водопад (minimum agility), а из-за частых изменений бизнеса у заказчика требуется что-то вроде scrum’а (maximum agility)? И я нашел решение!

 

Выбор персональной методологии для каждого проекта

Внимательно покрутив большинство методологий (от less agile до more agile) я пришел к выводу, что в любой методологии применяются абсолютно все области знаний управления проектами. Областями знаний я называю следующие пункты списка (не исключено, что список не полный, но это не меняет сути статьи):

  • Change Management
  • Communication Management
  • Requirement Management
  • Configuration Management
  • Risk Management
  • Project Initiation
  • Project Planning
  • Project Execution
  • Project Monitoring and Control
  • Project Closure
  • Product Design
  • Product Implementation
  • Product Documenting
  • Product Integration
  • Product Releasing
  • Product Review
  • Product Testing

Все они в том или ином виде (это важно) присутствуют в любом проекте software development. Отличия только в их условном «весе». В объеме и качестве присутствия, которые я называю «весом области знания». Таким образом, мы смело можем говорить, что в абсолютно любом проекте у нас применяются все области знаний управления проектом и продуктом. Отличия только в их «весе».

Вводим «веса» или грейды — от Grade1 до Grade4, где Grade4 — самый «тяжелый» грейд. Таким образом мы понимаем, что 4й грейд — это методологии типа Waterfall и RUP, а 1й грейд — это Scrum, XP, Kanban методологии. Магия начинается, когда мы пытаемся описать середину — грейды 2 и 3. Конечно, может оказаться так, что какая-то область знаний в вашем проекте не представлена никак (к примеру, risk management даже на словах отсутствует). В таком случае эта область знаний будет иметь вес Grade0.

Practices Grades

 

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

Practices Grades Matrix

 Что нам это дает?

  1. Во первых — удобную картину и инструмент при проведении аудита нашего (или чужого) проекта. Необходимы только опросники по каждой области знаний, а это уже просто.
  2. Во вторых — как только мы видим текущую картину, мы понимаем, а где же у нас те области, которым мы не уделяем достаточно внимания, либо наоборот — могут проявиться области, куда мы расходуем чрезвычайно много сил и ресурсов, более, чем это может быть необходимо и осмысленно (reasonable).
  3. В третьих — для тех руководителей, у которых больше одного проекта (и чем больше, тем актуальнее) — можно составлять heat map по вашим проектам и видеть их состояние буквально на одной странице в очень удобной для человеческого восприятия форме.

 

Как обычно — devil in the details 🙂 Как же понять, а где именно должен стоять квадратик в этой матрице «областей знаний vs. грейды», чтобы мы управляли нашим проектом наилучшим образом? Как определить ту оптимальную конфигурацию, которая наилучшим образом подходит конкретно под наш проект? И вот тут начинается самое интересное. Начало этому исследованию находится в статье Алистера Коуберна «Каждому проекту своя методология«. На входе у нас некоторые критерии или атрибуты нашего проекта. Дальше наступает шаг «BFM» (Big Fucking Magic). И на выходе мы получаем оцененные и взвешенные области знаний, с присвоенным им «весом», наиболее оптимальным под наш проект. Расшифровка сути магии BFM выходит далеко за рамки данной статьи, поэтому здесь не раскрывается.

BFM

 

Имея Current State (по результатам аудита нашего подопытного проекта) и получив некий Target State (оптимальные веса каждой области знаний), мы можем построить маршрут перехода из текущего состояния проекта к рекомендуемому для нынешней конфигурации. Очевидно, что как только нынешняя конфигурация проекта изменится, к примеру, команда вырастает с 10 человек до 50, нам потребуется заново пройти по схеме с BFM и определить новый Target State.

 

Плюшки

Зачем все это вообще делать? Какую пользу мы можем получить из такого подхода?

  1. Мы получаем унифицированные процессы (их удобно продавать заказчику, по ним удобно управлять нашими проектами внутри компании и множество других полезностей)
  2. Управленческие практики описаны достаточно четко и понятно, что облегчает время входа для новых менеджеров
  3. Инициация новых проектов выполняется шаблонно и быстро
  4. Передача проектов к нам (и от нас) происходит легко и все подводные камни выявляются вначале
  5. При любом существенном изменении в проекте (как на нашей стороне, так и на стороне подрядчика, либо вообще во внешней среде) — пересчет оптимальной стратегии управления делается быстро и легко
  6. Уменьшаются управленческие риски
  7. Повышается вероятность успеха проекта
  8. Значительно растет доверие и прозрачность между нами и заказчиком

 

Выводы

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

Успехов в ваших проектах, коллеги!

 

 

Comments

comments

Добавить комментарий