Стоит ли оценивать время на выполнение задач в IT? Или, может быть, просто приступить и начать работать? А что, если оценивать не время, а объем задач? И что вообще следует и можно оценивать?

Как и всегда, универсального ответа нет. Я придерживаюсь следующей стратегии: прежде чем давать или запрашивать оценку, важно понять, зачем это нужно обеим сторонам — бизнесу и разработке (в нашем случае). Кроме того, стоит уточнить, какая степень точности оценки будет оптимальной для вашего проекта на текущий момент.

Оценка может дать проджект-менеджеру представление о загрузке команды. Или, например, помочь бизнесу предварительно определить стоимость проекта. Также она может стать инструментом, позволяющим исключить из бэклога задачи с несоизмеримо большим объемом работы. Без ответов на эти вопросы команда и бизнес рискуют потерять уйму драгоценного времени, не получив при этом никакой полезной отдачи.

Когда я работала продакт-менеджером (а потом доросла до CPO) в стартапе, мне довелось наблюдать, как трансформировалось видение основателя компании. На старте он стремился к созданию «бирюзовой» организации, в которой можно было всё и не требовались никакие оценки. Однако со временем его подход изменился: компания стала работать по «красной» модели, где помимо оценки фичей нужно было рассчитывать еще и их стоимость.

По мере изменения целей основателя трансформировались и подходы к оценке задач.

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

Предисловие

В маленьком стартапе, в котором основатель хотел по-быстрому сделать продукт, и оценка носила информационный характер, «работал» метод оценки времени выполнения задачи из головы Chief Technical Officer (СТО), которая не выполнялась вообще никогда, как минимум потому, что команда разработки не имела ни малейшего представления об этой оценке. 

Эта страшно заниженная оценка очень нравилась основателю первые полгода. Но переставала нравится по мере того, как раз от раза задачи делались не 3 дня, а 3 месяца. Никто не объяснял, что это «не разработчики плохие», а 2 раза пересогласовали дизайн, 3 раза изменили требования, а к самой разработке приступили только через два месяца после постановки задачи.

Давайте посмотрим, как же можно делать иначе?

Немного душной теории

Моя теория оценивания оперирует тремя переменными: 

• скорость выполнения задач (V — Velocity) 

• время выполнения задач (T — Time) 

• объем выполненных задач (S — Scope) 

Переменные связаны уравнением:

Когда речь заходит об оценке задач в IT, получается картина: объем (S) и скорость (V) неизвестны, а хочется понимать время выполнения (T). Следуя логике школьной математики, становится понятно, что оценка времени (T) при неизвестных объеме (S) и скорости (V) — это простое угадывание. Угадывания иногда достаточно для целей компании. При этом наличие данных о скорости и объеме дает более высокую степень точности оценки времени. Но стоит помнить, что определение скорости (V) и объема (S) — это отдельные усилия и ресурсы.

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

Очень простая оценка по компонентам — Trivial

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

Глоссарий 

Компонент (системы) — функционально или технически независимая часть продукта. 

Как мы определяли компоненты

1 группа компонентов — продуктовая: формировалась путем «перемножения» функциональных частей системы — {Users, Staff, Admin, Partner…} и стеков — {Frontend, Backend, Infra…}. 

Пример

2 группа — техническая: список микросервисов — изолированных технически модулей системы — Auth Service, FE Proxy и т.д. 

Процесс оценки 

1. Формулируется задача в формате: «Надо сделать новую функциональность».

2. Методом пристального взгляда и наработанного опыта определяется, в каких компонентах системы нужно будет внести изменения.

3. В днях (или даже неделях) прикидывается, за какое время можно внести изменения в каждом компоненте самым медленным разработчиком команды.

Пример таблицы можно посмотреть тут (лист — Trivial).

Плюсы, условия применения и недостатки 

+ Процесс оценки занимает очень мало времени.

+ Есть понимание, когда примерно можно приходить к команде со следующей задачей.

+ Бизнесу понятны масштабы разработки, и появляется возможность отказаться от слишком больших задач или изменить их приоритет.

✓ Такая оценка может использоваться, когда разработка ведётся без ограничений по срокам — долго, качественно и дорого.

— Недостаток: нужен сильный СТО, который довольно хорошо знает команду.

Степень точности оценки = 2/10, время на оценку = 2/10. 

Усложненная оценка по компонентам — Simple 

Когда оценка предыдущим методом усложняется из-за объёма задачи и/или большого количества неизвестных в функциональности, можно дополнительно декомпозировать и саму задачу.

