По мере роста бизнеса растет и ваша команда. Как же сохранить команды маленькими в процессе масштабирования бизнеса? Когда появляется новая инициатива, а у вас на каждую команду приходится по одному продукту, ответ прост – финансируйте небольшую команду, созданную для решения новой проблемы. Но когда у вас есть продукт, который требует роста размера команды и масштаба деятельности, то как поступить тогда? Например, наша команда Twilio SMS поначалу, в 2010 г., представляла собой один небольшой коллектив, но теперь состоит из сотен инженеров. Как мы масштабировали ее? Ответ – путем клеточного деления.

Вначале команда совсем небольшая, скажем, пять человек. Когда она разрастается примерно до 10 человек, мы начинаем продумывать ее разделение надвое. Как правило, сложным моментом является то, как именно разделить команду, – подход зависит от ситуации. Иногда деление происходит по функциям продукта, иногда по уровням функциональности, иногда по потребительским сегментам – главное, сохранить клиента, миссию, показатели и базу исходного кода за командой. База исходного кода – самый сложный компонент, поскольку он планируется заранее. Чаще всего существует одна большая база кода, и для того, чтобы разделить команды, нужно разбить ее на две части, которыми две команды могут владеть независимо. Это требует времени – обычно разделение команды планируется как минимум за полгода. Положительная сторона этого процесса заключается в том, что вы постоянно инвестируете в свою кодовую базу, делите ее на микросервисы и исправляете прежние ошибки. Это похоже на весеннюю генеральную уборку, которая очень полезна, когда команда и продукт быстро растут. В результате база исходного кода постоянно приводится в соответствие с тем, что делают команды, которые, в свою очередь, согласуют направления своей деятельности с потребностями клиентов.

Вот пример: Twilio Voice начинался с одной команды. Но когда команда выросла до 15 человек, стало ясно, что она слишком велика и пришло время разделить ее. У этого продукта было два основных аспекта: подключение к телефонным сетям мира и API, выстроенные поверх подключения и позволяющие клиентам организовывать динамические взаимодействия, такие как надиктовывание текста, воспроизведение аудиозаписей и конференц-связь. На уровне подключения клиентам нужны такие функции, как глобальная связь и экономическая эффективность, а на уровне API – конференц-связь, масштабируемая до сотен человек, и более реалистично звучащий голос при преобразовании текста в речь. Это был естественный путь разделения продукта между двумя командами. Мы назвали их командами Voice Connectivity и Programmable Voice. В результате нам пришлось разделить код между этими двумя частями голосового продукта Twilio, и такой подход позволил нам гораздо быстрее подключать и тестировать новых операторов и масштабировать наши дата-центры по всему миру. Скорость разработки функционала также повысилась, поскольку командам больше не нужно было беспокоиться о взаимных соединениях операторов. А затем, когда команда Voice Connectivity сосредоточилась исключительно на потребностях клиентов, ее члены поняли, что сама связь может быть независимым продуктом. В 2014 г. эта команда запустила новый продукт под названием Twilio Elastic SIP Trunking, которым теперь пользуются более 6000 клиентов независимо от продукта Programmable Voice. Таким образом, разделение команды не только привело к переосмыслению архитектуры продукта, но и позволило нашим командам независимо друг от друга сосредоточиться на соответствующих потребностях клиентов, а также создать новый поток доходов для компании.