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