Процесс оценки

1. Задача декомпозируется на 1 шаг вглубь — уточняются особенности функциональности.

2. Методом пристального анализа в днях (или месяцах) оценивается декомпозированная задача по компонентам. 

Пример таблицы можно посмотреть тут (лист — Simple).

Плюсы, условия применения и недостатки 

+ Оценка становится на 1 балл более точной. 

✓ Такая оценка подходит, когда разработка все еще ведется без ограничений по срокам — дорого, качественно и долго, но у бизнеса и команды появляется запрос на нивелирование рисков.  

— Недостаток, аналогичный предыдущему методу: нужен сильный СТО, который довольно хорошо знает команду.

Степень точности оценки = 3/10, время на оценку = 3/10. 

Вычисление времени (T) — Hard

Этот подход отличается от всех предыдущих тем, что оценивается не время, а объём задач (S), а время (T) и скорость (V) вычисляются. 

Общий алгоритм

Итерация — 1 

1. Оценивается объем задачи (S) в некоторых величинах (обсудим их и методы оценки объёма ниже), единых для всей команды

2. Задачи передаются в разработку

3. После выполнения задачи считается количество времени, фактически потраченное на задачу

4. Имея для каждой задачи и , вычисляется скорость

Итерация — 2 (новая порция задач) 

1. Оценивается объем итерации-2

2. Начиная со второй итерации появляется возможность приблизительно вычислить время выполнения итерации (T), исходя из скорости, полученной из первой итерации —

3. После выполнения задачи считается количество времени, фактически потраченное на итерацию

4. После получения данных о фактическом значении времени (T) для итерации-2, повторяются вычисления, и уточняется значения скорости .

   Комментарии к новой скорости (V): расчётная скорость стала ниже по сравнению с той, которая получилась после первой итерации, поэтому фактически задача была выполнена медленнее, чем ожидалось.

Итерации уточнения скорости (V) повторяются, и постепенно скорость стремится к постоянному значению, а точность прогнозируемого времени (T) повышается. 

Пример таблицы-шаблона можно посмотреть тут (лист — Hard).

А как же оценить объем задач (S)?

Объём (S) — это относительная мера объёма или сложности задач. Он выражается в условных единицах (у.е.), которые отражают, насколько одна задача сложнее или проще другой для конкретной команды.

Объём (S) может выражаться в Story Points, T-Shirts, LOE (Level of Effort) и других единицах измерения, коих придумали уже много, но суть у всех одинаковая — смотри предыдущий абзац.

Практические рекомендации по оценке объема (S)  

1. Эффективнее оценивать подзадачи, то есть предварительно декомпозировать задачи.

2. Любая оценка объёма задач — это сравнительная мера задач относительно друг друга, не относитесь к такой оценке как к реальным часам работы.

3. Шкала оценки объёма задач должна быть единой для всей команды.

4. Для шкалы оценки объёма можно использовать последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21…) или степени двойки (1, 2, 4, 8, 16…).

Как оценить объем (S), например, в числах Фибоначчи  

1 способ: 

1. Отсортировать задачи (лучше подзачи — декомпозированные) в порядке их усложнения по субъективной оценке исполнителя.

2. По порядку выставить оценку объема = {1, 2, 2, 2, 3, 3…}, сравнивая каждую следующую задачу с предыдущей.  

2 способ: 

1. Отсортировать задачи в порядке их усложнения

   1. Результат = {}

2. Оценить первый и последний элемент массива, присвоив им значения 1 и Х

   1. Х зависит от количества задач 

   2. Результат = {, Задача 2, Задача 3, Задача 4, }

3. Повторить процесс оценки в оставшемся подмножестве ещё неоценённых задач по такой же логике:

   1. Сложность первой задачи в оставшемся массиве сравнить с соседом слева (во сколько раз эта задача сложнее предыдущей?), а сложность последней — с соседом справа (во сколько раз эта задача легче следующей).

   2. Результат шага 3.1 = {}

   3. Результат шага 3.2 = {}

4. Итоговый результ= { }

Фокус-фактор

Если имеется оценка объёма задач (S) и даже скорость разработки (V), полученная на предыдущей итерации, то есть все возможности приблизительно посчитать заветное время (T) разработки задачи.

Почему всё ещё приблизительное? Потому что всегда есть непредвиденные заранее риски, и для нивелирования таких рисков появился подход использования фокус-фактора.

Фокус-фактор (FF) — это коэффициент, который применяется к первоначальной оценке времени работы над задачей, чтобы учесть неопределённость и риски, которые не были известны во время оценки.

Формулы расчета FF у нас не было, лид всегда ориентировался на опыт команды и субъективную сложность задачи. 

Практические рекомендации из опыта 

1. — новая задача из новой предметной области, несработанная команда, неизвестный стек — очень много рисков.

2. — новая задача из новой предметной области, относительно сработанная команда, предсказуемо работающий стек — среднее количество рисков.

3. — новая задача из известной предметной области, сработанная команда, понятный стек — рисков мало.

Наш минимальный за историю компании FF был 1.5, когда предметная область и архитектура проекта стали понятны, и команда уже сработалась, но на неизвестные риски всё равно закладывались.

Процесс оценки объема задач с FF

Disclaimer: считаем, что это не первая итерация оценки объёма (S), и для расчётов есть приблизительно рассчитанная скорость (V).

1. Декомпозируются продуктовые требования к задаче. 

2. Рисуется дизайн. 

3. Готовится архитектура для новой функциональности. 

4. Оценивается объем задач (S) в у.е.

5. Исходя из скорости (V) и объема (S) приблизительно рассчитывается время (T).

6. Время (T) умножается на фокус-фактор.

Пример таблицы можно посмотреть тут (лист — Hard — Sprint 2). 

Плюсы, условия применения и недостатки метода вычисление времени (T) с FF

+ Появляется расчёт времени, а не простое угадывание.

+ Можно собрать спринт с прогнозируемым и продуманным временем реализации.

+ Появляется возможность отказаться от точечной функциональность внутри итерации, если она слишком сложная и/или объемная. 

✓  Такая оценка применима, когда надо сделать качественно, дорого и в предсказуемый срок. 

— Процесс оценки занимает много времени — первое рассчётное временя можно получить только после проведения первой итерации.  

Степень точности оценки = 6/10, время на оценку = 7/10. 

Очень детальная оценка — Hard+

Когда появляется необходимость считать деньги и точную дату релизов (с минимальной погрешностью), в подход «Hard» добавляется следующее:

1. Появляется оценка работ не только команды разработки, но и оценка работ продуктовой команды, QA, DevOps и релизной команды — то есть оценка всех исполнителей всех задач.

2. Время рассчитывается строго исходя из скорости конкретного исполнителя задачи.

Процесс оценки  

1. Команде разработки (разработчики нужного стека, QA, DevOps и аналитик) презентуются артефакты — детально расписанные продуктовые требования, дизайн и архитектура.

2. Команда разработки — непосредственные исполнители задачи — декомпозируют все назначенные на них задачи и оценивают время на основании своей скорости. Если подзадача делается больше 8 часов, декомпозиция продолжается.

3. К оценке задачи добавляется время багофикса и релиза задачи на прод.

4. Для нивелирования проблем с самооцениваем (не путаем с самооценкой) добавляется FF.

5. Формируется подробный план загрузки команды на нужный период.

Плюсы, условия применения и недостатки 

+ Становится понятна загрузка команды и точная дата релиза задачи на прод

+ Появляется возможность детально сравнить ожидаемую дату релиза с реальной 

✓ Такой тип оценки предполагает, что разработка находится в состоянии — качественно, медленно и предсказуемо по цене. 

— Сам процесс оценки занимает несколько (от 2 до 5 дней) команды, потому что каждый понимает ответственность и старается подстраховаться.

Степень точности оценки = 8/10, время на оценку = 8/10.

Послесловие и выводы

1. Если нужно просто спрогнозировать загрузку команды — подойдёт Simple оценка времени.

2. Очень детальная оценка времени имеет смысл только в том случае, если нужно понимать точную дату релиза или стоимость задачи.

3. Если используется фокус-фактор, то не забывайте уточнять его после каждого релиза.

4. Если принято решение оценивать, тогда (иначе будет оценка ради оценки):

   1. Оценка делается по декомпозированным задачам.

   2. Оценка рассчитывается всеми участниками команды, а не только разработчиками.

   3. Оценка рассчитывается исполнителями (прим. автора: чтобы человек закоммитился не только по времени, но и по деньгам, — оценка должна исходить от исполнителя, а не от архитектора/лида/СТО).

Выбирайте свой метод оценивания задач, а все шаблоны можно взять тут. 

Надеюсь, было полезно!

Если у вас остались вопросы по оценке задач, процессам разработки или любым другим аспектам в IT, буду рада помочь! Не стесняйтесь обращаться — обсудим, подберём подходящие решения и найдём ответы на любые ваши вопросы.

Алина М ♡ Продакт по любви