Как выбрать методологию для внедрения крупного веб-проекта

У каждого проекта свои сроки, задачи и ожидаемые эффекты от внедрения. Не существует идеальной методологии, подходящей для каждого проекта. Также нет методологии, которая бы подходила для всех заказчиков с учетом специфики задач: культуры компании, команды. Однако за время существования проектного управления было создано немало эффективных подходов, методик и стандартов, которые можно взять на вооружение. Рассмотрим самые популярные из них, а также расскажем о нашем опыте успешно реализованных проектов, и согласно каких методологий они выполнялись. В конце вы сможете определиться с методологией для вашего веб-проекта согласно чек-листу.

Как правило, выделяют методологии:

Гибкие методологии

SCRUM

Гибкие методологии подходят для проектов, где необходимо быстро протестировать гипотезы и запустить MVP продукта. Например, для запуска SCRUM на старте проекта создается небольшая и гибкая команда из специалистов заказчика и исполнителя. Общий состав команды 7-10 человек.

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

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

Полноценный подход по SCRUM, возможен, как правило, на проектах от 1000 часов. Это связано с тем что высоки организационные издержки - наличие тим-лида, тестирование, выкатка релизов, групповая разработка, учет задач. При меньших трудозатратах мы рекомендуем подход T&M/Retainer.

Верхняя граница таких проектов - от 10 000 до 15 000 часов, потому что в случае больших трудозатрат речь идет о бюджетах от 20 млн. рублей, а с точки зрениях финансового управления такие бюджеты требуют более жесткой отчетности (см. SAFe)

WATERFALL

Менее гибкий поэтапный подход планирования проекта от А до Я с обязательным документированием и жёсткой фиксацией ТЗ. Такой подход хорош, когда заказчик заранее знает результат, на который он должен выйти, и совместно с исполнителями просчитал, как его поэтапно достичь. Залог успеха при waterfall-подходе – грамотное ТЗ.

Причем на ТЗ должно быть заложено не менее 20% бюджета, а детальное ТЗ требуется участие нескольких высококвалифированных специалистов:

Как правило, это около 40-60 часов работы каждого из этих специалистов. Таким образом, на ТЗ должно быть заложено не менее 200 часов, поэтому, мы говорим что это целесообразно на проектах от 1000 часов.

Цена, согласно данному подходу фиксируется сразу после написание Технического Проекта (ТЗ) и не может быть изменена в рамках границ проекта (это называется FPP - Fix Price Project).

При меньших трудозатратах мы рекомендуем подход T&M / Retainer.

Scaled Agile Framework

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

Однако, одна только методика SCRUM тоже работать не будет, поскольку нужно соблюдать формальные процедуры. Поэтому в таких проектах применимы мутации. Сверху - формальный проектный подход (с проектными комитетами, длинными цепочками согласований и т. д.), а снизу команда разработчиков работает по гибкой методологии Scrum.

Такой подход и называется Scaled Agile Framework. Он позволяет соблюсти сверху все формальные процедуры, а команде внедренцев гибко и поэтапно реализовать проект. Причем Scaled Agile Framework - не единственная методология, использующая микс и гибких (внизу, на уровне команды) и жестких (на уровне управления) методологий. Существуют и другие фреймворки.

Эта методология похожа на SCRUM “снизу”, где работает команда, и на классический проектный подход - с точки зрения ее управления, то есть те же самые проектные комитеты, управляющие комитеты.

Так какую методологию выбрать?

Мы придерживаемся мнения, что для совсем небольших проектов лучше всего подойдет T&M - это проекты до 1000 часов. Зачастую эта методология включает элементы классического проектного подхода - написание ЧТЗ или технического проекта и так далее.

Для средних проектов от 1000 до 10 000 часов для выбора методологии нужно обращать внимание на:

корпоративную культуру Заказчика;

наличие доверия Заказчика к Исполнителю;

сроки проекта;

Если сроки сжатые и доверие между Заказчиков и Исполнителем позволяет работать по гибким методологиям (прежде всего есть доверие к исполнителю, так и между членами команды заказчика), то оптимально подойдут - Scrum, Agile, Kanban.

Как правило, хорошие продукты реализовываются большими командами от 5 человек, включающие Тимлида, системного архитектора, девопс специалистов. Такие команды оправданы для проектов от 2500-3000 часов, где сначала создаётся MVP, заказчик получает результат и происходит дальнейшая развитие продукта.

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

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

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

Однако если заказчик не готов выкупать команду специалистов и не готов плотно участвовать в процессе - ежедневных, еженедельных скрам- встречах (планерках), то проект реализовывается по классической водопадной технологии, где сначала пишется ТЗ, создается план график и далее реализовывается проект по ценообразованию (fix price project). То есть после составления подробного ТЗ, в рамках границ проекта фиксируются ожидания Заказчика и что необходимо реализовать на уровне функциональных требований, а на уровне технического проекта реализуется классический проектный подход по водопадной (whatefall) технологии.

Для реализации проектов от 10 000 часов где необходим MVP и сжатые сроки используются смешанные методологии. Это может быть, например, Scaled Agile Framework или симбиоз других методологий, описанных нами выше: где есть четкие границы проекта, бюджета, фиксирование технического проекта, частных технических заданий, но при этом работа осуществляется по методологии Scrum, Agile, Kanban с ежедневными скрам- встречами (не менее 2-х раз в неделю) и выкаткой релизов раз в одну-две недели. То есть проект управляется на уровне документации и middle менеджмента Заказчика, как классический водопадный подход (то есть существует проектные и управляющие комитеты), а снизу реализация осуществляется по гибким методологиям.

Выводы

• в небольших проектах мы рекомендуем фиксировать технические требования и работать по time materials (в проектах до 1000 часов)
• в средних проектах от 1000 часов, но как правило от 2500 до 10 000 часов мы рекомендуем использовать гибкие методологии в случае наличия доверия между Заказчиком и Исполнителем - Scrum, Agile, Kanban. В случае отсутствия доверия - классический проектный подход (whatefall) и подход к ценообразованию fix price project
• в проектах от 10000 часов используются смешанные методологии Scaled Agile Framework, либо гибкие методологии с фиксацией бюджета, технического проекта и ЧТЗ на каждый из этапов.

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

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

Чек-лист для определения метода внедрения проекта

От бюджета и трудозатрат проекта:

От задач проекта, культуры компании и прочих факторов

В проектах от 1000 до 10 000 часов

От задач проекта, культуры компании и прочих факторов

В проектах от 10 000 часов