Про_БА

Техники оценки задач

Вам приходилось слышать, что аналитик любую задачу делает слишком долго? Часто это вопрос выравнивания ожиданий от скорости работы аналитика.

При вызове такси приложение пишет, что поездка займет 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-лида в этой статье много общих описаний, мое внимание привлекло описание методов оценки в завершающей части статьи. Описано с точки зрения проектного менеджера, но подходы применимы к любым задачам

#инструменты #что_почитать

www.group-telegram.com/tw/pro_ba_it.com/172

394 viewsAug 12, 2024 at 07:23

Техники оценки задач

Вам приходилось слышать, что аналитик любую задачу делает слишком долго? Часто это вопрос выравнивания ожиданий от скорости работы аналитика.

При вызове такси приложение пишет, что поездка займет 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-лида в этой статье много общих описаний, мое внимание привлекло описание методов оценки в завершающей части статьи. Описано с точки зрения проектного менеджера, но подходы применимы к любым задачам

#инструменты #что_почитать

BY Про_БА