Рецепт инноваций:
модель Agile

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

Как показывает наш опыт, именно так разрабатывают новинки многие подразделения, осуществляются маркетинговые проекты, выстраиваются стратегии, решаются проблемы снабжения и распределения ресурсов. Эти условия менее характерны для рутинной деятельности вроде обслуживания и эксплуатации заводского оборудования, снабжения, обзванивания потенциальных покупателей, бухгалтерского учета (см. врезку «Условия, подходящие для адаптивной модели»). И поскольку адаптивная модель требует подготовки, изменения привычных способов работы и, как правило, — новых ИТ, руководителям надо решить, стоит ли овчинка выделки.

Чтобы работать по адаптивной модели, нужен костяк энтузиастов. Один из главных ее принципов таков: «Рассчитывайте на мотивированных людей. Создайте им условия, обеспечьте им необходимую поддержку и доверьтесь им. Остальное они сделают сами». Если большинством голосов компания, отдел или группа решает работать по адаптивной модели, то руководителю, возможно, придется отстранить от проекта, а то и заменить несогласных с этим. Хотя лучше, конечно, если энтузиасты и их перетянут на свою сторону.

Таким путем пошла фирма OpenView Venture Partners, капитал которой инвестирован примерно в 30 компаний. От нескольких из них основатель фирмы Скотт Максвелл и узнал об адаптивной модели. Он стал применять ее методы у себя в организации. И выяснил, что одним видам деятельности они подходят больше, другим — меньше. К примеру, они вполне применимы к стратегическому планированию и маркетингу: там сложные проблемы обычно можно разбивать на модули и решать силами сводных групп. С продажами все обстоит иначе: любой звонок клиенту с предложением может изменить список первоочередных дел торгового агента, а снова собирать группу продаж, перетасовывать портфель и каждый час переназначать ответственных за инициативу слишком­ хлопотно.

Максвелл организовал для компаний из портфеля OpenView тренинги, на которых людей ознакомили с азами адаптивной модели, и предоставил им самим решать, работать по ней или нет. Одним эта идея понравилась сразу, другие воздержались. В числе энтузиастов оказалась Intronis. Тогда ее маркетинговый отдел работал по годовому плану, упор в котором делался на показатели продаж. Отдел продаж жаловался, что маркетинг чересчур консервативен и особого толку от него нет. И компания пригласила Ричарда Делахея, бывшего разработчика веб-сайтов, который переквалифицировался в маркетолога, и поручила ему перевести Intronis на адаптивную модель. Под его руководством маркетологи ­стали, в частности, за несколько дней, а не недель, разрабатывать тематические вебинары. (Быстро подготовленный вебинар о хакерской программе CryptoLocker собрал 600 зарегистрировавшихся участников; пока для компании это рекорд.) Группа по-прежнему составляет графики и бюджет для отдела цифрового маркетинга, но теперь у нее гораздо больше свободы маневра на случай непредвиденного развития событий. Продавцы довольны.

3. Начинать с малого — и пусть идет молва

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

В качестве примера расскажем, как адаптивную модель полюбили в John Deere, компании, которая производит сельхозтехнику. Джордж Тоум, инженер-программист, стал руководителем проекта в ИТ-отделе компании и в 2004 году начал применять ее методы — пока в очень скромных масштабах. В следующие несколько лет на адаптивную модель перешли программисты из других подразделений Deere. Интерес к ее методам возрастал, и это упростило внедрение модели в отделах развития бизнеса и маркетинга.

В 2012 году Тоум работал менеджером в отделе Enterprise Advanced Marketing, входившем в состав подразделения НИОКР, которое изобретало технологии, принципиально изменяющие продукцию Deere. Джейсон Брентли, глава подразделения, считал, что традиционные методы управления проектами будут тормозить работу, и они с Тоумом решили проверить, не поможет ли адаптивная модель ускорить дело. Тоум пригласил еще двух глав подразделений на тренинг, посвященный ее методам. Но всю терминологию и все примеры он взял из области разработок ПО, и для одного из слушателей — не-программиста это была китайская грамота. Тоум понял, что и остальные будут реагировать так же, и нашел специалиста, который умел объяснять суть адаптивной модели не-программистам. За последние несколько лет они с этим специалистом подготовили коллективы во всех пяти центрах подразделения НИОКР. Кроме того, Тоум стал каждую неделю публиковать короткие, на одну страничку, заметки о правилах и методах новой модели. Он рассылал их по электронной почте всем заинтересовавшимся, а потом размещал на сайте Deere — Yammer. В обсуждении участвовали сотни сотрудников компании. «Я хотел создать базу знаний об адаптивной модели, но с учетом специфики Deere, чтобы каждому у нас все было понятно, — говорит Тоум. — С этого началось бы освоение метода всей компанией».

