Оценка: лучшее, что мы можем сделать

ИЗ АРХИВА ЖУРНАЛА PRAGPUB Апрель 2013

Оценка: лучшее, что мы можем сделать

Автор Рон Джеффрис

Два месяца назад на этих страницах Рон Джеффрис сказал нам, что оценка — это зло. Теперь он вернулся, чтобы сказать нам, что это необходимое зло — и что, если все сделано правильно, это даже не зло.

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

К сожалению, это приводит к распространенному наивному мнению среди потенциальных практиков Agile, чье обучение находится на ранней стадии: они хотят полностью отменить оценку. Это, вероятно, невозможно и, конечно, не идеально. У нас есть возможность оценить, насколько быстро мы можем сделать некоторые вещи, и бизнес может принимать лучшие решения, если мы поделимся своими знаниями.

Разработка — это не просто отлаженная машина, которая быстро запускает функции. Я знаю, что приятно думать, что мы не несем ответственности за заботы бизнеса о деньгах, времени и датах. Это просто неправда. То, что мы создаем, — это не только прерогатива какого-то Владыки Продукта, который решает, что мы будем делать, и берет на себя весь риск. Деловые люди могут принимать окончательные решения, но многие решения лучше всего принимаются командой — не только о том, как что-то делать, но и о том, что делать. Мы несем ответственность за помощь в реализации проекта, используя наш творческий потенциал и наши специальные знания.

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

Проблемы с оценкой

Действительно, существует ряд серьезных проблем, связанных с оценкой работы программного обеспечения. В предыдущей статье Оценка — это зло я описал некоторые из них. Давайте рассмотрим:

• Заранее определенные невыполненные работы снижают креативность и мешают успешному управлению проектом.
• Требовать доставки «всего» к какой-то фиксированной дате — уловка, которая никогда не сработает.
• Отношение к оценкам как к обещаниям приводит к консервативным командам и разочаровывающим результатам.
• Попытка улучшить «качество» оценок — это внимание, которое можно было бы лучше уделить улучшению качества продукта.
• И так далее.

В этой статье я утверждаю, что результатом такого внимания является «слабый Agile». По сути, команды, сосредоточенные на оценке, обычно работают на коротком конце рычага соотношения затрат и ценности. Лучшие команды уделяют больше внимания ценности и меньше затратам. Они по-прежнему учитывают стоимость, потому что стоимость является одним из важных компонентов создания ценности. Но ценность — их главный интерес.

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

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

Бюджетирование нового проекта

Теперь давайте рассмотрим только одну законную потребность — помощь организации в принятии решения о продолжении проекта.

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

Деловые люди, составляющие бюджет проектов, сталкиваются с той же проблемой распределения средств. Им необходимо подумать о том, как обеспечить максимально возможную ценность в рамках бюджета. В небольшой организации, пытающейся создать удивительный новый продукт, проблема еще более актуальна. Нам нужно начать генерировать положительный денежный поток, прежде чем у нас закончатся деньги!

В подобных ситуациях нам действительно нужна некоторая оценка. Нам нужно знать, разумно ли браться за этот новый проект. У деловых людей уже есть некоторые оценки: сколько людей будет заинтересовано? Какой процент потенциальных клиентов превратится в покупателей? Сколько покупатели будут платить за продукт?

Но им нужно решить: сможем ли мы начать зарабатывать достаточно денег, чтобы остаться в живых до того, как наши деньги закончатся?

Лицо, принимающее решения, знает, что все эти оценки являются оценками, и использует свои лучшие суждения, чтобы оценить их. Но есть ключевая область, о которой он мало что знает: какой объем этого продукта мы можем сделать, к какому сроку и за сколько денег? Это технический вопрос, и на него должны ответить технические специалисты.

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

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

Разве мы не можем просто сказать: «Попробуй?» Кажется, мы должны быть в состоянии сказать что-то вроде этого:

Наша команда стоит десять тысяч долларов в неделю. Давайте начнем работать над самыми важными, самыми рискованными, самыми информативными частями вашего продукта и создадим ощущение того, насколько это сложно и сколько времени это займет. Вы увидите, как мы строим то, что вы просите. Вы увидите, как это работает. Вы сможете решить, продолжать ли инвестировать или остановиться».

Кажется, это имеет смысл говорить, если только это не ваша личная Десять Больших, которые выходят каждую неделю. Тогда у вас есть еще вопросы. «Узнаю ли я об этом через неделю? Придется ли мне ждать месяц, чтобы узнать? Узнаю ли я к июню? Святая корова, ребята, до июня осталось больше сотни штук. Это большие деньги! Отрежь мне здесь перерыв, ладно? Сколько эта штука будет стоить?

Нам нужно подойти к такому вызову. Мы должны дать как можно более основательный ответ, даже если у нас нет абсолютно конкретного ответа.

Мы стоим на песке. Как мы получаем бетон?

Вопрос заключается в следующем: «Сколько времени и сколько денег потребуется, чтобы получить продукт, который люди могут купить?»

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

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

Предположим, мы думаем, что, возможно, мы могли бы получить элементарный, но пригодный для использования продукт через шесть месяцев, и инвестор готов инвестировать около миллиона долларов, чтобы получить положительный денежный поток. Миллион долларов — это примерно год нашего времени, и если бы нам потребовалось девять месяцев, а не шесть, нам нужно было бы заработать миллион долларов за три месяца, чтобы получить положительный результат. Давайте поговорим об этом. Насколько быстро, по его мнению, вырастет доход с первым релизом? Предположим, он думает, что выручка будет расти так быстро, что, если мы возьмем девять месяцев, все будет в порядке. Это звучит рискованно для меня, но похоже, что этот проект, по крайней мере, стоит изучить.

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

