[Перевод] Об оценках сроков в разработке ПО
В течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?
К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Оценки тормозят работу команды
Делать свою работу хорошо — абсолютно естественное желание для большинства людей. Поначалу, почти все разработчики являются оптимистами и недооценивают время необходимое на реализацию задач. Что неизбежно случается дальше: они соглашаются реализовать задачу за тот срок, который они сами назвали, и не успевают. Даже если никто их за это не укоряет (что кстати не всегда так), это создает определенный дискомфорт. По мере того, как такая ситуация повторяется снова и снова, люди учатся давать оценки «с запасом», потому что опаздывать со сроками, которые ты сам назвал — не очень приятная история.
Вопреки интуиции, называние сроков «с запасом» вовсе не обязательно помогает в них укладываться. Этот эффект известен как Первый закон Паркинсона, здесь психология играет против нас. Представьте, что вы предполагаете, что задача займет пару дней. Однако, с учетом всего неизвестного, и с учетом прошлого печального опыта, вы называете срок «неделя». Допустим, ваш менеджер говорит «окей», и вы принимаетесь за работу. Первое ощущение, которое у вас есть — времени достаточно! Вы только что договорились на срок с хорошим запасом. Поэтому первая половина недели проходит или в расслабленном режиме, или, что чаще, вы переключаете свои приоритеты на другие задачи, на которые раньше все никак не находилось время. По мере того, как назначенный срок приближается, вы принимаетесь за работу основательно, и вот тут начинают всплывать как раз те самые неожиданности, на которые вы, собственно, и закладывали запас. Вы упорно трудитесь, возможно засиживаетесь на работе допоздна, и, в итоге, с трудом укладываетесь (или не укладываетесь) в срок, который вы сами себе назвали «с запасом». В следующий раз та же самая история повторяется снова.
Проблемы могут возникать вне зависимости от того, как вы подходите к выдаче оценок. Если люди недооценивают, им зачастую приходится где-то срезать углы, чтобы уложиться к названному сроку. Удивительным образом, если оценки выдаются «с запасом», то происходит ровно то же самое, только позже. Как метко выразился Максим Дорофеев в одном из своих докладов, «дедлайн — это срок, раньше которого задача не будет выполнена ни при каких обстоятельствах».
Источник: Том ДеМарко и Тимоти Листер, Человеческий фактор
Наилучшую продуктивность показывают команды, которые не используют оценки. Чем чаще вы спрашиваете вашу команду об оценках, тем сильнее вы замедляете ее работу. Если вашей команде приходится оценивать вообще всю свою работу, то это замедление достигает максимума. Сначала люди тратят время на первоначальные оценки, потом они обсуждают, почему оценки не сбылись, и что же теперь делать дальше (обычное решение — потребовать новых оценок), а потом требования меняются, и вуаля — нужно оценить как изменение требований повлияло на оценки. А еще команде приходится иметь дело с техническим долгом, накопленным в многочисленных попытках уложиться в собственные оценки, что замедляет проект в долгосрочной перспективе.
Пальцем в небо
Сложность и неопределенность — постоянные спутники разработки ПО. Почти все, что мы делаем как разработчики, это что-то новое. Даже если мы делали что-то похожее в прошлом, теперь мы делаем это в новых условиях. Это может быть новый проект, или новые требования, или наши знания, полученные за время прошедшее с прошлого опыта. Если же задача является типовой и регулярно повторяющейся, то ее наверняка уже кто-то автоматизировал и предложил в виде готового продукта, библиотеки, или фреймворка. Таким образом, в подавляющем большинстве случаев разработчикам приходится давать оценки на задачи с высокой степенью неопределенности.
Источник — Show Progress | Shape Up by BaseCamp
Было бы лучше, если бы перед выдачей оценок разработчики имели возможность поработать над задачей некоторое время. В таком случае, они могли бы лучше понять задачу и были бы гораздо более уверены в своих оценках. К сожалению, такое редко встречается на практике. Как правило, у разработчиков есть очень немного времени на изучение задачи, прежде чем от них потребуют предоставить оценку. В результате, оценки по сути представляют собой тыкание пальцем в небо.
Разумеется, все опытные менеджеры знают, что оценки это всего лишь оценки, и они не пытаются трактовать их в качестве жестких дедлайнов. Тем не менее, оценки все равно воспринимаются как некая форма обещания. Если бы оценки не означали вообще ничего — зачем было бы о них спрашивать в принципе? Выдача оценки означает определенную степень готовности выполнить задачу за указанное время. Неудивительно, что многие разработчики это не любят — по сути, их просят подписываться под сроками на то, что они сами не до конца понимают.
Оценки создают опасные искажения
Плохая точность это не единственная проблема оценок. Помимо этого, они искажают представления о том, как вообще происходит разработка ПО. Как сказал Фред Брукс, «вынашивание ребенка занимает 9 месяцев, вне зависимости от того, скольким женщинам это поручено». Однако, когда люди слышат, что «проект займет 9 человеко-месяцев», они могут подумать, что это по сути 3 месяца работы для команды из 3-х произвольных разработчиков.
Источник: Фредерик Брукс, Мифический человеко-месяц
Люди и месяцы не являются взаимозаменяемыми, и это не только потому, что некоторая работа не может выполняться параллельно. Кто выполняет работу также имеет большое значение. Опытный разработчик, к тому же знакомый с предметной областью, возможно мог бы выполнить ее гораздо быстрее и лучше ожиданий. А джун, для которого еще и весь проект является новым, серьезно рискует не только не уложиться в сроки, но и полностью провалить поставленную задачу.
Первоначальная разработка — это меньшая из затрат
Люди постоянно спрашивают оценки на первоначальную разработку, но мало кто интересуется оценками на последующую поддержку решения. И это большая проблема, поддержка — это очень серьезно. Поддержка может занимать до 60–80% всех затрат на проект. Кроме того, каждая новая фича, которую вы добавляете в продукт, добавляет сложности и замедляет последующую разработку.
По идее, люди должны быть очень осторожны с выбором задач для разработки, и работать только над тем, что имеет наивысшую ценность для продукта. К сожалению, в проектах, управляемых на основе оценок, люди склонны продвигать фичи, которые не требуют больших затрат на первоначальную реализацию, и откладывать то, что кажется сложным. В результате, самая важная работа рискует быть отложенной, а продукт загромождается второстепенными фичами и костылями.
Как управлять проектом без оценок
Ну хорошо, пусть оценки требуют жертв. Они могут быть неточными, они замедляют команду, и возможно разработчики их иногда не любят. Но ведь нам все равно нужны оценки для планирования проекта, не так ли? На самом деле, необязательно. Да, иногда оценки действительно нужны, но во многих случаях они не требуются для принятия решений по проекту.
Во-первых, оценки не должны быть главным фактором, влияющим на приоритеты для команды разработки. Работайте над тем что важно, а не над тем, что можно сделать быстро. Если у вас нет абсолютной уверенности, что данная фича является важной, ее вообще не стоит рассматривать для полноценной разработки. Используйте MVP и product discovery для выявления реальных потребностей ваших пользователей.
Во-вторых, если у вас есть определенный дедлайн или ожидания от бизнеса, в которые надо уложиться, сообщите их вашей команде, вместо того чтобы запрашивать их оценки. Есть замечательный подход Fix Time and Budget, Flex Scope. Каждую задачу можно решить множеством разных способов. Тщательно приоритезируйте требования, и работайте над ними начиная от самых важных к менее важным, и будьте готовы запустить проект в любой момент времени. В таких условиях работать с дедлайнами гораздо проще. Даже если вам не удастся полностью закончить проект к сроку, вы успеете выполнить наиболее важные требования и будете готовы к запуску — и зачастую это именно то, что нужно.
В-третьих, если вам действительно очень нужна оценка, дайте разработчикам несколько дней поработать над задачей, прежде чем ее спрашивать. Если вам повезет, задача будет просто выполнена за эти несколько дней, и соответственно оценка вам больше не нужна. Если нет — к тому моменту разработчик будет гораздо лучше понимать, какие сложности есть в этой задаче, и у вас сможет состояться более продуктивное обсуждение. Принимайте в расчет не только затраты на первоначальную разработку, но и последующую поддержку решения, которая может оказаться куда более весомым фактором. И еще раз — если вы не уверены, что задача является важной, она вообще не должна доходить до разработчиков, даже для получения оценки.
Управление ожиданиями
Это, пожалуй, самое сложное. Как менеджер или тимлид, вы будете регулярно иметь дело с людьми желающими знать, сколько времени займет тот или иной проект. Если вы спросите, зачем людям нужна эта информация, они обычно скажут что или для планирования, или же просто хотят знать, чего вообще ожидать. Мы поговорили о планировании выше, теперь давайте поговорим об ожиданиях. Ожидания это естественно; человеку свойственно волноваться по поводу неопределенности в чем-то, что ему небезразлично. Иногда оценки спрашивает ваш руководитель, и вы не можете просто так ответить ему «я не знаю». Что вы можете сделать:
- Если задача уже взята в разработку или находится в очереди на разработку, спросите, какие есть планы, связанные с этой задачей. Постарайтесь помочь в достижении этих планов. Иногда разговоры о планах дают полезную вводную информацию для команды разработки. Возможно, будет достаточно предоставить упрощенный вариант на первое время. А иногда вы можете помочь найти какой-то обходной путь, который может использоваться, пока основное решение разрабатывается;
- Если задача еще не взята в разработку, уточните про ее приоритет. Поговорите о том, какая работа уже запланирована для команды, и подумайте вместе, как новая задача вписывается в эти планы. В некоторых случаях вы можете обнаружить, что нет никаких шансов взяться за эту задачу в обозримом будущем, а раз так — то и разговор об оценках не имеет смысла;
- Фокусируйтесь на продуктивности команды и прозрачности ее работы. Если ваша команда релизит в прод каждый день, и все могут это видеть, и видеть вашу очередь на разработку — люди будут менее склонны к запросам оценок;
- Как менеджер или тимлид, держите руку на пульсе и будьте постоянно в курсе, что уже сделано, что еще осталось, и какие есть препятствия. Если вы хорошо представляете себе картину происходящего, при необходимости вы сможете дать свои собственные оценки руководству, если посчитаете нужным. Помните, хорошие менеджеры защищают команду от всякого дерьма, плохие менеджеры просто пропускают дерьмо прямым потоком в команду. Прямая передача разработчикам всех запросов на оценки не является хорошей практикой.
Заключение
Оценки могут казаться естественными и даже необходимыми, но очень часто они просто вводят людей в заблуждение и тормозят разработку. Для людей естественно упрощать сложные для понимания вещи, но оценки часто упрощают понимание процесса разработки ПО сверх всякой меры. Scrum способен возвести это чрезмерное упрощение в культ, со своим Planning Poker ™, измерением Velocity и графиками Burndown charts.
Большинство людей согласны, что оценки имеют свои недостатки, но при этом оценки дают хотя бы что-то измеримое. Многим сложно представить, как можно управлять проектом не имея ничего измеримого. К сожалению, не все то, что имеет значение, можно измерить, и не все, что можно измерить, имеет значение. В этой статье я поделился своим опытом управления проектами без постоянного полагания на оценки. Разумеется, я не говорю что оценки полностью бесполезны. Я хочу сказать, что большую часть времени стоит полагаться на другие, более важные факторы. В ivelum мы используем этот подход много лет, и он хорошо работал для наших команд.
Я прекрасно осознаю, что эти советы — далеко не для всех. Мне приходилось работать с разными организациями, большими и маленькими, и подавляющее большинство из них полагалось на оценки в том или ином виде. Однако, в то же самое время, разработка в подавляющем большинстве организаций далека от эффективной. То, как работают наиболее продуктивные команды, порой сильно отличается от того, что делает большинство. Возможно, подход к оценкам как раз и является одним из таких отличий.
