Я Гончаров Тимофей, руководитель отдела разработки. Хочу поделиться своими мыслями на тему оценки проектов.
Оценка проекта
Самая ненавистная часть работы для всех разработчиков. Не важно продуктовая у вас компания, вы фрилансер или владелец ауторс-компании. Оценка проектов, прогнозы в нашей сфере - это всегда боль. Из всех сфер человеческой деятельности, именно разработка ПО является легендарно плохо-прогнозируемым занятием.
Исследователи изучили 16 000 реальных проектов и посмотрели, сколько из них завершились успешно. Они оценивали успех по трём критериям:
Бюджет — уложились ли в запланированные деньги?
Сроки — завершили ли вовремя?
Результаты (выгоды) — получили ли то, что планировали?
Что показали цифры
Критерий | % проектов |
|---|---|
Уложились в бюджет | 47,9% (почти половина) |
Уложились в бюджет И в сроки | 8,5% (менее одного из десяти) |
Уложились в бюджет И в сроки И получили ожидаемый результат | 0,5% (один из двухсот!) |
При этом исследование охватывает широкий спектр проектов. Но IT входит в группу с самых высоко рискованных — то есть они с наибольшей вероятностью могут привести к катастрофическим перерасходам (400% и более сверх бюджета).
Источник: How Big Things Get Done (Bent Flyvbjerg and Dan Gardner)
Вернемся с глобальной аналитике к более бытовому уровню. Распространенная проблема: отдел маркетинга скидывает один потенциальный проект за другим, ты вынужден вникать в каждый проект, оценивать, тратить на это большие трудозатраты, а потом разочаровываться наблюдая как клиент уходит к тем, кто особо не заморачиваясь дал оценку меньше твоей. И ты понимаешь что скорее всего клиент станет очередной жертвой ошибки планирования, ему сделают "демо версию", а доводить проект до ума придется ему самостоятельно или за дополнительные счета. На таком этапе очень часто заказчик меняет подрядчика сомневаясь в экспертизе или добросовестности текущего. С такими клиентами, как правило, проще, так как заказчик уже набил шишек и будет относиться к своим ожиданиям более скептически, осознавать риски и сложности.
Тут пожалуй стоит рассказать какие стратегии оценки проектов я наблюдал, практиковал и к чему в итоге пришел.
Вариант 1. Оценивает команда разработчиков
Кидаем разработчикам, они оценивают и они же отвечают за свою оценку головой.
Тут несколько исходов:
Оценка слишком оптимистична и оторвана от реальности. Разработчик вынужден перерабатывать на выходных, итогом всего разочарование, выгорание и напряжение для всех.
Оценка реалистична, но выглядит крайне не соблазнительно для бизнеса: долго/дорого.
Вариант 2. Верхне уровневая экспресс-оценка
Экспертная экспресс-оценка сверху - оценивает не команда, а один опытный архитектор/техлид за 1–2 часа. Грубо, по аналогии с прошлыми проектами.
К сожалению тут результат часто оторванный от реальности и все риски по оценке лежат на одном человеке. Большая вероятность провала между ожиданиями и реальностью.
Вариант 3. Платная оценка
Клиенту предлагается заплатить за оценку проекта. Замотивировать клиента платить деньги за то что бы ему сказали сколько стоит разработка - звучит крайне сомнительно. Это требует высокой культуры разработки которая к сожалению во многих сегментах РФ не дотягивает до международных стандартов. Под высокой культурой я имею в виду уровень компетенций
заказчика в области разработки: понимание ценности ТЗ, сложностей тестирования, стабилизации функционала, менеджмента, неопределенности и непредсказуемости многих процессов, а так же осознание всех остальных высоких рисков которые неизбежно сопряжены с таким сложным делом как разработка ПО.
Мотивацией платной оценки для заказчика будет то что в результат оценки, мы можем включить: дорожную карту проекта, более точный разбор ТЗ с декомпозицией и разбивкой на этапы. Эта послужит фундаментом для эффективного старта и заказчик получит осязаемый результат помимо озвученной стоимости.
Вариант 4. Оценка вилкой + прозрачная коммуникация рисков
Даёшь не одну цифру, а три:
• Оптимистичная — всё идеально, требования не меняются
• Реалистичная — с учётом типичных рисков
• Пессимистичная — сложные интеграции, неясные требования и тд.
В добавок объясняешь клиенту:
Тот, кто дал вам цифру ниже нашей оптимистичной — либо чего-то не учёл, либо планирует доплаты потом.
Вариант 5. Фильтрация
Этот вариант скорее был актуален для рынка в его лучшие годы. Когда отдел маркетинга несет стабильный поток заказов, и оценивать все подряд кажется нецелесообразным. Тут каждый для себя выявляет критерии фильтрации: стек технологий, размер бюджета (если его возможно определить на старте), адекватность сроков и ожиданий клиента.
Идеальный заказчик:
Уже набил шишки с прошлыми подрядчиками
Может назвать примерный бюджет который готов выделить
Имеет грамотное ТЗ
Хорошо знает чего хочет
Знает что такое T&M (оплата за человеко-часы)
Если проект подходит по всем или хотя бы части пунктов — имеет смысл браться за оценку.
Что я решил для себя
Жизненноважно больше вникать в цели заказчика и вести его за руку к ним. Очень часто больше половины того что есть в ТЗ заказчику не нужно. Возможно есть обходное рациональное решение проблемы с использованием уже изобретенных технологий.
Важно повышать квалификацию отдела маркетинга. Знакомить его с вашим стеком, обучать проводить первичный анализ клиента/проекта нельзя все сваливать на разработчиков.
Важно не количество лидов, а качество. Активный маркетинговый отдел, без погружения в технические детали создаст большую нагрузку на разработчиков. Это приведет к обоюдному выгоранию и потере мотивации как разрабов, так и продажников.
Полностью скидывать оценку и сроки на разработчиков - подходит авторитарным компаниям, но если вы уважаете своих трудяг, руководство должно брать на себя риски по срокам и оценке. Это стратегическая задача и прямая ваша ответственность как руководителя.
