Как управлять IT-проектами без универсальных подходов

Scrum, Kanban, Waterfall — зачем смешивать методики и почему IT-продуктам нужны разные подходы. Рассказывает Борис Лисовенко, руководитель отдела управления продуктом в компании Ratio.

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

Если у компании узкая специализация, то придерживаться одного шаблона разумно. Но когда от клиентов приходят разные по структуре задачи, управлять ими одинаково — не лучшее решение. Процесс становится сложнее, а сроки затягиваются.

В Ratio мы комбинируем подходы к управлению в зависимости от типа задачи: продукт, проект или поддержка.

При продуктовом подходе список дел меняется по ходу разработки — из-за тестирования гипотез и поиска новых путей. Поэтому мы используем scrum-спринты и управляем бюджетом по методике Time & Material (оплата по факту).

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

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

Самое важное в проектной работе — заранее определить сроки и примерный бюджет. Доработок нет, либо они вынесены в отдельный этап.

В Ratio работа над проектом идёт по каскадной модели, в три этапа.

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

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

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

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

Чтобы избежать путаницы, мы фиксируем ход разработки на канбан-доске. Задача проходит через пять колонок: Требует обсуждения, Открыта, В работе, Готова к проверке, Закрыта. Можем использовать дополнительные колонки, но меньше пяти не делаем никогда — иначе теряется прозрачность процесса.

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

Бюджетом управляем по той же методике Time & Material. Раз в квартал обсуждаем с заказчиком максимальное время, которое можно потратить на рядовую задачу.

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

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