Угадывать срок задачи - основной метод оценки (и он не правильный)

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

❌ И это НЕ работает для 80-90% задач!

Пример 1: 👮тимлид дает экспертную оценку, что разработка задачи займет неделю (7 дней). НО в итоге эту задачу делает не тимлид, а 👨 другой человек, которому тимлид поручил это сделать. Это человек не обладает таким багажом знаний и опыта как тимлид, и в результате, срок разработки затягивается на 🤷 3 недели.

Пример 2: Scrum-команда с помощью 🃏Planning Poker произвела анализ задачи, поделилась друг с другом своими экспертными мнениями, и сообща оценила задачу в 15 стори пойнтов, что соответствует целому спринту (2 недели). Но в процессе разработки проявилась не предусмотренная зависимость от смежной команды и в итоге задача заняла 🤷 3 спринта (1.5 месяца)

В результате: менеджер 👊 кнутом и 💰 пряником подгоняет сотрудников, чтобы уложиться в тот срок, который он напророчил бизнес-заказчику, хотя всем понятно, что в срок не успеть. 🤬 Бизнес бьется в истерике, а сотрудники тихо 🤮 ненавидят менеджера, и обновляют резюме на HeadHunter.

Что на самом деле стоит тут поменять?
1) Перестать верить в том, что можно предсказать будущее 🔮 с помощью экспертной оценки
2) Использовать 🎲 🎲 🎲 теорию вероятностей для прогнозирования сроков задач

Пример из практики:

🔫 Дано: Отдел аналитики делает автоматическую сборку 📝 регулярных управленческих отчетов для директоров бизнес-направлений. Каждый отчет - это мини-проект, требующий работы ИТ-команды из дата-инженера, бекенд- и фронтенд-разработчика и аналитика. Команда регулярно ошибается по срокам, что злит бизнес. ИТ-команда считает, что во всем виноваты бизнес-заказчики, а те, наоборот, считают что это ИТ-команда плохо делает свою работу.

🛠 Что сделали: Использовали статистику из трекера задач, чтобы построить 📊 вероятностную модель по срокам автоматической сборки разных типов отчетов

🏁 Что в итоге: Договорились с бизнес-заказчиками на эксперимент, в ходе которого срок брался из 📊 вероятностной модели. Через 6 месяцев эксперимент был признан успешным, и данный подход стал основным. Заказчики получили предсказуемость по срокам, ИТ-команда - возможность работать без давления, и понятные ориентиры по времени на основе статистики.

Подробнее про этот кейс можно посмотреть тут: https://youtu.be/TiLirIGAERM

Вывод: знание методов теории вероятностей и данные из трекера задач позволяют делать прогнозы сроков задач, с большой вероятностью попадания в прогноз

Всё это разбираю в своём Телеграм-канале "Данные в дейSTвии" , на который смело зову подписаться.

Вот подборка полезных постов, которые вы можете изучить прямо сейчас:
➲ Как узнать срок выполнения задачи с вероятностью 80%, не отвлекая подчиненных от работы

➲ Как выстрелить себе в ногу, собирая и анализируя данные о рабочем процессе

➲ Как Scrum-команде давать оценки задач с вероятностью 85% и не тратить на это 4-6 часов

➲ Как рассчитать оборачиваемость бэклога проекта

➲ Как и зачем делать аудит рабочих процессов, чтобы ускорить Time To Market в 1.5-2 раза?

Ещё больше полезноты — впереди.