😨 Не скрамом единым: 10 нетривиальных концепций управления проектом Серия постов - 2 /5 . Лайк, коммент, репост, если такой контент норм 😛.

3. Чтобы лучше прогнозировать сроки, иногда полезно перестать их оценивать: управление без оценок (#NoEstimates) Статья про подход Если дождаться созвона с гендиром (или кто у нас главный) и заявить: "Мы решили больше не оценивать сроки", - то после этого разговор, скорее всего, быстро закончится, а у вас как РП появится свободное время для поиска новой работы (наверное).

Концепция “управления без оценок” предлагает различать две вещи, которые мы очень часто смешиваем: оценку и прогноз. Допустим, у команды есть 50 относительно небольших задач. Можно собрать людей и начать выяснять, сколько займет каждая: эта - четыре часа, эта - восемь, эта - двенадцать, хотя похожая в прошлый раз была шесть, но тут интеграция сложнее, а там разраб уже знает код. Через несколько часов у нас появляется таблица с числами, которая выглядит очень научно и вызывает ощущение контроля.

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

Тогда вместо фразы “закончим 19 ноября” можно сказать "с вероятностью 85% закончим до 28 октября". Первое звучит точнее потому, что там одна конкретная дата, но сама эта точность может быть чисто… декоративной. Мы же знаем, что если взятую с потолка хрень написать с двумя знаками после запятой, она внезапно начинает выглядеть гораздо убедительнее.

Соответственно, смысл подхода довольно примитивный,  но интересный: если у вас есть поток похожей работы (и не супер-ответственной вроде строительства атомной станции), иногда полезнее прогнозировать поведение всей системы, чем заставлять людей подробно угадывать будущее по каждой отдельной задаче (и тратить доп. время).

4. Не спрашивайте, сколько времени займет работа. Спросите, сколько времени она заслуживает: фиксированное время и изменяемый объем (Fixed Time, Variable Scope) из Shape Up Публикация Basecamp(недоступна в рунете)

Эта концепция меняет местами привычный разговор между бизнесом и командой. Обычно все начинается, естественно, с требований. Заказчик приносит список, потом вспоминает еще десять вещей, через день кто-то добавляет мобильную версию / блокчейн / ИИ-фичу, через неделю появляется обязательная выгрузка в эксель, а еще через две недели становится известно, что все это желательно закончить примерно вчера. После этого разработчиков спрашивают, сколько времени займет реализация, разработчики называют неприятную (с кучей буферов) цифру, все расстраиваются и начинается обсуждение того, почему команда снова "завышает оценки".

В Shape Up предлагают сначала ответить на другой вопрос: сколько времени эта проблема вообще заслуживает? Не сколько займет идеальное решение, а сколько времени мы готовы на него потратить. Например, при ответе “четыре недели” команда уже проектирует такой вариант решения, который действительно помещается в эти четыре недели.

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

Поэтому жадничаем со временем - оно важнее и ценнее, пусть реализация подстраивается под это фундаментальное ограничение, а не наоборот.