По какой модели делать проект HR-автоматизации:
⁃ традиционный вариант (waterfall) с ТЗ, четким планом проекта, фиксированной ценой, формальным процессом сдачи-приемки
⁃ гибкий подход (agile) - без детального ТЗ, с последовательностью спринтов (этапов)
Мы более 10 лет делали проекты исключительно традиционным способом, но 2 года назад практически полностью перешли на agile. И у нас есть возможность сравнивать. Поделюсь нашими наблюдениями.
Возьмём типовой HR процесс, требующий автоматизации. Например, сложная процедура Performance Management.
Для традиционного проекта:
1. Есть этап (предпроект) по аналитике - подготовке ТЗ. Трудозатраты - не менее 1 человеко-месяца. Реальный срок - до 2-х месяцев. Проблемы на этом этапе - заказчик пытается «запихнуть» в ТЗ как можно больше, ведь второго шанса не будет
2. Этап реализации. Трудозатраты - от 3-4 человеко-месяца разработчика/аналитика. Но, к этим трудозатраты нужно добавить затраты на управление проектом и риски (ведь ТЗ не идеально). Резерв и затраты на управление могут составлять от 50 до 100% от основных трудозатрат.
3. Этап сдачи приемки. Тут будет о документация и обучение и подготовка ПМИ и проведение испытаний. Не менее месяца, как правило 2.
Итого, проект будет выполнен в лучшем случае за 5-7 месяцев, а оценочные трудозатраты составят 10-12 человеко-месяцев. И стоимость этих работ и рисков будет заложена в договор (он же с фиксированной стоимостью). Я знаю компании, которые и эти цифры умножили бы на 2x при классическом варианте проекта, особенно для сложного государственного заказчика.
На этапе сдачи приёмки обязательно возникнут спорные или даже конфликтные ситуации из-за различной трактовки ТЗ.
Итог: долго, дорого, почти неизбежные разногласия в конце проекта
А что в agile?
Аналогичный проект делается, как правило, за 3 месячных спринта и 4 спринт на финальное тестирование и сдачу приемку.
Требования уточняются по ходу проекта. В реализованную систему попадёт только то, что реально нужно. Не критичные требования исключаются автоматически и за них заказчик не платит.
Трудозатраты проекта (и как следствие цена) - 6-8 человеко-месяцев.
Итого: быстрее в полтора раза, на столько же дешевле., вероятность конфликта в ходе проекта - драматически ниже.
Вывод: при правильном подходе к agile, затраты будут на 50% ниже, а срок реализации быстрее, удовлетворенность заказчика и исполнителя - выше существенно.
Это если делать все правильно. Что такое правильный подход и чего не нужно делать в agile - в следующем посте.
Есть и более оптимистичные исследования, которые говорят что agile проекты стоят в 4 раза меньше, а их вероятность успеха в 6 раз выше
https://www.scrum.org/resources/blog/large-scale-agile-and-scrum-vs-waterfall-agile-6x-more-successful-14-cost-and-10x
⁃ традиционный вариант (waterfall) с ТЗ, четким планом проекта, фиксированной ценой, формальным процессом сдачи-приемки
⁃ гибкий подход (agile) - без детального ТЗ, с последовательностью спринтов (этапов)
Мы более 10 лет делали проекты исключительно традиционным способом, но 2 года назад практически полностью перешли на agile. И у нас есть возможность сравнивать. Поделюсь нашими наблюдениями.
Возьмём типовой HR процесс, требующий автоматизации. Например, сложная процедура Performance Management.
Для традиционного проекта:
1. Есть этап (предпроект) по аналитике - подготовке ТЗ. Трудозатраты - не менее 1 человеко-месяца. Реальный срок - до 2-х месяцев. Проблемы на этом этапе - заказчик пытается «запихнуть» в ТЗ как можно больше, ведь второго шанса не будет
2. Этап реализации. Трудозатраты - от 3-4 человеко-месяца разработчика/аналитика. Но, к этим трудозатраты нужно добавить затраты на управление проектом и риски (ведь ТЗ не идеально). Резерв и затраты на управление могут составлять от 50 до 100% от основных трудозатрат.
3. Этап сдачи приемки. Тут будет о документация и обучение и подготовка ПМИ и проведение испытаний. Не менее месяца, как правило 2.
Итого, проект будет выполнен в лучшем случае за 5-7 месяцев, а оценочные трудозатраты составят 10-12 человеко-месяцев. И стоимость этих работ и рисков будет заложена в договор (он же с фиксированной стоимостью). Я знаю компании, которые и эти цифры умножили бы на 2x при классическом варианте проекта, особенно для сложного государственного заказчика.
На этапе сдачи приёмки обязательно возникнут спорные или даже конфликтные ситуации из-за различной трактовки ТЗ.
Итог: долго, дорого, почти неизбежные разногласия в конце проекта
А что в agile?
Аналогичный проект делается, как правило, за 3 месячных спринта и 4 спринт на финальное тестирование и сдачу приемку.
Требования уточняются по ходу проекта. В реализованную систему попадёт только то, что реально нужно. Не критичные требования исключаются автоматически и за них заказчик не платит.
Трудозатраты проекта (и как следствие цена) - 6-8 человеко-месяцев.
Итого: быстрее в полтора раза, на столько же дешевле., вероятность конфликта в ходе проекта - драматически ниже.
Вывод: при правильном подходе к agile, затраты будут на 50% ниже, а срок реализации быстрее, удовлетворенность заказчика и исполнителя - выше существенно.
Это если делать все правильно. Что такое правильный подход и чего не нужно делать в agile - в следующем посте.
Есть и более оптимистичные исследования, которые говорят что agile проекты стоят в 4 раза меньше, а их вероятность успеха в 6 раз выше
https://www.scrum.org/resources/blog/large-scale-agile-and-scrum-vs-waterfall-agile-6x-more-successful-14-cost-and-10x