Текст книги "Чувствуй и реагируй. Как создавать продуты, нужные людям именно сейчас"

В 2011 году легендарный предприниматель в области технологий Марк Андриссен поделился своей убежденностью в том, что «программное обеспечение поглощает мир». Мы согласны с его метафорой. И не только мы: ее часто цитируют.

Последствия этого «поглощения» сейчас ощущаются в полной мере. Организации, ориентирующиеся на старые промышленные методы, теперь должны противостоять мощнейшим силам программного обеспечения. Им нужно составить новый план действий, по образцу описанного в Части I этой книги. В Части II мы углубимся в детали этого плана и исследуем выводы для менеджеров всех подразделений организации.

КЛЮЧЕВЫЕ МОМЕНТЫ ПОДХОДА «ПОЧУВСТВОВАТЬ И ОТРЕАГИРОВАТЬ» ДЛЯ МЕНЕДЖЕРОВ

✓ Все чаще организациям приходится сталкиваться с революционной силой программного обеспечения.

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

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

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

Часть вторая
Руководство для менеджеров по использованию подхода «почувствовать и отреагировать»

Глава 5
План изменений и неопределенность

Как определить, когда работу можно назвать выполненной? Для большинства из нас это кажется довольно простым: это означает, что мы сделали нашу работу. Мы учимся этому в начале нашей школьной жизни. Выполните свою домашнюю работу. Выполните работу по дому. А когда закончили, можете поиграть со своими друзьями, почитать книги, посмотреть фильм и так далее. Мы переносим этот подход на свое рабочее место. Закончите отчет. Сделайте обход. Сходите на собрание. Когда вы закончите? «Конец рабочего дня!»

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

Однако обычно это не означает: «Мы закончили делать то, что, как мы знаем, повышает ценность бизнеса».

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

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

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

Действительно ли компании предпочитают «выполнено», а не успех? И если так, то зачем?

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

Однако благодаря программному обеспечению связь между «мы выполнили это» и «это привело к планируемому эффекту» более-менее ясна. Будет ли наш недавно переделанный сайт действительно способствовать, например, росту аудитории или эти изменения приведут к неожиданным последствиям? Об этом очень трудно узнать без создания и тестирования системы. В отличие от промышленного производства, мы не создаем бесчисленное количество экземпляров одного товара. Вместо этого мы создаем единую систему (или набор взаимосвязанных систем, которые представляются нам как одна система) и зачастую не знаем до тех пор, пока не «выполним», будет ли то, что мы запускаем, работать по плану.

НАЦЕЛЕННОСТЬ НА РЕЗУЛЬТАТ НЕ СРАБОТАЕТ В НЕОПРЕДЕЛЕННОСТИ

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

В типичном процессе мы бы поручили внутренней команде разработать запрос на предложение (RFP – request for proposal). Этот запрос основывался бы на некотором анализе бизнес-проблемы, содержал описание характера решения и перечень требований (как правило, характеристик системы), а также просьбу поставщикам о представлении предложений.

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

Как только мы выбираем поставщика, мы заключаем контракт, фиксирующий разработанные нами требования, а также цену и сроки, обещанные поставщиком. Подобного рода контракт свидетельствует, что обе стороны содействуют выполнению проекта, нацеленного на некий результат. Поставщик, скорее, стремится к созданию заданного набора функций (другими словами, к «выполнению»), чем к разработке чего-то, что принесет успех.

ОПРЕДЕЛЕНИЕ ПРОБЛЕМЫ В РЕЗУЛЬТАТЕ

Если вы приобретаете пользовательское программное обеспечение примерно тем способом, который описан, вы знаете, что происходит дальше. Поставщик не выполняет обещанное. Опытный ИТ-менеджер объясняет: «Проблема в фиксированных контрактах. Вы оба обманываете друг друга в том, что якобы понимаете, в чем состоит проблема». В результате, когда выясняется истинная природа проблемы, каждая из сторон должна вносить корректировки. Результат поправок? Поставщик опоздал и превысил бюджет. Но опытный менеджер знает: «В итоге всегда появляется проблема, и вместо того, чтобы решать ее или улучшать продукт, вы спорите о том, кто за это заплатит».

КАК FACEBOOK СМОГ ДОСТИЧЬ ВСЕМИРНОГО ВЛИЯНИЯ С ВЕСЬМА НЕБОЛЬШИМ ШТАТОМ СОТРУДНИКОВ И ЗА ТАКОЙ КОРОТКИЙ СРОК? КОНЕЧНО ЖЕ, БЛАГОДАРЯ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ.