Благодаря методам адаптивной модели в подразделении Enterprise Advanced Marketing существенно, иногда более чем на 75%, сократились сроки выполнения инновационных проектов. Например, прототип «дизайна внешнего облика машины» (информацию о ней Deere еще держит в секрете) создали примерно за восемь месяцев. «Прежде, когда мы работали традиционным образом, это в лучшем случае заняло бы года полтора, а то и два с половиной — три», — говорит Брэнтли. Есть и другие приятные последствия. Теперь весь коллектив болеет за дело и каждый доволен своей работой: соответствующие показатели переместились из нижней трети сводных результатов компании в верхнюю треть. Повысилось качество. Скорость, то есть объем выполненной в каждом цикле работы, выросла в среднем более чем на 200%; некоторые группы работают более чем на 400% быстрее, а одна даже на 800% — это настоящий рекорд.

Такие успехи не остаются незамеченными. Сейчас, по словам Тоума, почти во всех подразделениях John Deere кто-нибудь либо осваивает адаптивную модель, либо размышляет, как перейти на нее.

Принципы адаптивной модели

В 2001 году 17 разработчиков ПО, в том числе Джефф Сазерленд, собрались в Сноубёрде (штат Юта), чтобы обсудить, как улучшить традиционный каскадный принцип разработки, при котором этапы выполнения проектов составляют заранее, а потом передают из отдела в отдел. Такой принцип хорош, когда все стабильно, но не тогда, когда рынки ПО начали изменяться быстро и неожиданно, ПО устаревали к тому времени, как попадали к пользователям, а разработчикам приходилось преодолевать слишком много бюрократических препон.

Заговорщики договорились о четырех ориентирах в разработке ПО, сформулировали правила перехода на них и назвали свой документ «Манифестом адаптивной разработки». И с тех пор концепция, сформулированная с учетом этих ориентиров и правил, известна как адаптивная модель.

Вот сокращенный вариант манифеста.

Сначала — люди, потом — процессы и инструменты

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

Реагировать на перемены, а не выполнять план

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

Рабочие прототипы, а не бумажная волокита

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

Сотрудничество с клиентами, а не жесткий договор

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

4. Разрешить лучшим ­коллективам настраивать ­модель под себя

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

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

Через какое-то время освоившим азы адаптивности надо разрешить по-своему совершенствовать модель. Например, согласно одному из правил, нужна постоянная гласность и в успехах, и в неудачах. Поначалу гласность обычно поддерживали так: на большие белые доски (известные как «доски канбан») в три колонки — «выполнить», «выполняется», «выполнено» — наклеивали цветные стикеры. Многие разработчики до сих пор так делают; им нравится, когда люди из других групп заходят к ним обсудить, как идут дела. Но кто-то предпочитает специальное ПО, потому что так проще вводить информацию и ее можно получить не только в офисе.

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

Spotify, сервис потоковой музыки, — опытный «приспособленец». Компания, основанная в 2006 году, работала по адаптивной модели с первых дней своей жизни. Вся ее бизнес-модель, от разработок продукции до маркетинга и общего управления, нацелена на качественное обслуживание клиентов, а именно на это и настроена адаптивная модель. Но руководство больше не диктует сотрудникам, как им работать. Наоборот, топ-менеджеры — за эксперименты и гибкость, ведь постоянные изменения соответствуют принципам адаптивности и улучшению результатов. В итоге все 70 «звеньев» Spotify (так тут называют группы адаптивной разработки) и все ее «тематические отделы» (тоже здешний термин, обозначающий их узкую специальность вроде разработки пользовательского интерфейса и тестирования качества) применяют разные методы. Хотя почти каждое «звено» состоит из маленькой сводной группы и по-своему отслеживает ход работ и адаптивного планирования, ранжирует задачи и на мозговых штурмах обсуждает, как добиваться большего, многие группы не составляют ­графики выполненного и незавершенного, то есть пренебрегают тем, что делает большинство адаптивных групп. «Звенья» не всегда измеряют скорость, ведут отчетность о ходе работ и одинаково оценивают время, необходимое для конкретного задания. «Звенья» протестировали собственные методы и пришли к выводу, что именно благодаря им они стали работать плодотворнее.

5. Адаптивная модель для руководства

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

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

1. Не отставать от первопроходцев. Systematic — компания, выпускающая ПО (в ее штате 525 человек), перешла на адаптивную модель в 2005 году. Когда методы модели освоили все группы программистов, гендиректор и сооснователь Systematic Майкл Хольм стал опасаться, что менеджеры будут мешать им работать. «Наши программисты освоили метод scrum и работали по-новому, а руководство — по старинке». Дело продвигалась медленно, начальники требовали множество письменных отчетов, которые сразу же казались ­устаревшими. И ­в 2010 году Хольм решил перестроить деятельность своих заместителей по примеру групп адаптивной разработки.

Руководство пересмотрело виды работ, выполняемых менеджерами, и от многих отказалось. Например, почти вдвое сократили количество периодических отчетов, остальные данные топ-менеджеры должны были сразу же заносить в цифровые системы и больше уделять внимания самым важным для бизнеса вопросам, таким как коммерческие предложения и удовлетворенность клиентов. Сначала группа собиралась на пару часов по понедельникам, но, поняв, что так редко принимать решения недопустимо, перешла на режим ежедневных 20-минутных летучек, которые начинались в 8:40 утра. На них обсуждалось, что было сделано накануне, чем заняться сегодня, какая и кому нужна помощь. Потом руководство стало писать данные о работе подразделений на белых досках: так было проще отслеживать положительные сдвиги. Остальные отделы — юридический, финансовый, продаж и персонала — работают сейчас во многом так же.

2. Способствовать изменению организации. В 2015 году General Electric провозгласила себя «цифровой производственной компанией», подчеркивая свою нацеленность на выпуск «умной» техники. В рамках преобразования было создано подразделение GE Digital, в него перевели 20 с лишним тысяч сотрудников — всех, кто так или иначе работал с ПО. Брэд Сурак, операционный директор GE Digital, который начинал трудовую карьеру как инженер-программист, хорошо знал методы адаптивной модели, в том числе скрам. Он отработал его с группой топ-менеджеров, отвечавших за создание приложений для промышленного интернета, а затем, относительно недавно, стал применять его к таким управленческим процедурам нового подразделения, как обзор операционной деятельности. Сурак — ответственный за инициативу, а главный инженер — ведущий. Они вместе выстроили очередность предстоящих работ для группы топ-менеджеров. В частности, они наметили упрощение правил, которым должны были следовать группы, приобретая оборудование и решая сложные вопросы ценообразования на продукцию, в производстве которой участвовало несколько подразделений GE.

Члены группы работают двухнедельными циклами-спринтами и трижды в неделю ­собираются на летучки. Выполнение своей работы они отмечают на доске, висящей в конференц-зале — там ее может увидеть каждый сотрудник. Сурак говорит об этом так: «Это снимает завесу тайны с повседневной работы топ-менеджеров. Люди хотят знать, идем ли мы с ними рядом, понимаем ли, что их волнует». Группа определяет степень удовлетворенности сотрудников, проводя опросы, анализирует первопричины того, что мешает работе, и информирует о результатах остальную организацию, там самым как бы говоря людям: «Мы вас слышим. Вот что мы сделаем, чтобы стало лучше». Это, как считает Сурак, показывает организации, что «топ-менеджеры работают так же, как программисты и инженеры», а от этого люди все больше доверяют методам адаптивной модели.

3. Сплотить подразделения вокруг общей концепции. Эрик Мартелла, вице-президент и управляющий Mission Bell Winery, производственного подразделения Constellation Brands, внедрил в своей вотчине методы адаптивной модели и всячески способствовал их ­распространению по всей организации. Главы каждого подразделения взяли на себя роль ответственных за инициативу в созданных ими адаптивных группах. Группы эти достигли ярких результатов, но Мартелла заметил, что они неэкономно расходуют время и что цели подразделений и предприятия в целом не всегда совпадают. Он решил объединить глав подразделений в адаптивную группу высшего звена, чтобы топ-менеджеры занимались общекорпоративными проектами вроде рационализации работы склада, которые лучше всего выполнялись бы сводными командами.

Эта группа топ-менеджеров отвечает за формирование и постоянное уточнение приоритетных задач компании и следит за тем, чтобы остальные адаптивные группы занимались первоочередными проблемами и располагали ­необходимыми ресурсами. Кроме того, топ-менеджеры защищают организацию от ненужных проектов, выполняемых по прихоти каких-нибудь начальников. Например, вскоре после того, как Мартелла начал внедрять методы адаптивной модели, он получил письмо от главы центрального офиса Constellation. Тот предлагал винному заводу воплотить идею, в которой он сам и был заинтересован. Раньше Мартелла согласился бы. Теперь же он ответил, что завод работает согласно правилам адаптивной модели и что идею оценят с точки зрения ее перспективности. Между прочим, тому топ-менеджеру понравился такой подход, и, когда его уведомили, что его предложение не сочли многообещающим, легко смирился с таким решением.

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

6. Устраните все, что ­мешает работать по адаптивной ­модели

Исследования, которые проводила Scrum Alliance, независимая НКО, насчитывающая в своих рядах более 400 последователей, показали: более 70% специалистов, работающих по адаптивной модели, сообщают о непростых отношениях между своими группами и остальной организацией. Удивляться тут нечему: у них разные планы и разная скорость.

Вот показательный пример. Крупная финансовая компания начала пилотный проект — разработку нового мобильного приложения по адаптивной модели. Естественно, первым делом надо было набрать группу, а для этого — подать заявку на утверждение и финансирование проекта. Заявка, вместе с другими, пошла по инстанциям, чтобы ее одобрили и включили в план на следующий год. Спустя несколько месяцев ее наконец утвердили. Проект выполнили, получилось очень удачное приложение, которое сразу же оценили пользователи. Группа была довольна результатом. Но, прежде чем ­выпустить ­приложение на рынок, его предстояло протестировать на ­уязвимость по традиционной каскадной модели (это долгая процедура: пишут программную документацию, проверяют функциональность, ­эффективность и стандартизацию) в порядке общей длинной очереди. Затем надо было интегрировать приложение в основные ИТ-системы, а это еще один «каскад», растягивающийся на шесть-девять месяцев. В итоге время от начала разработки до выпуска почти не сократилось.

Вот как можно устранять подобные прег­рады.

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

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

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

Группа важнее, чем каждый по отдельности. Согласно данным исследований, в том числе проведенных в Center for Collective Intelligence Массачусетского технологического института, результаты работы группы зависят от уровня интеллекта каждого ее отдельного члена, но больше всего — от коллективного интеллекта. И его намного проще изменять. Ведущий группы, работающей по адаптивной модели, помогает ей совершенствовать коллективный разум: уточняет роль каждого, объясняет, как улаживать конфликты, следит, чтобы все вносили равный вклад в работу. Полезно также руководствоваться другими показателями: оценивать не производительность и нагрузку, а результаты работы и удовлетворенность коллектива, то есть то, насколько люди ощущают свою нужность и насколько они преданы делу. Полезно также премировать сотрудников по результатам общей, а не индивидуальной работы.

Руководить, задавая вопросы. Как известно, генерал Джордж Паттон советовал руководителям никогда не указывать людям, как делать то или иное. «Говорите им, что надо делать, и они удивят вас своей изобретательностью». Руководители организации, работающей по адаптивной модели, учатся управлять, не отдавая приказы, а с помощью вопросов, например таких: «Что бы вы посоветовали?» или «Как можно это проверить?». В таком случае узкие специалисты превращаются в менеджеров широкого профиля, а стратеги компании и ее подразделения перестают драться за власть и ресурсы, а начинают работать как межфункциональные коллективы.

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