Войти в систему
Войти с помощью соц. сетей:
Когда я был техническим директором компании IMVU, мне казалось, что, за редкими исключениями, я хорошо выполняю свои обязанности. Я создал гибкую организацию, и мы успешно экспериментировали с методами, которые потом были включены в систему «экономичный стартап». Но несколько раз возникали ситуации, когда я вдруг понимал, что не справляюсь с работой. Для человека, ориентированного на результат, это очень неприятно. Хуже всего было то, что я не получал никакой обратной связи. А если бы получил, она могла бы быть примерно такой:
«Дорогой Эрик!
Поздравляю! Должности, которую вы до сих пор занимали, больше нет. Вы были переведены на новую должность в нашей компании. Вообще-то, это уже не та же самая компания, хотя у нее то же название и в ней работают те же люди. Ваша должность тоже называется так же, как раньше, и вы хорошо выполняли свои предыдущие обязанности, но на новой должности ваши дела идут неважно. Вас перевели уже полгода назад, и этим письмом мы хотим уведомить вас о том, что ваша деятельность на новой должности уже довольно давно не приносит желаемых результатов.
Всего наилучшего!»
Каждый раз в такой ситуации я начинал ломать голову над тем, что делать. Я знал, что компания растет и нам нужны дополнительные процессы и системы, которые позволяли бы координировать операции при каждом «скачке» в увеличении размера. Ведь я так часто видел стартапы, потерявшие гибкость и погрязшие в бюрократии из-за неуемного стремления к «профессионализму».
IMVU не могла себе позволить обойтись вообще без всяких систем, и вы тоже не можете себе этого позволить. Стартап всегда очень уязвим. Мне уже приходилось сталкиваться с ситуацией, когда компания создала избыточную архитектуру в попытках предотвратить любые проблемы, какие только могут возникнуть, и это мешало ей создавать продукты. Я видел компании, у которых возникали огромные технические трудности как раз в тот момент, когда популярность продукта была на пике. Для руководителя отдела это катастрофа, потому что все считают, что причина всех бед — в плохой работе какого-то отдела. т.е., его отдела. У компании возникли проблемы — и это ваша вина.
Почти все рекомендации на эту тему, которые я слышал, предлагают какие-то компромиссы (например, «планируйте что-то, но не слишком многое»). Но при таком избирательном подходе трудно как-то объяснить себе и окружающим, почему мы должны уделять внимание одним проблемам и при этом игнорировать другие. Это как работать под руководством капризного начальника, когда всем начинает казаться, что его решения имеют какие-то скрытые мотивы.
Если он склонен идти на компромисс, лучший способ повлиять на него и получить то, что вы хотите, — занять самую крайнюю позицию из всех возможных. Например, если одна группа предлагает увеличить время цикла выпуска — скажем, выводить на рынок новый продукт не чаще, чем раз в год, — можно привести доводы в пользу очень короткого цикла (возможно, каждую неделю или даже каждый день). В итоге из этих двух мнений возникнет нечто среднее. И когда компромисс будет достигнут, вы, вероятно, получите результат, близкий к тому, чего хотели на самом деле.
Но такая «гонка вооружений» приводит к эскалации. В другом лагере ваши оппоненты, вероятно, занимаются тем же самым. Со временем обе стороны занимают все более крайние позиции, и при этом достигать компромисса становится все труднее. В таком случае руководитель должен взять на себя ответственность за то, что вольно или невольно создал такую ситуацию. Возможно, он не желал подобной поляризации, но именно ее он и поощряет. Чтобы выбраться из этой ловушки, необходим другой подход.
Нужно ли стартапу вкладывать средства в программу обучения новых сотрудников? Если бы вы задали мне этот вопрос несколько лет назад, я посмеялся бы и сказал: «Конечно, нет. Программы обучения — для крупных компаний, которые могут себе это позволить». Тем не менее мы в IMVU в итоге создали программу обучения, и она оказалась так хороша, что новые сотрудники полностью вливались в рабочий процесс уже в первый день работы. Всего несколько недель спустя они работали наравне с «ветеранами». Нам пришлось приложить массу усилий, чтобы стандартизировать рабочие процессы и подготовить программу, которую должны были изучить новые сотрудники. У каждого нового разработчика был наставник, помогавший новичку освоить программу, ознакомиться с системами, понятиями и методами, необходимыми для эффективной работы в IMVU. Результаты работы наставника и его ученика были взаимосвязаны, и поэтому наставники серьезно относились к обучению новичков.
Что интересно, сейчас я вижу, что мы не принимали отдельного решения о необходимости создать программу обучения. Эта программа возникла сама собой, естественным образом, в соответствии с нашим общим экспериментальным подходом. Процесс адаптирования новых сотрудников был постоянным объектом экспериментов, все время пересматривался и постепенно становился все более эффективным — и при этом его создание не требовало больших усилий.
Я называю это созданием адаптивной организации, которая автоматически корректирует свои процессы и действия в соответствии с текущими условиями.
До сих пор мы говорили о том, как важна скорость. Стартап бьется не на жизнь, а насмерть, чтобы выяснить, как создать жизнеспособный бизнес, ведь если он не сделает это до тех пор, как у него закончатся ресурсы, то умрет. Но нужно думать не только о скорости. Чтобы эффективно действовать, стартапу необходимы встроенные регуляторы скорости, помогающие находить оптимальный темп движения.
Мы видели пример регулирования скорости в главе 9, когда говорили о том, как можно использовать идею андона в таких системах, как непрерывное развертывание. Эта концепция прекрасно выражена в парадоксе, возникшем в компании Toyota: «Вовремя останавливайте производство, чтобы производство никогда не останавливалось». Смысл андона в том, что он позволяет остановить работу, если возникает серьезная проблема с качеством — и вынуждает устранить ее. Это одно из самых важных открытий системы бережливого производства: нельзя жертвовать качеством ради скорости. Если сегодня возникают проблемы с качеством (или вы их не замечаете), позже они начнут мешать вам расти. Брак приводит к лишней работе, деморализует людей, заставляют клиентов жаловаться, и все это замедляет развитие компании и истощает ценные ресурсы.
До сих пор, описывая проблемы качества, я говорил о физических товарах, но делал это просто ради удобства. У компаний, работающих в сфере обслуживания, возникают те же сложности. Попросите любого менеджера тренинговой компании, рекрутингового агентства или гостиницы показать вам сборник правил, где описано, как сотрудники должны предоставлять сервис в разных условиях и в разных ситуациях. То, что сначала было простым руководством, со временем часто усложняется.
Очень скоро правила становятся невероятно запутанными, и сотрудникам приходится тратить массу времени и сил на то, чтобы выучить их. Теперь представьте себе, что в такой компании менеджер-предприниматель пытается экспериментировать с новыми правилами или процедурами. Чем более качественны новые правила, тем легче их будет совершенствовать со временем. И наоборот, неясные правила полны противоречивых и неоднозначных пунктов, и если произойдет что-то неожиданное, возникнет хаос.
Когда я рассказываю о системе «экономичный стартап» предпринимателям, имеющим техническое образование, им очень трудно понять эту концепцию. С одной стороны, логика подхода подтверждения фактами и минимально рабочего продукта гласит, что нужно как можно быстрее отдать продукт в руки пользователей и любая дополнительная работа, которая не поможет учиться у них, будет только лишней. С другой стороны, цикл обратной связи «создать–оценить–научиться» — это непрерывный процесс. Мы не останавливаемся на первом минимально рабочем продукте, но используем то, чему научились, чтобы немедленно начать работу над следующей версией.
Поэтому, если сегодня мы упустим что-то важное — в сфере качества продукта, разработки или инфраструктуры, — завтра это может помешать нам расти. Можно увидеть, как этот парадокс проявился в IMVU. В главе 3 я уже рассказывал о том, что мы вывели на рынок продукт, который имел минимум опций и был полон багов. Но никто даже не попробовал воспользоваться этим продуктом, и поэтому почти вся наша работа оказалась ненужной. Хорошо, что мы не потратили слишком много времени на то, чтобы «улучшить» ту первую версию продукта.
Новые знания позволяли нам создавать продукты, нужные пользователям, но в какой-то момент рост стал замедляться. Продукт невысокого качества может препятствовать обучению, если его дефекты не позволяют клиентам понять, каковы его преимущества, и дать нам обратную связь. В случае с IMVU, когда мы стали предлагать продукт клиентам основного рынка, они оказались куда менее снисходительными, чем ранние последователи. А чем больше опций мы добавляли, тем сложнее становилось добавлять новые, потому что возрастал риск того, что новая опция вступит в конфликт с уже существующими. Такая же динамика существует в сфере услуг, так как любые новые правила могут войти в конфликт с уже существующими, и чем больше правил, тем чаще они начинают противоречить друг другу.
Компания IMVU использовала методы, описанные в этой главе, чтобы расти и поддерживать качество в соответствии с подходом «точно вовремя».
Чтобы расти быстрее, стартапу необходим процесс, который приводил бы в движение естественный цикл обратной связи. Если вы движетесь слишком быстро, то лишь создаете новые проблемы. Адаптивные процессы вынуждают вас замедлиться и заняться решением тех проблем, которые в настоящее время приводят к напрасной трате времени. Когда такие профилактические усилия дают результат, вы естественным образом снова наращиваете скорость.
Давайте вернемся к нашей программе обучения для новых сотрудников. Без такой программы новые сотрудники будут делать ошибки, их обучение потребует помощи и участия других членов команды, и это замедлит общий темп работы. Как определить, стоит ли делать инвестиции в программу обучения? Выяснить это путем теоретических размышлений довольно сложно, ведь при этом нужно оценить два абсолютно неизвестных показателя: сколько будет стоить создание программы обучения и какие это даст преимущества. К тому же традиционный подход к подобным решениям основан на модели больших партий: либо у компании есть тщательно продуманная программа обучения, либо нет вообще никакой программы. Если не получается найти веских причин для инвестиций в создание такой программы, компания часто вообще ничего не делает.
Альтернатива в том, чтобы использовать метод под названием «Пять “Почему?”». Он позволит создавать программу обучения постепенно и шаг за шагом развивать процессы стартапа. Главная идея «Пяти “Почему?”» заключается в том, чтобы напрямую связать инвестиции с предотвращением самых болезненных симптомов. Название этого метода напоминает о приемах ведения расследований в полиции, когда детектив пять раз задает вопрос «Почему?», чтобы понять, что произошло (какова причина). Если вам доводилось отвечать на вопросы ребенка, который хотел знать, почему небо голубое, и продолжал спрашивать «Почему?» после каждого ответа, то вы с ним знакомы. Этот метод как системный инструмент решения проблем разработал Тайити Оно, создатель производственной системы Toyota. Я адаптировал его для системы «экономичный стартап» и внес несколько изменений, специально для стартапов.
В основе каждой, на первый взгляд, технической проблемы лежит проблема человеческая. Метод «Пяти “Почему?”» позволяет выяснить, в чем она заключается. Тайити Оно приводит следующий пример. Столкнувшись с той или иной проблемой можно остановиться и пять раз задать вопрос «Почему?». Это не так просто, как кажется. Предположим, перестал работать станок. Нужно спросить:
Пять раз повторив вопрос «Почему?», можно обнаружить основную проблему и решить ее. Если мы этого не сделаем, то ограничимся просто заменой вкладыша или шахты насоса. Но тогда, несколько месяцев спустя, проблема возникнет снова. Система производства Toyota основана на использовании и развитии такого подхода. Пять раз спросив «почему» и ответив на эти вопросы, можно найти настоящую причину проблемы, которая часто бывает скрыта за более заметными симптомами.
Обратите внимание: даже в таком простом примере видно, что основная причина — не в технической неполадке (вышел из строя предохранитель), а в ошибке, допущенной человеком (кто-то забыл присоединить сито к насосу). Это весьма типично для большинства проблем, с которыми сталкиваются стартапы, в какой бы сфере они ни работали. При этом в сфере обслуживания почти все проблемы, которые, на первый взгляд, кажутся промахами отдельных людей, можно объяснить проблемами в обучении или противоречивым набором правил компании.
Я хочу показать, как метод «Пяти “Почему?”» помог нам создать систему обучения сотрудников, о которой мы говорили выше. Представьте себе, что IMVU внезапно начала получать от клиентов жалобы на новую версию продукта, которую мы только что выпустили.
То, что сначала выглядело как техническая ошибка, на самом деле оказалось проблемой менеджмента и организации.
Как метод «Пяти “Почему?”» помогает создать адаптивную организацию? Нужно постоянно делать соразмерные инвестиции на каждом из пяти уровней. То есть нужно прикладывать меньше усилий, если симптом незначителен, и больше, если он более серьезен. Иначе говоря, мы не делаем значительных инвестиций в профилактику до тех пор, пока не справились с более серьезными проблемами.
В приведенном выше примере, чтобы устранить проблему, нужно устранить неполадки на сервере, изменить подсистему так, чтобы она была менее подвержена ошибкам, обучить нового сотрудника и, конечно же, провести беседу с его руководителем.
Эта последняя задача, разговор с руководителем, всегда трудна, а особенно в условиях стартапа. Когда я был руководителем в стартапе, если бы мне сказали, что должен заняться обучением своих людей, я ответил бы, что не стану заниматься ерундой. У меня всегда было слишком много других задач. Вероятно, я сказал бы какую-нибудь колкость, например: «Конечно, я буду счастлив это сделать! Если вы предоставите мне пару месяцев свободного времени, я обязательно этим займусь». Иначе говоря: «Ни за что на свете!»
Вот почему соразмерные инвестиции так важны. Если электричество отключилось просто в результате небольшого сбоя, достаточно потратить час времени на то, чтобы устранить его. Если проблема возникнет снова, следуя методу «Пяти “Почему?”», мы сможем выяснить ее причины. А если она больше не возникнет, час времени, потраченный на ее решение, — не слишком большая потеря.
Я не случайно привел в пример обучение новых сотрудников. Ведь я отказывался уделять ему внимание в IMVU. Когда мы только создали наш стартап, я искренне полагал, что нам нужно сосредоточиться исключительно на создании и маркетинге продукта. Но когда нам пришлось в короткий срок принять на работу много новых сотрудников, метод «Пяти “Почему?”» раз за разом стал показывать, что проблемы, связанные с отсутствием обучения, замедляют разработку продукта. Конечно, мы не стали бросать все остальное, чтобы заняться обучением новых людей. Но мы постоянно и последовательно совершенствовали программу обучения, и каждый раз она становилась немного лучше. Со временем положительные изменения накапливались, высвобождая время и силы, которые раньше мы тратили на авралы и кризис-менеджмент.
Метод «Пяти “Почему?”» может стать естественным регулятором скорости. Чем больше проблем, тем больше времени и сил уходит на их решение. Когда инвестиции в инфраструктуру или процесс начинают давать результаты, кризисы случаются все реже, они все менее серьезны, и команда снова набирает скорость. Стартапы особенно подвержены опасности того, что их команды начнут работать слишком быстро, жертвуя качеством ради времени, и это будет приводить к небрежности и ошибкам. Метод «Пяти “Почему?”» препятствует этому, позволяя команде найти оптимальный темп.
Этот метод помогает связать скорость развития с процессом обучения, а не просто с эффективностью. Команде стартапа нужно использовать подход «Пять “Почему?”», когда она сталкивается с любыми проблемами, в том числе и с техническими ошибками, отсутствием ожидаемых финансовых результатов или неожиданными изменениями в поведении потребителей.
«Пять “Почему?”» — мощный организационный метод. Некоторые разработчики, которых я научил его использовать, считают, что из него можно вывести все остальные методы системы «экономичный стартап». Вместе с подходом небольших партий он создает фундамент, необходимый компании, чтобы быстро и адекватно реагировать на возникающие проблемы, не тратя при этом лишних денег и не делая лишней работы.
Когда команды начинают использовать метод «Пяти “Почему?”» для решения своих проблем, у них часто возникают одни и те же трудности. Обычно мы склонны слишком сильно реагировать на то, что происходит с нами в данный момент. И при этом очень расстраиваться, если вдруг происходит то, чего мы не ожидали.
Когда «Пять “Почему?”» используют не по назначению, я называю это «Пять обвинений». Вместо того чтобы вновь и вновь спрашивать «почему» и выяснять, что пошло не так, расстроенные члены команды начинают тыкать друг в друга пальцами в поисках виноватых. Вместо того чтобы использовать «Пять “Почему?”» для выявления и решения проблем, менеджеры и сотрудники иногда попадают в ловушку и начинают играть в «Пять обвинений» — это помогает им как-то выразить свои негативные чувства. Но такие поиски виноватых не дают увидеть недостатки системы. Мы все склонны считать, что ошибка — это следствие плохой работы какого-то другого отдела, невежества или дурного характера других людей. Но метод «Пяти “Почему?”» предназначен для того, чтобы помочь нам увидеть объективную истину. А она обычно состоит в том, что если проблема повторяется — это следствие неэффективных процессов, а не действий отдельных людей. Если мы поймем это, у нас появится шанс создать более адекватные процессы.
Чтобы не погрязнуть в «Пяти обвинениях», я предлагаю несколько тактик. Во-первых, на встрече, посвященной «Пяти “Почему?”» должны присутствовать все, кого касается проблема. На ней должны быть все те, кто обнаружил или диагностировал проблему, в том числе, если это возможно, сотрудники, обслуживающие клиентов. На ней должны быть все, кто пытался устранить симптом, а также все, кто работал с подсистемами или опциями, связанными с проблемой. Если проблема дошла до уровня высшего руководства, то руководители, которые не решили проблему вовремя, тоже должны прийти на встречу.
В результате на встрече может быть очень много людей, но это не страшно. По моему опыту, если кто-то не будет участвовать в обсуждении, в итоге именно он станет мишенью для обвинений. Козлом отпущения здесь может оказаться любой — и сотрудник низшего уровня, и генеральный директор. Если это простой сотрудник, может показаться, что его легко заменить. Если на встрече не присутствует генеральный директор, все начнут думать, что на его действия повлиять невозможно. Но ни то, ни другое обычно не соответствует действительности.
Обвинения начнутся неизбежно. Но тем из присутствующих на встрече, кто имеет самый высокий статус, нужно выучить и повторять следующую мантру: «Если возникает ошибка, стыд нам и позор за то, что мы ее допустили! Но анализ пяти “Почему?” позволит нам взглянуть на проблему системно».
Вот пример ситуации, в которой эта мантра оказалась очень полезной. В процессе обучения новых сотрудников, который мы создали в IMVU с помощью метода «Пяти “Почему?”», мы просили их в самый первый рабочий день ввести какое-нибудь изменение в продукт. Программистов, обученных традиционным методам разработки, это пугало. Они спрашивали: «Что со мной будет, если я случайно прерву или остановлю процесс?» В компании, где они работали раньше, это считалось серьезной ошибкой, из-за нее могли уволить. Но мы говорили новичку: «Если наш производственный процесс такой хрупкий, что вы сможете нарушить его в первый же день работы, стыд нам и позор, что мы позволили вам это сделать». Если новичку действительно удавалось что-нибудь нарушить, мы немедленно поручали ему устранить проблему, а также придумать, как сделать так, чтобы следующему новичку не удалось повторить его ошибку.
Для новых сотрудников, приходивших к нам из компаний с другой культурой, это часто становилось настоящей инициацией, но все они проходили ее и при этом начинали понимать, каковы наши ценности. Шаг за шагом, система за системой это создавало надежный процесс разработки продукта, позволявший всем нашим сотрудникам работать более творчески и ничего не бояться.
Вот несколько подсказок на тему, как начать использовать метод «Пяти “Почему?”». Они основаны на моем личном опыте, ведь я помогал вводить этот метод во многих компаниях.
Чтобы «Пять “Почему?”» работали как следует, нужно соблюдать определенные правила. Например, он требует атмосферы взаимного доверия и ответственности. Если ее нет, использовать его будет довольно сложно. В таких ситуациях я предлагаю упрощенную версию, позволяющую командам анализировать причины проблемы и в то же время учиться применять этот подход — на будущее, когда появится возможность использовать его.
Я прошу всех следовать двум простым правилам:
Первое правило помогает научиться спокойно воспринимать ошибки, особенно допущенные другими людьми. Помните: почти все ошибки вызваны некорректными системами, а не действиями отдельных людей. Второе правило помогает делать соразмерные инвестиции в предотвращение ошибок в будущем.
Такая упрощенная система довольно эффективна. Фактически мы использовали ее в IMVU в те дни, когда я еще не нашел метод «Пяти “Почему?”» и ничего не знал о производственной системе Toyota. Но упрощенная версия метода со временем теряет эффективность, и я убедился в этом на собственном опыте. Честно говоря, поэтому и заинтересовался методологией бережливого производства.
Достоинства и недостатки упрощенной версии метода заключаются в том, что она побуждает задавать определенные вопросы: что важно не менее, чем эта проблема? На каких типах ошибок нужно сосредоточиться? Нужно ли решить эту отдельную проблему или лучше попытаться предотвратить целую категорию проблем, связанных с этой? Членов команды, которая только начинает работать, эти вопросы заставляют задуматься. Это может стать основой для более тщательно продуманных методов. Но, так или иначе, на них придется ответить.
Вы должны быть готовы к тому, что метод «Пяти “Почему?”» может вскрыть довольно неприятные факты. Он может показать, что сейчас важнее всего заняться профилактикой, и это придется делать за счет времени и денег, которые можно было бы направить на разработку новых продуктов или опций. При этом команде может казаться, что у нее нет времени, чтобы тратить его впустую на анализ причин, хотя такой анализ дал бы ей больше свободы и ресурсов в долгосрочной перспективе. В итоге может начаться игра в «Пять обвинений». Поэтому так важно, чтобы в процессе анализа пяти «Почему?» участвовал человек, обладающий достаточным авторитетом, способный довести дело до конца, а затем проследить за тем, чтобы проблема была решена, и способный выступить в роли арбитра, если возникнут разногласия. Иначе говоря, чтобы создать адаптивную организацию, нужна поддержка руководства компании.
Часто сотрудники стартапов приходят на мои семинары, чтобы научиться использовать метод «Пяти “Почему?”». Но я не рекомендую им это делать, если у них нет поддержки менеджера или руководителя группы. В такой ситуации нужно действовать осторожно. Возможно, вам не удастся собрать всю команду для настоящего исследования в стиле пяти «Почему?», но в своей собственной работе вы всегда можете использовать более простую версию этого подхода, состоящую из двух правил. Всякий раз, когда что-то идет не так, спросите себя: что я могу сделать, чтобы в следующий раз не оказаться в такой ситуации?
Я рекомендую начать с нескольких четко определенных симптомов. Например, я впервые успешно использовал метод «Пять “Почему?”» для анализа причин проблемы, касавшейся одного нашего внутреннего инструмента тестирования, который не оказывал непосредственного влияния на пользователей. Конечно, заманчиво начать с чего-то большого и важного, ведь именно на большие и важные вещи команда тратит впустую больше всего времени. Но когда на кону стоит многое, «Пять “Почему?”» могут быстро превратиться в «Пять обвинений». Чтобы научить команду использовать этот метод, лучше начать с не слишком важных проблем и только потом применять его там, где ставки высоки.
Чем конкретнее симптомы, тем легче понять, когда нужно назначить встречу, посвященную «Пяти “Почему?”». Скажем, вы хотите использовать «Пять “Почему?”», чтобы понять причины жалоб клиентов. В этом случае, назначьте дату, после которой все жалобы станут автоматическим сигналом о том, что пора провести встречу. При этом объем жалоб не должен быть слишком большим. Это позволит проводить встречи «Пяти “Почему?”» каждый раз, когда это потребуется. Если жалоб слишком много, выберите отдельный класс жалоб, на котором можно сосредоточиться. Правила, которые определяют, какие виды жалоб будут сигналом о том, что пора провести встречу «Пяти “Почему?”», должны быть простыми и неизменными. Например, можно рассматривать все жалобы, связанные с оплатой кредитными карточками. Это несложное и понятное правило. Не выбирайте правила, которые можно трактовать по-разному.
Сначала может возникнуть соблазн ввести радикальные изменения сразу во всех системах расчетов и во всех процессах. Не делайте этого. Лучше проводите короткие встречи и выбирайте относительно простые изменения для каждого из пяти «почему». Со временем, когда команда начнет лучше понимать метод «Пять “Почему?”», изменения могут становиться более серьезными, можно включать все больше типов жалоб, а затем перейти к другим проблемам.
Чтобы ускорить процесс обучения, назначьте специалиста по «Пяти “Почему?”» для каждой сферы, в которой используется этот метод. Этот человек будет модератором на каждой встрече, посвященной принятию решений о том, какие профилактические меры нужно принять, и будет давать задания ее участникам. Специалист по «Пяти “Почему?”» должен занимать высокую должность, чтобы иметь достаточно полномочий и гарантировать, что задачи будут выполнены, но при этом у него должно быть время для того, чтобы присутствовать на встречах. Специалист по «Пяти “Почему?”» — главный человек с точки зрения ответственности, он — основной проводник изменений. Он может оценить, успешно ли проходит встреча и эффективны ли действия компании, направленные на устранение обнаруженной проблемы.
IGN Entertainment, подразделение корпорации News Corporation, разрабатывает онлайн-видеоигры. У ее игр самая многочисленная аудитория геймеров в мире: она составляет больше 45 млн человек. Компания IGN была основана в конце 1990-х гг., а в 2005 г. ее купила News Corporation. На сегодняшний день в ней работает несколько сот человек.
Недавно у меня была возможность пообщаться с командой разработчиков IGN. В последние годы компания работала вполне успешно, но, как и все крупные компании, с которыми мы встречались в этой книге, хотела ускорить процесс разработки новых продуктов и активизировать инновации. Она объединила команды разработки, продукта и дизайна, чтобы обсудить способы использования системы «экономичный стартап».
Эту инициативу поддерживали руководители IGN, в том числе генеральный директор и глава подразделения разработки продукта. Прежние попытки использовать в компании метод «Пяти “Почему?”» не принесли особых результатов. Проблемы, которые нужно было решить, были самыми разными — от несоответствий в веб-аналитике до неэффективных партнерских баз данных. Первая встреча, посвященная анализу «Пяти “Почему?”», длилась около часа. На ней возникло несколько интересных идей, но в целом ее нельзя было назвать удачной. Никто из тех, кто был связан с проблемами и больше всего знал о них, на ней не присутствовал. Раньше компания никогда не проводила таких встреч, поэтому участники не придерживались формата и постоянно отклонялись от темы. Это нельзя было назвать пустой тратой времени, но не дало того эффекта, которым так ценен этот метод.
Компания IGN уже пыталась решить все эти проблемы. И это не удавалось ей в течение многих лет. Такие хронические проблемы носят эндемический характер и поэтому естественным образом выходят на поверхность во время анализа пяти «Почему?». Эту возможность можно использовать для того, чтобы начать постепенно решать их. Если же такие проблемы не всплывают сами собой во время анализа, возможно, они не так важны, как кажется.
В попытках использовать метод «Пяти “Почему?”» 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 на основании четырех принципов:
На первый взгляд, эти цели соответствуют методам и принципам, описанным в предыдущих главах. Но второй год работы Грега в команде QuickBooks тоже не был отмечен успехом. Например, он постановил, что команда перейдет к этапу выпуска за полгода, наполовину сократив время цикла и размер партий. Однако это не принесло успеха. Только благодаря своему упорству, команда отважно пыталась выпустить альфа-версию в январе. Однако проблемы, связанные с разработкой по методу больших партий, никуда не делись, и команда с трудом закончила альфа-версию лишь к апрелю. Эта система была лучше предыдущей, потому что проблемы можно было заметить на два месяца раньше, чем раньше, но она не принесла тех результатов, на которые рассчитывал Грег.
Фактически процесс разработки оставался почти таким же, как в прошлые годы. Как поясняет Грег: «У организации есть “мышечная память”, и людям трудно избавиться от старых привычек». Грег сражался с системой и проводил отдельные изменения, например переназначил дату выпуска, но старые привычки были еще сильны.
Раздраженный неудачами прошедшего года, Грег объединился с лидером команды разработки продукта Химаншу Бакси. Вместе они решительно избавились от всех старых процессов. Они публично заявили о том, что их объединенные команды намерены создать новые процессы и что они не собираются возвращаться к старому.
Грег и Химаншу не стали менять сроки выпуска новой версии. Вместо этого они сосредоточились на изменениях, связанных с процессами, продуктом и технологиями, которые позволяли работать с меньшими партиями. Эти технические инновации способствовали тому, что отзывы от клиентов стали поступать раньше. Грег начал новый год не с планирования действий на 12 месяцев вперед, а с того, что назвал «заторами» идеи/кода/решения. Инженеры, продукт-менеджеры и пользователи объединили усилия и создали «трубопровод идей». Грегу, как продукт-менеджеру, было страшно начинать год, не имея точного перечня опций новой версии продукта, но он был уверен в своей команде и в новом процессе. В третий год работы он ввел новые методы:
Важно понять, что прежний подход позволял получать обратную связь от клиентов и вовлекать их в процесс планирования. В истинном духе генти генбуцу продукт-менеджеры компании Intuit проводили «домашние встречи» с пользователями, чтобы определить проблемы, которые предстояло решить в следующей версии. Однако недостатком этой системы было то, что продукт-менеджеры несли всю ответственность за исследования потребителей. Они сообщали их результаты команде и говорили: «Вот проблема, которую мы хотим решить, а вот предложения, как это можно сделать».
Переход к кросс-функциональной модели работы был не слишком гладким. Члены команды были настроены скептически. Например, некоторые продукт-менеджеры считали общение разработчиков с клиентами пустой тратой времени. Ведь прежде это было задачей продукт-менеджеров — определить проблему пользователей и выяснить, какие опции нужно создать. Поэтому некоторые продукт-менеджеры стали спрашивать: «Что я теперь должен делать? В чем заключается моя работа?» Точно так же некоторых разработчиков вполне устраивало, что им просто говорят, что делать, и они не горели желанием общаться с пользователями. Как это обычно бывает при подходе больших партий, и менеджеры, и разработчики предпочитали пожертвовать обучением ради «эффективности».
Чтобы процесс изменений шел успешно, очень важно было наладить коммуникацию. Руководители команды были открыты к обсуждению изменений и причин, по которым эти изменения необходимы. Скептицизм сотрудников чаще всего был связан с тем, что они не представляли, какие конкретно преимущества может принести новый подход. Ведь это был совершенно новый процесс. Им нужно было объяснить, почему старый процесс не работает и почему привычный способ выпуска новой версии не ведет к успеху. В ходе изменений сотрудникам постоянно говорили, каких результатов нужно достичь: быстрее получать обратную связь от клиентов и ускорить цикл разработки, не связанный с ежегодной датой выпуска новой версии. Руководители постоянно подчеркивали, что новый подход используют конкуренты, разрабатывая новые продукты и проводя итерации. Поэтому компании придется или последовать их примеру, или просто уйти с рынка.
* * *
Раньше новые версии QuickBooks разрабатывала большая команда, и цикл разработки был длительным. Например, в предыдущие годы команда онлайн-банкинга состояла из 15 разработчиков, семи специалистов по качеству, продукт-менеджера, а иногда приглашали еще и нескольких дизайнеров. Теперь в каждой команде — не больше пяти человек. Основная их цель — быстрые итерации с участием пользователей, проведение экспериментов, подтверждение фактами и принятие на их основе решений, над чем нужно продолжать работать в первую очередь. Раньше было пять основных отделов по разработке QuickBooks, которые объединяли созданные ими опции только во время выпуска новой версии. Теперь таких отделов 20 или 25. Это позволяет проводить гораздо больше экспериментов. Каждая команда работает над новой опцией по полтора месяца, в течение всего процесса тестируя ее с участием реальных пользователей.
Мало изменить культуру — основные изменения, необходимые для создания адаптивной организации, должны произойти в мышлении ее сотрудников. Как мы видели в главе 9, метод бережливого производства требует, чтобы все действия компании воспринимались системно. А затем нужно сокращать размеры партий и время прохождения цикла всего процесса. Таким образом, для достижения долгосрочных изменений команде QuickBooks нужно было создать новые инструменты и изменить платформы, чтобы начать работать быстрее и по-новому.
Например, одной из основных проблем в процессе выпуска первой альфа-версии в прошлом году было то, что QuickBooks — очень важный продукт с точки зрения миссии компании. Для множества небольших фирм он является основным инструментом работы с важными финансовыми данными. Поэтому команда очень боялась, что альфа-версия, этот первый минимально рабочий продукт, может повредить базы данных клиентов. И хотя разработчики были объединены в небольшие команды, этот страх мешал им следовать подходу небольших партий.
Чтобы сократить партии, команде QuickBooks пришлось создать новую технологию. Это была система виртуализации, позволявшая запускать одновременно несколько версий QuickBooks на компьютере пользователя. Вторая версия могла получать доступ ко всем данным клиента, но не могла вводить в них никаких изменений. Это устраняло риск того, что новая версия может случайно повредить данные пользователей. Новая версия работала изолированно, пользователи могли протестировать ее и дать свои отзывы.
На третий год результаты заметно улучшились. Очередная новая версия QuickBooks продемонстрировала гораздо более высокие показатели удовлетворенности потребителей и продавалась лучше предыдущих. Если сейчас вы используете QuickBooks, возможно, ваша версия программы создана уже по методу небольших партий. На четвертый год работы в команде QuickBooks Грег стал искать новые способы сократить размеры партий и ускорить цикл. Как обычно, здесь есть возможности, лежащие за пределами технических решений. Например, ежегодный цикл продаж новых версий программного обеспечения не позволяет быстро учиться. Поэтому команда начала экспериментировать, привлекая самых активных пользователей. Они могут загружать обновления в режиме онлайн, и поэтому Intuit может выпускать новые версии своих программ чаще, чем раньше. В ближайшее время команда QuickBooks собирается выпускать обновления каждый квартал.
* * *
Работая по системе «экономичный стартап», команда может использовать адаптивные методы для разработки более сложных процессов, не отказываясь при этом от основного преимущества: быстро проходить цикл обратной связи «создать–оценить–научиться». Одно из основных преимуществ использования методов из арсенала бережливого производства заключается в том, что в процессе развития компания может в соответствии с ними совершенствовать свои операции. Команды уже знают, как следовать дисциплине, разрабатывать процессы с учетом своей индивидуальной ситуации, и используют такие методы бережливого производства, как «Пять “Почему?”» и работу небольшими партиями. И когда успешный стартап превращается в стабильную компанию, в нем уже есть культура, основанная на строгих экспериментах и дисциплине, характерная для лучших компаний мира, таких как Toyota.
Однако превращение стартапа в стабильную компанию — это не конец истории. Работа никогда не заканчивается, ведь, как мы говорили во второй главе, даже крупным компаниям сложно находить новые источники роста, связанные с подрывными инновациями. Об этих источниках нужно думать с самого начала. Стартап не может рассчитывать на то, что останется лидером рынка даже спустя годы после первичного размещения акций. Компания, достигшая успеха, немедленно сталкивается с давлением конкурентов, быстрых последователей и новых стартапов. Поэтому нет смысла надеяться на то, что в своем развитии стартап будет последовательно проходить отдельные фазы, словно превращаясь из гусеницы в бабочку. И успешным стартапам, и крупным компаниям нужно учиться жонглировать разными задачами одновременно, совершенствуя операции и создавая подрывные инновации. А для этого нужен новый подход, о котором мы поговорим в главе 12.
Войти с помощью соц. сетей: