Вам приходилось слышать, что аналитик любую задачу делает слишком долго? Часто это вопрос выравнивания ожиданий от скорости работы аналитика.
При вызове такси приложение пишет, что поездка займет 30 мин, а когда по факту получается 20, у клиента появляется ощущение удачно решенной задачи. До исполнения задачи клиенту показали маршрут и время выполнения, никто не обещал доехать за 10 мин. Аналитику тоже будет проще объяснить затраты, если показать маршрут и прогноз времени выполнения задачи.
В моем опыте вопрос "сколько нужно времени на анализ" часто даже не звучит, приходится слышать "надо побыстрее" или "мы оценили всю разработку в Х часов, неужели не хватит на анализ?". Поэтому в роли аналитика полезно оценивать задачи даже если никто об этом не просит. Это важно, чтобы управлять ожиданиями команды и не попасться на манипуляциях с оценками. Можно договориться об уменьшении объема всей задачи или отдельных задач аналитика, если оценку нельзя пересчитать. При этом вспоминается импульсивный стиль менеджмента, при котором сложно договориться, но это уже другая история🤷♀️
Выбор метода оценки зависит от имеющихся данных, готовности заинтересованных сторон к разговору, времени на оценку.
Оценка сверху-вниз Не уходя в детали, верхнеуровнево смотрим на компоненты задачи и оцениваем их на основании исторических данных, знаний о рисках и экспертного опыта. Предполагается, что можно будет уточнить оценку по мере раскапывания деталей задачи
Оценка снизу-вверх Разбираем задачу на детальные шаги, оцениваем каждый и все оценки суммируем. Для такой оценки нужно выделить время на детальную декомпозицию задачи, могут понадобиться уточнения и в этом недостаток метода, хотя он распространен и очень любим экспертами.
Экспертная оценка (Rough Order of Magnitude, ROM) На основании исторических данных в команде, внешних данных от других команд, экспертного опыта дается оценка задачи. Применяется часто, но здесь главный недостаток в субъективности такой оценки. Скорее всего будет оценен вариант решения, как его понял эксперт, с учетом производительности работы этого конкретного эксперта, для другого исполнителя это может не сработать. Хорошо работает, когда вы сами оцениваете свою же задачу и не забываете учесть возможные риски
Параметрическая оценка Метод предлагает выбрать единицу калибровки, например, вариант использования. Оценить эту единицу на основании опыта конкретной команды и использовать в оценке задач в зависимости от предполагаемого количества таких единиц в ней. Недостаток подхода в том, что калибровка и оценки одной команды аналитиков могут оказаться нерабочими для другой
Метод бегущей волны Это итеративная оценка работ аналитика от шага к шагу. Например, оценить предварительное уточнение требований, затем на основании уточненной информации оценить шаг по детализации требований и т.д.
PERT (Program Evaluation Review Technique) или техника трех точек Метод предлагает разделить три сценария выполнения задачи: оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Оценить каждый сценарий в отдельности. Итоговую оценку подсчитать как (O+4*R+P)\6
Что почитать?
A Business Analyst's Guide to Estimation Techniques (ENG ) в этом тексте самое ценное – разбор примеров для каждой из техник, что я перечислила выше
Requirements Estimation: How to Create a Business Analyst Timeline (ENG) живой рассказ о том, какие шаги автор блога рекомендует, если к вам пришел менеджер с очередной срочной задачей и спрашивает сколько времени вам на не нужно
Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида в этой статье много общих описаний, мое внимание привлекло описание методов оценки в завершающей части статьи. Описано с точки зрения проектного менеджера, но подходы применимы к любым задачам
