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

Мы понимаем, как важно контролировать расходы, поэтому поделились примерами, как можно спланировать стоимость в системе Agile.

Пропишите желания и расставьте приоритеты

Попросите команду предоставить список всех функций и проектов, которые они хотели бы завершить в течение года или более короткого периода. К документу можно подойти неформально — здесь не обязательно фиксировать требования, но важно расставить приоритеты по каждой задаче. Используйте для этого листа  таблицы Google docs, Jira или другой привычный инструмент для планирования.

Обсудите каждый пункт

Полученный список очень похож на RoadMap (дорожную карту задач по Agile), на встрече с командой мы проговариваем все пункты: на обсуждение каждого дается не более 5 мин (желательно включать таймер). За это время тот, кто добавил задачу (чаще всего это заказчик) раскрывает суть выбранной функциональности. Затем у команды есть 10 минут, чтобы задать вопросы. Если фичей много, то разбор RoadMap делится на несколько встреч с точным таймингом.

Установите диапазон затрат для каждого пункта

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

  • S: 0—80 часов;
  • M: 80—200 часов;
  • L: 200—600 часов;
  • XL: 600+ часов.

Эти «пакеты» рабочих часов могут быть любыми, в зависимости от проекта и команды. Чем сложнее и неопределеннее продукт, тем больше времени закладываем на работу. Когда часы подсчитаны, мы называем заказчику размер пакета.

Оцените общую стоимость

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

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

Ключ к успеху

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