Три проблемы Fixed Price проектов
Недооценили проект, изменился скоуп задач, так ещё и внезапный ЛПР с правками на финише? Разбираемся, как же испытать меньше боли в проектах Fixed Price.
Fixed Price — контракты с заранее оговорённой и фиксированной стоимостью работ. Идеально подходят для мелких проектов или запуска MVP. В них сразу понятна функциональность и она ограничена, изменения не вносятся, а сроки обычно не превышают трёх месяцев.
Однако в реальности Fixed Price часто выбирают крупные корпорации или государственные заказчики. Чаще всего это означает, что проект большой, запросы амбициозные и местами абстрактные, бюджет и сроки жёсткие, а результат должен быть чётким.
Я Ира Малкова, project-менеджер 2GIS KIT — мы доставляем точные пространственные данные, инструменты для геоаналитики и IT-решения для бизнеса и госсектора. Мы часто работаем по Fixed Price, и я не понаслышке знаю о проблемах, которые возникают на этих проектах. Расскажу, как избежать три основные.
Проблема №1: трудно оценить
Новый ИТ-продукт — не готовый товар с полки. Для него сложнее точно определить, сколько времени и денег потребуется.
Не попасть в оценку можно по разным причинам:
- Мало времени на оценку. Например, задача на оценку пришла в последний день подачи документов на тендер.
Заказчик сразу просит оценить весь проект без возможности сделать дискавери-фазу.
Нет развёрнутых требований или нужной документации для изучения задачи.
Добавляются новые вводные или не озвученные ранее моменты. Например, необходимость оформления документации по ГОСТу.
Решение: учёт рисков, точное ТЗ и дискавери-фаза
Два пути точной оценки:
— быть готовыми заложить в оценку больше, если не знаем всех деталей;
— точно понять объём работ.
Если идти по первому пути и закладывать риски в оценку, то нужно понимать, что цена контракта вырастет и контракт может не состояться.
Во втором варианте нужно максимально точное и детальное ТЗ. Такое ТЗ, которое, возможно, придётся составлять совместно с заказчиком. На это уйдёт больше времени и увеличит затраты. Есть риск, что клиент не готов ждать и попросит провести оценку быстрее.
Ещё один способ — провести дискавери-фазу. Это платный этап обследования, на котором анализируются бизнес-кейсы и предоставляется точная оценка.
«Дискавери» позволяет лучше понять проект и снизить риски неправильной оценки. Она требует времени, но окупается точностью дальнейших оценок, так как позволяет чётко понять границы разработки — скоуп.
В результате дискавери обычно определяют:
архитектуру ПО — интерфейсы, интеграции, дизайн,
спецификацию — бизнес-требования, вайрфреймы,
тест-план — все виды тестов, которые будут выполнены,
оценку — человеко-часы, состав команды, стоимость,
проектный план — длительность с разбивкой на фазы, обычно в виде диаграммы Ганта.
Для клиента «дискавери» удобна, потому что:
- За небольшой бюджет можно оценить профессионализм исполнителя и решить, стоит ли доверять ему остальной проект.
- Полученную документацию можно передать другой команде, которая готова взяться за проект на более удобных условиях.
Правила точной оценки Fixed Price проектов
Несколько рекомендаций, которые мы применяем:
Декомпозировать и детализировать требования. Чем чётче сформулирована задача, тем точнее будет оценка.
Кто делает, тот и оценивает. Это снизит риск избежать ошибок и недоразумений, ведь скорость работы в разных командах даже внутри одной компании может быть разная.
Заложить в оценку все активности:
- UI-дизайн, проектирование,
- стабилизация,
- тестирование: ручное, автоматизированное, юнит-тесты, кроссбраузерное, кроссдевайсное, производительность, нагрузка, безопасность,
- документация (продукта, кода, тестирования и т.п.),
- код-ревью, архитектура, исследования для дев лида,
- коммуникации,
- рефакторинг, технический долг,
- ПМ,
- бизнес-аналитик, работа с требованиями,
- девопс-задачи,
- деплой (поставка),
- демо,
- риски.
Проблема №2: требования меняются на ходу
Трудно заранее зафиксировать в ТЗ финальный образ результата, когда до сдачи ещё год и заказчик не в полной мере представляет, что хочет увидеть на выходе. В итоге проект либо не соответствует потребностям бизнеса и оказывается неудачным, либо выполняется с необходимыми изменениями, но выходит за рамки сроков и бюджета.
Пример: на старте проекта планировалось сделать сайт с базовой функциональностью, но в процессе работы заказчик решил добавить несколько новых разделов и сложные интеграции.
В больших проектах это происходит почти всегда. По мере работы выявляются новые потребности и риски, что требует пересмотра оценки и плана.
Решение: детальное ТЗ и модель FFF
В этом случае можно тоже пойти двумя путями:
Держаться первоначального ТЗ. С одной стороны, легко, а с другой — даже самое чёткое ТЗ на старте может не учитывать новые реалии и потребности бизнеса.
ТЗ останется актуальным до конца проекта только если:
провели «дискавери»;
у продукта действительно простая функциональность.
Второй путь — пересмотреть ТЗ и сформировать новые требования. Новые требования — новый проект. Договоритесь с клиентом, что изменение скоупа ведёт к изменению бюджета и сроков, или клиент уменьшает требования без изменения бюджета.
Например, заказчики не знают точно, чего хотят, и представляют продукт только в общих чертах. Они могут прийти с запросом: «Хотим разработать маркетплейс за 15 млн». В таких случаях Fixed Price не подходит, потому что уже на старте понятно, что в процессе будет много изменений.
И здесь может хорошо сработать модель Fixed price, flexible scope (FFF). Мы фиксируем бюджет и позволяем клиенту менять скоуп.
Как это работает:
Выделяем ключевые фичи.
Разрабатываем их на 60-70% бюджета (по договорённости с заказчиком).
Оставшийся бюджет отправляем на полировку и другие фичи.
Главное — определить, какой скоуп нельзя выкинуть ни под каким соусом.
Проблема №3: сложно сдать
Если не прописать, каким должен быть результат и кто его принимает, то это аукнется на финише. Например, появится новый ЛПР и скажет, что всё сделано не так.
Примеры проблем:
Документация по ГОСТу, которой оказалось очень много.
Тестирование всех сценариев клиентом.
Заведение тасок в таск-трекере клиента.
Обучение в офисе клиента.
Затягивание сроков из-за отпусков или горячего времени.
Решение: договорённости на берегу и связь со стейкхолдерами
Важно с самого начала договориться, прописать критерии приёмки, а также найти подходящих людей и управлять их ожиданиями.
Договорённости
Чек-лист для предотвращения возможных проблем, связанных с договорённостями:
Согласовать цели и сроки с заказчиком. Все должны знать, что мы делаем и чего хотим добиться. Лучше всего сверяться с заказчиком каждую неделю.
Регулярно показывать план работ. Это поможет заказчику видеть, что мы делаем и что планируем.
Заранее объяснить правила работы. Заказчику важно объяснять, что мы тестируем, ревьюим код, проводим ретроспективы и так далее. Это поможет ему понять наш процесс и задачи.
Создать бэклог с запасом. Желательно планировать задачи на три месяца вперёд. Это обеспечит гибкость и предсказуемость работы.
Составить матрицу ответственности (RACI). Важно, чтобы каждый знал, за что он отвечает. Это поможет избежать ситуаций, когда кто-то неожиданно принимает на себя чужие задачи или решения.
Наладить коммуникации. Регулярная коммуникация по статусу проекта и управление ожиданиями заказчика — ключ к успеху.
Демо. Нужно регулярно показывать промежуточные результаты, чтобы получать обратную связь.
Управлять изменениями. Если будут изменения в проекте, предупредите заказчика заранее, чтобы он был готов к этому морально и финансово.
Работа со стейкхолдерами
Важно познакомиться со всеми заинтересованными сторонами и выявить стейкхолдеров. Определить, кто принимает ключевые решения и подписывает акты. Выяснить их KPI и ценность проекта для них, чтобы не оказалось, что мы решаем не ту проблему.
Узнайте:
В чём ценность проекта для заказчика.
Какие проблемы он решает этим проектом.
Кто будет принимать проект и подписывать акты.
А дальше управлять отношениями — регулярно коммуницировать с ними, учитывать их интересы и потребности, адаптировать свои стратегии и планы к меняющимся условиям.
Итого
Это мои лайфхаки, с которыми голова точно будет болеть меньше. Но пределов совершенства нет, и у каждого могут быть свои приёмы. Если вы работали с такими проектами, буду рада узнать, как вы минимизируете боли Fixed Price.