насколько хорошо обслуживаются клиенты, необходимы показатели успеха. Многие компании называют это системой управления по целям или системой целей и ключевых результатов. Название может быть любым, но я считаю, что показатели должны быть долгосрочными, отражающими историю прогресса в достижении заявленной миссии, а не ежеквартально меняющимися. Например, когда началась разработка платформ Twilio Infrastructure, наша система сборки, упаковывающая код для развертывания на серверах, была ужасно ненадежна. Сборка и развертывание нашего ПО могло занять полдня, и половина времени сборка оказывалась неудачной по неизвестным причинам. Это сводило на нет производительность разработчиков. Так вот, команда, занимающаяся инфраструктурой, ввела показатель «время от регистрации кода до его развертывания». В краткосрочной перспективе было ясно, что им предстоит провести разбор существующей ситуации, но в долгосрочной перспективе этот показатель явно характеризовал производительность разработчиков, на которую могла влиять команда Twilio Infrastructure. Обратите внимание, что это не было «исправление системы сборки» или «уменьшение количества ошибок с 50 до 5 %», которые представляли собой краткосрочные проекты, а не долгосрочные показатели прогресса в достижении миссии.
У команды, разрабатывающей продукт для клиентов, все немного проще. Например, команда Twilio SMS знала, что их клиентами являются другие разработчики и компании, в которых они работают. Таким образом, их миссия состояла в том, чтобы быть «ведущим глобальным API обмена сообщениями, которому доверяют разработчики и предприятия по всему миру», а основными показателями успеха были доход, количество клиентов, время безотказной работы API и задержка, а также уровень лояльности клиентов.
При наличии четкого определения клиента, ясной миссии и показателей успеха команда настраивается на выполнение миссии, движимая внутренней мотивацией. Эти три аспекта не выдумка руководителей в зале заседаний, их определяет сама команда и, как следствие, считает собственными.
Еще одно преимущество небольшой, мотивированной команды: никто не может спрятаться. Если вы винтик в механизме или один из десятков или сотен участников проекта, то нередко кажется, что ваш вклад не имеет значения, и это плохо сказывается на моральном духе и не позволяет в полной мере использовать навыки и таланты каждого сотрудника. Это также облегчает существование для отстающего исполнителя или любителя отлынивать. Но в небольшой команде из 5–10 человек ни то, ни другое невозможно. У каждого есть важная роль и мало возможности уклониться от активного участия в общем деле.
Определение клиента, миссии и показателей является основой работы небольшой команды.
Клеточное деление
По мере роста бизнеса растет и ваша команда. Как же сохранить команды маленькими в процессе масштабирования бизнеса? Когда появляется новая инициатива, а у вас на каждую команду приходится по одному продукту, ответ прост – финансируйте небольшую команду, созданную для решения новой проблемы. Но когда у вас есть продукт, который требует роста размера команды и масштаба деятельности, то как поступить тогда? Например, наша команда Twilio SMS поначалу, в 2010 г., представляла собой один небольшой коллектив, но теперь состоит из сотен инженеров. Как мы масштабировали ее? Ответ – путем клеточного деления.
Вначале команда совсем небольшая, скажем, пять человек. Когда она разрастается примерно до 10 человек, мы начинаем продумывать ее разделение надвое. Как правило, сложным моментом является то, как именно разделить команду, – подход зависит от ситуации. Иногда деление происходит по функциям продукта, иногда по уровням функциональности, иногда по потребительским сегментам – главное, сохранить клиента, миссию, показатели и базу исходного кода за командой. База исходного кода – самый сложный компонент, поскольку он планируется заранее. Чаще всего существует одна большая база кода, и для того, чтобы разделить команды, нужно разбить ее на две части, которыми две команды могут владеть независимо. Это требует времени – обычно разделение команды планируется как минимум за полгода. Положительная сторона этого процесса заключается в том, что вы постоянно инвестируете в свою кодовую базу, делите ее на микросервисы и исправляете прежние ошибки. Это похоже на весеннюю генеральную уборку, которая очень полезна, когда команда и продукт быстро растут. В результате база исходного кода постоянно приводится в соответствие с тем, что делают команды, которые, в свою очередь, согласуют направления своей деятельности с потребностями клиентов.
Вот пример: Twilio Voice начинался с одной команды. Но когда команда выросла до 15 человек, стало ясно, что она слишком велика и пришло время разделить ее. У этого продукта было два основных аспекта: подключение к телефонным сетям мира и API, выстроенные поверх подключения и позволяющие клиентам организовывать динамические взаимодействия, такие как надиктовывание текста, воспроизведение аудиозаписей и конференц-связь. На уровне подключения клиентам нужны такие функции, как глобальная связь и экономическая эффективность, а на уровне API – конференц-связь, масштабируемая до сотен человек, и более реалистично звучащий голос при преобразовании текста в речь. Это был естественный путь разделения продукта между двумя командами. Мы назвали их командами Voice Connectivity и Programmable Voice. В результате нам пришлось разделить код между этими двумя частями голосового продукта Twilio, и такой подход позволил нам гораздо быстрее подключать и тестировать новых операторов и масштабировать наши дата-центры по всему миру. Скорость разработки функционала также повысилась, поскольку командам больше не нужно было беспокоиться о взаимных соединениях операторов. А затем, когда команда Voice Connectivity сосредоточилась исключительно на потребностях клиентов, ее члены поняли, что сама связь может быть независимым продуктом. В 2014 г. эта команда запустила новый продукт под названием Twilio Elastic SIP Trunking, которым теперь пользуются более 6000 клиентов независимо от продукта Programmable Voice. Таким образом, разделение команды не только привело к переосмыслению архитектуры продукта, но и позволило нашим командам независимо друг от друга сосредоточиться на соответствующих потребностях клиентов, а также создать новый поток доходов для компании.
Однопоточные лидеры и упрощенное принятие решений
Последняя и, пожалуй, самая важная часть масштабирования небольших команд – это, как и следует ожидать, подбор руководителей. Если вам нужна небольшая команда, члены которой сосредоточены на миссии, имеют право принимать трудные решения и нацелены на быстрое обслуживание клиентов, то стиль работы руководителя имеет решающее значение. Мы называем таких лидеров «однопоточные», поскольку они просыпаются утром с одной мыслью – как привести команду к победе. (Поток – это цепочка выполняемых задач в компьютерной программе. Многопоточная
