От нас, разработчиков, постоянно требуют дать оценку той или иной задаче. Зачем управленцам оценки, они вам сами расскажут. Зачем клиентам оценки — вам расскажут управленцы. Но нужны ли оценки самим разработчикам?
Вы знакомы с эффектом выпрямления сроков? Тогда вывод «оценки нужны» для вас очевиден. Если «работа занимает всё отведённое под неё время», то рефакторинг «когда-нибудь» никогда не осуществится. Чтобы его запланировать и назначить срок, нужна оценка задач.
Также важно давать оценку задачам и уметь это делать потому, что спрашивать с разработчика будут непосредственно по его оценке задачи. Оценили пессимистично — получили хлыстиком за транжирство времени. Оптимистично — получили выгорание из-за посиделок по 12 часов за экраном.
Почему оценку давать сложно
— Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
— Представь, что тебе надо разгрузить машину, сколько времени это займёт?
— Пару часов.
— Это Камаз.
— 8 часов.
— Камаз, груженный песком.
— 12 часов.
— У тебя нет лопаты и инструментов, только твои руки.
— 2 дня.
— На улице −40.
— 4 дня.
— Камаз вообще под водой.
— Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще всё это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто правильно оценить время на разработку.
Оценку давать сложно, потому что её обычно просят дать сразу. Без анализа можно оценить только поверхностно: нет возможности задуматься о тонкостях и «подводных камнях».
Мы каждый раз оцениваем разные задачи. Они похожи друг на друга, но всё же уникальности достаточно. Даже простая задача — реализовать CRUD какой-нибудь сущности — может подбросить сюрпризов.
Иногда приходится давать оценку задачам, требующим большого числа коммуникаций между исполнителями. Коммуникации — это накладные расходы, которые сложно учесть при оценке трудозатрат.
Как производить оценку
Немного поговорили о необходимости выставления оценок и возникающих сложностях в этом процессе. Так как же делать правильно?
Основной совет — вспомнить анекдот из начала статьи и не давать обещаний сразу.
В сети достаточно советов, какие факторы нужно учитывать при оценке задач. Но хочется пойти дальше и задаться вопросом: а в чём, собственно, измерять?
Абсолютная шкала оценки задач
Наиболее популярной единицей измерения размера задачи является час. Ну или, возможно, день. Но так ли хороши такие единицы? Хороши ли вообще абсолютные шкалы для оценки задач?
Попробуем изучить вопрос на примере.
Пусть есть задача — «покрасить на странице логина кнопку в красный цвет». Сколько времени это займёт?
Допустим, задачу делает старший разработчик. Он знает, какой атрибут какого компонента надо поменять, и делает это минут за 5.
Хорошо. Теперь допустим, что задачу берёт стажёр. Для него процесс выглядит иначе:
— Искать в коде компонент кнопки.
— Не найти, спросить ментора.
— Искать в коде компонента атрибут, отвечающий за цвет.
— Не найти, искать ментора.
— Не найти ментора, переживать.
— …
В общем, задача растянулась на целый рабочий день. Пример, конечно, притянут за уши, но хорошо показывает, насколько оценка задачи зависит от исполнителя.
Это мы оценивали задачу для работников компании Alpha. А теперь допустим, нам нужно оценить задачу для работников компании Omega. В этой компании нет CI/CD на проекте, а также нет специально выделенного человека, который мог бы задеплоить код. Изменится ли оценка? Конечно, ведь теперь исполнителю нужно деплоить код вручную. Выходит, одна и та же задача в разных компаниях имеет разную оценку.
С оценкой в часах/днях примерно понятно. Но единиц измерения целое множество. Что если попробовать оценивать задачи в попугаях или по сложности? Будут ли проблемы?
Как нам подсказывает Даниэль Канеман1, проблемы будут. Если коротко, человеческие возможности по использованию абсолютных шкал ограничены — мы, люди, попросту очень «шумные».
Разные люди будут по-разному воспринимать шкалы. Для кого-то простая задача — это только про изменение цвета кнопки, для кого-то простой задачей будет написать небольшой сервис целиком.
Ещё люди склонны на ходу менять цену деления шкалы. Примером крайности такого поведения может быть учитель, который никогда не ставит ученикам оценку «отлично».
Относительная шкала
Но нам повезло, есть и другой путь. На помощь спешат относительные шкалы.
Относительная шкала не отрицает существование абсолютной, а дополняет её.
Мы плохо умеем работать с абсолютными величинами, но вполне неплохо справляемся с попарными сравнениями. Более того, наш в принципе всегда пытается ответить не на задаваемый вопрос, а на похожий и менее сложный. И этим можно пользоваться себе во благо.
Попробуем иначе ответить на вопрос: «Сколько времени красить кнопку в красный». Не будем пытаться вспомнить, какой атрибут какого компонента нужно менять, а попробуем сравнить новую задачу с уже когда-то сделанными. В этом случае мы сможем дать более точную оценку на основе сроков пары выполненных задач.
При использовании относительной шкалы для оценки задач в команде стоит заранее обсудить (и записать) шкалу оценки. Можно выбрать диапазон (например, числа Фибоначчи от 1 до 8 или 13) и присвоить нескольким значениям референсы (например, поставить конкретные задачи в соответствие числам 1, 3 и 8). Впрочем, свою персональную шкалу тоже лучше формализовать.
Шум в оценке задач
Мы ожидаем ошибки, связанные с отсутствием должного анализа задач,
ожидаем ошибки предвзятости. Но мы склонны игнорировать такую
составляющую ошибки прогнозирования, как шум. Шум сложнее заметить, ведь
он имеет статистическую природу. Наше же — каузально.
Как можно лечить шум
Избавление от шума подразумевает работу с альтернативными точками зрения. Обычно этому мешает предвзятость подтверждения (confirmation bias), а также тот факт, что компании предпочитают комфортные условия конфликтующим мнениям.
Руководствуясь соображениями уменьшения шума, мы должны относиться к уникальным решениям как к типовым, принимаемым лишь единожды.
«Мудрость толпы»
Одним из проверенных способов снизить шум является «мудрость толпы». «Мудрость толпы» (wisdom of crowds) гласит: среднее независимых суждений разных людей, в общем случае, улучшает точность.
Ключевое здесь — независимость суждений. Второе (или даже третье) мнение будет бесполезным (и может привести к ещё большей предвзятости), если человек, выражающий это мнение, ознакомлен с результатами исходного или последующих. Он невольно будет склонен поддержать уже высказанную точку зрения. В этом несложно удостовериться — попробуйте поставить лайк (там, где лайк ставится анонимно) случайному свежему комментарию и понаблюдайте, как этот случайный комментарий будут поддерживать.
Инструменты вроде Planning Poker (Scrum Poker) появились не случайно. Это попытка представить «мудрость толпы» в виде пригодного для использования фреймворка.
Диалектический бутстрап
Другой способ — диалектический бутстрап (dialectical bootstrapping). Это такой метод оценки, где в дополнение к исходной оценке рассматривается другая, при подготовке которой исходные предположения считаются ошибочными.
Как это работает:
-
Даём оценку так, как обычно это делаем. Записываем.
-
Предполагаем, что оценка может быть неточной.
-
Думаем, какие предположения или соображения могли быть ошибочными.
-
Как, учитывая альтернативные предположения или соображения, меняется оценка — в большую или меньшую сторону?
-
Учитывая новые вводные, делаем вторую, альтернативную оценку.
Исторически, среднее полученных оценок ближе к истине.
Как не набрать слишком много
Хорошо. Положим, теперь мы можем оценить задачу. Но как запланировать спринт/итерацию/квартал/релиз таким образом, чтобы не набрать слишком много?
Внимание! От экранов лучше подальше убрать эффективных менеджеров и им сочувствующих.
Тут следует остановиться, вдохнуть, выдохнуть и смириться со страшным: разработка — это марафон. А раз у нас марафон, значит, нужно беречь ресурсы. Придётся периодически оставлять людей недозагруженными. Если всегда пытаться загрузить всех на 100%, то всегда кто-то будет перегружен.
Другой важный момент, без которого дальше «не поедем», — нужно научиться разрешать себе быть недозагруженным. Это тот самый момент, когда выполнены все задачи в спринте, и вместо того, чтобы заняться помощью коллегам или саморазвитием, мы берём задачи из следующего спринта. Это тот самый момент, когда нам кажется, что «ну вот ещё одна маленькая задача точно влезет». Не влезет. А даже если и влезет, помните — всегда делайте «умнее», а не больше.
Вероятностный метод
Забудьте всё, что вы учили в школе читали в этой статье. Для этого метода оценивать задачи не нужно от слова «совсем».
Вам нужны исторические данные о выполнении задач исполнителем (или группой, если речь о командном планировании). У всех же есть Jira, Trello, Redmine — что угодно, в чём можно двигать задачи из состояния в состояние, запоминая дату изменения.
Суть метода состоит в том, что, зная историческую продуктивность исполнителя или команды, можно предсказать, с какой вероятностью будет закончен тот или иной объём работ.
Наивный подход:
— Взять все выполненные задачи, найти максимальное и минимальное время выполнения.
— Предположить, что время выполнения новых задач равномерно распределено на этом промежутке.
— Построить график плотности вероятности (догадались, что за график мы увидим?).
— ???
— Profit!
Первой доработкой этого подхода будет изменение предположения о характере распределения. Проще всего назвать его нормальным и ждать «колокол» на графике.
Доработка для тех, кому нечего делать продвинутых. Можно заморочиться и точнее определить распределение времени выполнения задач. Дальше — по плану.
«Но это уже совсем другая история», так что было бы уместно отослать к интересной статье и всё тому же Максиму Дорофееву для дальнейшенго погружения.
Важный момент. Статистические модели принятия решений не могут добавить ничего к той информации, что в них содержится, из-за отсутствия шума. В том числе, при изменении внешних факторов. Меняется размер команды, меняется технический стек, случается пандемия — модель начинает хуже работать. До тех пор, пока не соберётся достаточно исторических данных.
И ещё. Нам не нужны модели более точные, чем наши измерения. Не стоит планировать по минутам, если данные по задачам собираются с точностью до дня.
Бонус: как быстро узнать количество выполняемых задач в неделю в Trello.
Шаг 1. Делаем экспорт данных в JSON.
Шаг 2. Берём скрипт, подставляем путь до файла (вместо trello.json), подставляем название колонки с выполненными задачами (константа CARD_DONE_STATE).
import itertools as it
import datetime as dt
import json
with open("trello.json") as f:
data = json.load(f)
list_name_to_id = {
el['name']: el['id'] for el in data['lists']
}
CARD_DONE_STATE = "DONE"
LIST_DONE_ID = list_name_to_id[CARD_DONE_STATE]
done_actions = []
for action in data['actions']:
if not action['data'].get('listBefore'):
continue
if action['data']['listAfter']['id'] != LIST_DONE_ID:
continue
date = action['date']
card_id = action['data']['card']['id']
card_name = action['data']['card']['name']
done_actions.append(
(card_name, dt.datetime.fromisoformat(date.strip('Z')))
)
def by_week_grouper(action):
date = action[1]
_, week, _ = date.isocalendar()
return week
for week, group in it.groupby(done_actions, key=by_week_grouper):
print(week, len(list(group)))
Скрипт выведет номер недели и количество задач, выполненных в течение этой недели. От текущей недели, к первой.
Теория ограничений
Теория Ограничений (TOC) — методология управления системами, которая была придумана Элияху Голдраттом. Погружение в эту методологию выходит сильно за рамки статьи. Вкратце: в основе методологии лежит поиск ограничения системы — звена, определяющего успех системы в целом.
Пример. Пусть есть команда разработки. Допустим, её основная метрика — количество выпущенных фичей. Программисты могут делать 5 фичей в неделю, а тестировщики могут тестировать только 3 фичи в неделю. Выходит, за неделю мы можем получить только три готовых, протестированных фичи. Здесь отдел тестирования — ограничение, т.е. сколько ни увеличивай штат разработчиков, всё равно будем получать 3 протестированных фичи в неделю.
Пять шагов работы с ограничениями:
-
Определить ограничение системы — найти наиболее загруженное звено.
-
Использовать ограничение по максимуму — как можно более эффективно использовать ограничение без дополнительных инвестиций.
-
Подчинить всё ограничению — сделать так, чтобы все части системы, отличные от ограничения, вносили вклад в его работу.
-
Расширить ограничение — масштабировать его, добавить ресурсов.
-
Если ограничение убрано, вернуться на первый шаг. Важно не давать инерции системы вернуть ограничение в предыдущее состояние.
В определении ограничения, а также и на следующих шагах, может помочь как навык оценки задач, о котором мы говорили в первой части, так и умение извлекать исторические данные о планировании, что мы рассматривали на примере Trello.
Распространённая ошибка — неправильно определённое ограничение. Когда хочется выпускать 20 фичей в неделю, а разработчики выдают только 5, хочется на этом остановиться и вливать все усилия в найм лишних кодеров. К сожалению, часто никто заранее не думает о том, что дальше по конвейеру стоит команда тестирования, которая не пропустит больше 3 фичей.
Используя Теорию Ограничений, мы больше не пытаемся загрузить по максимуму все звенья системы, поэтому они никогда не будут перегружены. Ёмкость же самого ограничения познаётся исторически, и, следуя методологии, мы работаем над тем, чтобы этому ограничению облегчить жизнь (смотрим третий шаг).
Методологию стоит изучить по оригинальному циклу книг Голдратта, но для затравки можно ознакомиться с докладом Максима Дорофеева.
Заключение
Помните: для самого работника важны качественная оценка задач и реалистичное планирование. Вместе они позволяют регулировать нагрузку, тем самым защищая от переработок и выгорания.
Профсоюз работников IT всегда нуждается в людях, умеющих планировать и организовывать производственные процессы из говна и палок в жёстких условиях ограничений по ресурсам. Если ты всегда хотел применить навыки органайзинга или научиться им, ждём от тебя заявку на участие.
Профсоюз работников IT:
Автор: Профсоюз
