Что не так с оценкой разработки IT-продуктов⁠⁠

В чем риск? Как нам недавно объяснили: риск в риске. Истории в агентствах начинаются одинаково, а заканчивается по-разному. Начинаются с “назовите примерную стоимость / сроки, ну примерно сколько?”, а заканчиваются либо проектом сданным в срок, либо сорванными договоренностями. От чего же зависит результат?

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

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

Какие вопросы нужно обсудить с командой и заказчиком?

На этапе оценки

• Сколько команд участвует в разработке, кто кого ждет? Одно дело, если весь проект разрабатывает одна команда, и совсем другое, если работают две и больше команд. API, с которым вы интегрируетесь, полностью готово? Заказчик готов предоставить его на приемку вашей команде?

• На проекте уже есть наработки прошлой команды, осталось только “доработать пару моментов”? А совпадают ли версии приложения в сторах с исходниками, которые дает заказчик?

• Проект необходимо запустить к конкретному дню (выставка / конференция / презентация) или есть запас по времени?

• В часть какого ландшафта будет вписан разрабатываемый продукт? Каков контекст текущего проекта? Какая приоритизация работ?

• Ваш проект попадает на гендерные / майские / новогодние праздники? Учли, что это выходные дни и команда будет отдыхать?

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

На этапе разработки

Разработчик выполняет функции менеджера )

• Тестовые данные предоставлены в полном объеме? Данные совпадают с боевыми? Или на проде появятся новые поля о которых не шла раньше речь?

• Как будут фиксироваться изменения и вбросы от заказчика? Отказаться от изменений, может быть, нельзя, но зафиксировать их и сместить реализацию после сдачи основных функций — вполне (а лучше на следующий этап).

• Легаси-проект с зависимостями 2016 года, который нужно “просто поправить”?

• Заложили 10% времени на финальную проверку и полировку проекта?

• На чьей стороне ведется учет работы, в каких трекинговых системах? В какой срок будут предоставлены необходимые доступы?

• Какая критичность ошибки? Нужно ли отслеживать / анализировать и логировать каждый шаг пользователя?

• Сложность тестирования и его вариативность. На проекте достаточно ручного тестирования? Или тест-кейсов настолько много, что проще написать сценарии автоматизированного тестирования?

На этапе запуска и сопровождения

Все равно все может пойти наперекосяк, нужно быть к этому готовым)

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

• Сопровождать разработанный проект будет та же самая команда разработки? Разрабатывать и сопровождать должны уметь разные команды, тем самым вы проверяете код на “липкость” к конкретному разработчику.

• Обучение конечных пользователей было включено в оценку? Иначе даже после сдачи проекта он может “сожрать” бюджет.

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

Точных вам оценок.