Меня зовут Александр Белов, и я – трудоголик. Однажды я автоматизировал общепит, с той поры втянулся и уже более 20 лет занимаюсь автоматизацией учета и управления.
Термин #NoEstimates («Без оценок»), скорее всего, уже знаком многим специалистам. Но, прежде чем перейти к его обсуждению, предлагаю ответить на несколько вопросов – выполняли ли вы хоть раз оценку проекта или задачи? Ошибались ли вы в оценке? Или верите, что ни разу не ошибались? Считаете ли вы, что разработка без оценок – это полный бред? Или, наоборот, считаете, что разработка и должна быть без оценок? Попробуем разобраться.
Статистика успешности проектов
Есть такая компания Standish Group, аналитики которой регулярно выпускают так называемые Chaos Report – отчеты по статистике успешности программных проектов.
Успешный проект – это тот, который укладывается в тройственное ограничение «3С» – содержание, сроки, стоимость. В нем содержание, сроки и стоимость полностью совпадают с тем, что было изначально запланировано.
Так вот, согласно статистике успешности программных проектов:
- По крупным проектам в 1995 году количество успешных составляло 9%, а в 2015 году – 10,5%. Это говорит о том, что за 20 лет в индустрии среди крупных проектов успешных стало только на 1,5% больше.
- Среди средних проектов в 1995-м году было 16,2% успешных, а в 2015 году их стало 17% (разница менее 1%).
- По малым проектам ситуация уже лучше – в 1995 успешных было 28%, а пару лет назад их стало 49%.
Причем, если посмотреть статистику успешности в привязке к «водопадной модели» и к гибким методикам Agile, то те, кто использует «водопадную модель», значительно проигрывают тем, кто использует Agile:
- Крупные проекты, сделанные по «водопадной модели», скатились до 3% успешности. И только гибкие методики дают возможность хоть как-то улучшить статистику.
- Также обратите внимание на процент успешности в малых проектах: 44% - «водопадная модель», 55% – гибкие методики.
Вопрос: Какова вероятность, встретить на улице динозавра? Ответ: 50%, так как у этого события всего два исхода - либо встретишь, либо нет.
Таким образом, максимальная определенность в оценке появляется только на малых проектах, и это – вероятностная характеристика. Практически угадывание, а не оценивание.
Кто и когда придумал отказаться от оценок
- В 1995 году Agile еще не было – Agile Manifesto появился в 2001 году.
- В 2013 году, одновременно с пятой редакцией PMBoK, появился термин «NoEstimates».
- Сейчас уже анонсирована 6 редакция PMBoK, она должна появиться в конце 2017 – начале 2018 года, и в ней уже содержатся материалы по управлению оценками по гибким методикам, включающие метод «Без оценок».
Сам термин «NoEstimates» зародился в Твиттере, как холивар (спор) между сторонниками гибких методик – Вуди Зуйлом, Ником Кликом и Васко Дуарте.
Васко Дуарте выпустил книгу, которая так и называется #NoEstimates. На русском языке я ее не нашел, но ее можно купить в интернете и прочитать на английском.
В русскоязычной индустрии разработки программного обеспечения использовать терминологию #NoEstimates начали примерно в 2014-2015 году. В 2015-ом году Асхат Уразбаев даже делал на эту тему большой доклад для разработчиков.
Разные методы оценки
Существует множество разных методов оценки проектов. Среди наиболее популярных:
- нормативный метод оценки;
- покер-планирование;
- экспертная оценка;
- по точкам;
- метод аналогий;
- ресурсное планирование;
- метод «Три П» (пол, палец, потолок), когда оценку берут «с потолка»;
- метод «За сколько купят» или «Г-в-Г» – глаза в глаза. Это – когда приходишь к заказчику, рассказываешь о проекте и называешь примерную цифру «с потолка», а потом смотришь ему в глаза. Если он «поплыл», значит, сумма для него высоковата. Если оживился, то, видимо, можно было и еще больше денег попросить. Так по реакции, по глазам, тоже можно оценивать.
- сметная оценка;
- научные методы – я их сейчас перечислять не буду;
- оценка по детальному перечню работ – самая точная. К каждой детали применена экспертная оценка, плюс метод аналогий. Единственный ее недостаток в том, что, для получения этого детального перечня работ их нужно сначала выполнить, либо обладать предвидением.
Сервис оценки за 5 минут
Недавно в сети появился любопытный сервис, на котором за 5 минут обещают оценить любой проект по 1С – бесплатно, без регистрации и дополнительных вопросов. Чтобы проверить, насколько качественно этот сервис работает, я взял свою реальную задачу по проекту 2015 года, где заказчик хотел перейти с переработанной базы на «1С:УПП» на типовую «1С:ERP» в части регламентированного учета (бухгалтерский, налоговый учет, плюс зарплата и управление персоналом).
Написал в этом сервисе свой вопрос и стал ждать. Несколько минут сайт никак не реагировал, а потом мне ответили: «Здравствуйте! Поначалу крайне рекомендую вести учет в двух системах». Через минуту-полторы приходит еще одно сообщение: «Потому как в ERP проводки у документов создаются фоновым заданием или регламентной процедурой».
Затем еще одно: «Плюс, если хотите поменять счет у проводки, это тоже не так просто сделать. Счета учета хранятся в специальных группах финучета, которые, например, присваиваются договорам».
Ответы совсем никак не относились к вопросу – возникло ощущение, что меня просто отговаривают. Я настоял, что все-таки хочу оценить проект.
На что мне дали уже конкретный ответ: «59 600 рублей. Без оборотов». Хитро, смешно, интересно.
Тогда я спрашиваю: «А если мне еще нужно перенести кадровые данные по 1200 сотрудникам, включая договоры гражданско-правового характера?». Мне отвечают (орфография сохранена): «Также содержаться в упп? Тогда вам нужен и средний и кадровая история. Стоимость работ вырастет и может составить в среднем от 150 до 200 тысяч рублей».
Я спрашиваю: «А если добавить обороты за 2017 год, чтобы годовую отчетность 2017 сдавать уже в ERP?». Мне ответили, что по предварительной оценке, стоимость работ может вырасти с 200 до 300 тысяч рублей.
Я уже начал выходить из себя, спрашиваю: «Назовите срок и стоимость, за которые вы возьметесь решить эту задачу, включая кадровые данные». Мне отвечают: «По сроку – полтора-два месяца, по стоимости – 300 тысяч рублей».
На самом деле, когда эта задача реально выполнялась, на нее было потрачено в 30 раз больше. Поэтому вы, конечно, можете использовать этот сервис, но потом не забудьте результат умножить на 30, и то, все равно не попадете.
Для чего вообще нужна оценка?
В начале проекта и разработчикам, и заказчику нужно принять какое-то решение и начать планировать. Большинство считает, что для этого проект нужно оценить. Но, на деле, эта оценка не годится для планирования. Потому что все планируется в точке максимальной неопределенности по проекту. Как на слайде – гладко было на бумаге, да забыли про овраги.
В реальности такая оценка никаким образом не связана с будущим, только если у нас нет хрустального шара, который действительно предсказывает будущее.
Делать оценку для принятия решения тоже крайне сомнительно. Вы находитесь в точке максимальной неопределенности, содержание – неизвестно. Этот треугольник качества у меня на слайде нарисован неправильно, он должен стоять на острие срока и стоимости, балансируя с лошадкой наверху:
- Какие будут работы – неизвестно;
- Какая будет команда – неизвестно;
- Какие внешние условия – неизвестно;
- Какие факторы, вызывающие взаимозависимость команды, если это достаточно крупный проект – неизвестно;
- Как будет коммуницировать заказчик, и какие политические силы на него будут воздействовать – неизвестно.
План в этом случае – это вероятностная характеристика, или, другими словами, прогноз. И основная проблема оценки в том, что к этому прогнозу все относятся по-разному.
Я по образованию – инженер-океанолог, и знаю, что при расчете метеопрогнозов используются численные методы расчетов на основе предыдущих данных. Берется большой объем предыдущих данных, и при помощи определенных численных методов делается прогноз. Если прогноз составляется больше чем на 2 календарных дня, и сходимость метода получается 34% – это считается успехом. А если сбываемость прогноза на один - два дня – 50%, то это вообще ошеломительный успех. Считали, считали различными численными методами, а получили оценку, сопоставимую с вероятностью “встретить динозавра на улице”.
И применительно к проектам, как показывает статистика успешности, прогнозная модель подходит только к малым проектам, но и в этом случае точность оценки, как “встретить динозавра”.
Проблемы предварительной оценки
Какие проблемы есть у предварительной оценки?
- Она может внезапно стать обязательством, даже если не включена в контракт. Например, если вы в разговоре с заказчиком называете какие-то цифры, то заказчик слышит ту из них, которую хочет услышать. И считает почему-то, что это – фиксированная цена (fixed price), по которой вы будете с ним работать. Неважно, включена эта оценка в контракт или не включена, но она уже превратилась в обязательство. Причем, из крайних цифр заказчик обычно запоминает наименьшую, а вы можете думать, что он вам заплатит наибольшую, плюс еще риски, надбавки за переработки и т.д.
- Другая проблема – это закон Паркинсона. Вы, работая по методу Time and material (сколько бюджета выделено, столько и работ будет рассчитано), можете начать злоупотреблять доверием заказчика, и работы у вас станут занимать все отведенные на них время и деньги. И, чем больше вы будете планировать времени и денег, тем дольше будут выполняться работы, и вы станете «доить» заказчика.
- Или, если вы с запасом заложите в фиксированную цену различные риски, у вас может получиться цена на уровне отказа, и вы потеряете проект.
- Еще одна проблема предварительной оценки – это непроизводительные потери времени. Когда вам нужна достаточно точная оценка, на это требуются большие затраты. Чем крупнее проект, тем тщательнее нужно проанализировать, какие там будут работы. При этом огромные усилия тратятся на совещания, встречи, выбор из ничего. Однако, как мы уже знаем по статистике успешности, предварительная оценка совпадает с реальными затратами только в 50% и то, только на коротких проектах.
Хочу отметить, что в самом методе Time and material ничего плохого нет. Мы работаем именно по этой схеме – выработка у нас меняется в зависимости от поступления требований и соответствующего количества денег. На слайде показан пример сотрудничества с одним из наших заказчиков. По горизонтали – количество месяцев сотрудничества (всего 97 месяцев). По вертикали – значения выработки (часов в месяц).
Новый подход – без оценок. Что надо делать?
Мы приходим к выводу, что, какие бы мы усилия ни прикладывали, результативность оценки всегда получается низкая. Поэтому и возникло направление, связанное с работой «без оценок». Это, конечно, скорее, провокационный хэштег, потому что совсем без оценок не обойтись. Но этот принцип можно сформулировать с помощью девиза, который гласит, что жить надо по-японски: «Не торопиться, не волноваться и улыбаться».
Или, иными словами, нужно непрерывно доставлять ценность.
- Что такое «непрерывно»?
- Попробуйте представить себе ситуацию – вы опаздываете на электричку, а я иду вам навстречу. Вам надо успеть, и вы спрашиваете у меня, когда придет электричка. Я отвечаю, что через 15 минут. Запомните свои ощущения.
- А теперь представьте другую ситуацию – вы бежите, встречаете меня и опять спрашиваете, когда отходит электричка. Я вам на это отвечаю, что электрички ходят каждые 10 минут.
Сравните свои ощущения в первом случае и во втором. Понимаете разницу? Суть в том, что вторая информация была для вас более комфортной. Появляется ощущение и понимание непрерывности, потому что раз в 10 минут – это не то же самое, что через 15 минут, и вам не нужно что-то делать, чтобы успеть.
- Что такое «доставлять» – понятно.
- А что такое «ценность»? Как понять, ценность ли это?
В 60-80-е годы прошлого столетия в Японии получило развитие так называемое бережливое производство. Если перефразировать эту теорию по отношению к проектам, то ее суть в том, что все, что не имеет отношения к достижению цели проекта, – это потери.
Как узнать, потери ли это? Задаете себе вопрос – нужно ли вам того, что вы сделали, в два раза больше?
Например, вы создаете техническое задание, написали 100 страниц красивого текста. Нужно ли вам, чтобы этого текста было 200 страниц? Нет, это мусор, это потери.
Или вы написали программный код на тысячу строк. Нужно ли вам, чтобы этого кода было две тысячи строк? Или, может, вашему заказчику нужно именно две тысячи строк кода? Нет! Ни ему, ни вам этого не нужно. Заказчик хочет решить проблему, а не знать количество строк кода, и вы заинтересованы в том, чтобы написать меньше кода и быстрее решить проблему.
Хотите ходить на совещания в два раза чаще? Нет, потому что на это тратится время, а задача не решается.
Вот – определение ценности.
В книге Васко Дуарте #NoEstimates предлагается способ измерения проектов для случая, когда вы работаете без оценок. Там появляется термин – Running Tested Stories – объем работы, который можно легко проверить. У нас существует аналог этого термина, это – воспроизводимый пользовательский (проверочный) пример.
Как с помощью пользовательских примеров можно измерять проекты? В книге Васко Дуарте рассказывается о том, что есть критерии хороших пользовательских примеров:
- Они должны быть относительно независимыми, их может быть один или несколько, но они должны проверять результат независимо друг от друга и в короткий срок;
- Эти примеры могут быть не окончательными, по ним еще будут обсуждения относительно сроков, способов решения и стоимости;
- Эти примеры должны доставлять ценность;
- Должны быть оцениваемыми, достаточно малыми и тестируемыми.
Наименования всех этих критериев, применимых к Running Tested Stories, можно объединить в одну аббревиатуру – INVEST (ИНВЕСТ). Имея хорошие пользовательские примеры, мы можем получить некий измеритель проектов, чтобы каким-то образом отслеживать прогресс по этому проекту «без оценок».
И последний момент – это визуализация прогресса.
На проекте, где нет оценок, планирование сохраняется, но оно происходит только на самом коротком промежутке времени. Все остальное – откладывается «на потом».
- Первый горизонт планирования рассчитан на две недели;
- Второй – на два месяца;
- И третий – на полгода.
В этот маленький зеленый пятиугольник (в первый горизонт планирования) попадают те функции, которые нужно сделать в первую очередь – на них задаются Running Tested Stories. Поэтому, при безоценочной разработке в первую очередь становится востребованным навык декомпозиции требований - необходимо так декомпозировать требования, чтобы доставить заказчику ценность в течение каждой итерации.
Идеальный пример, как можно работать без оценок
И в заключение, на примере небольшого диалога из фильма «Человек с бульвара Капуцинов» я покажу, как можно работать без оценок.
Рассмотрим эпизод, в котором герой Андрея Миронова (Джон Фёст) заказывает у гробовщика (Лев Дуров) будку для билетной кассы. Смотрите, какая идеальная постановка задания по методу «Без Оценок»:
- Заказчик оглашает критерии приемки (примеры использования), очерчивая границы творчества подрядчика;
- Дает задаток;
- Сообщает приоритеты – срок («не тороплю») и требования к качеству.
Важно, что работать без оценок можно только вдвоем – подрядчику и заказчику. При этом между ними должен быть достигнут достаточный уровень доверия.
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
