Войти в систему
Войти с помощью соц. сетей:
Принято считать, что, когда компания начинает расти, она неизбежно теряет способность создавать инновации, творить и развиваться. Я с этим категорически не согласен. В процессе развития стартапа можно создать организацию, которая будет учиться удовлетворять потребности уже имеющихся клиентов и привлекать новых, управлять существующими направлениями бизнеса и исследовать другие бизнес-модели — и все это одновременно. И если предприниматели готовы менять свою философию менеджмента, я уверен, что даже крупные и стабильные компании могут принять этот новый подход, который я называю портфельным.
Чтобы команда инноваций достигла успеха, ей нужна правильная структура. Если у стартапа есть поддержка венчурного капитала, такая структура возникает естественным образом — ведь он остается небольшой, независимой компанией. Внутренним командам-стартапам в крупных компаниях тоже нужна такая структура, и здесь важна поддержка высшего руководства. По моему опыту, командам стартапов обоих типов необходимы для успешного развития три условия: скромные, но доступные ресурсы, возможность независимо развивать и проверять свои идеи и личная заинтересованность в результате. В подразделениях крупных стабильных компаний таких условий обычно нет. Помните, что структура — это просто предпосылка, она не гарантирует успеха. Но неправильная структура почти наверняка приведет к неудаче.
В крупных, стабильных организациях руководители подразделений, чтобы увеличить свой бюджет, обычно используют политические игры, но они знают, что этот бюджет может быть сокращен. Поэтому зачастую они пытаются увеличить его как можно больше и готовы любыми способами защищать его от посягательств других подразделений. В этих политических играх менеджер иногда выигрывает, а иногда проигрывает: если в организации случается кризис, бюджет может быть внезапно сокращен. Это не катастрофа: команде просто придется работать больше с меньшими ресурсами. Но именно поэтому, чтобы учесть такую вероятность, бюджет часто с самого начала завышают.
У стартапа все по-другому: слишком большой бюджет для него так же вреден, как и слишком маленький — это подтвердили неудачи бесчисленных доткомов, — и стартапы очень чувствительны к изменениям бюджета в процессе работы. Очень редко стартап может позволить себе неожиданно сократить бюджет на 10%. Такой удар может оказаться для него фатальным. У независимых стартапов очень невысокая доля прибыли и поэтому почти нет права на ошибку. Так что стартапом управлять и легче, и сложнее, чем подразделением крупной компании: ему нужно намного меньше капитала, но этот капитал должен быть защищен от любых посягательств.
Возможности стартапа всегда ограничены, и чтобы создавать и выводить на рынок новые продукты, его командам нужна полная независимость. Они должны иметь возможность разрабатывать и проводить эксперименты без необходимости получать одобрение множества начальников.
Я рекомендую создавать кросс-функциональные команды, чтобы в них постоянно работали люди из всех подразделений компании, участвующих в создании или продажах первых продуктов. Задача таких команд — разрабатывать и представлять потребителям реальные функционирующие продукты, а не просто опытные образцы. Дискуссии с руководством и необходимость получать его одобрение замедляют цикл обратной связи «создать–оценить–научиться», мешают обучению и снимают с команды стартапа ответственность. Поэтому любые связанные с одобрением начальства задержки должны быть сведены в стартапе на нет.
Конечно, такой уровень независимости часто пугает головную организацию. Но развеять ее страхи поможет метод, описанный ниже.
Предприниматель должен быть лично заинтересован в результате своих творческих усилий. Независимые новые предприятия обычно предлагают своим сотрудникам какие-либо формы владения акциями. Если же вместо них используется система бонусов, то сотрудники должны получать премии и поощрения в случае долгосрочного успеха инноваций, которые они создают.
Но я не думаю, что личная заинтересованность должна быть только финансовой. Например, есть некоммерческие и государственные организации, где инновации не связаны с финансовыми целями. Но и в таких случаях личная заинтересованность может присутствовать. От головной организации требуется точно определить, кто несет ответственность за разработку инноваций, и этот человек должен получать признание, если он создал новый продукт и этот продукт успешен. Как сказал один предприниматель, руководитель подразделения в крупной медиакомпании: «Если оставить в стороне финансовые стимулы, я всегда помню: если на двери написано мое имя, мне есть что терять. Поэтому я стараюсь делать больше, чем все остальные. Такое чувство личной ответственности очень важно».
Эта формула эффективна и для коммерческих организаций. В компании Toyota менеджера, который отвечает за разработку новой модели от начала до конца, называют главным инженером, или суса.
«В американской бизнес-литературе суса часто называют менеджерами проектов, но это название не отражает их истинной роли в руководстве проектами. Сотрудники компании Toyota переводят этот термин как “главный инженер”, а модель, находящуюся в разработке, здесь называют “автомобиль суса”. Нам сказали, что суса несет полную, абсолютную ответственность за каждый аспект разработки».
И наоборот, я знаю чрезвычайно успешную и известную технологическую компанию, заслужившую особую репутацию своей инновационной культурой, но ее опыт разработки новых продуктов весьма неутешителен. Компания гордится своей системой стимулирования, основанной на больших премиях и статусных бонусах для членов команд, которые добились каких-то выдающихся успехов, но премии присуждает высшее руководство неизвестно на каких основаниях. Нет никаких объективных критериев, по которым команда может понять, выиграет ли она в этой лотерее. Команда не уверена, что ей поручат дальнейшую разработку инноваций, которые она создала. Поэтому люди не мотивированы идти на реальный риск и вместо этого предпочитают заниматься только теми проектами, которые почти наверняка получат одобрение высшего руководства.
Далее важно установить основные правила, по которым будет действовать независимая команда стартапа. Эти правила должны регулировать следующее: как защитить головную организацию, как будут отчитываться руководители, наконец, как реинтегрировать в головную организацию инновации, если они будут успешными. Вспомните «остров свободы» — мы говорили о нем во второй главе, — позволивший команде SnapTax создать внутренний стартап в компании Intuit. Это и есть то, что создает платформу для экспериментов.
Обычно в крупных компаниях членам внутренних инновационных команд рекомендуют защищать свою группу от головной организации. Но я считаю, что нужно делать как раз наоборот.
Давайте начнем с описания довольно типичной встречи, которая проходила в офисе одного из моих клиентов, крупной компании. Целью встречи было определить, какие опции нужно включить в следующую версию продукта. В соответствии с новым подходом, основанным на сборе строгих данных, был проведен эксперимент с ценообразованием. Первая часть встречи была посвящена данным, полученным в ходе этого эксперимента.
Тут возникла одна проблема: никто не мог понять, что эти данные означают. Для этой встречи было подготовлено множество отчетов о пользователях; команда разработки баз данных также присутствовала на ней. И чем настойчивее ее просили объяснить смысл каждой строки в электронной таблице, тем яснее становилось, что никто не понимает, как были получены эти цифры. Все просто сидели и смотрели на цифры валового оборота по различным пунктам, на цены, разбитые по кварталам и сегментам потребителей.
Хуже того, никто не понимал, какие пользователи участвовали в экспериментах. Разные эксперименты проводили разные команды, и поэтому разные опции продукта обновлялись в разное время. Весь процесс экспериментов занял несколько месяцев, и люди, которые их разрабатывали, уже трудились в другом подразделении, а непосредственно эксперименты проводили другие сотрудники.
Думаю, вы сами представляете, какие проблемы возникают в такой ситуации: «показатели тщеславия» вместо действенных показателей, слишком длительный цикл, работа большими партиями, неясная гипотеза роста, непродуманный план экспериментов, отсутствие личной ответственности и как следствие — никакого обучения, никаких новых знаний.
Слушая выступающих, я думал, что встреча на этом и закончится. Если никто не может прийти к согласию, просто нет смысла приводить доводы в пользу того или иного решения. Но я ошибся. Каждое подразделение просто интерпретировало данные так, как было выгоднее для его позиции, и защищало ее. Другие подразделения соглашались с альтернативными интерпретациями, которые поддерживали их позицию, и т.д. В конце концов, решения были приняты, не основываясь на данных. Вместо этого руководитель, который вел встречу, был вынужден руководствоваться параметрами, которые казались ему самыми достоверными.
Мне казалось бессмысленным тратить столько времени на обсуждение всех этих данных, ведь аргументы, которые в итоге признали самыми убедительными, были очевидны с самого начала. Казалось, представители каждого отдела считали, что их пытаются заманить в засаду: если бы одной команде удалось быстрее прояснить ситуацию, все остальные остались бы в проигрыше, и поэтому, естественно, присутствующие пытались еще больше все запутать. Это была совершенно напрасная трата сил и времени.
Подобные ситуации как раз и создают плохую репутацию экспериментам и решениям, основанным на данных. А все дело было в том, что команда баз данных писала отчеты, которых никто не читал или не понимал. Проектные группы считали, что эксперименты — пустая трата времени, потому что для них придется создавать сырые и «недоделанные» опции. Слова «провести эксперимент» казались просто оправданием для того, чтобы отложить трудное решение. И даже высшее руководство компании считало такие встречи хронической головной болью. Привычные встречи, посвященные расстановке приоритетов, могли быть просто борьбой мнений, но хотя бы было понятно, что на них происходит. Теперь же им приходилось проводить ритуал, связанный со сложными математическими расчетами и не приносивший никаких результатов, — и он все равно заканчивался борьбой мнений.
Однако в основе этой вражды подразделений лежал вполне понятный страх. Компания обслуживала два сегмента потребителей: корпоративных клиентов и частных. В одном сегменте у компании были продавцы, предлагавшие сложные системы другим компаниям, а в другом происходили по большей части одноразовые покупки. Основная часть текущих доходов компании поступала от продаж B2B, но рост в этом сегменте замедлился. Все считали, что в сегменте частных клиентов есть огромный потенциал роста, но его никак не удавалось реализовать.
Отчасти рост замедляла структура ценообразования. Подобно многим поставщикам, работающим с крупными заказчиками, эта компания изначально установила высокие цены, а затем предлагала большие скидки «привилегированным» корпоративным клиентам. Естественно, каждый продавец убеждал своих клиентов в том, что ему предложены исключительные условия. Но частным покупателям цены в прайс-листе казались просто заоблачными.
Команда, отвечавшая за рост сегмента В2С, хотела провести эксперимент: снизить цены и посмотреть, что будет. Команда, отвечавшая за сегмент В2В, опасалась, что это отпугнет корпоративных клиентов. Что будет, если они увидят, что обычные люди покупают продукт по более низким ценам, чем они?
Любой, кто работал в компании, ориентированной на несколько сегментов, согласится, что у этой проблемы есть множество возможных решений. Например, можно создать отдельные наборы опций, чтобы разные клиенты могли покупать продукт разного «уровня» (как разные «классы» у авиакомпаний), или даже продавать продукты под разными брендами. Тем не менее компания не могла принять ни одно из таких решений. Почему? Из страха поставить под удар текущий бизнес каждый предложенный эксперимент откладывался, саботировался и усложнялся.
Важно подчеркнуть, что страхи компании были вполне обоснованы. Саботаж — адекватная реакция менеджера, если кто-то вторгается на его территорию. Эта компания — не скромный маленький стартап, у которого еще ничего нет. Большой компании всегда есть что терять. Если доход от основного бизнеса начнет снижаться, полетят головы. И к этому невозможно отнестись легкомысленно.
Но если бы эта компания не стала активно экспериментировать, ее в итоге постигла бы печальная участь: год за годом высокие прибыли, а потом внезапная смерть.
Создавая внутренние команды инноваций, мы часто спрашиваем: как защитить внутренний стартап от головной организации? Но я хочу задать противоположный вопрос: как защитить головную организацию от стартапа? Люди начинают защищаться, когда чувствуют, что им угрожают, и в такой ситуации никакие инновации невозможны. Поэтому крупным компаниям часто советуют «спрятать» команду инноваций. Но это ошибка. Такой подход иногда бывает успешным, как и ситуация, когда команда инноваций работает на стороне. Например, первая модель ПК IBM была создана в Бока-Ратоне, штат Флорида, совершенно независимо от остальных подразделений IBM. Но такая стратегия редко приводит к жизнеспособным инновациям. В перспективе секреты от головной организации чреваты серьезными проблемами.
Рассмотрим эту ситуацию с точки зрения менеджеров, которым поручили разработку инноваций. Скорее всего, они будут считать, что их предали, и начнут превращаться в параноиков. В конце концов, если что-то настолько важное можно успешно скрывать, что еще поджидает их в темноте? Со временем это приводит к политическим играм, поскольку менеджеры начинают во всем искать угрозу своей власти, влиянию и карьере. И успех инноваций — не оправдание для такого нечестного поведения. С точки зрения опытного менеджера, ситуация выглядит так: если вы не владеете информацией, все эти секреты приведут к тому, что вам нанесут удар в спину.
Несправедливо критиковать этих менеджеров — ответственность здесь лежит на высшем руководстве, которое не смогло создать систему поддержки, позволяющую открыто действовать и создавать инновации, не пытаясь «прятать» их. Я полагаю, что именно по этой причине компании, действующие по примеру IBM, быстро теряют лидерские позиции на новых рынках, которые завоевали, создав инновации в «черном ящике». Ведь они не могут укреплять и поддерживать культуру, которая и позволила им создать эти инновации.
Но выход есть. Можно создать механизм, который даст команде необходимые полномочия и позволит открыто создавать инновации. Это — путь к жизнеспособной культуре инноваций, которая позволит компании выжить, когда она снова и снова будет сталкиваться с угрозами своему существованию. Я предлагаю такое решение: создать «песочницу» инноваций, в которой можно проверять новые идеи любыми методами, без всяких ограничений. Это можно сделать следующим образом: любая команда может разработать эксперимент по сплит-тестированию, затрагивающий только те элементы товара или услуги (если они состоят из нескольких элементов), которые помещены в «песочницу», либо предназначенный только для определенных сегментов потребителей или территорий (для новых продуктов). При этом:
Вначале «песочница» должна быть небольшой. В компании, описанной выше, в «песочницу» сперва входил только прайс-лист. В зависимости от типа продуктов, которые создает компания, размер «песочницы» может быть определен по-разному. Например, онлайн-сервис может ограничить ее определенными страницами сайта или потоками пользователей. Розничная компания может ограничиться несколькими магазинами или географическими областями. Если компания пытается вывести на рынок совершенно новый продукт, ограничения могут касаться определенных сегментов потребителей.
Клиенты, участвующие в экспериментах, которые проводятся в «песочнице», могут быть реальными, и команда инноваций должна иметь возможность установить с ними долговременные отношения. В конце концов, она может экспериментировать с этими ранними последователями в течение длительного времени до того, как будут достигнуты результаты в обучении.
При любой возможности команды инноваций должны быть кросс-функциональными, и их руководитель должен обладать теми же полномочиями, что и суса в компании Toyota. Он должен иметь возможность руководить созданием, выводом на рынок и продвижением продуктов или опций в «песочнице» без предварительного одобрения высшего руководства. Его отчеты об успехах или неудачах проекта должны быть основаны на стандартных действенных показателях и учете инноваций.
Этот подход может оказаться эффективным даже в том случае, если в компании раньше не было кросс-функциональных команд. Первые несколько изменений, например изменение цен, возможно, не потребуют больших технических усилий, но приведут к координации работы разных подразделений: разработки, маркетинга, обслуживания клиентов. Команды, действующие таким образом, более продуктивны — если продуктивностью считается способность создавать ценность для потребителей, а не просто постоянная занятость.
Успех или неудачу эксперимента оценить легко, потому что с самого начала установлены точные критерии и показатели. Так или иначе, команда может очень быстро выяснить, верны ли ее предположения о поведении клиентов. Используя систему учета инноваций, описанную во второй части, команда может сообщать о своем продвижении. И все, кто будет читать ее отчеты, тоже увидят, насколько эффективны действенные показатели. Такой подход очень продуктивен. Даже если кто-то захочет саботировать усилия команды инноваций, для этого ему придется как минимум понять, что такое действенные показатели и этапы обучения.
«Песочница» также способствует быстрым итерациям. Когда люди могут выполнить проект от начала до конца, когда команда работает по принципу небольших партий и быстро принимает четкие решения, она получает все преимущества обратной связи. Если ей не удается улучшить показатели, она может тут же что-то сделать на основании полученных результатов. Поэтому такие команды склонны быстро принимать оптимальные решения, даже если они начинали не с самых лучших идей.
Как мы уже видели, это один из аспектов подхода небольших партий. Благодаря ему «песочница» позволяет команде делать ошибки быстро, без особых затрат и при этом учиться. Как мы скоро увидим, такие небольшие начальные эксперименты могут показать, что у команды появился новый жизнеспособный бизнес, который можно интегрировать в головную компанию.
Мы подробно обсуждали этапы обучения в главе 7. Для внутренней команды инноваций последовательность действий — та же самая: на основании архетипа потребителей создать идеальную модель подрывных инноваций, разработать минимально рабочий продукт, определить базовые показатели, а затем попытаться настроить механизм так, чтобы приблизить их к идеалу.
В соответствии с такой моделью внутренние команды инноваций, по сути, действуют как стартапы. А если они добились успеха, новые продукты нужно интегрировать в общий портфель товаров и услуг компании.
Любая компания проходит в своем развитии разные фазы. На первой стадии развития стартапа предприниматели, авторы оригинальной идеи, должны решить проблему масштаба. У компании появляются новые клиенты на основном рынке, она завоевывает новые территории, у нее возникает определенная репутация, и это отражается в ее пиар-кампаниях, маркетинге, продажах и развитии бизнеса. В большинстве случаев продукт привлекает конкурентов: подражателей, быстрых последователей и имитаторов всех мастей.
Как только рынок нового продукта более или менее сформировался, процедуры и процессы становятся более стабильными и рутинными. Чтобы избежать превращения продукта в массовый товар на целевом рынке, нужно расширять ассортимент, вводить постепенные обновления и новые формы маркетинга. На этой фазе важно совершенствовать операции, ведь это позволяет увеличивать долю прибыли и снижать затраты. Для управления этими процессами нужен менеджер особого типа: тот, кому хорошо удаются оптимизация, делегирование полномочий, контроль за выполнением плана. Стоимость акций компании зависит от ее стабильности и возможности прогнозировать ее рост.
Затем компания входит в ту фазу, когда особое значение приобретают унаследованные продукты и эксплуатационные расходы. Это область аутсорсинга, автоматизации и снижения затрат. Тем не менее и на этом этапе проблемы с ресурсами, с инфраструктурой или потеря лояльных клиентов могут уничтожить компанию. И в отличие от первых фаз теперь инвестиции не помогут ей достичь быстрого роста. На этой стадии менеджеры часто похожи на бейсбольных судей: их критикуют, когда что-то идет не так, но не обращают на них внимания, когда все хорошо.
Принято считать, что через эти стадии проходят только крупные компании и они могут касаться целых подразделений и сотен или даже тысяч сотрудников. Это логично, ведь процесс развития бизнеса в таких показательных ситуациях наблюдать легче всего. Однако на самом деле через эти стадии развития проходит каждая компания, каким бы ни был ее размер. Как только продукт выходит на рынок, команда начинает упорно трудиться, чтобы перевести бизнес в следующую фазу. Каждый успешный продукт или опция, созданные в отделе исследований и разработок и ставшие элементом стратегии компании, подвергаются оптимизации и со временем устаревают.
И у стартапов, и у крупных компаний возникает проблема: сотрудники часто «следуют» за продуктами, которые разрабатывают, по мере того, как бизнес переходит из одной фазы в следующую. Обычно создателям нового продукта или опции поручают управлять ресурсами, командой или подразделением, которое должно вывести его на рынок. В результате творческим менеджерам, которым лучше всего удается создавать что-то новое, приходится заниматься рутинными задачами, связанными с развитием и оптимизацией продуктов.
Это одна из причин того, что стабильным компаниям так сложно найти творческих менеджеров, способных руководить процессом создания инноваций. Каждый инновационный проект конкурирует за ресурсы с более стабильными проектами, и один из самых ценных и редких ресурсов — талантливые люди.
Что же делать в такой ситуации? Выход в том, чтобы по-разному управлять всеми видами задач, создавая кросс-функциональные команды в каждой области. Когда проект по разработке нового продукта переходит из одной фазы в другую, его передают от команды команде. Сотрудники могут переходить из команды в команду вместе с продуктом или оставаться на прежнем месте и начинать работу над чем-то новым. Ни тот ни другой выбор не является предпочтительным, все зависит от характера и навыков каждого человека.
Некоторые люди — прирожденные изобретатели, они любят работать, не испытывая давления, без ожиданий, характерных для более поздних фаз процесса разработки. Другие честолюбивы и рассматривают инновации как путь наверх, в ряды высшего руководства. Есть и те, кому лучше всего удается управлять стабильным бизнесом, аутсорсингом, поддерживать эффективность и сокращать затраты. Людям нужно позволить решать те задачи, которые даются им лучше всего.
Предпринимательство может стать для новаторов хорошим способом развития карьеры в крупных организациях. Тогда менеджерам, способным возглавлять команды и работать по системе «экономичный стартап», не придется покидать компанию, чтобы самореализоваться, или пытаться вписаться в жесткую иерархию традиционных функциональных подразделений. Вместо этого на их визитных карточках будет написано: «Такой-то. Предприниматель». И все. Такие менеджеры могут отчитываться перед руководством, используя систему учета инноваций, и получать вознаграждение в соответствии с достигнутыми результатами.
После того, как продукт оказался в «песочнице инноваций», его нужно снова интегрировать в головную организацию. Здесь нужна более многочисленная команда, ведь новый продукт нужно завершить, вывести на рынок и привлечь потребителей. Сначала команде, выполняющей эти задачи, требуется помощь новаторов, которые экспериментировали с продуктом в «песочнице». И это хорошо, ведь в таком случае новаторы могут обучить членов команды новому стилю работы, которому они следовали в «песочнице».
В идеале со временем «песочница» будет расти: вместо того, чтобы переводить команду инноваций из «песочницы» в стандартные рутинные условия работы в компании, можно увеличить объем «песочницы». Например, если эксперименты в «песочнице» касались лишь некоторых аспектов продукта, к ним можно добавить новые опции. В ситуации, описанной выше, это можно сделать, сначала поместив в «песочницу» только ценообразование. Получив результаты этих экспериментов, компания может добавить в «песочницу» домашнюю страницу веб-сайта. А затем — функциональность поиска или общий веб-дизайн. Если изначально в целевую группу входили только отдельные пользователи или определенное их количество, то можно привлечь новых. При этом руководители компании должны позаботиться о том, чтобы команды, работающие в «песочнице», не подвергались давлению со стороны головной организации. «Песочница» нужна и для их защиты, и для защиты головной компании, и если возникла идея увеличить «песочницу», об этом нужно помнить.
Работать в «песочнице» инноваций — все равно что тренировать мышцы. Сначала команда проводит небольшие эксперименты. Возможно, первые из них не дадут ничего для обучения и окажутся не слишком успешными. Но со временем команда будет работать все лучше и лучше и в итоге благодаря подходу небольших партий и действенным показателям начнет получать постоянную обратную связь. При этом обучение будет все более эффективным.
Конечно, любая система инноваций в итоге становится жертвой собственного успеха. «Песочница» расширяется, благодаря созданным в ней инновациям доходы компании растут, и цикл начинается снова. Бывшие новаторы превращаются в сторонников статус-кво. В «песочнице» неизбежно возникают дополнительные правила и средства контроля, необходимые, чтобы решать задачи, важные для миссии компании. И новым командам инноваций понадобится новая «песочница», в которой она сможет свободно экспериментировать.
Этот последний переход дается новаторам особенно трудно: превращение из радикалов-аутсайдеров в сторонников статус-кво. Лично мне сделать это было очень сложно. Думаю, вы уже поняли, что в тех компаниях, где я работал, я всегда был эдаким нарушителем спокойствия. Я призывал всех к быстрым итерациям, принятию решений на основании полученных данных, к тому, чтобы как можно раньше начать диалог с потребителями. Если эти идеи не были частью доминирующей культуры, продвигать их было легко. Для этого достаточно было как можно активнее предлагать их. В культуре компании они считались ересью, поэтому руководство пыталось идти на «разумные» уступки. Возникала забавная ситуация: чем более радикальными были мои предложения, тем чаще «разумный» компромисс оказывался ближе к моей истинной цели.
Вернемся на несколько лет назад, в те годы, когда я руководил процессом разработки продукта. Каждого нового сотрудника нужно было ознакомить с системой «экономичный стартап». Сплит-тестирование, непрерывное развертывание и тестирование с участием клиентов были в нашей компании стандартными методами. Мне нужно было постоянно продвигать свои идеи, чтобы каждый новый сотрудник был готов дать им шанс. Но те, кто уже какое-то время проработал в компании, воспринимали их как нечто само собой разумеющееся, как установленный порядок.
Подобно многим предпринимателям, я оказался в тисках между постоянным продвижением своих идей и неординарными предложениями, как их можно улучшить. Мои сотрудники оказались в той же ситуации, что и я сам несколько лет назад: чем радикальнее были их предложения, тем чаще компромисс сдвигался в желаемую для них сторону. Я слышал все на свете: призывы вернуться к водопадной модели разработки, больше или меньше вовлекать потребителей, больше полагаться на видение и меньше на данные или интерпретировать данные более строгим способом с точки зрения статистики.
Требовались постоянные усилия, чтобы рассматривать эти предложения всерьез, но занимать категоричную позицию было бесполезно, а попытки достичь компромисса тоже ничего не давали.
Я понял, что каждое предложение нужно подвергать тому же самому строгому анализу, который привел к созданию системы «экономичный стартап». Можно ли на основе теории предсказать результаты предложенных изменений? Можно ли ввести изменение в небольших масштабах и посмотреть, что будет? Можно ли измерить его воздействие? Всякий раз, когда это можно было сделать, эти подходы позволяли учиться мне самому и, что еще важнее, увеличивали продуктивность компаний, с которыми я работал. Многие методы системы «экономичный стартап», которые мы изобрели в IMVU, не были предложены лично мною. Их предложили, протестировали и внедрили наши сотрудники, вложив в них свой талант и творческий подход.
Прежде всего я столкнулся с простыми вопросами: как узнать, что «ваш способ» создания компании окажется успешным? Какие еще компании его используют? Кто стал богатым и знаменитым в результате такого подхода? Эти вопросы весьма разумны. Титаны нашей отрасли работают медленнее и последовательнее. Зачем же нам поступать иначе?
Чтобы ответить на эти вопросы, нужна теория. Те, кто пытается использовать систему «экономичный стартап» просто как набор методов или тактик, не добьются успеха. Мне пришлось узнать это на собственном горьком опыте. У стартапа постоянно возникают проблемы. И каждый раз мы сталкиваемся со старой дилеммой, поставленной еще Демингом: как мы узнаем, что проблема вызвана отдельной ошибкой, а не системной причиной? Если мы находимся в процессе принятия нового подхода, то всегда есть соблазн обвинить в возникающих проблемах новую систему. Иногда это бывает справедливо, а иногда нет. Чтобы это выяснить, нужна теория. Нужно иметь возможность предсказывать, что принесут изменения, которые мы вводим, чтобы определить, что возникающие проблемы — действительно проблемы.
Например, если мы начнем определять продуктивность команды не как успешное выполнение узкофункциональных обязанностей — в сфере маркетинга, продаж или разработки продукта, — а как получение фактических данных, возникнут проблемы. Как мы уже говорили, функциональные специалисты привыкли оценивать свою эффективность в соответствии с тем, сколько времени они тратят на работу. Например, программисты считают, что весь день должны писать коды. Именно поэтому традиционная рабочая атмосфера их так раздражает, ведь им все время приходится отвлекаться: встречи, кросс-функциональные задачи и бесконечные совещания с начальством — все это снижает эффективность. Однако эффективность отдельных специалистов не является целью «экономичного стартапа». Вместо этого нужно создавать кросс-функциональные команды, позволяющие получать подтверждение фактами. Многие методы — действенные показатели, непрерывное развертывание и полный цикл обратной связи «создать–оценить–научиться» — предназначены для того, чтобы побуждать команду оптимизировать отдельные функции. Не так важно, как быстро мы можем создать продукт. Не так важно, как быстро мы можем его оценить. Важнее всего то, как быстро мы можем пройти весь цикл.
Я обучаю других своей системе уже много лет и постоянно сталкиваюсь с тем, что переход к концепции подтверждения фактами сначала вызывает отторжение и только потом люди начинают видеть, в чем заключается ее суть. Дело в том, что проблемы, вызванные старой системой, часто бывают неосязаемыми, а проблемы новой системы слишком очевидны. Но тут нужно знать теорию. Если все понимают, что временное снижение продуктивности в переходном периоде неизбежно, то этим процессом можно активно управлять. Ожидания можно установить с самого начала. Например, в своей консалтинговой практике я поднимаю этот вопрос с первого дня; если не сделать этого, то есть риск свести на нет все остальные усилия. Но по мере внедрения изменений можно с помощью анализа первопричин выяснять, какие проблемы нужно предотвратить. В конце концов, «экономичный стартап» — это система, а не план, которому нужно следовать. Она разработана таким образом, чтобы ее можно было адаптировать к условиям каждой отдельной компании. Не нужно слепо копировать то, что делают другие. Такие методы, как «Пять “Почему?”» позволяют найти то, что лучше всего подходит именно вашей организации.
Лучший способ экспериментировать с новыми методами и исследовать новые идеи — вступить в сообщество практикующих. Сегодня по всему миру возникают группы сторонников системы «экономичный стартап», возникло также и онлайн-сообщество. В конце этой книги вы узнаете, как можно присоединиться к ним.
Войти с помощью соц. сетей: