Главный вопрос управления проектами: «Почему одни проекты и команды приходят к успеху, а другие к катастрофе?» Состав и этапность работ по проекту, уровень компетенций менеджера, выбранная команда — от перестановки этих слагаемых напрямую зависят результаты работ.

Для разных ситуаций и задач придуманы, испытаны и используются несколько методик управления проектами. Для производственных компаний, оказывающих услуги разработки, в том числе и IT-продуктов, управление проектами — базовая компетенция, а вот заказчикам приходится непросто при выборе и оценке предлагаемых путей работы над проектом.

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

Проектный подход: предсказуемость

Большинство проектов делаются по «обычной» поэтапной схеме, которая имеет вполне определенное название — «водопадная модель». Названа она так, потому что напоминает водопад с каскадами, следующими один за другим. Именно так этапы проекта следуют друг за другом в этой модели.

Самый первый этап проектного водопада — это подробное проектирование, результаты которого фиксируются в техническом задании и гарантируют клиенту уверенность в составе и объеме всех работ по проекту. Именно за эту уверенность клиенты любят эту модель.

Но на деле все случается немного иначе. Кроме гарантий, заказчик получает и ограничения: подрядчик выполнит только то, что запланировано в техническом задании и не больше. Это означает, что в стоимость НЕ включены:

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

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

Именно поэтому такую систему управления проектами часто называют баллистической: прицелились на этапе проектирования, спустили «курок», подписывая договор, и безучастно наблюдаем, куда полетел наш проект.

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

Водопад плохо подходит сложным и долгим IT-проектам, ситуация вокруг которых меняется быстро и проекты успевают устареть во время работы: «за время пути собачка могла подрасти...» Фиксированный договор и подробное ТЗ превращаются в хорошо подготовленную и задокументированную мину под проектом, не позволяя направить его в правильном направлении. Для таких проектов нужны более «гибкие» подходы.

Процессный подход: гибкость

Гибкие методологии ориентированы не на завершение проекта, а на создание процесса непрерывной работы над ним. Работа над проектом идет постоянно и разделена на блоки, каждый из которых можно публиковать и использовать, путь проекта постоянно меняется, ресурсы экономятся: делается только самое необходимое в данный момент.

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

Конкретные реализации моделей управления

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

Водопад + риски

Основной недостаток водопадной модели — это жесткие рамки требований и бюджетов, зафиксированных в ТЗ и договоре. Эти рамки создают конфликт между подрядчиком и клиентом, если что-то идет не так. Опытные компании и менеджеры знают: что-нибудь всегда пойдет не так. Риски обычно заранее известны и предсказуемы, а значит ими можно управлять.

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

Работа с рисками может довольно сильно увеличить бюджет проекта.

Водопад + гибкий бюджет

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

Клиент получает все, что действительно нужно для успешного завершения проекта и может влиять на состав и объем работ, но бюджет проекта становится вариативным — не все компании готовы к такой неопределенности.

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

Scrum

Самый известный вариант гибкой методологии разработки проектов. Итерационная разработка ведётся небольшими отрезками времени, от недели до месяца. Каждый такой этап называется спринтом или итерацией. У каждой итерации должен быть результат:

• выпуск новой версии продукта;
• внутренний релиз продукта;
• новый раздел или реализация пачки требований;
• исправление пачки багов;
• и т.д.

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

В итерационной разработке нужно умело управлять требованиями. Каждое новое требование к проекту — это определенный функционал и затраты на его реализацию. Требования собираются и бережно компонуются в будущие итерации. Для управления итерационной разработкой используется специальная доска — «Канбан».

В Scrum-методологию встроена система мотивации команды, построенная на разделении ролей и регулярных встречах команды. За соблюдение чистоты методологии отвечает отдельный человек — scrum-мастер.

На практике, большинство команд используют только суть методологии — разработку спринтами, оставляя другие особенности за кадром.

FFF

Fixed Time, Fixed Budget, Flex Scope — модель работы, широко разрекламированная благодаря усилиям Бюро Горбунова. Если описывать ее простыми словами, то это проект, который клиент получает вовремя и в рамках бюджета, но возможно... не целиком.

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

Это простой и понятный метод работы, под который обычно выделяется команда на некоторый срок, по окончании которого должен появиться работоспособный продукт.

Time & Material

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

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

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

Ежемесячный фикс

По сути, это вариант Time & Material, но с фиксированным бюджетом на каждый месяц. Мы отрабатываем только то количество времени, которое клиент готов оплачивать ежемесячно. Все остальные работы переносятся на следующий период.

Такой подход идеален для поддержки проектов, но подходит и для разработки, особенно если у клиента лимитированы расходы и важна их равномерность.

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

Что выбрать?

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

• Водопад с открытым бюджетом.
• Упрощенный вариант Scrum.
• Time & Material.
• Ежемесячный фикс.

Такая комбинация позволяет «покрыть» большинство проектов, на которых мы специализируемся: разработка среднего и высокого уровня сложности, постоянная поддержка и развитие проектов.

Оригинал: http://book.nimax.ru/project-management-methods/