Глава шестая
ПЛАНИРУЙТЕ РЕАЛЬНОСТЬ, А НЕ ПУСТУЮ МЕЧТУ
«Привет, Джефф, у нас проблема…»
Так обычно начинаются мои телефонные разговоры. Люди загнали себя в угол, теперь они хватаются за трубку и звонят мне. На этот раз это был Марк Лэнди, главный архитектор программного обеспечения компании Medco. Если вы получаете прописанные вам лекарства по почте, то, скорее всего, вас обслуживает его фирма. На тот момент Medco входила в список ста наиболее успешных компаний по версии журнала Fortune; она была самой крупной фирмой по оказанию фармацевтических услуг, имела 38 миллиардов долларов годового дохода и насчитывала десятки тысяч сотрудников. И сейчас руководство компании собственными руками толкало весь многотысячный коллектив в пропасть.
Звонок Лэнди раздался в декабре 2006 года. В июле того года президент Medco Кенни Клеппер оповестил Уолл-стрит о своей свежей идее. Марк Лэнди передает это так: «Мы пытались убедить как можно больше людей перейти на получение лекарств по почте. Понимаете, сейчас, когда вы приходите в аптеку, к вам относятся несколько отстраненно. Вы протягиваете рецепт, подписываете бумажку, что не нуждаетесь в консультации фармацевта, и уходите. А мы хотим сделать эту практику более человечной. Правда, есть кое-какие препятствия». Но Марк считал все неудобства слишком очевидными, поэтому с ними вполне можно было справиться.
Самое главное, на что, строго говоря, делалась ставка, — наладить прямую связь пациента с фармацевтом. По телефону. Причем фармацевту полагалось не только давать консультации по конкретному лекарству, которое человек заказал по почте, но и быть в курсе всех препаратов, назначенных врачами этому пациенту. Последнее было особенно важно, поскольку 80 процентов людей, принимающих лекарства постоянно, страдают тем или иным хроническим заболеванием, например диабетом или пороком сердца. Причем большинство, особенно пожилые люди, принимают одновременно шесть и более различных препаратов. А их лечащие врачи-специалисты не всегда это учитывают.
«Доктора не имеют обыкновения делиться друг с другом подробностями о своих пациентах. Мы — в нашем аптечном учреждении — знаем о лечении конкретных людей больше любого врача; и мы узнаем обо всем довольно оперативно, по крайней мере быстрее, чем это становится известно программе медицинского страхования», — объяснил Марк Лэнди.
Собственно, идея Клеппера заключалась в том, чтобы создать специализированные аптеки с пятью различными подразделениями и сетью по всей стране. Будут отдельные аптеки для людей, страдающих сердечно-сосудистыми заболеваниями, диабетом, астмой и многими другими недугами. Предполагалось обучить фармацевтов, закрепленных за каждым направлением, чтобы они разбирались во всех тонкостях взаимодействия лекарственных препаратов, их побочных действиях и прочее, и прочее. У фармацевта должна быть полная информационная картина состояния пациента, тогда он сможет предупреждать лечащих врачей этого человека о серьезных противопоказаниях. Скажем, ему звонит диабетик. Такие пациенты склонны к полноте, нередко у них возникают проблемы с печенью, и, как следствие, лекарства усваиваются иначе. Например, если ему понадобится препарат от давления, фармацевт Medco может позвонить его кардиологу и порекомендовать проверить пациенту печень, чтобы скорректировать дозировку гипотензивного средства.
Целью всех предполагаемых нововведений было привлечь в Medco новых клиентов, а заодно и компании, оказывающие услуги по медицинскому страхованию. Новым аптекам — их решили называть терапевтическими методическими центрами — предназначалось играть весьма положительную роль в жизни пациентов. Став клиентами этих центров, люди, приобретая выписанные врачами препараты, смогут наконец существенно сэкономить свои средства. Каждый из нас знает, как быстро растут расходы, когда мы вынуждены принимать лекарства в неправильной дозировке, или плохо сочетающиеся друг с другом, или вообще нам противопоказанные. Более того, Medco сама гарантировала сокращение издержек. Если клиент не достигал обещанной экономии средств, компания брала на себя обязательство каждый раз возмещать ему эту сумму.
Сказать, что на Уолл-стрит идею приняли, — значит ничего не сказать. Последовала бурная реакция типа «Классно! Круто! Сильно!» — приблизительно так. А как иначе? Мало того что предлагалось поднять медицинские услуги на более высокий уровень, но еще и давалось обещание существенной экономии денег. Что не могло не привлечь людей, особенно пожилых. Больше клиентов — больше продаж. Беспроигрышный вариант. Была лишь одна загвоздка. Обсуждая со своими управляющими, насколько в принципе воплотима его идея, Клеппер не уточнил одну деталь: сколько времени уйдет на ее осуществление. Специалисты, которым непосредственно предстояло воплощать высокую мечту в жизнь, узнали о ней уже после того, как их президент дал обязательство на Уолл-стрит, что новая система заработает 7 июля 2007 года, — мол, нам по плечу любые трудности.
Уложиться в обещанный срок было крайне важно. Хотя Medco и была первой, кто ввел автоматизированную систему рассылки лекарственных средств по почте, но далеко не единственной. Конкуренты жаждали крови. И компании предстояло преодолеть не одно препятствие. Как на грех, значительная часть программного обеспечения, при помощи которого управлялась вся автоматизированная система на местах, безнадежно устарела. На пяти гигантских заводах Medco, где сорок тысяч фармацевтов обрабатывали рецепты, одни роботы доставали со складов необходимое лекарство, другие его упаковывали, третьи отправляли по почте — и все эти системы должны были сообщаться друг с другом со стопроцентной точностью. Любая ошибка могла стоить кому-то жизни.
Когда Кенни Клеппер задумывал свой грандиозный и смелый план, он предполагал, что его реализация даст Medco шанс обновить устаревшие автоматизированные системы и сохранить конкурентное преимущество на рынке. Компании понадобилось приблизительно полгода, чтобы понять: ее разработчики не справятся к обещанной дате. Расчеты показали, что даже при самом благоприятном варианте они смогут запустить новую систему на год позже. Это минимальный срок. Возможно, и дольше. На этом этапе мне и позвонил Марк Лэнди.
Почему, чтобы осознать, что они не укладываются в сроки, им потребовалось шесть месяцев — вопрос, требующий отдельного рассмотрения. Дело не в нехватке ума, способностей или профессионализма. Их нельзя упрекнуть ни в плохой командной работе, ни в недостаточно упорном труде или незнании современных технологий. Речь не идет об отсутствии конкурентоспособности. Ведь без всего этого вы никогда не стали бы крупнейшей компанией в своей отрасли.
Дело было в базовой ошибке — и они ее не учли. Работники, ответственные за проект, считали, что можно спланировать все заранее. Было потрачено много месяцев и много сил на создание детальных планов, которые казались правдоподобными — они были изложены в виде красивых диаграмм, включали в себя детальные и четко прописанные этапы и почти всегда представляли вымышленную реальность.
Как я уже говорил, акт планирования всегда кажется столь соблазнительным и привлекательным, что составление плана становится важнее самого плана. А план становится важнее реальной жизни. Никогда не забывайте простую истину: карта — еще не живая местность.
Когда команда впервые садится за стол, чтобы набросать план проекта, в комнате царит воодушевление — возможность открывать новые миры и экспериментировать с безумными идеями. Действительно, одно из самых прекрасных чувств на свете. Но быстро наступает момент, когда вдохновение сталкивается с расчетом, и часть этой энергии улетучивается. Люди начинают сомневаться: «Как мы вообще собираемся попасть из пункта А в пункт Б? Когда мы придумаем, как это сделать, сколько времени уйдет на само его создание?»
К несчастью, фаза расчетов может обернуться чистой профанацией, и все заканчивается принципом «мечтать не вредно». Люди, занимающиеся планированием — скорее всего, они настоящие профессионалы своего дела, — как правило, не сознают, что в красивой упаковке таблиц и диаграмм они навязывают разработчикам пустые мечты.
Когда Марк объяснил мне всю ситуацию, мне оставалось только вздохнуть: «Да, вы влипли». Подумав секунду, я сказал: «Уверен, выход есть».
Пришлось накануне Рождества лететь в Нью-Джерси. Весь день я провел в Medco, пытаясь определить масштабы бедствия. Везде следы активной деятельности: бесконечные требования, нормы, отчеты, поэтапные планы, технические задания, декларации качества оценки — груды бумажного мусора. Тут задача не из пустяковых. Потому что под ворохом бумаг был погребен проект — то, что на самом деле должно быть выполнено, но в данный момент никто не представлял, как его сделать.
Обсудив кое-что с ведущими разработчиками, я позвонил Бренту Бартону, скрам-тренеру, с которым мы работали вместе на других проектах. «Брент, — сказал я, — мне нужен ты и все, кого сможешь собрать к началу января. Есть работа, и случай будто специально для нас».
Позднее Брент назвал ситуацию в Medco безвыходной — такой он увидел ее, появившись там впервые. Обстановка была настолько накалена из-за конфликтов интересов и разногласий между людьми, что дело совсем не двигалось. В тот первый день мы встретились с семью различными группами, каждая занималась своей частью проекта, и никто из исполнителей не был особенно заинтересован опробовать новый подход. Сейчас Брент вспоминает: «Я понял, что надо действовать по принципу “всё дерьмо, и хуже быть не может” — это дает относительное преимущество, почти как у висельника. Ты консультант, и их боль и страх становятся твоими союзниками. Чтобы преодолеть их сопротивление, мы просто говорили: “Если вас устраивает нынешнее положение дел — пожалуйста. Провалите сроки — ну и пусть. Продолжайте работать, как работали раньше”. И слышали в ответ: “Так не пойдет”».
Сотрудники по нашей просьбе собрались в конференц-зале. Первым делом пришли управляющие — те, кто был кровно заинтересован в осуществлении проекта. Брент заранее велел распечатать всю документацию. «Нет, — сказал он, — электронных версий недостаточно, нам все нужно на бумаге». Мы сидели в большой комнате, в длину не менее пятнадцати метров, без окон, как обычно бывает с такими помещениями по какой-то загадочной для меня причине. Посередине стоял стол, заваленный распечатками, которые все принесли с собой. Стопки выглядели внушительно.
— Кто из вас действительно прочитал все это? — спросил я.
Тишина.
— Но смотрите, — обратился я к одному из управляющих, — здесь ваша подпись. Вы подписали эти документы. Неужели вы их не читали?
Неловкое молчание.
Я не собирался цепляться к нему, но факт остается фактом: проект за проектом люди копируют и вставляют шаблоны разных документов, но никто толком не читает эти тысячи страниц. Потому что это невозможно. Вот в чем суть. Они построили систему, которая заставляет их подписываться под фантазиями.
Тогда Брент и я взяли в руки ножницы, положили рядом скотч, клей и стикеры. Видимо, действительно самому необходимому мы учимся еще в детском саду.
«Вот чем мы сейчас займемся, — сказал Брент. — Пройдемся по всем бумажкам, вырежем все, что на самом деле должно быть сделано для завершения проекта. А потом наклеим наши вырезки на стену».
На протяжении последующих нескольких часов все сотрудники занимались этим увлекательным делом. В итоге три стены оказались сплошь покрыты сотнями бумажек. На столе оставалось не меньше того, что мы наклеили на стены, но то уже был полнейший мусор — можно сказать, общая сумма потерь.
После этого я объяснил им: «Теперь нам надо оценить, сколько работы потребует каждая бумажка». Не как долго, а сколько работы. Я научил их, как это подсчитать на скорую руку — не самый лучший способ, но остальные еще хуже. (Дальше в главе я подробно разберу лучшие методы проведения такой оценки. Дело в том, что люди из рук вон плохо умеют это делать.)
Через какое-то время они выполнили мое задание. Приклеенные на стены бумажки содержали все виды работ, выполнение которых приведет нас к завершению проекта; практически все было разбито на отдельные задачи; только что собравшиеся в конференц-зале прикинули, сколько усилий потребуется на работу над каждой. К этому моменту все участники проекта уже почувствовали некое воодушевление. Не поддающиеся прочтению горы бумаг превратились в понятные рабочие задачи. Помните старую шутку: «Как съесть слона? По кусочку».
На каждой бумажке мы написали не только то, что нужно сделать, но и критерии, по которым мы поймем, что задача выполнена. Были учтены все необходимые требования соответствия стандарту, контроль качества и отчеты об оценке. Мы просто указывали, что для выполнения какой-то конкретной задачи нужно, чтобы она соответствовала таким-то и таким-то требованиям. Мы интегрировали эти критерии в проект на уровне единиц работы, поскольку не собирались оказаться в ситуации, когда перед вводом проекта в эксплуатацию вдруг обнаружится, что какой-то элемент не соответствует государственным предписаниям или внутренним стандартам качества. В соответствии с нашей методикой, чтобы достичь необходимого качественного уровня, прежде чем перейти к следующей задаче, работать должна была вся группа в целом, а не только специалисты из отдела по контролю за качеством. Трудно представить, какого количества брака удается избежать, работая таким образом. Колонку критериев, которым должна соответствовать выполненная задача, я предложил назвать «Определение готовности». Теперь каждый будет знать, сделано что-то или нет, поскольку есть четкие критерии стандарта для любого участка работы.
Участники проекта дружно посмотрели на бумажки, наклеенные на стены, и почувствовали, что сделали что-то важное. Теперь они могли видеть, что им всем предстоит выполнить.
— Отлично, — сказал Брент. — С чего начнем?
Около пяти человек высказали свои предложения.
— А потом?
Еще пять человек поделились своими идеями.
— А потом?
Чего мы добивались от участников проекта? Чтобы они расставили приоритеты. Чаще всего люди отвечают на вопрос «что дальше?» довольно однозначно: важно все. Тогда Брент решил сформулировать более четко: «Что принесет проекту наибольшую ценность?» Вот с этого и начнем.
В конце рабочего дня у нас получилось шесть рядов стикеров разных цветов по числу групп. Списки задач в длину заняли три стены зала. По крайней мере, теперь я убедился, что пора начинать.
ПЛАНИРОВАНИЕ СВАДЬБЫ
Проблема, описанная в предыдущем сюжете, может показаться довольно простой и даже надуманной. Это не так. Позвольте мне проиллюстрировать этапы процесса планирования на примере проекта совсем другого жанра. Свадебные торжества предполагают, что множество процедур и вещей должны быть обязательно подготовлены к определенной дате — и только к ней. Как вы уже знаете (если вы семейный человек) или как вам предстоит узнать (если когда-нибудь отважитесь связать себя узами брака), все пойдет вкривь и вкось и потребует в четыре раза больше сил, чем вы рассчитывали.
Разумеется, может быть иначе. Самое трудное задание получается сделать за пятнадцать минут, а вам казалось, что на него уйдут многие часы. Вот он, вечно мучающий нас вопрос: почему, принимаясь за какое-либо дело, мы так плохо умеем рассчитывать время?
КОНУС НЕОПРЕДЕЛЕННОСТИ 
Практически совсем не умеем. Прежде чем мы дойдем до свадьбы, я хочу познакомить вас с одной диаграммой, имеющей очень привлекательное название — «конус неопределенности».
Мы видим, что сначала оценки работы колеблются от 400 процентов до двадцати пяти сверх реально потребовавшегося времени. Низкие и высокие оценки отличаются друг от друга в 16 раз. По мере того как работа продвигается вперед, оценки все более приближаются к реальной величине — и так до того момента, когда уже нет никаких оценок, а есть одна реальность.
Напоминает ситуацию в Medco. Они потратили месяцы на планирование своей работы, мечтая, каким будет конечный продукт, и вычисляя, сколько времени потребуется на его создание. Поэтому, на мой взгляд, каскадная модель при планировании — довольно дурацкий подход к работе.
Опять слышу ваши возражения: «Ладно, Сазерленд, я уже слышал, что мы не умеем рассчитывать ни время, ни силы, но мне же надо делать хоть что-нибудь, верно? Мне нужен какой-то план». И тут вы правы — нужен. Я все время пытаюсь объяснить главное: вместо того чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта. Тщательно планируйте, каким образом сделать следующий шаг к увеличению ценности проекта, и оцените оставшуюся часть проекта более крупными фрагментами работы. При методологии Scrum в конце каждого спринта вы получаете что-то ценное — это можно увидеть, потрогать и показать заказчику. Вы интересуетесь у него: «Мы создаем то, что вы хотели? По крайней мере часть проблемы уже решена, не так ли? В правильном ли направлении мы движемся?» И если на все ответ отрицательный, вы меняете план.
Давайте посмотрим, как это делается. Для этого вернемся к свадьбе.
Первое, что нужно сделать, — составить список всех вещей, делающих свадьбу самой лучшей. Он выглядит приблизительно так:
жених и невеста;
цветы;
приглашения;
церковь;
зал для приема гостей;
угощение;
священник;
платье невесты;
обручальные кольца;
музыка (диджей или «живая» группа).
Теперь, набросав список, мы приступаем к основному: просматриваем все пункты и выстраиваем их по приоритетности. У каждого человека, делающего это, получится своя последовательность. Невеста и жених по-разному смотрят на мир. Как-то я спросил своего друга Алекса, как он расставил приоритеты в своем свадебном списке, — посмотрите, что у него получилось:
жених и невеста;
священник;
обручальные кольца;
зал для приема гостей;
приглашения;
угощение;
музыка;
платье невесты;
цветы;
церковь.
Суть нашего упражнения в том, чтобы выявить действительно важные вещи и проработать их в первую очередь. Для Алекса еда и музыка важнее церковной церемонии и цветов. Эта информация дает шанс на будущее, когда придется сокращать список. А придется обязательно, поскольку вам грозит не уложиться во временные или финансовые границы — тогда вы начнете с последних пунктов. Я более подробно затрону эту тему в восьмой главе, а пока, пожалуй, сказанного достаточно.
В компании Medco список растянулся на три стены большого конференц-зала и состоял из сотен пунктов, над которыми работали несколько групп. Но концепция была в точности та же.
Выстраивайте свой список в соответствии с ценностью, какой бы она ни была. Это может быть ценность для бизнеса, как в случае с Medco, или для невесты, как в случае со свадьбой.
РАЗМЕР ИМЕЕТ ЗНАЧЕНИЕ, НО ТОЛЬКО ОТНОСИТЕЛЬНОЕ
Итак, у вас есть список и вы выстроили его в соответствии с приоритетностью дел. Теперь нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Как я уже говорил, люди довольно плохо справляются с такого рода расчетами, но мы хорошо умеем делать другое — сравнивать один размер с другим, то есть определять относительную оценку.
Например, видеть разницу между футболками размеров S, M и L. Мой любимый пример определения относительных размеров — это измерение «в собачьих баллах». Мой друг и один из ведущих представителей принципа гибкого подхода Майк Кон, как и я, всю жизнь борется с этой проблемой, пытаясь «уложить» проекты во временные, бюджетные и оценочные рамки. Большой любитель собак, хотя жена так и не дала ему завести пса, он придумал измерять объем той или иной работы по проекту «в собаках». Чтобы его разработчикам было удобнее ориентироваться в «собачьей» системе, он составил для них список пород:
лабрадор-ретривер;
терьер;
немецкий дог;
пудель;
такса;
немецкая овчарка;
ирландский сеттер;
бульдог.
Теперь его вопросы звучали примерно так: «Эта проблема — такса или дог? Последняя была таксой, значит сейчас мы имеем дело с лабрадором, да?» Участники группы просматривали все элементы, которые нужно было разработать, и определяли их размер «в собаках». Позже Майк предложил присвоить каждой породе числовое значение. Так было проще. «Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой»1.
То же самое можно сделать со свадебным списком, который мы только что составили. Найти зал для приема гостей? Придется потрудиться, надо будет собрать информацию по ценам, посмотреть все варианты помещений. Этот пункт потребует некоторых усилий, поэтому назовем его лабрадором — значит пять. Жених и невеста? Никаких проблем — просто нам обоим нужно явиться. Этот пункт будет таксой — единица. Приглашения? Дело хлопотное. Нужно составить список жениха, список невесты, получить список от одних и других родителей, выбрать бумагу и конверты, заказать печать приглашений, подписать их от руки. Этот тяжелый пункт тянет на дога — тринадцать. Может быть, даже на двух догов. Почти слон. Возможно, есть смысл разрезать его на мелкие кусочки. Сделаем подпункты: сбор имен и печать открыток. Каждый будет по бульдогу — по три. В отдельный подпункт выделим подписи жениха и невесты, который назовем овчаркой — пять. И так далее.
Это и есть относительное определение размера, сравнение задач друг с другом. К сожалению, не все пользуются такой единицей измерения, как «собака». Однако вы, наверное, обратили внимание, что в числах, которые я вроде бы произвольно присваивал разным пунктам из списка, есть некая последовательность: 1, 3, 5, 8, 13. Каждое число в этой последовательности является суммой двух предыдущих. Это называется «последовательность Фибоначчи», и мы ее неспроста используем. Она повсюду.
ПОСЛЕДОВАТЕЛЬНОСТЬ ФИБОНАЧЧИ — ПОВСЮДУ ВОКРУГ НАС
Последовательность Фибоначчи — это порядок чисел, при котором каждое последующее число является суммой двух предыдущих: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…
Последовательность Фибоначчи присутствует повсеместно в природных системах, так что у человечества были миллионы лет на то, чтобы привыкнуть к ней.
Благодаря последовательности Фибоначчи мы видим, как природа структурирует саму себя, будь то раковина наутилуса, ветви дерева, бугорки на ананасе или чешуйки сосновой шишки. Ее можно заметить в цветной капусте и извилинах человеческого мозга. Неважно, на что вы смотрите — на завиток побега папоротника или форму галактики. Это один из тех феноменов, которые, если задуматься, кажутся удивительной причудой природы. У этого явления есть название — золотое сечение, или золотая середина. Мы видим эти пропорции в архитектуре и искусстве. От Парфенона в Афинах до Великой мечети в Кайруане в Тунисе. Используем их для определения формата книг и игральных карт. Человек запрограммирован стремиться к пропорциям. Важно понимать, что люди глубоко чувствуют пропорции последовательности Фибоначчи. Мы ощущаем их интуитивно.
Числа последовательности Фибоначчи достаточно далеки друг от друга, поэтому мы легко обнаруживаем различия. Если человек оценит объект как пять, а другой как восемь, мы интуитивно чувствуем разницу. Но когда второй объект оценивается как шесть, то мы уже не в состоянии определить, чем они отличаются друг от друга, — наш мозг не справляется с такой тончайшей гранью.
Медики хорошо знают: чтобы пациент мог сообщить об улучшении своего состояния, это улучшение должно превышать 65 процентов. Наш разум не работает со сглаженными значениями. Мы лучше осознаем прыжки из одного состояния в другое — не плавные переходы, но резкие скачки.
Использование последовательности Фибоначчи для измерения масштабов задач позволяет этим оценкам не быть точными на все сто процентов. Ничто не будет точно пятью, или восемью, или тринадцатью, но, применяя эти числа, можно собирать мнения о масштабах задачи в условиях, когда все пользуются приблизительно одной системой измерения, — так мы быстрее достигнем согласия.
Таким образом получается, что коллективная оценка дает нам гораздо более точные результаты, чем индивидуальная.
ДЕЛЬФИЙСКИЙ ОРАКУЛ
Итак, мы выяснили, что хорошо умеем сравнивать разные объекты. Знаем самое лучшее значение, которое можно использовать. Но как нам этого достичь? Замечательно, что уже составлен список приоритетных задач, но как понять, какая из них «пять», а какая «восемь», что у нас «лабрадор», а что «пудель»? Когда кто-то предлагает новую идею, считая ее блестящей, как нам убедиться, что его оценки стоят в одном ряду с оценками других специалистов? Учтены ли все ключевые факторы?
Проблема не нова. Люди бились над ней десятилетиями. У каждого члена коллектива свои предпочтения и есть собственное мнение, но в то же время существует эффект стадности. Вам, наверное, случалось бывать на совещаниях, когда один высказывает какую-то мысль, все ее подхватывают и начинают обсуждать. И даже если вы сначала были против его идеи, то вынуждены принять ее, присоединяясь к мнению большинства. Все согласны идти вперед путем, считавшимся самым лучшим, но со временем он оказывается совершенно провальным. Если расспросить людей о принятом решении, почти всегда выясняется, что сомнения были почти у всех, но никто не высказывал их вслух. Человек склонен думать, что если все остальные поддерживают какую-то мысль, то его сомнения возникли по незнанию или глупости. Но кто захочет выглядеть недалеким неучем в глазах всей группы? Помните, групповое мышление — не ошибка отдельного человека, а типичное заблуждение людей.
В литературе это явление описано как информационный каскад, о нем писали в своей статье A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades («Теория моды, обычаев и культурных изменений как информационных каскадов») Сушил Бикчандани, Дэвид Хиршлейфер и Иво Уэлш:
Информационный каскад возникает, когда для человека удобнее всего, понаблюдав за действиями своих предшественников, повторить их поведение вне зависимости от имеющейся у него информации2.
Авторы рассматривают проблему информационного каскада на примере передачи статьи в журнал. Редактор первого журнала статью вернул. Тогда автор шлет ее во второй журнал. Его редактор, узнав о первом отказе, скорее всего, тоже откажет. А если есть еще и третий журнал и его редактор узнает о первых двух отказах, вероятность того, что он отклонит ее, еще выше. Человек склонен считать, что мнения других людей более верные, чем его, даже если эти суждения противоречат его собственной оценке. Это плохо. Когда вы оцениваете, в какие сроки можете сдать многомиллиардный проект или успеете ли вы все подготовить ко дню свадьбы, критически важно высказывать свое мнение, прислушиваясь к оценкам других, чтобы откорректировать собственную.
Еще одна известная проблема — эффект ореола, или гало-эффект, когда мы составляем общее мнение о человеке согласно восприятию какой-либо одной его черты. Это явление было впервые эмпирически изучено в 1920 году Эдвардом Ли Торндайком. В его статье A Constant Error in Psychological Ratings («Постоянная ошибка в психологических оценках») Торндайк попросил военных офицеров оценить своих солдат по различным качествам: физическим, интеллектуальным, лидерским, личностным. Затем он смотрел, как один набор качеств влияет на оценку других качеств, и обнаружил довольно сильную взаимосвязь. Если чья-то физическая подготовка получала высокую оценку, то так же высоко оценивались и лидерские качества этого человека. И интеллект. И характер. Результаты исследования Торндайка подтвердились данными последующих экспериментов, которые он проводил на протяжении многих лет. Например, если кто-то хорош собой, то все охотно признают за этим человеком и ум, и порядочность3.
Эффект ореола влияет не только на общее восприятие отдельной личности, он распространяется и на оценки целых коллективов и даже сфер деятельности. Исследователи выяснили, что негосударственные организации (НКО), по общему мнению, всегда действуют во благо, даже если известны другие случаи. Кроме того, эффект ореола успешно применяется в маркетинге, например в автомобилестроении, когда по демоверсии продукта составляют положительное мнение о линейке новой модели.
Как и в ситуации с эффектом стадности, люди, склонные подпадать под влияние эффекта ореола, не обращают внимания на реальные данные — их чаще тянет к чему-то или кому-то, несущему в себе положительный заряд. Еще раз хочу подчеркнуть — это не бессилие человеческой воли, такова природа человека. Бороться с ней глупо — все равно что протестовать против силы тяжести.
Но вы можете переиграть воздействие этих эффектов. Корпорация RAND[34] в 1950-е годы инициировала ряд экспериментов, во время которых задавались нарочито пугающие вопросы, которые были особенно популярны во времена холодной войны. В ходе этих исследований был разработан дельфийский метод[35] (название восходит к Дельфийскому оракулу, чья жрица предсказывала будущее), авторами которого были Норман Далки и Олаф Хелмер, опубликовавшие в 1963 году статью, аккуратно озаглавленную An Experimental Application of the Delphi Method to the Use of Experts («Экспериментальное применение дельфийского метода для экспертной оценки») с полезной ссылкой — «Меморандум RM-727/1 — сокращенная версия». В статье они заявляли о своем намерении задавать вопросы так, чтобы мнение одного человека не влияло на остальных. Для этого они собрали группу экспертов: четырех экономистов, специалиста по анализу физической уязвимости, системного аналитика и инженера-электротехника.
Им предложили высказать экспертное мнение с точки зрения лица, осуществляющего стратегическое планирование в СССР, о системе американских промышленных объектов и оценить то количество атомных бомб, которое необходимо, чтобы снизить выпуск соответствующих вооружений до описанного объема4.
Если переложить с «экспертного» языка на человеческий, то речь идет о выработке мнения, сколько атомных бомб понадобится русским, чтобы помешать американцам производить их собственные. Это было в те времена, когда считалось, что атомный конфликт не только возможен, но и что в нем можно победить. Суть формирования экспертного мнения состояла в том, по замыслу Далки и Хелмера, чтобы социальное положение и статус одних экспертов не оказывал давления на других. Могло оказаться, что в одну экспертную группу одновременно входят и ректор крупного престижного университета, и скромный преподаватель незаметного колледжа. Как помешать ошибочным суждениям одного повлиять на мнение других? И как получить на основании независимых оценок общее мнение с достаточной степенью достоверности?
Поэтому Далки и Хелмер провели серию анонимных опросов. Ни один из экспертов не знал, кем были остальные. Потом индивидуальные оценки квалифицированных экспертов изучались, обобщались и обрабатывались организационной группой других ученых, и уже в обезличенном виде их снова скармливали анонимной экспертной группе. В общем, намылить, смыть, повторить[36].
Итак, при первом опросе количество бомб, необходимое, чтобы создать пятидесятипроцентную гарантию уничтожения американской военной промышленности, было оценено в диапазоне от пятидесяти до пяти тысяч боеголовок. Когда Далки и Хелмер анализировали ответы, им бросились в глаза некоторые общие моменты: уязвимость различных объектов, способность к восстановлению отдельных отраслей, изначальный запас и тому подобное. После этого они спросили экспертов, была ли оценка верной и какими данными они пользовались при подготовке своих оценок. В ответ ученые получили тематически очень разбросанную информацию: от сведений о том, насколько крепки заводы, до разницы между физической и экономической уязвимостью или сроками поставки различных комплектующих.
Далки и Хелмер взяли эти данные и передали их всем экспертам и еще раз спросили о количестве бомб. Теперь разброс мнений был от 89 до 800 боеголовок. Они снова повторили всю процедуру. А потом еще раз. Разброс мнений постепенно сужался. В конце концов он сократился и составил от 167 до 360 ядерных боеголовок.
Возможность отсеять невероятно широкий спектр оценок — от десяти тысяч процентов до двухсот — это очень мощное оружие в руках политиков. Оно позволяет получать единое экспертное мнение, не опасаясь взаимного влияния. Это настолько действенный инструмент, что он и по сей день используется корпорацией RAND. Один из недавних примеров дельфийского метода — прогноз возможности успеха американских вооруженных сил в Афганистане, сделанный в 2011 году. И если вдруг вам интересно, то прогноз был неутешительный.
ПОКЕР ПЛАНИРОВАНИЯ
Преимущество дельфийского метода заключается в том, что он использует широкий спектр мнений, пытается свести к минимуму взаимное влияние и при помощи информативных, но в то же время анонимных точек зрения сужает этот спектр до некой оценки, принимаемой всеми. Плохо в нем то, что для наших целей он требует слишком много времени. Когда я встречался с группами в компании Medco, я не стал тратить время на анонимные опросы. Я хотел, чтобы все задачи были оценены за несколько часов, не дней и уж точно не недель.
К счастью, есть довольно быстрый и точный способ сбора оценок. Он называется «покер планирования».
Идея проста. Каждому участнику дается колода карт с числами Фибоначчи — 1, 3, 5, 8, 13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта.
Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными.
Например, вы красите стены в доме, и вам нужно оценить, сколько времени уйдет на покраску гостиной, кухни и двух спален. Вы работаете с мастерами, с которыми уже красили стены раньше. Итак, сначала две спальни: все оценивают их на три. Никаких особых разногласий, вы делали такое раньше, и вам не кажется, что со спальнями могут возникнуть сложности. Затем команда оценивает гостиную. Это довольно большое помещение, но там все просто. Оценки расходятся от пяти до тринадцати, затем сходятся на средней оценке — шесть. И снова нет смысла спорить. Затем дело доходит до кухни, и тут на столе оказываются и три, и восемь, и тринадцать, и еще пять. Тот, кто положил тройку, уверяет, что комната небольшая, площадь даже меньше, чем у двух спален. Человек, положивший цифру тринадцать, напоминает, что стоит учесть все то время, которое понадобится, чтобы заклеить шкафчики и столы, а красить отдельные маленькие участки придется кистью, а не валиком. Команда быстро выкладывает новые карты. Цифра три превратилась в восемь, все остальные оценки остались старыми. Теперь оценки довольно близки друг к другу, можно их сложить, вычислить среднее арифметическое и переходить к следующей задаче.
Покер планирования очень хорош: во-первых, это невероятно простой метод; во-вторых, он дает возможность избавиться от любого нежелательного влияния и избегать эффекта стадности и эффекта ореола; в-третьих, позволяет всей команде делиться информацией по конкретной задаче. При этом важно, что оценка проводится группой специалистов, которая действительно будет выполнять эту работу, а не некими анонимными и «идеальными» экспертами.
Я научился всему этому на собственном горьком опыте, когда работал в Пенсильвании в GSI Commerce, занимавшейся интернет-продажами. С тех пор их купила компания eBay. GSI специализируется на создании онлайн-магазинов для таких компаний, как Levi’s, Toys “R” Us, Major League Baseball и Zales Diamond. Это не мелкие проекты. И GSI с ними очень неплохо справляется.
Однако у компании GSI появилась идея, которая какое-то время казалась хорошей. Вместо того чтобы каждая группа занималась оценкой проекта самостоятельно, руководство решило отдавать эту часть работы лучшим оценщикам компании — довольно умным и профессиональным ребятам, отлично разбиравшимся как в проектах, так и технологических процессах и знавшим, что нужно делать. Они взяли несколько проектов и оценили их. Вот этот потребует столько-то времени, другой столько-то и так далее. Всего требовалось оценить восемьдесят мультимиллионных проектов, оформить бумаги по экспертизе и представить результаты в первую очередь всем заказчикам, во вторую — группам разработчиков, которые будут непосредственно выполнять задания. На первый взгляд все разумно, не так ли?
Как выяснилось, этот путь до такой степени плох, что эксперты остановились на полпути, успев оценить ровно сорок проектов. Сразу приходят на ум срочно прерванные клинические исследования лекарств, в процессе которых выяснялось, что препараты скорее убивают, чем лечат. Экспертные оценки в GSI были настолько далеки от реальности, что оказались совершенно бесполезными.
Ничто не выполнялось вовремя. Клиенты оставались недовольными. Рабочие группы были деморализованы. В общем, полная катастрофа. Руководители вернулись к старому варианту: теперь группы разработчиков снова самостоятельно проводили оценку проектов. Вот чудеса! Оценки вновь стали сходиться с реальностью.
Из этой истории я вынес простую мысль: только тот, кто непосредственно выполняет проект, знает, сколько он требует времени и сил. Скорее всего, группы, работавшие в GSI, очень разные. Какая-нибудь группа хороша в разработке одного вида продукта, но совершенно несостоятельна в работе над другим. Наверняка в каждой группе можно найти специалистов, способных совершать чудеса в какой-то конкретной сфере. Наверное, есть группы, где кто-то с чем-то не справляется. Как мы уже не раз говорили, все команды уникальны и неповторимы. У каждой свои темп и ритм работы. Подгонять их под общий шаблон — верный путь в пропасть.
НИКАКИХ ЗАДАНИЙ. НАМ НУЖНЫ ИСТОРИИ И ФАКТЫ
Когда составляешь список требований, которые должны быть выполнены, очень соблазнительно сделать так, как я поступил со свадебным списком Алекса: церковь, цветы, священник, угощения и прочее. Однако если с пунктами этого списка будут разбираться люди, не посвященные в таинство белых роз и маргариток и не разбирающиеся в вечном противостоянии между почитателями первых и любителями вторых, вы рискуете получить совсем не то, что вам нужно.
Сколько раз на работе вам давали задание, смысла которого вы не понимали? Вас просят определить, как меняются за месяц продажи в регионе A в магазинах площадью более пятидесяти квадратных метров. Вы выполните эту работу, не вдаваясь в то, для чего это нужно. Из-за этого вы можете проставить не те данные, неправильно истолковать вопрос или почувствовать досаду, что вас загрузили нудной работой. Если вы управляющий, дающий такое задание, то, скорее всего, вы будете недоумевать, почему ваши сотрудники не возьмут в толк, что вы просто хотите закрыть маленькие магазины и открыть большие.
Дело в том, что вы, с одной стороны, не получаете, а с другой — не предоставляете того объема информации, который необходим для выполнения хорошей работы. Люди мыслят фактами и историями. Именно через них мы понимаем мир. Мы умеем схватывать на лету характеры, желания и мотивы. Проблемы появляются сразу, как только мы начинаем вытягивать из основного сюжета отдельные линии, чтобы оперировать ими вне контекста.
Таким образом, первое, о чем стоит задуматься, когда вы размышляете о смысле своего задания, — это действующее лицо. Покупатель, невеста, читатель, служащий — тот, для кого вы будете выполнять данную задачу, чьими глазами вам придется смотреть на мир, когда приступите к созданию новой вещи, принятию конкретного решения, разработке программы.
Затем надо обратить внимание на то, что мы хотим сделать в первую очередь. Обычно это лишь часть работы, с которой мы начинаем наш процесс и на которой всегда можем его остановить, хотя по плану (или по списку) таких частей много и, конечно, мы должны следовать всему процессу.
Наконец, нужно подумать о мотивах. Почему выбранный нами персонаж хочет эту вещь? Как она будет ему служить, чем будет радовать его как потребителя? Определенно, этот момент оказывается ключевым. Личная заинтересованность придает колорит всему.
Мой любимый пример связан с интернет-мемом, который был популярен несколько лет назад. Это картинка с изображением капитана Жана-Люка Пикара[37] в знаменитом звездолете «Энтерпрайз» с подписью: «Как капитан космического корабля я хотел бы, чтобы в бортовом журнале автоматически использовалась сегодняшняя звездная дата…» Это высказывание приобретает некий смысл, только если задуматься. Вас никогда не удивляло, что в далеком будущем капитану космического корабля приходится в ручном режиме вводить дату, когда он заполняет бортовой журнал? «Дневник капитана. Звездная дата 4671.7. Планета Марс так хорошо смотрится с орбиты…» Даже нам не приходится делать так, когда мы оставляем запись у себя в блоге. Так почему же это делает он? Но ключевой вопрос, который остается без ответа на этой картинке, — зачем? Зачем ему нужна такая функция? Для какой цели? Чтобы отслеживать порядок записей? Или что-то более серьезное? Должны ли эти записи исключать возможность внесения изменений в целях проверок и расследований криминалистами Звездного флота? Две совсем разные цели. Одна — бытовая, другая — имеет весьма вескую причину. Команде нужно разобраться, что капитан на самом деле хочет делать, при этом они могут найти совершенно иной подход к выполнению задачи, так что капитан будет получать гораздо более важную информацию, о которой он, возможно, даже и не задумывался, но которая была бы ему очень полезна.
Потребности разных персонажей, как правило, совсем разные. Представьте себе такой случай, когда ситуация меняется на противоположную. Предположим, вы произносите: «Мне нужна машина, чтобы ездить на работу». А теперь начните предложение так: «Как жителю пригорода, постоянно ездящему в центр на работу…» Или ровно наоборот: «Как фермеру Южной Дакоты с ее плохими дорогами…» В результате вы получите два совершенно разных представления об идеальном автомобиле.
Поэтому, прежде чем расставлять по приоритету дела в списке задач, определитесь с персонажем, пользователем, клиентом — тем человеком, который будет использовать то, что вы собираетесь производить. Вам нужно знать, что ему нравится, чего он терпеть не может, о чем мечтает, что вызывает вдохновение, от чего расстраивается, что приносит радость. Но более всего нужно понять его побудительные мотивы. Как он распорядится той вещью, которую заказал? Почему ему нужна машина? То есть все упирается в вопрос: зачем капитану Пикару потребовалось вести бортовой дневник? Все, что вы выясните о человеке, окажет влияние на вашу оценку задания. Если поймете, что задумал капитан Пикар, вы создадите программу с правильной функцией. Капитан останется доволен.
КОРОТКИЕ ИСТОРИИ
Когда сочиняете свои сюжеты, в которых содержатся пожелания пользователя, — будем называть их пользовательскими историями, а для краткости просто историями, — следите за тем, чтобы они были лаконичными и удобными для дальнейшей работы. Представьте, что вы составляете «пожелание пользователя Amazon.com». Пробный вариант выглядит так: «Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время».
Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:
Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.
Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.
Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.
Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание. Составив истории, вы можете начать обсуждать пути их воплощения. Они достаточно конкретны, чтобы быть выполнимыми, но не предписывают, каким образом следует действовать. Помните, группа решает самостоятельно, каким образом будет сделана работа, а цель, которой предполагается достичь, определяется ценностью самого проекта. Пакет пожеланий одного пользователя часто называют эпопеей или просто эпиком. В эпопее собрано все, что в целом несет в себе идею продукта — в нашем случае книжного интернет-магазина. Эпопея слишком велика, чтобы ее можно было воплощать сразу целиком, но она включает в себя множество фрагментов — мелких пользовательских историй, работающих на одну общую идею.
Тим Стол — один из тех парней, о которых обычно говорят: прошел огонь, воду и медные трубы. Сейчас он хороший специалист, работающий с разными командами, чтобы те умели выполнять свое дело быстро. Тим служил медиком в спецназе, прошел Ирак и Афганистан, работал по контракту на ЦРУ, был офицером полиции и занимался там опасными преступниками, — теперь он скрам-тренер. Как Тим сам говорит, он всегда и был скрам-тренером, даже когда руководил операциями спецназа.
«В спецназе, — рассказывает он, — мы не называем это историей. Мы говорим: “план действий”. Но суть та же». Вот одна из немногих историй из практики спецназа, которые Тим может рассказывать открыто, — медицинская миссия в Лаосе. «У нас было два своих “эпика”. Первый эпик — по курсу медицинской подготовки, поскольку мы обучали отряды самообороны навыкам тактической медицины. Второй — по операциям по разминированию неразорвавшихся боеприпасов на освобожденных территориях».
Будучи врачом, Тим отвечал за курс медицинской подготовки. Он говорит, что перед началом своей миссии ему пришлось крепко подумать, что нужно делать, как разбить истории на фрагменты и выстроить их в логической последовательности. Он начал с идей, которые хорошо вписывались в систему Scrum. «Я был военврачом и служил в спецназе, поэтому мне полагалось обучать людей азам анатомии и физиологии, чтобы они могли понимать устройство человеческого тела и как функционирует наш организм», — Тим, когда стал составлять истории, понял, что начинать надо именно с этого, ведь его ученикам придется в будущем уметь оказывать любую первую помощь. «Для начала я рассказал им про кости человеческого скелета, про суставы, сухожилия, связки». Только после того как был заложен фундамент, то есть рассказаны базовые истории, Тим перешел к принципам вправления костей при переломах и суставов при вывихах, освобождению дыхательных путей и остановке кровотечений. Записав все истории, он сразу смог увидеть, что ему нужно для выполнения учебных задач. Нужен был скелет. Нужен был наглядный материал на английском и лаосском. Потом Тим разбил весь процесс обучения на короткие циклы, то есть спринты: «Два дня на перелет в Лаос. Неделя на подготовку. Затем два шестинедельных учебных цикла. Нам нужно было обучить с нуля до уровня младшего специалиста по оказанию первой помощи. И мы сделали это».
ГОТОВНОСТЬ И ВЫПОЛНЕННОСТЬ
Когда вы пишете истории или составляете список заданий, важно задать себе два вопроса. Готова ли история? Как я пойму, что задача выполнена?
Возьмем в качестве примера историю Тима.
…Мне полагалось обучать людей азам анатомии и физиологии, чтобы они могли понимать устройство человеческого тела и как функционирует наш организм.
Есть мнемоническое правило, которое я всегда использую, когда нужно определить, готова ли история. Придумал его вдумчивый исследователь и серьезный программист Билл Уэйк. Билл говорит, что любая история, чтобы считаться готовой, должна соответствовать определенным критериям. Он назвал их критериями INVEST (I ndependent . N egotiable . V aluable . E stimable . S mall . T estable ).
Завершенность, выполнимость, независимость (Independent). История должна быть: абсолютно завершенной; осуществимой на практике; независимой от разных обстоятельств.
Открытость (Negotiable). История до своего завершения должна быть открыта для общего обсуждения; любой участник группы должен иметь возможность внести в нее свои поправки.
Ценность (Valuable). История должна приносить реальную пользу и увеличивать ценность проекта для заказчиков, пользователей и любых заинтересованных лиц.
Оценочность (Estimable). История должна быть удобна для оценки объема работы.
Лаконичность (Small). История должна быть краткой, компактно изложенной и конкретной, чтобы можно было просто и быстро планировать работы. Если история получилась слишком расплывчатой, перепишите ее, а лучше разбейте на мелкие функциональные фрагменты.
Тестируемость (Testable). История должна пройти проверку на практике, чтобы считаться завершенной. Составьте заранее список критериев, которым должна соответствовать законченная история.
История Тима независима. Он мог выполнять свою операцию по обучению сил самообороны, не задумываясь о таких вещах, как, например, расход топлива вертолета, который доставлял его в лагерь. Его история открыта. Учитывая полевую практику, он мог добавлять ее или, напротив, сокращать в зависимости от того, как быстро усваивались знания его учениками. Его история имеет ценность. Она принесла реальную пользу, поскольку ученики узнали о строении человеческого тела, научились применять свои знания практически. Его история лаконичная. В ней кратко и емко изложены основы анатомии и физиологии. Сложной операции обучаемый не проведет, но первую помощь оказать сможет. Его история тестируема. Тим легко мог проверить по определенным критериям, как усвоен материал.
Любая пользовательская история, которую мы внедряем в практику, должна отвечать двум условиям: «готовность» — то есть соответствует ли она критериям INVEST; «выполненность» — то есть соответствует ли она тем критериям, по которым мы можем судить, что задача выполнена. При работе над реальными проектами мы видим, что если история действительно готова, команда удваивает скорость ее реализации. Когда в конце спринта история выполнена, команда в два раза увеличивает темпы работ в начале следующего спринта. Это один из ловких приемов Scrum, дающий возможность в два раза быстрее выполнить двойной объем работы.
ПЛАНИРОВАНИЕ СПРИНТА
В методологии Scrum планирование происходит в начале каждого нового спринта; собственно, оно так и называется — «планирование спринта». Все собираются вместе, просматривают список пользовательских историй, которые уже стоят в очереди на выполнение; выясняют, какое количество задач может взять на себя каждый участник группы; тщательно взвешивают, смогут ли они за этот спринт довести до полной готовности отобранные задания; смогут ли продемонстрировать заказчику сделанные единицы работ и показать ему готовые функции продукта; смогут ли сами себе в конце спринта сказать, что они со всем справились.
Быстро решив все вопросы, команда дружно произносит: «Вперед!» — и приступает к работе.
УЗНАЙТЕ ДИНАМИКУ ПРОИЗВОДИТЕЛЬНОСТИ
Наконец мы готовы ответить на вопрос, когда будет выполнен наш проект. Мы измерили ускорение темпа, с которым группа двигается вперед. У нас написаны и собраны пользовательские истории, и потому мы знаем все задачи, которые должны быть выполнены. Мы уже успели оценить объем каждого задания. И мы готовы приступить к первому спринту. Длиной в неделю. В конце недели мы подсчитаем все завершенные нами истории и общее количество очков, на которое они были оценены. Это число покажет нам, насколько быстро движется группа и какова динамика производительности (для удобства сократим и в дальнейшем ограничимся одной «динамикой»). Выяснив текущую динамику, мы делаем последний шаг: подсчитываем оставшееся (несделанное) количество историй, оцениваем сложность каждой, опять складываем все очки и смотрим на получившееся число. Теперь мы ясно понимаем, когда сможем завершить проект.
Помимо этого, узнав свою динамику, вы можете определить самую важную в Scrum вещь: что мешает двигаться вперед еще быстрее? Что не дает наращивать темп? В прошлой главе мы поговорили о потерях и факторах, замедляющих ход работы. Теперь пора выяснить, как не допускать появления данных факторов и навсегда избавиться от самого понятия «потери».
Вернемся к компании Medco, с рассказа о которой мы начали настоящую главу. Мы расстались с ней на том моменте, когда все группы разработчиков закончили процесс оценки сложности предстоящей работы над проектом. После этого я собрал высшее руководство и всех управляющих, которые несли ответственность за сроки сдачи проекта. Мы сели за стол в переговорной.
— Вы уложитесь в заявленные сроки? — спросил старший вице-президент, хлопнув рукой по столу.
— Не знаю, — ответил я. — Но мы закончим до той даты, которую ваши люди назвали после пересмотра сроков. В противном случае я верну деньги.
— Этого недостаточно! Вы уложитесь в первоначальные сроки?
— Я не могу ответить на ваш вопрос. Пока не могу. Нам нужно, чтобы группы начали работать, только тогда мы поймем, насколько быстро они продвигаются. Вот что я вам скажу: я назову вам дату сдачи проекта через полтора месяца, и она вам не понравится. Но, — быстро добавил я, прежде чем он успел меня перебить, — я дам вам список факторов, которые встают на пути ваших групп и реально мешают им завершить проект к июльской дате, которую вы пообещали на Уолл-стрит. Полный список препятствий. И вашей задачей будет устранить эти препятствия как можно быстрее.
— Препятствия! Не вопрос, Джефф. Я работал в Toyota, — рассмеялся он.
— Этот проект начинает мне нравиться, — рассмеялся я в ответ.
Я понял, что он знал классификацию потерь Тайити Оно и понимал, как все устроено: чтобы наращивать нужный темп, прежде надо свести на нет все потери.
Прошло три спринта, и по результатам измерения их динамики выяснилось, что группы повысили скорость работы с 20 очков до 60. Тогда я прикинул с довольно большой вероятностью срок, за который можно завершить проект. Учитывая динамику всех групп, разработчикам понадобится еще 19 двухнедельных спринтов. Сейчас начало марта — получается 1 декабря.
Высшее руководство осталось недовольным. Медленно и поздно. Или 1 июля, или никогда. На том они и стояли. Тогда я выдал им обещанный список с препятствиями, включавший 12 пунктов. Обстоятельства самые разнообразные: нежелание руководителей предоставлять разработчикам право самостоятельно принимать решения; плохие технические условия; сотрудники, отказывающиеся приходить на ежедневные собрания по спринту; отсутствие нужных для работы помещений; проблемы, связанные с рабочим процессом; межличностные отношения; системные проблемы, присущие любой корпорации.
Многие перечисленные в списке препятствия могли казаться непреодолимыми. Как часто вам случалось, оглянувшись вокруг себя, задуматься: «Мы работаем безответственно сегодня, мы работали безответственно все годы, и все понимают, как это глупо». Поэтому сотрудникам кажутся нереальными изменения в корпоративной культуре. Когда-то я соглашался с ними, особенно если речь шла о больших компаниях с их душной атмосферой и косными принципами. Сегодня мне не хотелось бы поощрять такого рода мысли, поскольку Medco доказала, как я был неправ. Мой постоянный оппонент, старший вице-президент, работавший раньше в Toyota, в понедельник разослал наш список всем сотрудникам. Рядом с каждым препятствием было указано имя руководителя. К четвергу все пункты были решены, препятствия устранены. Поистине иногда, чтобы подтолкнуть людей к переменам, им нужно приставить пистолет к виску. Эта ситуация стала ярким примером, чего можно добиться, если есть воля к победе — или если за все отвечает парень из Toyota. Нет правил, начертанных на камне. Поэтому не бойтесь все ставить под сомнение. К концу следующего спринта динамика групп увеличилась на пятьдесят процентов. Новая дата сдачи была назначена на 1 сентября. Теперь на три месяца позже заявленного. Однако мы все равно не успевали, даже несмотря на ускорение темпа с 20 до 90 очков за спринт, более чем на 400 процентов!
Но и этого было недостаточно.
Мы с Брентом снова собрали всех: инженеров, разработчиков, и маркетологов, экономистов-аналитиков, сотрудников отдела по контролю за соблюдением норм, управляющих. Они боялись. Боялись потерять работу, боялись за свои должности, за свое будущее. Что с ними будет, если не удастся справиться с ситуацией? Я задал им три вопроса, и они должны были ответить на каждый.
Можем ли мы начать делать что-то иначе, чтобы еще ускорить темпы?
— Ну, в середине прошлого спринта ребята, отвечающие за информационную безопасность, отключили интернет, в результате наши сотрудники в Индии и Бразилии не могли работать, — сказал управляющий техническим отделом.
— Вот те раз! Мы не в состоянии это уладить, нет? — в недоумении спросил я.
Управляющий техническим отделом взглянул на управляющего отделом информационных технологий, сидевшего в дальней части стола. Они решили, что это сэкономит максимум один месяц. Оставалось найти еще два месяца.
Можем мы вычеркнуть что-то из списка заданий? Распределить часть заданий по разным группам?
Ни у кого не было никаких идей.
Может, найдем что-то, что мы могли бы не делать? Можем мы каким-то образом уменьшить объем работ?
— Нет, ни в коем случае, мы и так урезали требования как могли.
— Хорошо, тогда давайте проведем остаток дня в борьбе со списком заданий. Пусть каждое задание поборется за свою жизнь, — сказал я.
На это ушло несколько часов, но мы отбили еще один месяц.
— Ну вот, мы все еще отстаем, но теперь только на месяц. Если не найдем решения, то придется сказать начальству, что, увы, сделать ничего не можем, — сказал я.
— Нет! Нас всех уволят. Давайте еще разок взглянем на те три вопроса.
Я предложил встретиться с руководством. В конце концов, это не только наша проблема. И их тоже, и они могли бы помочь нам.
Встреча была короткой. Руководители компании внимательно выслушали нас и сказали: «Нам необходимо закончить проект к 1 июля. Может быть, для начала стоит ужать его до одного завода? Или одного центра? Или пары центров? Это помогло бы?» Было много сомнений, споров, кое-что пришлось организовать иначе, но в результате они пришли к выводу, что могут сократить некоторые параметры и уложиться в срок до июля 2007 года, как пообещал на Уолл-стрит их президент.
На той встрече старший вице-президент спокойно заметил: «Давайте признаем свою победу. Если у вас возникнут какие-либо проблемы — звоните».
Было любопытно наблюдать за ценами на акции Medco в то лето. Когда мы только начали создавать инфраструктуру проекта, цены уже пошли вверх, и когда мы сдали готовый проект, они продолжили расти. Как сильно? Ну, на многие миллиарды долларов, за год цена одной акции взлетела с 25 долларов до 50. На Уолл-стрит успокоились: компания продолжит привлекать новых клиентов и будет сохранять лидерские позиции в своей отрасли. Оглядываясь назад, я понимаю, что надо было просить не гонорар, а процент от дохода.
Спустя несколько лет Medco использовала Scrum, чтобы создать то, что они назвали «Medco 2.0». Они реструктурировали всю компанию. Новые заводы, новые роботы, новые процессы, новая автоматика. Марк Лэнди, который к тому моменту стал главным техническим директором компании, говорит, что, не будь у них опыта создания терапевтических методических центров, они не смогли бы осуществить такую реорганизацию: «Нам просто не разрешили бы сделать это в масштабах компании. Но к нам было доверие всей организации. Отдел развития, производственный и финансовый отделы, лаборатория клинической фармакологии — практически все нам верили. У нас была возможность создавать новую культуру». Именно это, по его мнению, самое важное в Scrum: менять среду, в которой люди работают десятилетиями, — многих, кстати, это пугает. Действительно, Medco, по словам Марка, пришлось избавиться от сотрудников, которые не смогли перестроиться. Не потому, что были некомпетентны, нет, дело в другом: они берегли информацию и знания лишь в собственных интересах, пытаясь гарантировать свою незаменимость, — а ведь могли бы помочь компании, команде и себе.
Изменение стратегического подхода к работе позволяет прийти к истинному совершенству.
Подведем итоги
Карта — еще не живая местность. Не обольщайтесь своим планом. Почти наверняка он неверен.
Планируйте только то, что нужно. Не пытайтесь предусмотреть все на многие годы вперед. Планируйте ровно столько, сколько нужно, чтобы ваши команды были всегда заняты.
Какая это собака? Не оценивайте в абсолютном выражении, например в часах, — уже не раз доказано, что люди не умеют этого делать. Оценивайте относительно, например в собако-единицах или по размеру футболок (S, M, L, XL, XXL), либо — что самое надежное — используйте последовательность Фибоначчи.
Спросите у оракула. Используйте анонимный метод, вроде дельфийского, чтобы не подвергнуться влиянию чужого мнения; избегайте эффекта ореола, эффекта стадности и группового мышления.
Планируйте с помощью покера. Используйте покер планирования, чтобы быстро оценить работу, которую нужно сделать.
Работа — это история. Сначала подумайте о человеке, который получит пользу от той вещи, которую вы делаете; потом подумайте о том, что это такое и, наконец, зачем им это нужно. Люди мыслят сюжетами и фактами, так дайте им их историю. Будучи X, I хочет Y, так что Z.
Узнайте свою динамику. Каждая команда должна точно знать, сколько работы она может выполнить за один спринт. Она должна знать, насколько может повысить динамику производительности, работая разумнее и устраняя все, что встает на пути и тормозит ее работу.
Динамика × время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише.
Ставьте перед собой стратегические цели. С методикой Scrum не слишком трудно удвоить производительность и в два раза приблизить время сдачи проекта. Если вы сделаете это вовремя, ваши доходы и стоимость акций удвоятся.