Оценка, с которой можно жить

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

Итак, давайте сделаем это: давайте возьмем две недели, чтобы дать более конкретный ответ. Две недели обойдутся вам всего в 20 000 долларов, что намного меньше миллиона. В течение этих двух недель вы будете активно работать с нами над наиболее важными аспектами продукта. Некоторые из них будут связаны с внешним видом и ощущениями, а некоторые будут обусловлены другими бизнес- или техническими рисками, которые мы можем предвидеть сейчас. По истечении двух недель мы решаем, стоит ли двигаться дальше. Наша работа состоит в том, чтобы конкретно показать вам, что мы можем построить, чтобы убедить всех нас, стоит ли нам двигаться вперед. Ваша работа заключается в том, чтобы направлять нас, описывая, что вы хотите, и работать с нами над выявлением рисков и опасений.

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

Да все верно. Каждые две недели мы будем говорить с вами о том, что делать дальше. Мы это сделаем и покажем вам. Если будет достаточно, продолжим. Если нет, мы остановимся.

Таким образом, ваш риск никогда не превышает еще 20 000 долларов. Вы можете решить, использовать ли эти деньги, чтобы получить больше информации, перенаправить наши усилия или лучше потратить их как-то иначе.

Можем ли мы так работать?

Если он скажет да, давайте начнем. Если он говорит «нет», нам нужно выяснить, почему, и подходит ли нам этот проект.

Это определенно оценка, и это своего рода оценка, которую мы можем проводить совместно с людьми из нашего бизнеса, а не в конфликте с ними.

Мы оцениваем с некоторой уверенностью, что сможем предоставить полезную информацию за две недели. Если мы думаем, что не сможем этого сделать, нам лучше предложить четыре, шесть или восемь недель.

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

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

Когда дело доходит до траты чужих денег, я думаю, что мы в долгу перед ними.

Это оценка, а не переговоры!

Смета не обязательно должна быть такой: «Этот проект будет выполнен во вторник, 14 мая, в 14:35». Оценка должна выражать диапазон возможностей. Было бы совершенно нормально сказать что-то вроде: «Мы не видим возможности сделать это в апреле. Если все пойдет идеально, мы можем быть готовы в середине мая. Основываясь на нашем опыте, мы думаем, что июнь, может быть, июль».

Говорим мы это или нет, скорее всего, мы это знаем или подозреваем. И если это то, что мы думаем, проекту нужна эта информация. Однако, если мы скажем так, мы получим отпор. Кто-то собирается бросить нам вызов, чтобы доказать без тени сомнения, что мы не можем сделать это к 30 апреля, и если каким-то образом мы это сделаем, они скажут: «А как насчет 5 мая?» Ба, мы ненавидим, когда они так делают. Так как же мы можем дать проекту необходимую информацию, не играя в эту игру?

Переход от оценки даты к оценке скорости

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

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

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

Тебе решать. Мы можем разделить вещи до такого размера, мы можем оценить нашу скорость сейчас примерно как три элемента в две недели, и каждые две недели вы будете знать, что происходит на самом деле. Вы можете использовать эту информацию, чтобы решить, что делать, а что отложить, чтобы получить наилучший продукт на любую дату, которую вы выберете.

Помогите руководству научиться использовать Velocity

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

Кто-то может попытаться увеличить скорость. «Разве ты не можешь делать семь раз в две недели? Таким образом, вы могли бы закончить работу вовремя».

Помните, как работает Agile: разработчики работают в оптимальном устойчивом темпе; разработчики не отвечают за даты; деловая сторона владеет сроками и несет ответственность за соблюдение сроков.

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

Мы думаем, что сможем сделать от трех до пяти. Если мы поедем быстрее, ты узнаешь. Если мы пойдем медленнее, вы тоже это узнаете. Когда мы закончим, зависит от этого, но еще больше зависит от того, сколько или как мало вы даете нам сделать. Что поставить в дате, зависит от вас. Вы должны планировать от трех до пяти пунктов в две недели и следить за тем, что происходит на самом деле.

Они могут нажимать более одного раза для ускорения. Но в нашем распоряжении есть факты, как они есть.

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

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

Мы даем руководству наши наилучшие оценки производительности и придерживаемся их, улучшая их только по мере того, как учимся. Мы продолжаем разъяснять, что деловые люди контролируют свидание, выбирая, сколько работы они просят.

Оптимизация продукта

Независимо от того, любите вы оценки или нет, вы должны знать, что Agile заключается в создании продукта постепенно, в хорошем состоянии с первого дня и до самого конца, и как можно скорее извлекать из него пользу. Это требует больших технических навыков, но технических навыков недостаточно. Люди, оплачивающие нашу работу, должны выделять свои ресурсы. Им нужно управлять своими денежными средствами, и им необходимо координировать нашу работу с действиями и заинтересованными сторонами за пределами нашей команды.

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

Отказ от оценки — неправильный способ сделать это. Оценка необходима, а также необходима эффективная передача оценок.

Лучший способ сделать что-то — разработать небольшие функции в максимально возможном устойчивом темпе и использовать полученную информацию, чтобы помочь деловым людям решить, что просить, а что отложить. Для этого мы должны сделать оценку. Мы нарезаем истории до предполагаемого небольшого размера и оцениваем скорость их доставки. Такая оценка вовсе не плоха: она невероятно полезна, и ею занимаются лучшие agile-команды.

Вас также может заинтересовать…

об авторе

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

Возьмите его книгу The Nature of Software Development на The Pragmatic Bookshelf: