Как управлять IT-проектами без универсальных подходов
Scrum, Kanban, Waterfall — зачем смешивать методики и почему IT-продуктам нужны разные подходы. Рассказывает Борис Лисовенко, руководитель отдела управления продуктом в компании Ratio.
Разработчики любят спорить о том, как лучше управлять IT-проектами. Agile-методы, каскадная модель, бережливое производство — последователи есть у каждой методики.
Если у компании узкая специализация, то придерживаться одного шаблона разумно. Но когда от клиентов приходят разные по структуре задачи, управлять ими одинаково — не лучшее решение. Процесс становится сложнее, а сроки затягиваются.
В Ratio мы комбинируем подходы к управлению в зависимости от типа задачи: продукт, проект или поддержка.
Продукт
При продуктовом подходе список дел меняется по ходу разработки — из-за тестирования гипотез и поиска новых путей. Поэтому мы используем scrum-спринты и управляем бюджетом по методике Time & Material (оплата по факту).
Спринт длится от одной недели до одного месяца. При оплате за человеко-часы заказчик знает стоимость очередного захода, поэтому каждый раз согласовывать бюджет не нужно. Но трудозатраты на задачу мы всё-таки оцениваем — для внутреннего контроля.
В итоге все остаются довольны. Мы получаем честную оплату, а заказчику проще корректировать направление разработки — ведь в конце каждого спринта он видит рабочую версию продукта.
Проект
Самое важное в проектной работе — заранее определить сроки и примерный бюджет. Доработок нет, либо они вынесены в отдельный этап.
В Ratio работа над проектом идёт по каскадной модели, в три этапа.
- Проектирование: техзадание, варфреймы и интерактивный прототип
- Дизайн
- Разработка: вёрстка и интеграция
Этапы идут друг за другом и не пересекаются — каждый мы прорабатываем, как отдельный проект.
К началу этапа мы можем точно оценить его сроки и стоимость. Иногда заказчик хочет узнать бюджет всего проекта. Тогда мы точно называем стоимость первого этапа, а цены на остальные указываем вилкой.
Поддержка
В поддержке мы работаем с уже готовым продуктом. Иногда он требует обновления, но мы в любом случае не собираем его с нуля.
Управлять поддержкой сложнее всего. На первых порах в задачах царит хаос, они могут приходить наплывами и без чёткого приоритета — от двух или трёх сотрудников заказчика сразу.
Чтобы избежать путаницы, мы фиксируем ход разработки на канбан-доске. Задача проходит через пять колонок: Требует обсуждения, Открыта, В работе, Готова к проверке, Закрыта. Можем использовать дополнительные колонки, но меньше пяти не делаем никогда — иначе теряется прозрачность процесса.
Доступ к онлайн-доске есть у всех представителей заказчика — они видят список работ и верно расставляют приоритеты.
Бюджетом управляем по той же методике Time & Material. Раз в квартал обсуждаем с заказчиком максимальное время, которое можно потратить на рядовую задачу.
Чтобы использовать время и бюджет с максимальной отдачей, нужно подстраиваться под заказчика и конкретную ситуацию. Где-то важнее заранее согласовать план, где-то лучше полностью уйти в гибкие методики.
Эффективный путь — применять разные подходы к разным задачам. Это лучше, чем привязывать подход к философии компании: когда недостатки любимого метода игнорируются, а управление проектом выходит громоздким и неудобным для заказчика.
А почему вообще статья в разделе "Карьера"? На какую конкретно аудиторию она рассчитана?
Это вопрос к vc.ru. Материал почему-то переместили сюда.
Честно говоря, так хочется прочитать всё это на простом до безобразия языке, "на пальцах", чтобы поняли и малыш и бабуля. Вот например, можно говорить, что сервис автоматизирует, оптимизирует, максимизирует, синхронизирует, интегрирует ... но вы поняли :), а можно сказать так: ты будешь загружать товары в свой интернет-магазин 52 дня по 8 часов в день, и это будет стоить тебе количество часов умножить на почасовую ставку, а можно сделать это за день и за сумму в 10 раз меньшую. Примерно так. Или ты будешь как "кто-то" сидеть до боли в глазах над прайс-листами с тысячами товарных позиций, или мониторить цены на тридцати сайтах конкурентов, которые поменяют цены быстрее, чем ты откроешь сайт номер 29, вместо того, чтобы заплатить за то, чтобы это делалось быстро и автоматически, и пойти заниматься другими делами.
Разработка по продуктовому подходу — слишком гибкий процесс, чтобы так запросто разбрасываться впечатляющими цифрами. Да и полного списка работ на старте обычно нет, сравнивать нечего.
Мы тут больше про то, как эффективно работать с тремя типами задач в IT: продуктом, проектом и поддержкой. Если есть конкретные вопросы, буду рад помочь :)
Вот честное пионерское - "Разработка по продуктовому подходу" - даже это уже не понимаю.
Да дело даже не в цифрах. Написано сложно. Понимаете, бывает, читаешь, и всё отлично заходит. А бывает, что и абзац осилить сложно. Ну не идёт и всё. А понимать хочется.
Не ваша тема, бывает. Тут больше пользы для разработчиков и тех, кто сотрудничает с разработчиками. Писать про управление проектами в IT для малышей и бабуль можно, наверное. Вот только зачем?
Дело не в теме, а в построении предложения с точки зрения русского языка. Не может быть вообще никакой "разработки по подходу". И уже не важно какой подход.Понимаете? Не может быть "разработки по чему?". Может быть разработка чего, в соответствии с чем и так далее. Если у читателя ступор уже в первом предложении, дальше он может и не прочитать.
Что касается нашей или не нашей темы: ну извините, если менеджмент и разработка - это не наша тема, то о чём говорить? :)
" IT-продуктам нужны разные подходы" - не продуктам, а к их разработке, к продажам и т.д. У Вас что, продукты кусаются, что к ним нужны подходы? Это же не собаки! Мне пришлось раз 5 прочитать первое! предложение, чтобы примерно понять. Ваша статья могла бы быть успешней, если бы её просто более "удобоваримо" написали.
Ради эксперимента взял фокус-группу в 10 человек: пять айтишников, пять людей из других сфер. Все поняли статью прекрасно, разъяснять не потребовалось.
А вообще это какое-то бесполезное обсуждение, не в нашем духе. Давайте сместим фокус: расскажите про свой опыт управления проектами. Нам интересно узнать про ваши подходы — будем благодарны за информацию)
А какие методики управления применяете вы? Как считаете, бывают ли универсальные подходы?