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

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

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

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

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

Сколько команд участвует в разработке, кто кого ждет? Одно дело, если весь проект разрабатывает одна команда, и совсем другое, если работают две и больше команд
API с которым вы интегрируетесь полностью готово? Заказчик готов предоставить его на приемку вашей команде? На проекте уже есть наработки прошлой команды, осталось только “доработать пару моментов”? А совпадают ли версии приложения в сторах с исходниками, которые дает заказчик? Проект необходимо запустить к конкретному дню (выставка / конференция / презентация) или есть запас по времени? В часть какого ландшафта будет вписан разрабатываемый продукт? Каков контекст текущего проекта? Какая приоритизация работ? Ваш проект попадает на гендерные / майские / новогодние праздники? Учли, что это выходные дни и команда будет отдыхать? Как часто будут меняться требования? Например, нужно реализовать парсер 5-ти сайтов
Казалось бы, ничего сложного
Но готов ли заказчик оплачивать допилы парсера под изменяющиеся функции сайта?

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

Тестовые данные предоставлены в полном объеме? Данные совпадают с боевыми? Или на проде появятся новые поля о которых не шла раньше речь? Как будут фиксироваться изменения и вбросы от заказчика? Оказаться от изменений, может быть, нельзя, но зафиксировать их и сместить реализацию после сдачи основных функций — вполне (а лучше на следующий этап)
Легаси-проект с зависимостями 2016 года, который нужно “просто поправить”? Заложили 10% времени на финальную проверку и полировку проекта? На чьей стороне ведется учет работы, в каких трекинговых системах? В какой срок будут предоставлены необходимые доступы? Какая критичность ошибки? Нужно ли отслеживать / анализировать и логировать каждый шаг пользователя? Сложность тестирования и его вариативность
На проекте достаточно ручного тестирования? Или тест-кейсов настолько много, что проще написать сценарии автоматизированного тестирования?

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

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

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

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

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