No Estimates!!!

Автор: Асхат Уразбаев

На самом деле, тут есть два нюанса… Первое — это то, что точная оценка занимает довольно много времени: чем точнее оценка, тем дольше. И в плохих случаях, по нашим замерам, она занимает до 40% времени. То есть 40% времени разработчик тратит на то, чтобы получить запрос, разобраться, оценить его! Это, по большей части, потерянное время.

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

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

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

И это занимает какое-то время, чтобы исправить.

Вторая вещь — это изменения. Время от времени прибегает заказчик и говорит: «Знаете, я вот тут подумал, подумал — надо всё сделать по-другому».

Приходится тратить время на то, чтобы переделать проект либо просто переформулировать, двинуть в другом направлении. Это тоже занимает довольно много времени.

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

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

Сейчас уже есть инструменты и методы, которые позволяют сделать постоянную поставку результата. Это — то, что называется «continuous delivery», постоянная поставка. Идея такая: заказчик просит сделать какую-то эту вещь, вы начинаете делать. Как только она готова, вы не ждёте даты релиза, выкладываете, и заказчик сразу может это использовать. То есть время проходит очень небольшое. При этом можно добиться высокого качества, чтобы ничего не ломалось. Результат заказчик получает за очень небольшое время.

Можно поставлять результат очень быстро, быстрее, чем он может передумать. И потребность заказчика в оценке падает. Ему уже неинтересно спрашивать у вас сроки. Он не прибегает с вопросом: «Когда?». Потому что он знает, что если он вас попросит, то вы сделаете быстрее, чем он успеет поменять свои требования.

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

Опять-таки это тренд, поэтому о плюсах и минусах можно говорить условно. Но тут, пожалуй, из минусов я упомяну следующее. Это некоторый «hype», то есть люди обращают на это внимание, говорят «О, No Estimates — это круто!». И знаете, есть такая вещь, они говорят: «Мы ничего не оцениваем, мы уже «No Estimates», мы используем безоценочный метод работы». При этом заказчик недоволен, качество работы низкое, всё валится, падает и т. д. То есть они не добились некоторых предпосылок. Тем не менее, говорят: «Мы ничего не оцениваем, мы в тренде, мы молодцы». Это немного забавно выглядит со стороны. По большому счету никакой ценности это не несёт.

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

А когда люди не оценивают, а просто берут куском, не разбивая на части, они поставляют долго. Это не то, что нужно заказчику, потому что прошло 2-3 месяца, и он успел десять раз передумать.

Поэтому я часто своим ребятам говорю: «Для того чтобы отказаться от оценки, надо сначала научиться хорошо оценивать. И только на следующем этапе — отказаться от оценки». Плюсы No Estimates понятны — это огромная экономия времени и быстрая поставка. А минусы — это неправильное понимание того, что это означает.

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

Во-первых, постепенно огрублялась оценка в индустрии. Сначала оценивали в часах, с точностью до часа. Понятно, что 76-77 часов — абсолютно бессмысленная точность. Правда? Потому что мы всё равно знаем, что всё поменяется. Заказчик, скорее всего, передумает. Потом оценивать стали в днях, потом оценку делали всё более и более грубой, потом, в какой-то момент, начали оценивать в некоторых условных единицах, которые в IT-бизнесе называются story points.

Вторая вещь, которая произошла, — перестали оценивать по тому, сколько люди могут работать. Например, человек работает 8 часов в день. Задачу оценили в восемь часов — значит, он будет работать один день. Оказывается, это не точная оценка. Реально разработчик работает в несколько раз медленнее.

Разница может составлять 2-3 раза. Обычно айтишники шутят, что это число между E и Пи, то есть между 2,7 и 3,14. Причем никто не знает, где точно эта граница проходит. Стали считать просто: сколько сделали в этих условных единицах за прошлый период. Такие периоды называются итерациями, или спринтами. Например, за прошлую неделю мы сделали 20 этих условных единиц. Дальше предполагаем, что в следующую итерацию мы сделаем тоже 20.

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

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

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

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

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

No Estimates — это использование таких вот интересных статистических методов предсказания.

Своим коллегам я бы рекомендовал не фокусироваться на самом

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

* Асхат Уразбаев, Управляющий партнер ScrumTrek, совладелец SkillTrek, GameTrek

Прошел вполне типичную карьеру от младшего разработчика до менеджера проектов в небольшой софтверной компании.

В Luxoft занимался внедрением «тяжелых» традиционных методологий разработки программного обеспечения в подразделениях компании. Затем довелось поучаствовать в некоторых Agile проектах.В 2006 году стал заниматься внедрением гибких методологий в подразделениях компании. В марте 2006 года основал движение практиков гибкой разработки AgileRussia.

В 2008 году вместе с Никитой Филипповым основал компанию ScrumTrek, которая консультирует, проводит тренинги и помогает компаниям внедрять гибкие методологии. Среди клиентов ScrumTrek такие компании, как Яндекс, Rambler, Skype, Альфа-Банк, Связной и другие. Один из организаторов конференций AgileDays и AgileCamp.

Беседовала Екатерина Кахраман