Мгновенная оценка

Перевод статьи Дэна Норта - "Blink Estimation"

Парни, что собаку съели на поставке ПО, обладают удивительно развитыми инстинктами в высоко-уровневой оценке проектов, в то время как мы очень осторожно управляемся с «тёмными пятнами» и когнитивными предубеждениями. Такое умение может быть важным инструментом на начальных этапах переговоров по поводу инвестиций проекта, и может убрать помехи, когда людям некомфортно или не хочется заниматься оценками.
Пролог
Мысленно возвращаюсь в 2003 год, когда мне довелось работать в Интернет-банке с замечательным Дейвом Лей-Феллоус. Я мог бы вам рассказать много историй о Дейве. Одна из моих любимых – о роликовых коньках. Но в этот раз мы проводили сессию предварительного планирования нового флагманского продукта, который должен был интегрировать все банковские аккаунты клиента в одном месте. Вы сможете увидеть на одном экране данные о вашей ипотеке, сбережениях, займах, текущих счетах, кредитных картах, обо всём в одном месте, из любых банков и прочих финансовых институтов. Это был достаточно дерзкий план, и понятно, что в нём было заложено много рисков и точек интеграции. До того, как мы приступили к планированию релизов – решили провести целый день в обсуждении того, как это планирование должно проходить. Это было похоже на заседание ООН: 18 человек сидят вокруг большого П-образного стола, представители от технарей, бизнеса, высшего руководства, оперативных менеджеров, юристов, внутренних аудиторов из комплаенс-контроля и прочих товарищей.
Обсуждение длилось уже 2 часа, а дела продвигались крайне медленно. Камнем преткновения были масштаб и границы проекта. Насколько велика коробка? Сколько нужно людей и сколько времени это займёт? Мы ходили кругами в наших мета-дискуссиях: что нам нужно сделать, чтобы начать оценку необходимых усилий? Измученные и удрученные, мы взяли паузу. В коридоре Дейв заговорил со мной. Он был уверен, что все люди в зале уже имели представление о «масштабе трагедии», но никто не хотел подставляться и предлагать свой вариант, опасаясь враждебной критики. Поэтому у Дейва появилась идея. Поскольку я был внешним консультантом – мне предоставлялась роль козла отпущения. Я предложу всем план Дейва, как будто я его придумал – поскольку его никто не будет слушать, ведь он всего лишь ведущий разработчик, а на карту поставлено так много. Когда все вернулись после перерыва – я предложил упражнение. Мы говорили уже 2 часа и каждый уже понял смысл проекта и его параметры. Мы уже согласились, что вопросы интеграции с различными внешними банковскими системами возьмёт на себя третья сторона, поэтому реальный продукт будет возвышаться над всеми этими сервисами с единой целью – поражать наших клиентов.
Я попросил каждого взять лист бумаги и написать на нём (основываясь только на своём голом инстинкте и том, что мы здесь слышали) – сколько людей и сколько времени, по их мнению, займёт проект. Я подозреваю, что количество поднятых бровей превысило количество людей в комнате, но я сказал, что само упражнение займёт не более 5 минут и попросил всех подыграть мне. Вы можете представить, что произошло. На счёт три мы все подняли листочки – и все наши оценки были почти одинаковые: 6-8 человек и около 6-8 месяцев. Некоторые были чуть больше, другие чуть меньше, но ничья оценка не выбивалась на порядок – при этом каждый ставил оценку независимо.
«Отлично,» - сказал Дейв, смеясь «похоже мы оценили наш проект. Что дальше?» Действительно мы достигли консенсуса в том, что 8 человек за 8 месяцев смогут справиться с большей частью задачи. Восемь месяцев спустя, команда из восьми человек выдали первый релиз «Money Manager» и это был крутой проект!
Второй раз
Я помню, как я был поражен тем, насколько эффективным оказалось то упражнение. И потом я (естественно) забыл об этом на пять лет. Последующие года я применял намного более детализированные и сложные техники планирования. Апогеем этих техник была электронная таблица с множеством столбцов, детализирующих историю за историей минимальное, наиболее вероятное и максимальное усилие, числа, характеризующие четкость и волатильность, и другие вещи, которые я толком не понимал. Я писал об этом раньше, но не рассказал, что потом произошло.
Я вышел после одного из таких упражнений по планированию – два дня изнурительного микро-планирования и осмечивания, в результате которых было сгенерировано 400 с лишком историй и проведено всего несколько действительно полезных обсуждений – и встретился со своим коллегой, который спросил меня, отчего я выгляжу таким потрепанным. Я рассказал ему, что я провёл два дня на совещаниях по планированию разработки коммерческого сайта. Он спросил меня, какая же итоговая оценка по этому проекту, ну и я сказал ему.
«Что??» - воскликнул он. «За столько времени даже моя бабушка справится!» И, к сожалению, он был прав. Это был выстрел в руку, мне пришлось признать, что а) микро-планирование фрактально: чем больше вы вникаете в детали, тем больше нюансов всплывает, которые надо учесть при планировании, и что б) должен существовать какой-то лучший способ. Тот факт, что все остальные в Agile-мире поступают точно также как я – нисколько не улучшил моё самочувствие.
Спустя пару дней к нам поступил телефонный звонок из ТВ-компании, планирующей реорганизацию их веб-платформы перед запуском нового сезона реалити-шоу. Трафик сайта будет с частыми пиками: после каждого эпизода будет двухчасовое окно, в течение которого несколько миллионов человек будут регистрироваться, чтобы проголосовать против участника, которого нужно выгнать из шоу. Всё остальное время это будет обычный медийный сайт с форумами, новостями, обновлениями и тому подобным. Я решил провести эксперимент, и оглянувшись назад, понял, что мне нужно использовать мой предыдущий опыт с Лей-Феллоус. Я позвал несколько человек в комнату. В группу входили ведущие разработчики, тестировщик, бизнес-аналитик и руководитель проектов. Мне вспомнилось, что у аналитика есть некоторый опыт разработки медийных вебсайтов. Я представил группе бриф по проекту, и мы некоторое время его обсуждали, может минут 20. Какого рода трафик будет поступать в ходе голосования? Какой уровень устойчивости и резервирования нужно запланировать? Как насчёт вёрстки согласно их руководству по медиа-стилю и ограничений дизайна? Какие технологии будут в нашем распоряжении? Насколько плотно мы будем взаимодействовать с клиентом и насколько часто?
Затем я снова провернул фокус с индекс-картой: я попросил каждого из них записать на карточке грубую прикидку по срокам и составу команды, которая понадобится для реализации данного проекта. Если им нужны какие-то дополнительные компетенции или люди для реализации проекта – всегда пожалуйста. Снова получился удивительный уровень согласованности по результатам, поэтому я позвонил клиенту и выдал ему оценку по проекту.
«Как вы вышли на эти цифры?» - спросил он меня.
Я мог бы сблефовать, но вместо этого сказал: «Я собрал в одной комнате самых компетентных людей с опытом работы не менее 10 лет – и спросил у них».
После некоторой паузы я получил ответ: «Мне импонирует ваш подход. Проект ваш».
Иногда ты просто не знаешь
Конечно, отныне у меня появилась проблема. Я наткнулся на быстрый, точный способ оценки масштаба проекта, и я был совершенно уверен, что мне никто не поверит ;-) В нём слишком мало магии. Я попробовал применить его ещё пару раз – и это реально срабатывало. Мне, конечно, не дали свободно пользоваться этим методом. Псевдонаучное микропланирование использовалось параллельно. Но мои «мгновенные оценки», как я их стал называть, служили хорошим контрастом для раздувания проекта. «Это просто не выглядит как проект на один год» - зачастую было достаточным для пересмотра большинства завышенных оценок.
Потом я наткнулся на препятствие. Клиент попросил нас оценить объём работы, и я собрал группу в одной комнате для оценки. Теперь они уже знали, что делать, и мы занялись обсуждением, после чего провели оценку и подняли карточки. На каждом из них было количество месяцев и людей, кроме одной карточки бизнес-аналитика. На её карточке был один единственный большой знак вопроса.
«Что это значит?» - спросил я. «Это значит, что мы не можем достоверно оценить, и вот почему.» И она назвала полдюжины причин, из-за которых мы не можем достоверно ответить. В то время как она говорила, мы все опустили наши карточки, чувствуя себя всё глупее и глупее. Она как катком прошлась по нашей мгновенной оценке. Поэтому я пошёл к клиенту и рассказал ему, что мы не можем оценить работу, но мы можем описать, где нам не хватает информации, и мы предлагаем провести пару недель в исследовании этих «чёрных дыр», после чего уже определиться с объёмом работ.
Клиент помолчал пару минут, потом сказал: «Это интересно, и я вам верю. Но сейчас меня удивляет тот факт, что ваши конкуренты смогли предоставить оценку. Видимо они ткнули пальцем в небо, поскольку исходная информация у всех была одинаковая». В итоге он дал возможность провести работу по исследованию, что позволило нам продолжить побеждать в борьбе за последующий объём работ, поскольку от нас поступила более точная смета по основной поставке.
Правила мгновенной оценки
Уже около года я обучаю технике мгновенной оценке в своём курсе «Accelerated Agile» и использую её в свое консалтинговой практике, и надо признать, что достаточно много людей уже пользуются ею. Обычно я рекомендую использовать её параллельно: практикуйте её одновременно со своим привычным подходом, и, если мгновенная оценка значительно расходится с вашим методом оценки – возможно, есть вопросы к её достоверности. Результаты были неожиданно положительными. Один из моих клиентов, рассказал мне, что они используют технику мгновенной оценки чтобы разрубить гордиев узел планирования, когда некоторым сотрудникам по разным причинам было неудобно озвучивать оценки, которые были у них в голове.
Существует несколько «правил», чтобы повысить достоверность оценки, и несколько предостережений. Сначала правила. Есть три момента, про которые нужно помнить, когда вы практикуете мгновенную оценку:

В оценке участвуют эксперты
Эксперт-переговорщик
Опытный пользователь

В оценке участвуют эксперты
Это должно быть очевидно. Мгновенная оценка – это упражнение по сопоставлению текущего контекста с тем опытом, который вы получили, становясь экспертом (по Дрейфусу). Звучит это так: если ориентироваться на все проекты, в которых вы участвовали, и основываясь на том, что вы знаете о текущем контексте и ограничениях, насколько велик будет этот новый проект? Без багажа прошлых проектов у вас просто не будет достаточного набора референсов, чтобы оценить этот новый проект, поэтому опыт всех предыдущих проектов, как успешных, так и неудачных, просто необходим.
Ваша роль как фасилитатора – это собрать вместе представителей разных дисциплин: тестировщиков, аналитиков, руководителей проектов, программистов, архитекторов, операционистов, инженеров поддержки и т.д. Выбирайте дисциплины таким образом, чтобы у них были пересечения, но при этом чтобы они отвечали за свою выделенную область экспертизы. Вы должны организовать обсуждение, не используя профессиональные термины и задавая открытые вопросы, и постарайтесь разубедить участников в необходимости тщательно всё продумать. Использование слов наподобие «грубо» или «приблизительно» позволит участникам освободиться от чувства дамоклова меча ответственности за чёткость и корректность их оценок. И помните – это всего лишь оценки.
Вам нужно обойти схожесть взглядов на известные «тёмные пятна», вот почему вам нужны люди из разных областей для обсуждения потенциальных рисков и подводных камней. Вам станет понятно, когда участники начнут приближаться к решению. В этот момент вам нужно задать вопрос о размере и длительности проекта, и потом если оценки сильно разойдутся – вы сможете исследовать допущения, которые привели к расхождениям в оценке.
Это тот же покер планирования только в масштабе всего проекта. Эксперт по информационной безопасности должен изучить проект оналйнового магазина также тщательно, как и разработчик, потому что ей известно сколько требований предъявляется по стандарту PCI (Payment Card Industry Data Security Standard), сколько времени займёт тестирование инъекционных атак и прочих труднореализуемых проверок. Разработчик может успокоить её, предложив использовать стороннее решение для обработки данных кредитных карт, чтобы уменьшить риски со стороны PCI, и пригласив её участвовать в каждой мини-сессии планирования, чтобы выслушать её советы по вопросам информационной безопасности. На практике я не видел такого, чтобы макро-оценка проекта проходила более двух туров обсуждений с разнообразными дискуссиями и спорами в каждом, не приводя в итоге к разумному консенсусу. Многократное повторение того не стоит – это сессия приблизительной оценки. Нам нужен порядок цифр, а не точный ответ.
Эксперт-переговорщик
Задача эксперта-переговорщика оформить результат упражнения таким образом, чтобы это имело смысл для заказчика. Ему должно быть удобно описывать как эксперты опираются на свои инстинкты и интуицию, и защищать закономерность такой оценки. Он должен учитывать различные когнитивные предубеждения, которые я опишу ниже: привязка, грунтовка (заливка) и окружение, которые могут повлиять на оценку. Одним из парадоксальных выводов мгновенной оценки – это то что команда проекта не принимает участия в оценке их собственной работы. Поскольку эксперты осведомлены о составе команды, особенно если это оказывает материальный эффект на их оценку, и поскольку команда проекта доверяет команде экспертов – то подход работает.
Эксперт-пользователь
Наличие эксперта-пользователя в группе – это условие, которое явно выходит из-под вашего контроля. В первый раз мне повезло – у меня был Дейв, и второй раз с медиа-клиентом, который просто отдал мне проект. Сейчас я реально сомневаюсь, что сумел бы его убедить. Если бы он потребовал полную раскладку по оценке пользовательских историй – я бы скорее всего закопался и потратил бы дня два на построение таблицы. На сегодня я рекомендую инвестировать в обучение ваших пользователей или клиентов. Как только они окажутся по одну сторону баррикад с вами, доверяя опыту проектной команды – многие вещи начнут проходить намного более гладко. Я даже проводил сессии мгновенной оценки с участием пользователей в составе группы. Это очень мощно!
Мгновенная оценка как учебный практикум
Так откуда же взять этих экспертов-оценщиков, и как нам подготовить их следующее поколение? Как только команда начинает динамично практиковать мгновенную оценку – вы сразу можете начинать использовать это как учебный практикум для не-экспертов. Не-эксперты наблюдатели должны делать только одно – наблюдать. Им не разрешается задавать вопросы на сессиях мгновенной оценки, потому что их вопросы могут непреднамеренно привести к поверхностным или якорным отклонениям, однако они могут делать любые заметки и уже после окончания сессии они могут задавать столько вопросов, сколько им надо. Один из таких частых вопросов: «Почему на обсуждался вопрос X?». Где X – это чья-то любимая тема, скажем из области безопасности или тестирования. Обычно выясняется, что все задумывались об X, но никто не посчитал, что эта тема может как-то повлиять на оценку, собственно поэтому вопрос X никто не обсуждал, и это общее положения для мгновенной оценки. Оценщики обсуждают только те вопросы, которые могут материально повлиять на оценку. Всё остальное, как бы не была важна тема сама по себе, может спокойно дождаться фазы инициации проекта.
Запрограммированные на ошибку
Мгновенная оценка может подложить большую свинью (и это та причина, по которой я рекомендую практиковать её параллельно с традиционным подходом к оценке) – как и любое инстинктивное упражнение данный метод обладает зависимостью от всяческих когнитивных отклонений. От статьи в газете, которую вы прочитали в газете по пути на работу, до температуры в комнате или последнего числа, которое вы услышали – как бы иррационально это ни было – ваше инстинктивное Я может включить перекалибровку в конкретный момент времени. Daniel Kahneman получил Нобелевскую премию за то, что показал, как легко мы можем быть одурачены, и насколько неоспоримо мы считаем, что это может случиться только с Другими Людьми. Я очень рекомендую его книгу «Думая быстро и медленно». Ваша работа как фасилитатора – это попытаться управлять этими отклонениями. Например, то, что все одновременно показывают свои оценки – это одна из контрмер. Если мы не окончили сессию за один тур, то наши первые оценки будут на бессознательном уровне сковывать более поздние оценки.
Оценка проекта как инвестиционное решение
Когда кто-нибудь просит меня оценить проект, я пытаюсь перевести разговор в сферу инвестиций. Когда они спрашивают, сколько же это займёт времени, на самом деле их интересует другое: сколько мне нужно инвестировать в это дело, для того чтобы в итоге «отбить бабки». И если вы сами поднимаете этот вопрос – вы можете помочь им оценить размер прибыли, и тогда разговор перейдёт от традиционной договорной риторики «оценка как контракт» к прямодушному обсуждению возврата инвестиций.
Как только вы договариваетесь об инвестициях в терминах людей, времени, и прочих ресурсов – вы берёте на себя обязательства сдать проект к определенному сроку. Пытаясь разрешить неопределенность на начальных этапах и всё время держа в фокусе цель проекта, вы просто работаете пока не дойдёте до даты конца проекта и декларируете победу, когда дата достигнута. В реальности вы можете часто декларировать мини-победы по ходу проекта, с промежуточными релизами для демонстрации прогресса и согласования своих допущений. Это как зажечь стрелу, а потом нарисовать вокруг неё мишень – так вы точно попадёте не в бровь, а в глаз. Фокусировка на неопределенностях на ранних этапах увеличивает схожесть допущений, которые могут иметь материальное влияние – как хорошее, так и плохое – на вашу исходную оценку проекта. Это позволяет вам обеспечить уверенность в сроке поставки и функции руководства при помощи информации для поддержки ручного управления.
Ну и что не так с оценкой на уровне пользовательских историй?
В каждом проекте есть доля неопределенности. Если её нет – то вам ничего делать не надо – всё уже готово! На макро-уровне у вас может быть обоснованное мнение о том, сколько места нужно для драконов, этих неведомых неизвестных, которые только и ждут как бы сбросить ваш проект с поезда. При достаточном опыте и правильном соотношении людей в комнате вы сможете обоснованно определить на какой проект похож и чем необычен ваш текущий проект, и сколько вам обоснованно нужно проинвестировать, чтобы реализовать бизнес-эффект, ожидаемый от проекта.
Декомпозиция до уровня пользовательских историй – это всего лишь один из способов исследования реальности, и он может привести к ряду полезных открытий, но он далёк от того, чтобы стать лучшим подходом для работы с неопределённостями. Если бы он был таковым, то все agile-проекты реализовывались бы без сучка и задоринки, поскольку они бы чётко прорисовывались на стадии формирования бэклога. Кроме того, это значит, что мы изобретаем велосипед, повторяя путь большого предварительного анализа и дизайна! Мы не можем знать, какие именно истории столкнуться с отдельно взятым драконом, не менее того, потому что многие неприятные неожиданности связаны с целым проектом, а не с конкретной историей, вроде неожиданно недоступного аппаратного обеспечения или внезапных организационных ограничений, поэтому на какой истории проявятся сюрпризы – это совершенно непредсказуемо. В момент окончания проекта одна история с оценкой в три стори-пойнта займёт в пять раз больше времени, чем другая история с аналогичной оценкой по вполне объяснимым макро-уровневым причинам. Ну и где тогда ценность от оценки каждой истории?
С другой стороны, группа людей с дополняющими друг друга опытом и навыками, проводящая дискуссию, единственной целью которой является идентификация пробелов и поверхностных допущений, может быстро достичь реального консенсуса в ответе на вопрос «насколько велика должна быть коробка».
Chief technology officer "Один Сервис.ВЦ" - Денис Олейник