Пару лет назад в Твиттере появился хэштег #NoEstimates. Целью его создания была дискуссия о том, чем стоит заменить предварительные оценки стоимости и сроков проекта. Сама идея проекта без таких оценок звучит странно для большинства занимающихся разработкой софта, однако, если вникнуть, можно обнаружить более удачные источники информации.
Когда я впервые услышал о хэштеге #NoEstimates, он звучал странно, даже ересью. Как возможен проект без предварительных оценок? Разве не любому очевидно, что они являются основой для планирования, без которой ничего не сделаешь?
В последовавшие два года это превратилось в дискуссионую тему, и я многократно думал и писал об этом. Эта статья суммирует мое отношение к #NoEstimates и его реальные цели.
Что такое #NoEstimates?
Думаю, хэштег намеренно сделали провокационным. Но если посмотреть на сайт, видно, что на самом деле идея не настолько категоричная. Люди, породившие дискуссию (Вуди Зуилл, Нил Киллик и Васко Дуарте), говорят, что она посвящена альтернативам предварительным оценкам, а не просто отказу от них.
Однако это неизбежно породило у менеджеров проектов возражения и закономерные вопросы: «Но как без этого планировать? Не должен ли заказчик проекта, платящий за него, знать, в какую сумму проект обойдется и сколько займет его создание?»
Это очень хорошие вопросы.
Представьте, что вы наняли кого-то делать ремонт в кухне. Вы запрашиваете у него смету, и он говорит, что все обойдется в $20 000 и займет четыре недели. Вы знаете, что он ошибается. На практике получится вдвое дольше и вдвое дороже.
Но если вы уже это знаете, зачем вы спрашиваете изначально?
Если вы думаете «Мне нужны предположительные значения, чтобы работа оказалась сделана», прекращайте это. Будь у вас бесконечный запас времени и денег, она бы в любом случае оказалась сделана.
Нам не требуются предварительные оценки сами по себе. Но мы их жаждем.
Почему мы их жаждем?
Мы хотим их для того, чтобы принять решение. Основываясь на них, мы решаем, стоит ли проект того. Если он стоит слишком дорого или займет слишком долго, мы можем отменить его или отложить. Значит, если мы сравним различные оценки, сможем выбрать ту, которая подходит нам лучше.
Кроме того, они помогают в планировании. Например, если предполагается, что разработка продукта займет год, то его маркетинг начнется за пару месяцев до окончания этого года. А тренировать продажников начнут за месяц. Предварительные оценки дают нам эти представления, позволяющие точнее планировать.
Очевидно, что они важны: все хотят их получить. Но нюанс в том, что никто не любит их предоставлять.
Проблема с предварительными оценками
Вы когда-нибудь давали предварительную оценку, которая «магически» превращалась в обязательство? Эта организационная накладка происходит очень часто, и неточные прогнозы становятся дедлайнами, по соответствию которым оценивают разработчика.
Разработчики умны, поэтому не попадаются в эту ловушку дважды. Они делают прогнозы с запасом, потом команда добавляет времени на всякий случай, а затем еще начальник усиливает, чтобы точно получилось. Мы можем перейти от нескольких недель к месяцам, а то и годам.
И тут все уже становится неправильно. Если оценка нам нужна для того, чтобы принять решение, то у нас уже не те числа, на основании которых надо решать!
Мы настолько умны, что нашли решение для этого: если мы узнаем о проекте больше, то получаем более точное представление (да, бывает и такое). Если все согласны с требуемым объемом работы, то нет потребности в запасе. Так мы собираемся, дискутируем, встречаемся снова, порой неделями, чтобы как можно точнее оценить, что мы собираемся сделать. Через пару месяцев у нас наконец появляется число на руках. И за эту пару месяцев мы потратили сотни человекочасов на оценки и подсчеты вместо того, чтобы, собственно, создавать продукт.
Есть много проблем с оценками. Но главное даже не в этом.
Предварительные оценки не очень-то помогают
Я никогда не видел, чтобы проект отменили из-за них. Если он был достаточно ценным, мы находили способ его сделать. Зато я видел, как проекты откладывали из-за того, что их ценность была неопределенной. И приятно иметь несколько разных вариантов, но они все не имеют ценности, если в момент принятия решения всем им в равной степени не доверяешь. И покажите мне главу проекта, который настолько доверится моему сегодняшнему прогнозу, что через десять месяцев не переспросит меня, действительно ли можно начинать заниматься маркетингом.
Мы хотим получать предварительные оценки для принятия решений и планирования. Но, кажется, они не слишком полезные инструменты для этих задач.
Мы не доверяем прогнозам, потому что мы плохо их делаем. Мы пристрастны, мы излишне оптимистичны, мы думаем, что знаем о чем говорим, и осуществить проект будет раз плюнуть. А затем мы каждый раз оказываемся удивлены. Так что при встрече с предварительными оценками мы настроены скептично и правы в этом.
У нас есть также теоретическое обоснование для этого. Стив МакКоннелл познакомил мир с концепций Конуса Неопределенности двадцать лет назад. Когда мы делаем предварительную оценку проекта, мы знаем о нем меньше всего. Чем больше мы продвигаемся в работе, тем сильнее рассеивается туман и уточняются прогнозы. Но если требования меняются (а они всегда меняются), конус снова раскрывается, и все оценки летят псу под хвост.
Чего мы хотим на самом деле?
Мы хотим быть правы. Мы хотим принимать правильные решения и чувствовать себя уверенно в связи с этим. Оценки являются инструментами для этого, но полагаться ли только на них. Возможно, есть другой источник информации, способный помочь нам действовать правильно и уверенно.
Нил Киллик приводит такой пример. Вам нужно добраться куда-то поездом. Вы можете спросить «когда поезд отъезжает?», и я дам приблизительную оценку, которая помогает планировать. Но если бы я сказал «не буду гадать, когда отъезжает, но точно знаю, что они ходят через десять минут», это бы помогло принять лучшее решение?
При появлении новой информации точность предварительных оценок внезапно становится менее значимой.
Какие еще виды информации могут нам помочь?
Если оглянуться, можно увидеть и другие разновидности информации, на основании которой можно принимать решения.
Приоритезация по ценности: если мы оценим, какую ценность получим, а затем сравним с предполагаемыми расходами, сможем принять лучшее решение. Фокусироваться на ценности, а не стоимости, означает исходить из того, куда стоит инвестировать. Методы планирования вроде подсчета стоимости задержки ставят во главу угла ценность, позволяя легко сравнивать проекты и расставлять приоритеты.
Оценка сложности: оценить, насколько проект похож на другие и какая часть информации о них применима к вашей команде. Осуществлялся ли подобный проект ранее вашей командой? В вашей компании? Или он совершенно новый? Ответьте на это и поймете, чего стоят ваши оценки. Модель Лиз Кеох для оценки сложности может поместить ваши оценки в контекст.
Собирайте данные: опыт прошлого позволяет предсказывать куда точнее, чем внутренний голос. То, с какой скоростью работает команда над проектом, говорит о том, какой срок будет логичным для подобных проектов. Однако это может не быть применимо для других команд, технологий или областей, так что здесь стоит быть осторожным.
Снижайте вариативность: данные о скорости полезны, если проекты близки по размеру. Если на что-то всегда уходит три-четыре дня, то можно предсказывать. Если все очень по-разному, то уже точно не предскажешь. Команда должна уметь отмерять равные промежутки работы, и когда научится, прогнозировать станет можно куда надежнее.
Предполагайте, что ничего не знаете: бывший министр обороны США умно сводил категории знания к «о чем мы знаем, что это знаем», «что мы не знаем» и «о чем мы не знаем, что этого не знаем». По первым двум категориям мы составляем прогнозы, а третья рвет все наши прогнозы в клочья. Самое важное, что мы можем предположить: что мы ничего не знаем и все известное нам лишь предположения.
Подсчитывайте свои предположения: наши оценки основаны на предположениях, и лучше сначала обсудить предположения, а потом уже переходить к основанным на них прогнозам. Когда мы делаем известными наши предположения, происходит забавная вещь: они могут быть раскритикованы, одобрены или разгромлены. Критика, которую придется получить, довольно скромная плата за то, чтобы основываться на оторванных от реальности предположениях.
Экспериментируйте: наконец, стоит ли брать все из головы? Возможно, стоит на практике попытаться понять, что нам предстоит сделать. Вместо создания плана на основе наших высосанных из пальца можно экспериментально проверить многие предположения. Мы можем запланировать набор маленьких, бюджетных, не угрожающих нам в случае провала экспериментов, которые покажут, какие из предположений верны, и покажут путь к успешному продукту, а не болезненному провалу.
Существуют проекты, сделанные вообще без прогнозов. Но для такого подхода требуется, чтобы окружение его понимало. Если ваша организация еще не достигла понимания, попытайтесь научить окружающих вас людей хотя бы использовать альтернативы в качестве дополнения прогнозов, если не замены. Ограничьте время на высчитывание оценок и вместо этого отведите его на быстрое получение фидбэка о предположениях.
Когда я начинал изучать #NoEstimates, идея казалась мне странной. Теперь странным мне кажется традиционный подход. Хотя очень легко спросить «В какую сумму это обойдется», я теперь почти автоматически вместо этого пытаюсь совершать решения, основанные в меньшей степени на предположениях и в большей на реальной информации. Это логичнее, не правда ли?
Когда я впервые услышал о хэштеге #NoEstimates, он звучал странно, даже ересью. Как возможен проект без предварительных оценок? Разве не любому очевидно, что они являются основой для планирования, без которой ничего не сделаешь?
В последовавшие два года это превратилось в дискуссионую тему, и я многократно думал и писал об этом. Эта статья суммирует мое отношение к #NoEstimates и его реальные цели.
Что такое #NoEstimates?
Думаю, хэштег намеренно сделали провокационным. Но если посмотреть на сайт, видно, что на самом деле идея не настолько категоричная. Люди, породившие дискуссию (Вуди Зуилл, Нил Киллик и Васко Дуарте), говорят, что она посвящена альтернативам предварительным оценкам, а не просто отказу от них.
Однако это неизбежно породило у менеджеров проектов возражения и закономерные вопросы: «Но как без этого планировать? Не должен ли заказчик проекта, платящий за него, знать, в какую сумму проект обойдется и сколько займет его создание?»
Это очень хорошие вопросы.
Представьте, что вы наняли кого-то делать ремонт в кухне. Вы запрашиваете у него смету, и он говорит, что все обойдется в $20 000 и займет четыре недели. Вы знаете, что он ошибается. На практике получится вдвое дольше и вдвое дороже.
Но если вы уже это знаете, зачем вы спрашиваете изначально?
Если вы думаете «Мне нужны предположительные значения, чтобы работа оказалась сделана», прекращайте это. Будь у вас бесконечный запас времени и денег, она бы в любом случае оказалась сделана.
Нам не требуются предварительные оценки сами по себе. Но мы их жаждем.
Почему мы их жаждем?
Мы хотим их для того, чтобы принять решение. Основываясь на них, мы решаем, стоит ли проект того. Если он стоит слишком дорого или займет слишком долго, мы можем отменить его или отложить. Значит, если мы сравним различные оценки, сможем выбрать ту, которая подходит нам лучше.
Кроме того, они помогают в планировании. Например, если предполагается, что разработка продукта займет год, то его маркетинг начнется за пару месяцев до окончания этого года. А тренировать продажников начнут за месяц. Предварительные оценки дают нам эти представления, позволяющие точнее планировать.
Очевидно, что они важны: все хотят их получить. Но нюанс в том, что никто не любит их предоставлять.
Проблема с предварительными оценками
Вы когда-нибудь давали предварительную оценку, которая «магически» превращалась в обязательство? Эта организационная накладка происходит очень часто, и неточные прогнозы становятся дедлайнами, по соответствию которым оценивают разработчика.
Разработчики умны, поэтому не попадаются в эту ловушку дважды. Они делают прогнозы с запасом, потом команда добавляет времени на всякий случай, а затем еще начальник усиливает, чтобы точно получилось. Мы можем перейти от нескольких недель к месяцам, а то и годам.
И тут все уже становится неправильно. Если оценка нам нужна для того, чтобы принять решение, то у нас уже не те числа, на основании которых надо решать!
Мы настолько умны, что нашли решение для этого: если мы узнаем о проекте больше, то получаем более точное представление (да, бывает и такое). Если все согласны с требуемым объемом работы, то нет потребности в запасе. Так мы собираемся, дискутируем, встречаемся снова, порой неделями, чтобы как можно точнее оценить, что мы собираемся сделать. Через пару месяцев у нас наконец появляется число на руках. И за эту пару месяцев мы потратили сотни человекочасов на оценки и подсчеты вместо того, чтобы, собственно, создавать продукт.
Есть много проблем с оценками. Но главное даже не в этом.
Предварительные оценки не очень-то помогают
Я никогда не видел, чтобы проект отменили из-за них. Если он был достаточно ценным, мы находили способ его сделать. Зато я видел, как проекты откладывали из-за того, что их ценность была неопределенной. И приятно иметь несколько разных вариантов, но они все не имеют ценности, если в момент принятия решения всем им в равной степени не доверяешь. И покажите мне главу проекта, который настолько доверится моему сегодняшнему прогнозу, что через десять месяцев не переспросит меня, действительно ли можно начинать заниматься маркетингом.
Мы хотим получать предварительные оценки для принятия решений и планирования. Но, кажется, они не слишком полезные инструменты для этих задач.
Мы не доверяем прогнозам, потому что мы плохо их делаем. Мы пристрастны, мы излишне оптимистичны, мы думаем, что знаем о чем говорим, и осуществить проект будет раз плюнуть. А затем мы каждый раз оказываемся удивлены. Так что при встрече с предварительными оценками мы настроены скептично и правы в этом.
У нас есть также теоретическое обоснование для этого. Стив МакКоннелл познакомил мир с концепций Конуса Неопределенности двадцать лет назад. Когда мы делаем предварительную оценку проекта, мы знаем о нем меньше всего. Чем больше мы продвигаемся в работе, тем сильнее рассеивается туман и уточняются прогнозы. Но если требования меняются (а они всегда меняются), конус снова раскрывается, и все оценки летят псу под хвост.
Чего мы хотим на самом деле?
Мы хотим быть правы. Мы хотим принимать правильные решения и чувствовать себя уверенно в связи с этим. Оценки являются инструментами для этого, но полагаться ли только на них. Возможно, есть другой источник информации, способный помочь нам действовать правильно и уверенно.
Нил Киллик приводит такой пример. Вам нужно добраться куда-то поездом. Вы можете спросить «когда поезд отъезжает?», и я дам приблизительную оценку, которая помогает планировать. Но если бы я сказал «не буду гадать, когда отъезжает, но точно знаю, что они ходят через десять минут», это бы помогло принять лучшее решение?
При появлении новой информации точность предварительных оценок внезапно становится менее значимой.
Какие еще виды информации могут нам помочь?
Если оглянуться, можно увидеть и другие разновидности информации, на основании которой можно принимать решения.
Приоритезация по ценности: если мы оценим, какую ценность получим, а затем сравним с предполагаемыми расходами, сможем принять лучшее решение. Фокусироваться на ценности, а не стоимости, означает исходить из того, куда стоит инвестировать. Методы планирования вроде подсчета стоимости задержки ставят во главу угла ценность, позволяя легко сравнивать проекты и расставлять приоритеты.
Оценка сложности: оценить, насколько проект похож на другие и какая часть информации о них применима к вашей команде. Осуществлялся ли подобный проект ранее вашей командой? В вашей компании? Или он совершенно новый? Ответьте на это и поймете, чего стоят ваши оценки. Модель Лиз Кеох для оценки сложности может поместить ваши оценки в контекст.
Собирайте данные: опыт прошлого позволяет предсказывать куда точнее, чем внутренний голос. То, с какой скоростью работает команда над проектом, говорит о том, какой срок будет логичным для подобных проектов. Однако это может не быть применимо для других команд, технологий или областей, так что здесь стоит быть осторожным.
Снижайте вариативность: данные о скорости полезны, если проекты близки по размеру. Если на что-то всегда уходит три-четыре дня, то можно предсказывать. Если все очень по-разному, то уже точно не предскажешь. Команда должна уметь отмерять равные промежутки работы, и когда научится, прогнозировать станет можно куда надежнее.
Предполагайте, что ничего не знаете: бывший министр обороны США умно сводил категории знания к «о чем мы знаем, что это знаем», «что мы не знаем» и «о чем мы не знаем, что этого не знаем». По первым двум категориям мы составляем прогнозы, а третья рвет все наши прогнозы в клочья. Самое важное, что мы можем предположить: что мы ничего не знаем и все известное нам лишь предположения.
Подсчитывайте свои предположения: наши оценки основаны на предположениях, и лучше сначала обсудить предположения, а потом уже переходить к основанным на них прогнозам. Когда мы делаем известными наши предположения, происходит забавная вещь: они могут быть раскритикованы, одобрены или разгромлены. Критика, которую придется получить, довольно скромная плата за то, чтобы основываться на оторванных от реальности предположениях.
Экспериментируйте: наконец, стоит ли брать все из головы? Возможно, стоит на практике попытаться понять, что нам предстоит сделать. Вместо создания плана на основе наших высосанных из пальца можно экспериментально проверить многие предположения. Мы можем запланировать набор маленьких, бюджетных, не угрожающих нам в случае провала экспериментов, которые покажут, какие из предположений верны, и покажут путь к успешному продукту, а не болезненному провалу.
Существуют проекты, сделанные вообще без прогнозов. Но для такого подхода требуется, чтобы окружение его понимало. Если ваша организация еще не достигла понимания, попытайтесь научить окружающих вас людей хотя бы использовать альтернативы в качестве дополнения прогнозов, если не замены. Ограничьте время на высчитывание оценок и вместо этого отведите его на быстрое получение фидбэка о предположениях.
Когда я начинал изучать #NoEstimates, идея казалась мне странной. Теперь странным мне кажется традиционный подход. Хотя очень легко спросить «В какую сумму это обойдется», я теперь почти автоматически вместо этого пытаюсь совершать решения, основанные в меньшей степени на предположениях и в большей на реальной информации. Это логичнее, не правда ли?