АЛЬТЕРНАТИВА РЕЗУЛЬТАТУ – ЦЕЛЬ

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

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

Оказывается, подобную проблему – срыв планов вследствие неопределенности и ошибочную реакцию в виде составления все более подробных планов – военные командиры пытались решить на протяжении сотен, если не тысяч лет. Они разработали систему военного руководства под названием управление целями как альтернативу жесткой системе руководства, которая очень подробно определяет, что подразделения должны делать в бою. Новая гибкая система, напротив, предписывает высшему командованию устанавливать цели и задачи, но при этом оставляет принятие конкретных решений людям, ведущим боевые действия. В работе Стивена Бунгей «The Art of Action» прослеживается развитие этих идей в прусской армии 1800-х годов и описывается система, которую военачальники разработали для того, чтобы справляться с неопределенностью на поле битвы[50]50
  Stephen Bungay, The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results (London: Nicholas Brealey Publishing, 2010), Kindle edition.


[Закрыть].

Такое гибкое командование строится на трех важных принципах:

• Не командуйте больше, чем нужно, или не планируйте сверхпредсказуемые условия;

• Донесите до каждого подразделения как можно больше идей, необходимых для достижения цели;

• Убедитесь в том, что каждый человек свободен в принятии решений в пределах своей ответственности.

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

УПРАВЛЕНИЕ ЦЕЛЯМИ

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

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

Чтобы перевести разговор с темы деталей, мы спросили: «Чего должна добиться успешная система? Если бы мы должны были доказать себе, что в систему стоит инвестировать, какую информацию мы бы использовали?» Этот разговор дал некоторые четкие, конкретные ответы. Прежде всего, система должна быть запущена в конкретный день, примерно через четыре месяца. Организация участвует в ежегодном мероприятии по случаю празднования дня отрасли, и ее руководители хотели бы продемонстрировать систему спонсорам. Мы спросили: «Что для вас значит запуск?» И снова их ответы были конкретными: нам нужно, чтобы X участников были активными со стороны волонтеров, а Y участников были активными со стороны организации. Поскольку цель сервиса состояла в том, чтобы количество волонтеров и организаций для совместной работы над проектами было сопоставимо, мы должны были сверстать Z соответствий: определенный процент пересечения этих совпадений должен был создать предпосылки для успешных, завершенных проектов.

Такими были наши показатели успеха: X и Y участников, Z совпадений, процент выполненных проектов. (На самом деле, обычно мы устанавливаем конкретные количественные цели, но для этой истории используем переменные).

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

Понятно, что руководители, подписавшие контракт, были обеспокоены: какие у них гарантии того, что это будет полноценный проект?

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

Наш контракт с Taproot содержал не только список желаемых функций, но и список желаемых целей. Вот цели, которые мы вписали в этот контракт:

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

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

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

ВИДЕНИЕ РЕЗУЛЬТАТОВ

Так как же продвигался проект? Сначала команда считала, что самой важной вехой является запуск системы. Чтобы не ждать четыре месяца (срок исполнения проекта), члены команды решили запустить ее как можно скорее. Как оказалось, они смогли выйти в эфир для пробной аудитории в течение месяца. Они запустили радикально упрощенную версию сервиса с очень небольшим количеством автоматических функций. Большая часть работы в системе выполнялась вручную специальным человеком, комьюнити-менеджером (комьюнити-менеджер – специалист в области создания, поддержки и развития сообществ/структур – перев.), действующим за кулисами. (Подобный подход, который использовался командой Cooking Light Diet, мы описали в Главе 2).

Этот диспетчерский подход к минимальному жизнеспособному продукту (MVP) стал популярным способом запуска систем. Команда Taproot знала, что потребуется больше автоматизации, если она хочет, чтобы система расширялась в масштабах, но также она знала, что автоматизация может появиться и позже. Досрочный запуск достиг двух целей. Во-первых, он гарантировал, что команде будет что показать спонсорам на ежегодном мероприятии. Это было чрезвычайно важной маркетинговой и торговой целью. А во-вторых, что более важно, он позволил команде выяснить, какие функции ей действительно понадобятся для масштабной работы системы. Другими словами, это вывело команду в режим «почувствовать и отреагировать» – двусторонний разговор с рынком, который и будет направлять развитие сервиса.

Например, проектировщики предполагали, что квалифицированные волонтеры должны иметь возможность создавать в сервисе профили. Затем организации будут просматривать эти профили и отбирать волонтеров, которые пришлись им по душе. Это оказалось совершенно неверным. Когда команда предложила волонтерам создавать профили, те ответили безразличием. Команда осознала – для того чтобы система работала, волонтеров придется замотивировать к участию: им необходимо подыскать проекты, которые им понравятся. Для этого нужны списки проектов, а не списки волонтеров. Иначе говоря, команда должна была изменить порядок системы, поскольку первоначальные планы были неверными.

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

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

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

Мы увидели много примеров провала централизованного планирования в современную эпоху. Достаточного вспомнить неудачи советского блока и коммунистической китайской экономики XX века, чтобы увидеть примеры того, что экономисты называют проблемой местных знаний: речь о том, что центральные органы планирования не имеют четкого понимания реальности на местах для разработки адекватных детальных планов. Сколько хлеба нужно в этом городе? Сколько пшеницы нужно поставить этой фабрике? А что если будет плохой урожай? Что если на складе случится пожар? Что если в регионе едят рис?

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

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

Agile-методы не масштабируются. Меня убеждали в этом больше десяти лет, и я просто отказывался верить оппонентам, однако они были правы. Означает ли это, что вы не можете выполнять крупномасштабные программы с использованием agile-методов? Вовсе нет.

Но для масштабирования вам нужно что-то еще, что-то существенно другое, о чем существующие agile-методы умалчивают[51]51
  Dan North, “Why Agile Doesn’t Scale, and What You Can Do About It,” presentation at GOTO conference, September 30, 2013, http://gotocon.com/aarhus-2013/presentation/Why+Agile+doesn’t+scale,+and+what+you+can+do+about+it. When we spoke to North, he went on to say, “If you want to scale and be agile, the solution may not be more scrum teams.” (Scrum is the most popular agile method. When people think of agile, they’re usually thinking of scrum.) Instead, he told us, “When you have a lot of work to do,you have to ask, What is the shape of the work, and what’s the best shape of people to do the work?” North described a process of asking these questions quarterly and adjusting assignments and organization continuously in response to the nature of the work.


[Закрыть].

УПРАВЛЕНИЕ НА ПРОГРАММНОМ И ПОРТФЕЛЬНОМ УРОВНЯХ

На примере Taproot мы наблюдали, как одна команда смогла приблизиться к созданию проекта с помощью agile-методов. Но если мы действительно хотим создать agile-организации, нам следует рассмотреть, как гибкий подход может быть применим не только на уровне команды, но и на двух следующих уровнях. Первый – это программный уровень, когда группа из двух или более команд сотрудничает между собой и работает над достижением общей цели. Второй – портфельный уровень, отражающий совокупность всей работы организации.

В последние годы подход agile перестал считаться методом для особо продвинутых и стал распространенным способом работы. Авторы недавнего доклада, подготовленного по заказу компании Hewlett-Packard, подсчитали, что более 90 % крупных организаций либо уже используют эти подходы, либо работают над их широким использованием[52]52
  TechBeacon, “State of Performance Engineering, 2015–2016 Edition,” http://techbeacon.com/sites/default/fi les/State-of-Performance-Engineering-2015-16_FINAL2.pdf.


[Закрыть]. И по мере обретения популярности этих методов, организации по всему миру пытаются найти решения для масштабирования гибкого подхода. Как указывает Норт, это обусловлено тем, что гибкость по существу является «командным» методом работы, а крупным организациям нужна система для координирования работы многих команд.

Один из наиболее популярных подходов к такому координированию называется масштабированный гибкий фреймворк, или SAFe (scaled agile framework). Как следует из аббревиатуры, SAFe дает менеджерам чувство комфорта. В конце концов, огромная организация, в которой существуют самоуправляемые команды – это кошмар для менеджеров. Очень похоже на анархию.

SAFe – это способ дробления больших проектов на небольшие части, работа над которыми поручается командам, а также создания системы подотчетности, гарантирующей, что команды завершат работу, на выполнение которой они подписались. Проблема данного подхода заключается в том, что он, собственно, является подходом «более детализированного плана», который исключает влияние неопределенности. SAFe уводит команды от подхода «почувствовать и отреагировать» и направляет к методам централизованного планирования. Фактически, это снижает статус гибкой команды до уровня производственной команды – ей выставляется фиксированный набор требований, и ожидается, что со сборочной линии сойдет конкретный произведенный товар. Этот подход может подойти для каких-то конкретных задач, но в целом он ограничивает возможность команды обучаться с помощью обратной связи по мере продвижения вперед. А ведь именно опыт обратной связи позволяет командам ориентироваться в условиях высокой неопределенности.

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