Помоги проекту - поделись книгой:
Проклятие «Пяти обвинений»
Когда команды начинают использовать метод «Пяти “Почему?”» для решения своих проблем, у них часто возникают одни и те же трудности. Обычно мы склонны слишком сильно реагировать на то, что происходит с нами в данный момент. И при этом очень расстраиваться, если вдруг происходит то, чего мы не ожидали.
Когда «Пять “Почему?”» используют не по назначению, я называю это «Пять обвинений». Вместо того чтобы вновь и вновь спрашивать «почему» и выяснять, что пошло не так, расстроенные члены команды начинают тыкать друг в друга пальцами в поисках виноватых. Вместо того чтобы использовать «Пять “Почему?”» для выявления и решения проблем, менеджеры и сотрудники иногда попадают в ловушку и начинают играть в «Пять обвинений» – это помогает им как-то выразить свои негативные чувства. Но такие поиски виноватых не дают увидеть недостатки системы. Мы все склонны считать, что ошибка – это следствие плохой работы какого-то другого отдела, невежества или дурного характера других людей. Но метод «Пяти “Почему?”» предназначен для того, чтобы помочь нам увидеть объективную истину. А она обычно состоит в том, что если проблема повторяется – это следствие неэффективных процессов, а не действий отдельных людей. Если мы поймем это, у нас появится шанс создать более адекватные процессы.
Чтобы не погрязнуть в «Пяти обвинениях», я предлагаю несколько тактик. Во-первых, на встрече, посвященной «Пяти “Почему?”» должны присутствовать все, кого касается проблема. На ней должны быть все те, кто обнаружил или диагностировал проблему, в том числе, если это возможно, сотрудники, обслуживающие клиентов. На ней должны быть все, кто пытался устранить симптом, а также все, кто работал с подсистемами или опциями, связанными с проблемой. Если проблема дошла до уровня высшего руководства, то руководители, которые не решили проблему вовремя, тоже должны прийти на встречу.
В результате на встрече может быть очень много людей, но это не страшно. По моему опыту, если кто-то не будет участвовать в обсуждении, в итоге именно он станет мишенью для обвинений. Козлом отпущения здесь может оказаться любой – и сотрудник низшего уровня, и генеральный директор. Если это простой сотрудник, может показаться, что его легко заменить. Если на встрече не присутствует генеральный директор, все начнут думать, что на его действия повлиять невозможно. Но ни то, ни другое обычно не соответствует действительности.
Обвинения начнутся неизбежно. Но тем из присутствующих на встрече, кто имеет самый высокий статус, нужно выучить и повторять следующую мантру: «Если возникает ошибка, стыд нам и позор за то, что мы ее допустили! Но анализ пяти “Почему?” позволит нам взглянуть на проблему системно».
Вот пример ситуации, в которой эта мантра оказалась очень полезной. В процессе обучения новых сотрудников, который мы создали в IMVU с помощью метода «Пяти “Почему?”», мы просили их в самый первый рабочий день ввести какое-нибудь изменение в продукт. Программистов, обученных традиционным методам разработки, это пугало. Они спрашивали: «Что со мной будет, если я случайно прерву или остановлю процесс?» В компании, где они работали раньше, это считалось серьезной ошибкой, из-за нее могли уволить. Но мы говорили новичку: «Если наш производственный процесс такой хрупкий, что вы сможете нарушить его в первый же день работы, стыд нам и позор, что мы позволили вам это сделать». Если новичку действительно удавалось что-нибудь нарушить, мы немедленно поручали ему устранить проблему, а также придумать, как сделать так, чтобы следующему новичку не удалось повторить его ошибку.
Для новых сотрудников, приходивших к нам из компаний с другой культурой, это часто становилось настоящей инициацией, но все они проходили ее и при этом начинали понимать, каковы наши ценности. Шаг за шагом, система за системой это создавало надежный процесс разработки продукта, позволявший всем нашим сотрудникам работать более творчески и ничего не бояться.
С чего начать
Вот несколько подсказок на тему, как начать использовать метод «Пяти “Почему?”». Они основаны на моем личном опыте, ведь я помогал вводить этот метод во многих компаниях.
Чтобы «Пять “Почему?”» работали как следует, нужно соблюдать определенные правила. Например, он требует атмосферы взаимного доверия и ответственности. Если ее нет, использовать его будет довольно сложно. В таких ситуациях я предлагаю упрощенную версию, позволяющую командам анализировать причины проблемы и в то же время учиться применять этот подход – на будущее, когда появится возможность использовать его.
Я прошу всех следовать двум простым правилам:
1. Будьте терпимы к ошибкам, которые возникли впервые.
2. Не позволяйте, чтобы одна и та же ошибка повторялась дважды.
Первое правило помогает научиться спокойно воспринимать ошибки, особенно допущенные другими людьми. Помните: почти все ошибки вызваны некорректными системами, а не действиями отдельных людей. Второе правило помогает делать соразмерные инвестиции в предотвращение ошибок в будущем.
Такая упрощенная система довольно эффективна. Фактически мы использовали ее в IMVU в те дни, когда я еще не нашел метод «Пяти “Почему?”» и ничего не знал о производственной системе Toyota. Но упрощенная версия метода со временем теряет эффективность, и я убедился в этом на собственном опыте. Честно говоря, поэтому и заинтересовался методологией бережливого производства.
Достоинства и недостатки упрощенной версии метода заключаются в том, что она побуждает задавать определенные вопросы: что важно не менее, чем эта проблема? На каких типах ошибок нужно сосредоточиться? Нужно ли решить эту отдельную проблему или лучше попытаться предотвратить целую категорию проблем, связанных с этой? Членов команды, которая только начинает работать, эти вопросы заставляют задуматься. Это может стать основой для более тщательно продуманных методов. Но, так или иначе, на них придется ответить.
Лицом к лицу с неприятной правдой
Вы должны быть готовы к тому, что метод «Пяти “Почему?”» может вскрыть довольно неприятные факты. Он может показать, что сейчас важнее всего заняться профилактикой, и это придется делать за счет времени и денег, которые можно было бы направить на разработку новых продуктов или опций. При этом команде может казаться, что у нее нет времени, чтобы тратить его впустую на анализ причин, хотя такой анализ дал бы ей больше свободы и ресурсов в долгосрочной перспективе. В итоге может начаться игра в «Пять обвинений». Поэтому так важно, чтобы в процессе анализа пяти «Почему?» участвовал человек, обладающий достаточным авторитетом, способный довести дело до конца, а затем проследить за тем, чтобы проблема была решена, и способный выступить в роли арбитра, если возникнут разногласия. Иначе говоря, чтобы создать адаптивную организацию, нужна поддержка руководства компании.
Часто сотрудники стартапов приходят на мои семинары, чтобы научиться использовать метод «Пяти “Почему?”». Но я не рекомендую им это делать, если у них нет поддержки менеджера или руководителя группы. В такой ситуации нужно действовать осторожно. Возможно, вам не удастся собрать всю команду для настоящего исследования в стиле пяти «Почему?», но в своей собственной работе вы всегда можете использовать более простую версию этого подхода, состоящую из двух правил. Всякий раз, когда что-то идет не так, спросите себя: что я могу сделать, чтобы в следующий раз не оказаться в такой ситуации?
Начните с малого и будьте конкретны
Я рекомендую начать с нескольких четко определенных симптомов. Например, я впервые успешно использовал метод «Пять “Почему?”» для анализа причин проблемы, касавшейся одного нашего внутреннего инструмента тестирования, который не оказывал непосредственного влияния на пользователей. Конечно, заманчиво начать с чего-то большого и важного, ведь именно на большие и важные вещи команда тратит впустую больше всего времени. Но когда на кону стоит многое, «Пять “Почему?”» могут быстро превратиться в «Пять обвинений». Чтобы научить команду использовать этот метод, лучше начать с не слишком важных проблем и только потом применять его там, где ставки высоки.
Чем конкретнее симптомы, тем легче понять, когда нужно назначить встречу, посвященную «Пяти “Почему?”». Скажем, вы хотите использовать «Пять “Почему?”», чтобы понять причины жалоб клиентов. В этом случае, назначьте дату, после которой все жалобы станут автоматическим сигналом о том, что пора провести встречу. При этом объем жалоб не должен быть слишком большим. Это позволит проводить встречи «Пяти “Почему?”» каждый раз, когда это потребуется. Если жалоб слишком много, выберите отдельный класс жалоб, на котором можно сосредоточиться. Правила, которые определяют, какие виды жалоб будут сигналом о том, что пора провести встречу «Пяти “Почему?”», должны быть простыми и неизменными. Например, можно рассматривать все жалобы, связанные с оплатой кредитными карточками. Это несложное и понятное правило. Не выбирайте правила, которые можно трактовать по-разному.
Сначала может возникнуть соблазн ввести радикальные изменения сразу во всех системах расчетов и во всех процессах. Не делайте этого. Лучше проводите короткие встречи и выбирайте относительно простые изменения для каждого из пяти «почему». Со временем, когда команда начнет лучше понимать метод «Пять “Почему?”», изменения могут становиться более серьезными, можно включать все больше типов жалоб, а затем перейти к другим проблемам.
Специалист по «Пяти “Почему?”»
Чтобы ускорить процесс обучения, назначьте специалиста по «Пяти “Почему?”» для каждой сферы, в которой используется этот метод. Этот человек будет модератором на каждой встрече, посвященной принятию решений о том, какие профилактические меры нужно принять, и будет давать задания ее участникам. Специалист по «Пяти “Почему?”» должен занимать высокую должность, чтобы иметь достаточно полномочий и гарантировать, что задачи будут выполнены, но при этом у него должно быть время для того, чтобы присутствовать на встречах. Специалист по «Пяти “Почему?”» – главный человек с точки зрения ответственности, он – основной проводник изменений. Он может оценить, успешно ли проходит встреча и эффективны ли действия компании, направленные на устранение обнаруженной проблемы.
«Пять “Почему?”» в действии
IGN Entertainment, подразделение корпорации News Corporation, разрабатывает онлайн-видеоигры. У ее игр самая многочисленная аудитория геймеров в мире: она составляет больше 45 млн человек. Компания IGN была основана в конце 1990-х гг., а в 2005 г. ее купила News Corporation. На сегодняшний день в ней работает несколько сот человек.
Недавно у меня была возможность пообщаться с командой разработчиков IGN. В последние годы компания работала вполне успешно, но, как и все крупные компании, с которыми мы встречались в этой книге, хотела ускорить процесс разработки новых продуктов и активизировать инновации. Она объединила команды разработки, продукта и дизайна, чтобы обсудить способы использования системы «экономичный стартап».
Эту инициативу поддерживали руководители IGN, в том числе генеральный директор и глава подразделения разработки продукта. Прежние попытки использовать в компании метод «Пяти “Почему?”» не принесли особых результатов. Проблемы, которые нужно было решить, были самыми разными – от несоответствий в веб-аналитике до неэффективных партнерских баз данных. Первая встреча, посвященная анализу «Пяти “Почему?”», длилась около часа. На ней возникло несколько интересных идей, но в целом ее нельзя было назвать удачной. Никто из тех, кто был связан с проблемами и больше всего знал о них, на ней не присутствовал. Раньше компания никогда не проводила таких встреч, поэтому участники не придерживались формата и постоянно отклонялись от темы. Это нельзя было назвать пустой тратой времени, но не дало того эффекта, которым так ценен этот метод.
Не пытайтесь решать с помощью «Пяти “Почему?”» хронические проблемы
Компания IGN уже пыталась решить все эти проблемы. И это не удавалось ей в течение многих лет. Такие хронические проблемы носят эндемический характер и поэтому естественным образом выходят на поверхность во время анализа пяти «Почему?». Эту возможность можно использовать для того, чтобы начать постепенно решать их. Если же такие проблемы не всплывают сами собой во время анализа, возможно, они не так важны, как кажется.
В попытках использовать метод «Пяти “Почему?”» IGN упустила из виду три важных момента:
1. Чтобы ввести в организации этот метод, необходимо проводить новую встречу каждый раз, когда возникает новая проблема.
2. На сессиях анализа пяти «Почему?» должны присутствовать все, кто имеет отношение к проблеме. Многие организации пытаются экономить время, освобождая слишком занятых людей от участия в таких встречах. Но это вовсе не экономия, как обнаружила IGN на собственном горьком опыте.
3. В начале каждой встречи нужно отводить несколько минут на то, чтобы объяснить, для чего она нужна и какие преимущества анализ пяти «Почему?» даст тем, кто с ним пока не знаком. Если можно, приведите пример подобных успешных встреч из прошлого. Если вы проводите такую встречу впервые, можете использовать мой пример о менеджере, который не считал нужным обучать новых сотрудников. Команда IGN открыла для себя, что лучше всего, если это возможно, использовать примеры, важные для членов команды.
После первой встречи руководство IGN решило дать методу «Пять “Почему?”» еще один шанс. Следуя советам, изложенным в этой главе, они назначили специалиста по «Пяти “Почему?”». Им стал Тони Форд, директор по разработке. Тони был предпринимателем и пришел в IGN, когда она купила его небольшую компанию. Он начал с интернет-технологий и в конце 1990-х гг. стал создавать веб-сайты, посвященные видеоиграм. Так появился стартап TeamXbox, где Тони был ведущим разработчиком программного обеспечения. В 2003 г. TeamXbox вошла в состав IGN Entertainment, и Тони стал разработчиком, а также лидером инноваций и сторонником гибкой методологии разработки и бережливого производства.
К сожалению, с самого начала Тони не удалось выбрать узкую проблемную область, на которой все могли бы сосредоточиться. Это вызвало замешательство и раздражение. Сам Тони рассказывает об этой ситуации так: «Я только недавно стал специалистом по «Пяти “Почему?”» и провел встречу не лучшим образом. Кроме того, мы выбрали для решения слишком сложные проблемы. Поэтому первые встречи не принесли особой пользы. Я был обескуражен и расстроен».
Так обычно бывает, когда мы пытаемся сделать сразу слишком много. Но чтобы овладеть новыми навыками, нужно время. К счастью, Тони проявил упорство: «Я считаю, что очень важно назначить специалиста по «Пяти “Почему?”». Этот метод несложен в теории, но его трудно использовать на практике, поэтому на встрече должен присутствовать тот, кто хорошо с ним знаком, и направлять тех, кто еще мало знает о нем».
Все изменилось, когда Тони провел встречу в связи с одним проектом, который не был закончен в срок. Встреча была увлекательной, на ней родилось множество новых идей и были приняты правильные решения. Тони говорит: «Все прошло хорошо, ведь и у меня, и у других участников было больше опыта. Все уже знали, что это за метод, и я поработал как следует. Я успешно руководил встречей и не позволял участникам отклоняться от темы. Это было самое главное. Это был поворотный момент. Тогда я понял, что «Пять “Почему”» – новый инструмент, который поможет нам работать еще лучше».
На первый взгляд, метод «Пять “Почему?”» хорош для решения технических проблем. Но по мере того, как команды избавляются от ненужных трат, они начинают по-новому воспринимать командную работу. Тони говорит: «Я осмелюсь сказать, что этот метод позволяет не только анализировать причины проблем, но и делиться информацией и мнениями. Это сближает команду, благодаря общему пониманию и общей точке зрения. Часто проблемы разобщают людей, а «Пять “почему?”», наоборот, объединяют их».
Как перейти к работе небольшими партиями
Прежде чем завершить тему создания адаптивной организации, я хочу рассказать еще одну историю. Она связана с продуктом, с которым вы, возможно, знакомы, если вам когда-нибудь приходилось управлять собственным бизнесом. Это QuickBooks, один из ведущих продуктов компании Intuit.
Программа QuickBooks много лет занимает ведущие позиции в своей категории. Поэтому у нее есть большая база лояльных клиентов, и она приносит компании Intuit существенную долю ее дохода. Команда разработчиков QuickBooks обычно выпускала новую версию ежегодно, одним большим пакетом. Так происходило и с другим программным обеспечением для ПК, созданным в последние два десятилетия. И так было еще три года назад, когда в команду пришел Грег Райт, новый директор по маркетингу QuickBooks. Существовало множество процессов, обеспечивавших целостность продукта и его своевременный выпуск. Перед выпуском новой версии команда тратила достаточно времени на то, чтобы выяснить, чего хотят пользователи.
Как правило, первые три-четыре месяца ежегодного цикла создания новой версии занимали разработка стратегии и планирование, при этом новые опции не создавались. После разработки плана и установки промежуточных этапов команда тратила следующие шесть-девять месяцев на создание опции. Этот процесс достигал кульминации в торжественный момент выпуска новой версии, а затем, в самом конце, команда получала первую обратную связь о том, удалось ли ей удовлетворить потребности клиентов.
Последовательность действий была такой: процесс начинался в сентябре, первая бета-версия была готова в июне, а вторая – в июле. Бета-версия, по сути, должна проверить, не уничтожит ли новый продукт компьютеры пользователей или их данные – на этой фазе процесса можно устранить только серьезные ошибки.
Это метод водопадной разработки, который разработчики программного обеспечения используют уже много лет, – линейная система, основанная на подходе больших партий, успех которой зависит от правильности прогнозирования и планирования. Другими словами, она совершенно не соответствует современной быстро меняющейся среде бизнеса.
Год первый: вперед – к провалу
В 2009-м, в первый год своей работы в команде QuickBooks, Грег столкнулся с серьезной проблемой. Компания представила совершенно новую систему для онлайн-банкинга. Это была одна из самых важных опций новой версии QuickBooks. Команда провела несколько раундов тестирования удобства и простоты использования, применяя макеты и теоретические модели, а затем провела бета-тестирование на основании типовых данных о пользователях. В момент запуска все выглядело хорошо.
Первая бета-версия была выпущена в июне, и тут же стали поступать негативные отзывы. Пользователи жаловались, но достаточных оснований для того, чтобы приостановить выпуск новой версии, не было, потому что технически она отвечала всем требованиям – не уничтожала компьютеры. Грег оказался в безвыходном положении. Он никак не мог выяснить, как эта обратная связь повлияет на реальное поведение потребителей на рынке. Это просто отдельные жалобы? Или симптом общей проблемы? Одно он знал наверняка: его команда должна уложиться в срок.
Когда продукт наконец вышел на рынок, разразилась буря. Пользователям требовалось в четыре-пять раз больше времени, чтобы совершать свои банковские операции, чем в более ранней версии. Оказалось, команда Грега не смогла удовлетворить именно ту потребность клиентов, которую пыталась удовлетворить (несмотря на то, что продукт был создан в соответствии со спецификациями). Кроме того, следующая версия продукта также должна была пройти через тот же самый процесс водопадной разработки. Поэтому у команды ушло девять месяцев на то, чтобы устранить ошибки. Это классический случай успешного выполнения некорректного плана.
Чтобы оценить степень удовлетворенности пользователей ее продуктами, компания Intuit проводит маркетинговые исследования с использованием NPS (Net Promoter Score – чистый индекс поддержки). Это надежный способ установки действенных показателей, дающий объективное представление о том, что пользователи думают о продукте. Я использовал его и в IMVU. Одно из достоинств NPS заключается в том, что он очень стабилен. Он измеряет основной уровень удовлетворенности потребителей и не подвержен незначительным колебаниям, регистрируя только существенные изменения в настроениях пользователей. В тот год показатели QuickBooks упали на 20 пунктов, впервые с того времени, как в компании начали проводить подобные исследования. Такое падение привело к существенным убыткам для Intuit и стало очень неприятным сюрпризом, ведь обратная связь от потребителей пришла на слишком поздних стадиях процесса, и у компании уже не было времени на итерацию.
Руководство компании решило, что пора что-то менять. Управлять этими изменениями было поручено Грегу. Теперь у него была важная миссия: достичь при разработке и развертывании QuickBooks скорости стартапа.
Год второй: мышечная память
Следующая страница этой истории рассказывает о том, что создать адаптивную организацию очень непросто. Грег решил изменить процесс разработки в QuickBooks на основании четырех принципов:
1. Сократить размер команды. Перейти от больших команд к небольшим, гибким группам, участники которых могут выполнять разные задачи.
2. Сократить время цикла.
3. Быстрее получать обратную связь от потребителей, тестировать, не повредит ли новая версия компьютеры пользователей, и выяснять, как влияют новые опции на качество обслуживания клиентов.
4. Дать командам полномочия принимать быстрые и смелые решения.
На первый взгляд, эти цели соответствуют методам и принципам, описанным в предыдущих главах. Но второй год работы Грега в команде QuickBooks тоже не был отмечен успехом. Например, он постановил, что команда перейдет к этапу выпуска за полгода, наполовину сократив время цикла и размер партий. Однако это не принесло успеха. Только благодаря своему упорству, команда отважно пыталась выпустить альфа-версию в январе. Однако проблемы, связанные с разработкой по методу больших партий, никуда не делись, и команда с трудом закончила альфа-версию лишь к апрелю. Эта система была лучше предыдущей, потому что проблемы можно было заметить на два месяца раньше, чем раньше, но она не принесла тех результатов, на которые рассчитывал Грег.
Фактически процесс разработки оставался почти таким же, как в прошлые годы. Как поясняет Грег: «У организации есть “мышечная память”, и людям трудно избавиться от старых привычек». Грег сражался с системой и проводил отдельные изменения, например переназначил дату выпуска, но старые привычки были еще сильны.
Год третий: прорыв
Раздраженный неудачами прошедшего года, Грег объединился с лидером команды разработки продукта Химаншу Бакси. Вместе они решительно избавились от всех старых процессов. Они публично заявили о том, что их объединенные команды намерены создать новые процессы и что они не собираются возвращаться к старому.
Грег и Химаншу не стали менять сроки выпуска новой версии. Вместо этого они сосредоточились на изменениях, связанных с процессами, продуктом и технологиями, которые позволяли работать с меньшими партиями. Эти технические инновации способствовали тому, что отзывы от клиентов стали поступать раньше. Грег начал новый год не с планирования действий на 12 месяцев вперед, а с того, что назвал «заторами» идеи/кода/решения. Инженеры, продукт-менеджеры и пользователи объединили усилия и создали «трубопровод идей». Грегу, как продукт-менеджеру, было страшно начинать год, не имея точного перечня опций новой версии продукта, но он был уверен в своей команде и в новом процессе. В третий год работы он ввел новые методы:
• команды активно участвовали в создании новых технологий, процессов и систем;
• кросс-функциональные команды были сформированы вокруг новых идей;
• контакт с пользователями поддерживался с самого начала разработки каждой опции.
Важно понять, что прежний подход позволял получать обратную связь от клиентов и вовлекать их в процесс планирования. В истинном духе
Переход к кросс-функциональной модели работы был не слишком гладким. Члены команды были настроены скептически. Например, некоторые продукт-менеджеры считали общение разработчиков с клиентами пустой тратой времени. Ведь прежде это было задачей продукт-менеджеров – определить проблему пользователей и выяснить, какие опции нужно создать. Поэтому некоторые продукт-менеджеры стали спрашивать: «Что я теперь должен делать? В чем заключается моя работа?» Точно так же некоторых разработчиков вполне устраивало, что им просто говорят, что делать, и они не горели желанием общаться с пользователями. Как это обычно бывает при подходе больших партий, и менеджеры, и разработчики предпочитали пожертвовать обучением ради «эффективности».
Чтобы процесс изменений шел успешно, очень важно было наладить коммуникацию. Руководители команды были открыты к обсуждению изменений и причин, по которым эти изменения необходимы. Скептицизм сотрудников чаще всего был связан с тем, что они не представляли, какие конкретно преимущества может принести новый подход. Ведь это был совершенно новый процесс. Им нужно было объяснить, почему старый процесс не работает и почему привычный способ выпуска новой версии не ведет к успеху. В ходе изменений сотрудникам постоянно говорили, каких результатов нужно достичь: быстрее получать обратную связь от клиентов и ускорить цикл разработки, не связанный с ежегодной датой выпуска новой версии. Руководители постоянно подчеркивали, что новый подход используют конкуренты, разрабатывая новые продукты и проводя итерации. Поэтому компании придется или последовать их примеру, или просто уйти с рынка.
Раньше новые версии QuickBooks разрабатывала большая команда, и цикл разработки был длительным. Например, в предыдущие годы команда онлайн-банкинга состояла из 15 разработчиков, семи специалистов по качеству, продукт-менеджера, а иногда приглашали еще и нескольких дизайнеров. Теперь в каждой команде – не больше пяти человек. Основная их цель – быстрые итерации с участием пользователей, проведение экспериментов, подтверждение фактами и принятие на их основе решений, над чем нужно продолжать работать в первую очередь. Раньше было пять основных отделов по разработке QuickBooks, которые объединяли созданные ими опции только во время выпуска новой версии. Теперь таких отделов 20 или 25. Это позволяет проводить гораздо больше экспериментов. Каждая команда работает над новой опцией по полтора месяца, в течение всего процесса тестируя ее с участием реальных пользователей.
Мало изменить культуру – основные изменения, необходимые для создания адаптивной организации, должны произойти в мышлении ее сотрудников. Как мы видели в главе 9, метод бережливого производства требует, чтобы все действия компании воспринимались системно. А затем нужно сокращать размеры партий и время прохождения цикла всего процесса. Таким образом, для достижения долгосрочных изменений команде QuickBooks нужно было создать новые инструменты и изменить платформы, чтобы начать работать быстрее и по-новому.
Например, одной из основных проблем в процессе выпуска первой альфа-версии в прошлом году было то, что QuickBooks – очень важный продукт с точки зрения миссии компании. Для множества небольших фирм он является основным инструментом работы с важными финансовыми данными. Поэтому команда очень боялась, что альфа-версия, этот первый минимально рабочий продукт, может повредить базы данных клиентов. И хотя разработчики были объединены в небольшие команды, этот страх мешал им следовать подходу небольших партий.
Чтобы сократить партии, команде QuickBooks пришлось создать новую технологию. Это была система виртуализации, позволявшая запускать одновременно несколько версий QuickBooks на компьютере пользователя. Вторая версия могла получать доступ ко всем данным клиента, но не могла вводить в них никаких изменений. Это устраняло риск того, что новая версия может случайно повредить данные пользователей. Новая версия работала изолированно, пользователи могли протестировать ее и дать свои отзывы.
На третий год результаты заметно улучшились. Очередная новая версия QuickBooks продемонстрировала гораздо более высокие показатели удовлетворенности потребителей и продавалась лучше предыдущих. Если сейчас вы используете QuickBooks, возможно, ваша версия программы создана уже по методу небольших партий. На четвертый год работы в команде QuickBooks Грег стал искать новые способы сократить размеры партий и ускорить цикл. Как обычно, здесь есть возможности, лежащие за пределами технических решений. Например, ежегодный цикл продаж новых версий программного обеспечения не позволяет быстро учиться. Поэтому команда начала экспериментировать, привлекая самых активных пользователей. Они могут загружать обновления в режиме онлайн, и поэтому Intuit может выпускать новые версии своих программ чаще, чем раньше. В ближайшее время команда QuickBooks собирается выпускать обновления каждый квартал.
Работая по системе «экономичный стартап», команда может использовать адаптивные методы для разработки более сложных процессов, не отказываясь при этом от основного преимущества: быстро проходить цикл обратной связи «создать – оценить – научиться». Одно из основных преимуществ использования методов из арсенала бережливого производства заключается в том, что в процессе развития компания может в соответствии с ними совершенствовать свои операции. Команды уже знают, как следовать дисциплине, разрабатывать процессы с учетом своей индивидуальной ситуации, и используют такие методы бережливого производства, как «Пять “Почему?”» и работу небольшими партиями. И когда успешный стартап превращается в стабильную компанию, в нем уже есть культура, основанная на строгих экспериментах и дисциплине, характерная для лучших компаний мира, таких как Toyota.
Однако превращение стартапа в стабильную компанию – это не конец истории. Работа никогда не заканчивается, ведь, как мы говорили во второй главе, даже крупным компаниям сложно находить новые источники роста, связанные с подрывными инновациями. Об этих источниках нужно думать с самого начала. Стартап не может рассчитывать на то, что останется лидером рынка даже спустя годы после первичного размещения акций. Компания, достигшая успеха, немедленно сталкивается с давлением конкурентов, быстрых последователей и новых стартапов. Поэтому нет смысла надеяться на то, что в своем развитии стартап будет последовательно проходить отдельные фазы, словно превращаясь из гусеницы в бабочку. И успешным стартапам, и крупным компаниям нужно учиться жонглировать разными задачами одновременно, совершенствуя операции и создавая подрывные инновации. А для этого нужен новый подход, о котором мы поговорим в главе 12.
Глава 12
Создание инноваций
Принято считать, что, когда компания начинает расти, она неизбежно теряет способность создавать инновации, творить и развиваться. Я с этим категорически не согласен. В процессе развития стартапа можно создать организацию, которая будет учиться удовлетворять потребности уже имеющихся клиентов и привлекать новых, управлять существующими направлениями бизнеса и исследовать другие бизнес-модели – и все это одновременно. И если предприниматели готовы менять свою философию менеджмента, я уверен, что даже крупные и стабильные компании могут принять этот новый подход, который я называю портфельным.
Как создавать подрывные инновации
Чтобы команда инноваций достигла успеха, ей нужна правильная структура. Если у стартапа есть поддержка венчурного капитала, такая структура возникает естественным образом – ведь он остается небольшой, независимой компанией. Внутренним командам-стартапам в крупных компаниях тоже нужна такая структура, и здесь важна поддержка высшего руководства. По моему опыту, командам стартапов обоих типов необходимы для успешного развития три условия: скромные, но доступные ресурсы, возможность независимо развивать и проверять свои идеи и личная заинтересованность в результате. В подразделениях крупных стабильных компаний таких условий обычно нет. Помните, что структура – это просто предпосылка, она не гарантирует успеха. Но неправильная структура почти наверняка приведет к неудаче.
Скромные, но доступные ресурсы
В крупных, стабильных организациях руководители подразделений, чтобы увеличить свой бюджет, обычно используют политические игры, но они знают, что этот бюджет может быть сокращен. Поэтому зачастую они пытаются увеличить его как можно больше и готовы любыми способами защищать его от посягательств других подразделений. В этих политических играх менеджер иногда выигрывает, а иногда проигрывает: если в организации случается кризис, бюджет может быть внезапно сокращен. Это не катастрофа: команде просто придется работать больше с меньшими ресурсами. Но именно поэтому, чтобы учесть такую вероятность, бюджет часто с самого начала завышают.
У стартапа все по-другому: слишком большой бюджет для него так же вреден, как и слишком маленький – это подтвердили неудачи бесчисленных доткомов, – и стартапы очень чувствительны к изменениям бюджета в процессе работы. Очень редко стартап может позволить себе неожиданно сократить бюджет на 10 %. Такой удар может оказаться для него фатальным. У независимых стартапов очень невысокая доля прибыли и поэтому почти нет права на ошибку. Так что стартапом управлять и легче, и сложнее, чем подразделением крупной компании: ему нужно намного меньше капитала, но этот капитал должен быть защищен от любых посягательств.
Возможность развиваться независимо
Возможности стартапа всегда ограничены, и чтобы создавать и выводить на рынок новые продукты, его командам нужна полная независимость. Они должны иметь возможность разрабатывать и проводить эксперименты без необходимости получать одобрение множества начальников.
Я рекомендую создавать кросс-функциональные команды, чтобы в них постоянно работали люди из всех подразделений компании, участвующих в создании или продажах первых продуктов. Задача таких команд – разрабатывать и представлять потребителям реальные функционирующие продукты, а не просто опытные образцы. Дискуссии с руководством и необходимость получать его одобрение замедляют цикл обратной связи «создать – оценить – научиться», мешают обучению и снимают с команды стартапа ответственность. Поэтому любые связанные с одобрением начальства задержки должны быть сведены в стартапе на нет.
Конечно, такой уровень независимости часто пугает головную организацию. Но развеять ее страхи поможет метод, описанный ниже.
Личная заинтересованность в результате
Предприниматель должен быть лично заинтересован в результате своих творческих усилий. Независимые новые предприятия обычно предлагают своим сотрудникам какие-либо формы владения акциями. Если же вместо них используется система бонусов, то сотрудники должны получать премии и поощрения в случае долгосрочного успеха инноваций, которые они создают.
Но я не думаю, что личная заинтересованность должна быть только финансовой. Например, есть некоммерческие и государственные организации, где инновации не связаны с финансовыми целями. Но и в таких случаях личная заинтересованность может присутствовать. От головной организации требуется точно определить, кто несет ответственность за разработку инноваций, и этот человек должен получать признание, если он создал новый продукт и этот продукт успешен. Как сказал один предприниматель, руководитель подразделения в крупной медиакомпании: «Если оставить в стороне финансовые стимулы, я всегда помню: если на двери написано мое имя, мне есть что терять. Поэтому я стараюсь делать больше, чем все остальные. Такое чувство личной ответственности очень важно».
Эта формула эффективна и для коммерческих организаций. В компании Toyota менеджера, который отвечает за разработку новой модели от начала до конца, называют главным инженером, или суса.
«В американской бизнес-литературе суса часто называют менеджерами проектов, но это название не отражает их истинной роли в руководстве проектами. Сотрудники компании Toyota переводят этот термин как “главный инженер”, а модель, находящуюся в разработке, здесь называют “автомобиль суса”. Нам сказали, что суса несет полную, абсолютную ответственность за каждый аспект разработки»[19].
И наоборот, я знаю чрезвычайно успешную и известную технологическую компанию, заслужившую особую репутацию своей инновационной культурой, но ее опыт разработки новых продуктов весьма неутешителен. Компания гордится своей системой стимулирования, основанной на больших премиях и статусных бонусах для членов команд, которые добились каких-то выдающихся успехов, но премии присуждает высшее руководство неизвестно на каких основаниях. Нет никаких объективных критериев, по которым команда может понять, выиграет ли она в этой лотерее. Команда не уверена, что ей поручат дальнейшую разработку инноваций, которые она создала. Поэтому люди не мотивированы идти на реальный риск и вместо этого предпочитают заниматься только теми проектами, которые почти наверняка получат одобрение высшего руководства.
Создание платформы для экспериментов
Далее важно установить основные правила, по которым будет действовать независимая команда стартапа. Эти правила должны регулировать следующее: как защитить головную организацию, как будут отчитываться руководители, наконец, как реинтегрировать в головную организацию инновации, если они будут успешными. Вспомните «остров свободы» – мы говорили о нем во второй главе, – позволивший команде SnapTax создать внутренний стартап в компании Intuit. Это и есть то, что создает платформу для экспериментов.
Защита головной компании
Обычно в крупных компаниях членам внутренних инновационных команд рекомендуют защищать свою группу от головной организации. Но я считаю, что нужно делать как раз наоборот.
Давайте начнем с описания довольно типичной встречи, которая проходила в офисе одного из моих клиентов, крупной компании. Целью встречи было определить, какие опции нужно включить в следующую версию продукта. В соответствии с новым подходом, основанным на сборе строгих данных, был проведен эксперимент с ценообразованием. Первая часть встречи была посвящена данным, полученным в ходе этого эксперимента.
Поделиться книгой: