Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [67]

Я взял маркер и нарисовал следующее:

Линия тянулась далее… Большая прямая линия с именами 30 с чем-то человек, которые все как один подчинялись мне!

«Вот в чем твоя проблема», – с ходу и совершенно правильно заявил Альберт. Я никогда раньше не думал об организационной структуре. Мы просто нанимали людей, которые, как и все до них, подчинялись напрямую мне. Как только численность нашего персонала вышла за пределы 10 человек, прямолинейная организационная структура стала мешать работе, что стало очевидно, как только я нарисовал ее. Проблема заключалась в том, что мы выросли и наша команда перестала воспринимать в целом то, чем мы занимались. Поэтому я вернулся с совещания с намерением разделить компанию на более мелкие команды, оставалось только решить, по какому принципу.

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

Прежде всего мы внедрили идею, что все сотрудники должны в какой-то мере заниматься поддержкой клиентов – не все время, конечно, а для сохранения связи с клиентами. Мы стали предлагать всем новым сотрудникам в течение первых двух недель обработать по полсотни обращений в службу поддержки, чтобы узнать наших клиентов, наш продукт и наш подход к обслуживанию клиентов. Мы также стали просить всех новых сотрудников создать приложение с использованием Twilio – причем не только разработчиков, а всех подряд. Торговым представителям и агентам по работе с клиентами это, несомненно, идет на пользу. Но мы ставили такую задачу юристам, бухгалтерам, аналитикам (всем без исключения) – создать что-нибудь с помощью сервисов Twilio и таким образом познакомиться с тем, какие возможности мы предоставляем клиентам. Цель заключалась в том, чтобы выстроить как можно больше связей между нашими сотрудниками и клиентами. И по сей день каждый новый «твилион» независимо от своей роли в компании изучает основы кодирования и создает приложение на нашей платформе. После завершения работы над своим приложением он получает красную спортивную куртку Twilio – своего рода почетный знак компании.

Самым значимым изменением стало преобразование нашего подхода к работе в небольших командах в структуру на основе команд. Мы разделили группу из 30 с лишним человек на три команды: Twilio Voice (уже существующий продукт), Twilio SMS (наш будущий продукт) и Twilio Infrastructure (наши внутренние платформы), каждую из которых можно было накормить дюжиной рогаликов (в продолжение традиции Twilio).

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

Клиент, миссия и показатели

Чтобы команда обрела внутреннюю мотивацию стартапа, ей нужны организационные принципы, в которых сформулирована цель. Обычно я начинаю с определения клиента, которого она обслуживает. Это может быть внешний клиент в традиционном смысле или внутренний клиент. Для команды, разрабатывающей продукт, идентификация потребительского сегмента или персоны может быть полезной. Например, эта команда создает продукты для малого бизнеса, а эта – для индивидуальных потребителей. Это довольно очевидная часть создания нового направления. Но это менее очевидно для команды, ориентированной на внутреннего клиента, а потому требует ясного формулирования и документирования. Например, команда Twilio Infrastructure, о которой я упоминал ранее, прямо заявила, что их «клиентами» являются другие внутренние разработчики Twilio. Это помогает понять, зачем ее члены ежедневно идут на работу. Если им нужно выяснить, куда двигаться, они должны расспрашивать клиентов об их насущных проблемах. В отсутствие клиента направление работы задает тот, кто кричит громче всех или имеет самую большую зарплату. Наличие клиента сводит все к выяснению того, что он хочет.

После определения клиента наступает очередь миссии. Это не маркетинговое упражнение вроде подготовки заявления о миссии компании. Речь идет о ключевой цели, которую команда принимает сама и вокруг которой она может сплотиться. Для команды, занимающейся инфраструктурой, это может быть «максимизация производительности наших инженеров при создании, тестировании, выпуске и эксплуатации высококачественных продуктов для интернета». Чтобы члены команды действительно верили в миссию, ее формулировка должна быть понятной, легко запоминающейся и лишенной жаргонизмов.

Наконец, для оценки прогресса в достижении миссии и того, насколько хорошо обслуживаются клиенты, необходимы показатели успеха. Многие компании называют это системой управления по целям или системой целей и ключевых результатов. Название может быть любым, но я считаю, что показатели должны быть долгосрочными, отражающими историю прогресса в достижении заявленной миссии, а не ежеквартально меняющимися. Например, когда началась разработка платформ Twilio Infrastructure, наша система сборки, упаковывающая код для развертывания на серверах, была ужасно ненадежна. Сборка и развертывание нашего ПО могло занять полдня, и половина времени сборка оказывалась неудачной по неизвестным причинам. Это сводило на нет производительность разработчиков. Так вот, команда, занимающаяся инфраструктурой, ввела показатель «время от регистрации кода до его развертывания». В краткосрочной перспективе было ясно, что им предстоит провести разбор существующей ситуации, но в долгосрочной перспективе этот показатель явно характеризовал производительность разработчиков, на которую могла влиять команда Twilio Infrastructure. Обратите внимание, что это не было «исправление системы сборки» или «уменьшение количества ошибок с 50 до 5 %», которые представляли собой краткосрочные проекты, а не долгосрочные показатели прогресса в достижении миссии.