И это может произойти с компанией любого размера. Поэтому нужно одновременно настраивать механизм роста и развивать новые источники роста на тот случай, когда этот механизм перестанет работать. О том, как это сделать, мы поговорим в главе 12. Но для того, чтобы компания смогла действовать таким образом, нужно создать организационную структуру, культуру и дисциплину, которые способны справляться с быстрыми и зачастую неожиданными изменениями. Я называю это адаптивной организацией, и это – тема главы 11.
Глава 11
Адаптация
Когда я был техническим директором компании IMVU, мне казалось, что, за редкими исключениями, я хорошо выполняю свои обязанности. Я создал гибкую организацию, и мы успешно экспериментировали с методами, которые потом были включены в систему «экономичный стартап». Но несколько раз возникали ситуации, когда я вдруг понимал, что не справляюсь с работой. Для человека, ориентированного на результат, это очень неприятно. Хуже всего было то, что я не получал никакой обратной связи. А если бы получил, она могла бы быть примерно такой:
«Дорогой Эрик!
Поздравляю! Должности, которую вы до сих пор занимали, больше нет. Вы были переведены на новую должность в нашей компании. Вообще-то, это уже не та же самая компания, хотя у нее то же название и в ней работают те же люди. Ваша должность тоже называется так же, как раньше, и вы хорошо выполняли свои предыдущие обязанности, но на новой должности ваши дела идут неважно. Вас перевели уже полгода назад, и этим письмом мы хотим уведомить вас о том, что ваша деятельность на новой должности уже довольно давно не приносит желаемых результатов.
Всего наилучшего!»
Каждый раз в такой ситуации я начинал ломать голову над тем, что делать. Я знал, что компания растет и нам нужны дополнительные процессы и системы, которые позволяли бы координировать операции при каждом «скачке» в увеличении размера. Ведь я так часто видел стартапы, потерявшие гибкость и погрязшие в бюрократии из-за неуемного стремления к «профессионализму».
IMVU не могла себе позволить обойтись вообще без всяких систем, и вы тоже не можете себе этого позволить. Стартап всегда очень уязвим. Мне уже приходилось сталкиваться с ситуацией, когда компания создала избыточную архитектуру в попытках предотвратить любые проблемы, какие только могут возникнуть, и это мешало ей создавать продукты. Я видел компании, у которых возникали огромные технические трудности как раз в тот момент, когда популярность продукта была на пике. Для руководителя отдела это катастрофа, потому что все считают, что причина всех бед – в плохой работе какого-то отдела. т. е., его отдела. У компании возникли проблемы – и это ваша вина.
Почти все рекомендации на эту тему, которые я слышал, предлагают какие-то компромиссы (например, «планируйте что-то, но не слишком многое»). Но при таком избирательном подходе трудно как-то объяснить себе и окружающим, почему мы должны уделять внимание одним проблемам и при этом игнорировать другие. Это как работать под руководством капризного начальника, когда всем начинает казаться, что его решения имеют какие-то скрытые мотивы.
Если он склонен идти на компромисс, лучший способ повлиять на него и получить то, что вы хотите, – занять самую крайнюю позицию из всех возможных. Например, если одна группа предлагает увеличить время цикла выпуска – скажем, выводить на рынок новый продукт не чаще, чем раз в год, – можно привести доводы в пользу очень короткого цикла (возможно, каждую неделю или даже каждый день). В итоге из этих двух мнений возникнет нечто среднее. И когда компромисс будет достигнут, вы, вероятно, получите результат, близкий к тому, чего хотели на самом деле.
Но такая «гонка вооружений» приводит к эскалации. В другом лагере ваши оппоненты, вероятно, занимаются тем же самым. Со временем обе стороны занимают все более крайние позиции, и при этом достигать компромисса становится все труднее. В таком случае руководитель должен взять на себя ответственность за то, что вольно или невольно создал такую ситуацию. Возможно, он не желал подобной поляризации, но именно ее он и поощряет. Чтобы выбраться из этой ловушки, необходим другой подход.
Построение адаптивной организации
Нужно ли стартапу вкладывать средства в программу обучения новых сотрудников? Если бы вы задали мне этот вопрос несколько лет назад, я посмеялся бы и сказал: «Конечно, нет. Программы обучения – для крупных компаний, которые могут себе это позволить». Тем не менее мы в IMVU в итоге создали программу обучения, и она оказалась так хороша, что новые сотрудники полностью вливались в рабочий процесс уже в первый день работы. Всего несколько недель спустя они работали наравне с «ветеранами». Нам пришлось приложить массу усилий, чтобы стандартизировать рабочие процессы и подготовить программу, которую должны были изучить новые сотрудники. У каждого нового разработчика был наставник, помогавший новичку освоить программу, ознакомиться с системами, понятиями и методами, необходимыми для эффективной работы в IMVU. Результаты работы наставника и его ученика были взаимосвязаны, и поэтому наставники серьезно относились к обучению новичков.
Что интересно, сейчас я вижу, что мы не принимали отдельного решения о необходимости создать программу обучения. Эта программа возникла сама собой, естественным образом, в соответствии с нашим общим экспериментальным подходом. Процесс адаптирования новых сотрудников был постоянным объектом экспериментов, все время пересматривался и постепенно становился все более эффективным – и при этом его создание не требовало больших усилий.
Я называю это созданием адаптивной организации, которая автоматически корректирует свои процессы и действия в соответствии с текущими условиями.
Не слишком ли быстро мы едем?
До сих пор мы говорили о том, как важна скорость. Стартап бьется не на жизнь, а насмерть, чтобы выяснить, как создать жизнеспособный бизнес, ведь если он не сделает это до тех пор, как у него закончатся ресурсы, то умрет. Но нужно думать не только о скорости. Чтобы эффективно действовать, стартапу необходимы встроенные регуляторы скорости, помогающие находить оптимальный темп движения.
Мы видели пример регулирования скорости в главе 9, когда говорили о том, как можно использовать идею андона в таких системах, как непрерывное развертывание. Эта концепция прекрасно выражена в парадоксе, возникшем в компании Toyota: «Вовремя останавливайте производство, чтобы производство никогда не останавливалось». Смысл андона в том, что он позволяет остановить работу, если возникает серьезная проблема с качеством – и вынуждает устранить ее. Это одно из самых важных открытий системы бережливого производства: нельзя жертвовать качеством ради скорости. Если сегодня возникают проблемы с качеством (или вы их не замечаете), позже они начнут мешать вам расти. Брак приводит к лишней работе, деморализует людей, заставляют клиентов жаловаться, и все это замедляет развитие компании и истощает ценные ресурсы.
До сих пор, описывая проблемы качества, я говорил о физических товарах, но делал это просто ради удобства. У компаний, работающих в сфере обслуживания, возникают те же сложности. Попросите любого менеджера тренинговой компании, рекрутингового агентства или гостиницы показать вам сборник правил, где описано, как сотрудники должны предоставлять сервис в разных условиях и в разных ситуациях. То, что сначала было простым руководством, со временем часто усложняется.
Очень скоро правила становятся невероятно запутанными, и сотрудникам приходится тратить массу времени и сил на то, чтобы выучить их. Теперь представьте себе, что в такой компании менеджер-предприниматель пытается экспериментировать с новыми правилами или процедурами. Чем более качественны новые правила, тем легче их будет совершенствовать со временем. И наоборот, неясные правила полны противоречивых и неоднозначных пунктов, и если произойдет что-то неожиданное, возникнет хаос.
Когда я рассказываю о системе «экономичный стартап» предпринимателям, имеющим техническое образование, им очень трудно понять эту концепцию. С одной стороны, логика подхода подтверждения фактами и минимально рабочего продукта гласит, что нужно как можно быстрее отдать продукт в руки пользователей и любая дополнительная работа, которая не поможет учиться у них, будет только лишней. С другой стороны, цикл обратной связи «создать – оценить – научиться» – это непрерывный процесс. Мы не останавливаемся на первом минимально рабочем продукте, но используем то, чему научились, чтобы немедленно начать работу над следующей версией.
Поэтому, если сегодня мы упустим что-то важное – в сфере качества продукта, разработки или инфраструктуры, – завтра это может помешать нам расти. Можно увидеть, как этот парадокс проявился в IMVU. В главе 3 я уже рассказывал о том, что мы вывели на рынок продукт, который имел минимум опций и был полон багов. Но никто даже не попробовал воспользоваться этим продуктом, и поэтому почти вся наша работа оказалась ненужной. Хорошо, что мы не потратили слишком много времени на то, чтобы «улучшить» ту первую версию продукта.