Почему предварительные оценки проекта бесполезны

Конспект заметки консультанта Аллена Голуба о подходе NoEstimates.

Перевод подготовлен онлайн-школой PMCLUB.

Предварительные подсчёты — пустая трата времени. Они не только не приносят пользы, но и подрывают рабочие процессы, а значит нужно перестать их делать. Такую философию продвигает зародившаяся несколько лет назад в Twitter культура NoEstimates — «Без оценок».

NoEstimates можно рассматривать по-разному: как процесс, практику, методологию, структуру, дискуссию. Сколько у движения сторонников, столько и мнений.

Своим взглядом поделюсь и я. Моя точка зрения — не единственно верная. Предупреждаю об этом сразу, потому что не хочу, чтобы подход, способный привнести в проект ценность, повторил судьбу Agile — изначально гибкой методологии разработки, которая превратилась в набор строгих правил, не имеющих ничего общего с гибкостью (если что, она не измеряется количеством «стэндапов»).

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

Принципы NoEstimates, а также связанные с ним положения бережливой разработки (lean approach) — то, что нужно, чтобы объяснить слушателям, как на деле должен работать Agile. И один из способов повысить гибкость проекта и изменить образ мышления у его участников — это как раз отказ от предварительных расчётов.

Сами по себе Agile и NoEstimates — не практики, которые диктуют, что можно, а что нельзя. Это скорее пример культуры или же философии, из которых эффективные практики рождаются. NoEstimates в частности — это техника Agile-разработки, которая позволяет стать на шаг ближе к бережливому подходу.

Но для начала разберёмся, зачем мы всё подсчитываем. Наши подсчёты чаще всего крайне неточные. По правде говоря, смысл в них я вижу лишь в одном случае: если вы делаете то, с чем уже сталкивались, — например, разрабатываете ещё один сайт для того же клиента, используя идентичный шаблон на WordPress. В таком случае дерзайте. В остальном ваши подсчёты будут не более чем просто догадками.

Проблема в том, что мы не умеем грамотно оценивать, и доказательство тому — отчёт аналитиков The Standish Group под названием CHAOS Report. Согласно ему, 80% проектов «запаздывают», но на деле они никуда не опоздали: команды всего лишь не уложились в сроки, которые компания установила на основе своих предварительных подсчётов.

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

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

В разработке же нет ни единого продукта, который был бы загнан в столь же жёсткие рамки. На начальном этапе создания ПО мы никогда не знаем наверняка, что именно будем строить и как. Мы, конечно, думаем, что знаем, но позже, как правило, понимаем, что ошибались.

Мы учимся в процессе работы над продуктом — так же, как наши пользователи учатся, когда получают доступ к нему. Только практическое взаимодействие с программой позволяет увидеть то, о чём никто не думал, когда мыслил абстракциями. Сколько ни пытайся заранее учесть все возможные требования к продукту, это не даст тебе той же пользы, что публичный релиз.

Строить долгосрочные планы на основе абстрактных подсчётов — безрассудство. Даже если вы уложитесь в сроки и бюджеты, в конечном счёте вы вряд ли «выиграете». Планировать, зная, что подсчёты, скорее всего, окажутся неверными, значит своими же руками подрывать внутренние процессы.

Менеджерам среднего звена придётся построить огромную и дорогую инфраструктуру, чтобы не отставать от графика. На это уйдут деньги, которое можно было бы инвестировать в действительно необходимые задачи. А на сотрудников будут давить дедлайны.

На самом деле мы все это понимаем. Тогда почему не перестаём так делать? Думаю, дело в привычке. Никто не пытается поставить под сомнение пользу предварительных оценок, просто потому что «мы всегда так делали». Я часто спрашиваю менеджеров, зачем им эти оценки, если они, скорее всего, будут ошибочны, и в ответ часто слышу одно: «Расчёты помогают нам лучше взглянуть на проблему».

Звучит как оправдание. При подсчётах вы разбиваете проблему на мелкие задачи и оцениваете каждую из них отдельно, но вместо того чтобы пытаться понять, сколько времени займёт их выполнение, спросите себя: «А нужны ли все они в принципе?».

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

Привычка всё рассчитывать подобна вирусной заразе, которая не обошла стороной и методику Scrum с её спринтами. Идея спринтов заключается в том, чтобы задать работе определённый ритм, в котором команда, например, раз в пару недель берёт паузу и оценивает результаты.

Но и Scrum-у навязывают абстрактные расчёты. Пример тому — предварительная оценка задач в баллах (story points). Наличие таких оценок приводит к тому, что разработчики тревожатся из-за нелепых вещей: как «заработать» побольше баллов и повысить собственную «скорость» (её измеряют количеством полученных за спринт очков).

Никаких «сторипоинтов» нет ни в руководстве Scrum Guide, ни в Agile-манифесте, поэтому они не имеют отношения ни к Scrum, ни к гибкости. Рон Джеффрис, которому приписывают создание концепции, поясняет: баллы нужны, чтобы исключить оценку в часах, которыми менеджеры давят на команды. Но не странно ли оценивать баллами усилия?

Да и обязательство выполнить задачу на определённое количество баллов за определённое время — это практика, ничем не отличающаяся от «водопадного» подхода. Это та же история, только с более короткими временными рамками в виде спринтов. И она противоречит Agile и Scrum.

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

Это необязательно та же ценность, которая была заявлена при планировании отрезка. Согласно Scrum Guide, это «любое... звено, которое объединяет усилия команды разработчиков» — никак не случайный список «историй», которые вы составили две недели назад.

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

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

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

Вы спросите: «А что насчёт бизнес-планирования? Разве компании не нужно предварительно всё рассчитать, чтобы понять, стоит ли браться за проект?» Это неверный вопрос.

Если решение о начале разработки продукта или его части зависит от затрат, то я бы на вашем месте дважды подумал, стоит ли в принципе браться за дело. Основополагающий вопрос должен быть таким: «Сможет ли наш бизнес выжить (о процветании на данном этапе речи не идёт), если мы не сделаем ПО?»

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

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

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

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

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

Заметьте: процесс, который я описываю, динамичен. Он не похож на предварительные расчёты, которые вы делаете один раз перед началом проекта, и на этом всё.

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

Суммируя напоследок мой взгляд на NoEstimates, скажу: бросьте подсчёты и используйте прогнозы, основанные на реальных измерениях.

PMCLUB — онлайн-школа для менеджеров проектов и продуктов. Мы учим управлять проектами и не срывать дедлайны, правильно оценивать сроки, риски и бюджет. Подписывайтесь на нас на vc.ru и в Telegram.

#планирование #проектныйменеджмент #noestimates #риски