Comments 9
Заголовок кликбейтный, конечно :)
за два часа вы делаете индикатив, и потом все равно встречаетесь с заказчиком и делаете уже оценку не 2-часовую. Индикатив, бывало, и за минуту делался :)
Такой подход сильно зависит от продукта. Пример: Платформы уровня MES с множеством модулей. Вот ТЗ на 150 страниц, чтоб его вычитать и соотнести функциональные требования, уже не 2 часа. А ошибка что-то не оценить, если как пример это конкурс, может быть очень дорогой, вплоть до разработки отдельного нового модуля и это так же считается как 5.3*срок_разработки=стоимость, только это минус из рисков, а если выше рисков сумма, то из маржи…
Посчитать стоимость серверов под проект, как выше автор комментария написал, реально можно и за секунду, вопрос опыта и знания своей области.
Да, я сразу в начале статьи описала, что у нас была за платформа и запросы. И к нам тоже приходили такие ТЗ на 150страниц, но за два часа можно было его прочитать и сказать - это наше/не наше, будем ли мы тратить приличное количество наших часов на этот пресейл, какой шанс, что его выиграем.
Т.к. компания была не гигантская, мы сразу договорились с руководством, что имеем право "завернуть" запрос и отказаться еще в самом начале.
Не увидел в статье оценки от разработчиков и QA. А именно их вклад по вашим же оценкам более 50%. То есть им просто спускается указ сделать за Х времени потому что мы так договорились с заказчиком?
Аналитики как раз и давали оценку на разработку, консультируясь с архитектором, который и отвечает за разработчиков. Т.к. в нашем случае добиться быстрого и вменяемого ответа от разработчиков на вопрос: "за сколько сделаешь" было нереально. QA всегда было долей от общего числа часов. Т.е. именно в нашем случае статистически +- мы всегда знали, сколько займет тестирование. Были некоторые отклонения, где, действительно, отдельно добавляли часов на тестирование, но в среднем по департаменту и всем ее проектам за год тестирование выводилось формулой.
Нам не важно было в рамках одной конкретной задачи дать точные оценки, важна была скорость оценок всех требований по пресейлам и экономия времени на входе. А также среднее число "по больнице" в год уравнивало все погрешности каждого конкретного требования в каждом конкретном проекте.
По итогам статьи не понял, насколько хорошо сработал (срабатывает) эта модель оценки? Вы как-то оценивали попадание, разброс оценок и реальность?
В целом, к сожалению, модель применима исключительно к продуктовой команде, которая много лет сидит на продукте и может многими итерациями подгонять свои коэффициенты
Мы брали так: сначала взяли факт по трудозатратам, затем вывели формулу оценок через коэффициент, а затем полтора года оценивали требования по этой модели и вышли на такие же фактические трудозатраты. Явно каждое требование мы не оценивали с т.зр. прогноз/факт. Нам, на самом деле, было важно разработать такую модель, чтобы уменьшить трудозатраты по пресейлам - они являлись дырой в бюджете (вся работа по оценке требований до контракта) и нам было важно как более точно с наименьшим временем их оценить.
Да, тут важно, что это был продукт, но я решила опубликовать наш опыт, так как, когда я искала хоть какие-то варианты оценок требований не в стори-поинтах, информации не было.
Как мы оценивали любые требования заказчика за два часа