Когда я впервые брался за оценку стоимости разработки продукта, я честно полагал, что достаточно посчитать часы работы и умножить на ставку разработчиков. Через полгода и три проваленных проекта я понял, что это самый короткий путь к убыткам. Оценка — это не арифметика, это система, и мне пришлось заново выстроить её с нуля.
Нажать чтобы Перейти на сайт
Мой первый серьёзный проект — внутренний CRM-систем для логистической компании — обошёлся в 3,4 раза дороже первоначальной оценки. Причина была простая: я не заложил время на коммуникацию с заказчиком, который формулировал требования на лету и постоянно менял приоритеты. Я считал только «чистое» программирование и забыл про встречи, переделки, согласования и тестирование. Сейчас я закладываю минимум 20-30% бюджета на управление проектом и коммуникацию, и это уже не выглядит завышением.
Второй урок я получил, когда занимался мобильным приложением для сети кофеен. Я оценивал разработку по модулям и забыл про интеграцию с уже существующей ERP-системой заказчика. На этапе тестирования оказалось, что API противника, то есть стороннего разработчика, документирован наполовину и ломается при нестандартных запросах. Интеграция съела два месяца и почти 400 тысяч рублей сверх плана. С тех пор я всегда нахожу время, чтобы пообщаться с командой заказчика и понять, что за «простое API» на самом деле скрывается.
Третий принцип, который я вынес из практики: никогда не оценивай продукт по функциональности без понимания бизнес-контекста. Один и тот же функционал — авторизация и оплата — в финтех-стартапе и в корпорации с аудиторским контролем стоят совершенно по-разному. Я начал собирать референсы по аналогичным проектам в конкретной отрасли и учитывать требования регуляторов, безопасность, аудит. Это не всегда снижает стоимость, но делает оценку реалистичной и снижает риск споров с заказчиком.
Узнать подробнее →
Сегодня я использую трёхслойную модель оценки: сначала определяю объём работ по функциональным блокам с оценкой трудозатрат в часах, затем добавляю буфер на риски и неизвестности (обычно 15-25%), и только потом формирую смету с разбивкой по этапам. Заказчик видит прозрачность, а я не работаю в убыток. Конечно, это не панацея и точность до рубля никто не гарантирует, но расхождение в пределах 10-15% стало моей нормой вместо прежних 200-300%.
Подскажите, как вы сами подходите к оценке стоимости разработки? Используете ли вы какие-то специализированные методы вроде Story Points или COCOMO, или полагаетесь на интуицию и опыт? Буду благодарен за любой опыт, особенно если у вас были промахи — мне кажется, ошибки чужих коллег учат не меньше собственных.
По теме советую почитать: Как я автоматизировал бизнес-процессы с помощью Python
Нажать чтобы Перейти на сайтМой первый серьёзный проект — внутренний CRM-систем для логистической компании — обошёлся в 3,4 раза дороже первоначальной оценки. Причина была простая: я не заложил время на коммуникацию с заказчиком, который формулировал требования на лету и постоянно менял приоритеты. Я считал только «чистое» программирование и забыл про встречи, переделки, согласования и тестирование. Сейчас я закладываю минимум 20-30% бюджета на управление проектом и коммуникацию, и это уже не выглядит завышением.
Второй урок я получил, когда занимался мобильным приложением для сети кофеен. Я оценивал разработку по модулям и забыл про интеграцию с уже существующей ERP-системой заказчика. На этапе тестирования оказалось, что API противника, то есть стороннего разработчика, документирован наполовину и ломается при нестандартных запросах. Интеграция съела два месяца и почти 400 тысяч рублей сверх плана. С тех пор я всегда нахожу время, чтобы пообщаться с командой заказчика и понять, что за «простое API» на самом деле скрывается.
Третий принцип, который я вынес из практики: никогда не оценивай продукт по функциональности без понимания бизнес-контекста. Один и тот же функционал — авторизация и оплата — в финтех-стартапе и в корпорации с аудиторским контролем стоят совершенно по-разному. Я начал собирать референсы по аналогичным проектам в конкретной отрасли и учитывать требования регуляторов, безопасность, аудит. Это не всегда снижает стоимость, но делает оценку реалистичной и снижает риск споров с заказчиком.
Узнать подробнее →Сегодня я использую трёхслойную модель оценки: сначала определяю объём работ по функциональным блокам с оценкой трудозатрат в часах, затем добавляю буфер на риски и неизвестности (обычно 15-25%), и только потом формирую смету с разбивкой по этапам. Заказчик видит прозрачность, а я не работаю в убыток. Конечно, это не панацея и точность до рубля никто не гарантирует, но расхождение в пределах 10-15% стало моей нормой вместо прежних 200-300%.
Подскажите, как вы сами подходите к оценке стоимости разработки? Используете ли вы какие-то специализированные методы вроде Story Points или COCOMO, или полагаетесь на интуицию и опыт? Буду благодарен за любой опыт, особенно если у вас были промахи — мне кажется, ошибки чужих коллег учат не меньше собственных.
По теме советую почитать: Как я автоматизировал бизнес-процессы с помощью Python