Что не так с оценкой разработки IT-продуктов
В чем риск? Как нам недавно объяснили: риск в риске. Истории в агентствах начинаются одинаково, а заканчивается по-разному. Начинаются с “назовите примерную стоимость / сроки, ну примерно сколько?”, а заканчиваются либо проектом сданным в срок, либо сорванными договоренностями. От чего же зависит результат?
В прошлой статье рассмотрел технические тонкости реализации digital-продуктов. В этой рассмотрю организационные. Как не ошибиться при составлении сметы? На что обратить внимание по ходу проекта, чтобы сделать проект в срок и в плюс? Эти наблюдения, в основном, относятся к модели Fix Price, но также применимы для корректной оценки трудозатрат на спринты.
Начнем с кейса. На рынок выходит новый оператор мобильной связи: нужно разработать личный кабинет абонента в виде мобильного приложения. Бэкенд уже готов — запилила внутренняя команда разработки.
Какие вопросы нужно обсудить с командой и заказчиком?
На этапе оценки
- Сколько команд участвует в разработке, кто кого ждет? Одно дело, если весь проект разрабатывает одна команда, и совсем другое, если работают две и больше команд. API с которым вы интегрируетесь полностью готово? Заказчик готов предоставить его на приемку вашей команде?
- На проекте уже есть наработки прошлой команды, осталось только “доработать пару моментов”? А совпадают ли версии приложения в сторах с исходниками, которые дает заказчик?
- Проект необходимо запустить к конкретному дню (выставка / конференция / презентация) или есть запас по времени?
- В часть какого ландшафта будет вписан разрабатываемый продукт? Каков контекст текущего проекта? Какая приоритизация работ?
- Ваш проект попадает на гендерные / майские / новогодние праздники? Учли, что это выходные дни и команда будет отдыхать?
- Как часто будут меняться требования? Например, нужно реализовать парсер 5-ти сайтов. Казалось бы, ничего сложного. Но готов ли заказчик оплачивать допилы парсера под изменяющиеся функции сайта?
На этапе разработки
- Тестовые данные предоставлены в полном объеме? Данные совпадают с боевыми? Или на проде появятся новые поля о которых не шла раньше речь?
- Как будут фиксироваться изменения и вбросы от заказчика? Оказаться от изменений, может быть, нельзя, но зафиксировать их и сместить реализацию после сдачи основных функций — вполне (а лучше на следующий этап).
- Легаси-проект с зависимостями 2016 года, который нужно “просто поправить”?
- Заложили 10% времени на финальную проверку и полировку проекта?
- На чьей стороне ведется учет работы, в каких трекинговых системах? В какой срок будут предоставлены необходимые доступы?
- Какая критичность ошибки? Нужно ли отслеживать / анализировать и логировать каждый шаг пользователя?
- Сложность тестирования и его вариативность. На проекте достаточно ручного тестирования? Или тест-кейсов настолько много, что проще написать сценарии автоматизированного тестирования?
На этапе запуска и сопровождения
- Кто и когда будет принимать проект? Тот же менеджер, который ставил задачу или за время реализации продукта менеджер сменит компанию и вам снова придется утрясать контекст?
- Сопровождать разработанный проект будет та же самая команда разработки? Разрабатывать и сопровождать должны уметь разные команды, тем самым вы проверяете код на “липкость” к конкретному разработчику.
- Обучение конечных пользователей было включено в оценку? Иначе даже после сдачи проекта он может “сожрать” бюджет.
Эти вопросы в бриф не занесешь. Но сэкономить себе нервные клетки и бюджеты можно на берегу заранее найдя ответы на них.
Точных вам оценок.
Крайне полезная статья. Как раз планирую заказать разработку бота под товарный бизнес (возможно, вы уже видели на самопиаре, что мы занимаемся кленовым сиропом). Большое спасибо)
Собираемся как раз рассказать в нашем подкасте "Системный маркетинг" про эту проблему - чаще всего маркетологи и разработчики ни договориться не могут, ни даже понять друг друга)
отлично, зовите если что! )
Хорошая статья, спасибо!
Thanks for sharing! Worth Reading it!