Когда я работал в компании REIT, я разрабатывал систему управления доходами для оценки единиц хранения. Пока система разрабатывалась, команда по доходам была рада начать ее использовать, поскольку она активно развивалась (фактически альфа-версия). Проблема заключалась в том, что у них было много пунктов списка пожеланий, которые они хотели реализовать быстро, чтобы они могли более эффективно выполнять свои рабочие функции. Эти запросы были отправлены в Asana в больших количествах очень быстро. Это привело к проблеме: как оценить время этих задач и приоритизировать их.
Сначала я попытался дать всему стандартную оценку часов, но это оказалось трудным. У меня редко было достаточно времени, чтобы правильно оценить задачи, у нас не было нормальных спринтов, и мои ресурсы как единственного разработчика на проекте были ограничены. Это означало, что часто без надлежащего расследования группа по доходам классифицировала заявки, для которых я поставил более низкие оценки, только для того, чтобы выяснить, что я полностью недооценил задачу, требуя от нас выставить заявку и начать новую, повторно расставив приоритеты в моей очереди.
Чтобы помочь противостоять этому, я начал переоценивать «неизвестные» задачи или задачи, которые я не был на 100% уверен, сколько времени они займут. Проблема в том, что наша команда по управлению доходами не совсем понимала внезапный скачок в оценках времени или почему некоторые похожие по звучанию элементы так сильно отличались друг от друга.
Так что я начал говорить на встречах: «Это крайне неизвестно, потому что я никогда не использовал эту технологию, это странный хак, который нужно было сделать, который мне нужно будет отменить, или мне придется сделать больше открытий, если вы хотите лучшего». оценить это».
Это было незадолго до того, как я сделал это официально. В каждой отдельной задаче я начал ставить множитель рядом с оценками времени, в которых не был уверен. Это выглядело так:
[1x3] Настройка расположения таблиц и анимации строк
Это означает "Я думаю, что это займет 1 час, но это может занять в 3 раза больше времени (3 часа), если все пойдет к черту".
Это было чрезвычайно эффективно. Из этой разбивки по трем числам они могли видеть, что именно происходит, и могли задавать целевые вопросы на основе этого. Это означало, что они могли сразу же игнорировать любую из более определенных и типичных задач: x1 и x2 и сосредоточиться на еще более высоких множителях, которые даже помогли бы некоторым элементам не застревать:
Менеджер: «Почему это x5?»
Я: «Команда поддержки X еще не ответила мне».
Менеджер: «О, нет проблем, я напишу им прямо сейчас и предоставлю вам эту информацию».
Модификаторы неопределенности, которые я использовал, следующие:
- [x1] — Я абсолютно точно знаю, сколько времени это займет, и у меня есть опыт, чтобы достичь этого. Скорее всего, это либо очень просто, либо область кода, в которой я только что работал.
- [x2] — Стандарт, я не очень уверен в этом изменении, но я почти уверен, что смогу сделать это за такое количество времени.
- [x3] — Неуверенно, я окончательно не уверен в этой оценке, но у меня есть представление о том, о чем идет речь.
- [x4] — очень неуверенно, вероятно, есть технология, которую я никогда не использовал, или целые области кода, которые я никогда раньше не видел.
- [x5] — Неизвестно, вероятно, есть зависимость от третьей стороны или дизайн еще не завершен для этого предмета. Чаще всего x5 обычно означает"вернитесь ко мне позже и оцените это лучше, когда будете знать больше"
Мой менеджер в то время любил эту систему, потому что она давала ему три оценки:
- Возможен лучший вариант развития событий (мы никому не говорили эту оценку и сами в нее не верим)
- Вероятный сценарий (оценка времени для внутренней фиксации)
- Наихудший сценарий (оценка времени для внешней фиксации)
Предположим, у нас было 5 задач: [1x1], [1x2], [2x2], [1x3], [3x4], [2x5],
- В лучшем случае (сумма левых чисел): 10 часов.
- Наихудший сценарий (умножьте все оценки и добавьте): 32 часа.
- Вероятный сценарий (усреднение наихудшего и наилучшего вариантов) (10+32)/2 = 21 час
Это может показаться очень неточным способом выполнения оценок, но на самом деле он работал очень хорошо. Это дало мне больше времени для работы над предметами и меньше времени на поиск; это даже позволило нашей команде по управлению доходами удалить некоторые элементы, которые, по их мнению, не оправдывали оценки или обнаружения, и я не думаю, что когда-либо так часто попадал в оценки времени. Почти вся проделанная нами работа была близка к вероятному сценарию (21 час) и намного меньше худшего (32 часа).
Эта система оценок также сняла с моих плеч много стресса. Потребовалось, чтобы неловкость «как мне сказать моему менеджеру об этой простой на первый взгляд одночасовой задаче, которую я оценил в 3 часа, потому что я думаю, что это будет сложно», теперь выглядит как [1x3]. Это передает всю эту информацию в таком небольшом количестве текста. Это также позволяет другим переосмыслить задачу и, возможно, полностью удалить ее или изменить приоритетность чего-либо.
Похоже на Planning-Poker "Light"
В тайм-менеджменте существует система под названием «Покер планирования», где каждый получает карты с разным рейтингом сложности и назначает их задачам. Они не могут назначить каждую задачу легкой или каждую задачу сложной, поскольку на всех картах есть разные сложности/номера.
Хотя каждая задача имеет отдельную оценку времени, множитель часто является более важным фактором. С помощью множителя сортировка чьего-либо списка задач дает вам представление об их возможностях, о том, насколько они борются, и злоупотребляют ли они множителем, в конце концов, если у вас есть разработчик, который никогда не ставит x1 или x2 на задачу, которая, почти по определению означает, что они понятия не имеют, что делают.
Сотрудник 1: [1x1], [1x1, [1x1], [1x2], [1x3], [1x3], [2x3], [2x4], [4x4]
Сотрудник 2: [1x2], [1x3, [1x3], [1x3], [1x4], [1x4], [2x5], [2x5], [4x5]
Очевидно, что не все задачи созданы равными, но сотрудники не могут просто рутинно давать всем сложность x5, если бы они это сделали, их менеджер должен был бы предупредить их об этом, эта относительная шкала заставляет сотрудника решить: «Хм, я уже использовал много x4 и x5 здесь… может быть, этот x3 лучше x2, а этот x2 может быть x1, я работал в этой области кода раньше».
Заключительные мысли
Эта система не для всех и не для каждой организации, но я считаю ее полезной даже в среде, где необходимы отдельные оценки. В прошлом я ловил себя на том, что спрашивал себя «что бы это было в моей старой компании» [2x3], я вычислял среднее из лучшего и худшего в своей голове ((2+6)/2 = 4) и тратил 4 часа на задание. Тем не менее, это, вероятно, было наиболее полезно для первоначальной приблизительной оценки большого количества задач при работе над крупными продуктами.