Помните Patio11, с которым вы познакомились в главе 4? У него есть отличный образ для описания того, на что похоже построение успешной небольшой команды: создание единого мозгового центра, включающего все необходимые функции. Такой подход помогает избежать того, что, по его мнению, является главной проблемой многих компаний (хотя это стандартная практика): изоляции разработчиков от бизнес-процессов. По его словам, «это проблема организационной структуры во многих отношениях. Обычно компании говорят: “Ничего, что у нас бизнес-подразделение здесь, а инженерная команда в другом месте – у них ведь есть интерфейс”». Под «интерфейсом», к которому он относится скептически, понимаются требования к продукту, канбан-доска или другие системы вывешивания рабочих задач на стене. На деле это часто приводит к конфронтации, поскольку программисты составляют график и выполняют работу, а потом, как это всегда бывает, требования меняются. И тогда начинаются взаимные обвинения. По словам Patio11, «те, кто работал над ПО, говорят: “Вы меняете правила игры для меня, мне приходится выбрасывать сделанную работу. У меня теперь летят все сроки. Эти тупицы в бизнес-подразделении не понимают, как пишутся программы”. А бизнесмены говорят: “Эти тупые разработчики обещали, что система будет готова к марту. На дворе февраль, а мы даже не приблизились к завершению разработки системы”».

Подводя итог, он заключает: «Разработчики – на Марсе, те, кто составляет требования, – на Венере, и они никогда не встретятся». Такая структура и ее предсказуемый результат возникают в каждой компании, где решили отделить тех, кто создает продукт, от тех, кто понимает, что именно требуется создать.

Так быть не должно. Здесь на сцену выходят небольшие кросс-функциональные команды.

Компания Stripe, где работает Patio11, давно научилась объединять разработчиков и бизнесменов в одну команду для выполнения проектов. Но при создании команды для разработки приложения Atlas – продукта, который позволяет предпринимателям зарегистрировать корпорацию в штате Делавэр с помощью всего нескольких кликов, – они пошли еще дальше в плане объединения функций. Для этого проекта они свели в одну команду не только разработчиков и бизнесменов, но и службу по работе с клиентами, юридическую службу и маркетинг. Мало того, они посадили всех в одной комнате.

Это дает огромные преимущества, в частности, повышает эффективность. Patio11 так описывает один из результатов: «Юрист Atlas сидел рядом с командой инженеров. Юридический аспект был очень важен для этого продукта. Когда кто-то приходил в 11:00 с вопросом вроде “Я не уверен, что эта скопированная часть кода у меня на экране в порядке”, они могли буквально повернуться к юристу и сказать: “Слушай, законность копирования – это твой вопрос. Можно мне сделать то-то и то-то?”, а тот отвечал: “Стоп. Зачем вообще делать это? Нельзя ли подойти к этому фрагменту по-другому?”» А потом они за пять минут придумывали оптимальный подход.

Сравните это с обычным процессом, когда разработчик занимается программой 12 недель, и только после этого проект поступает на рассмотрение. В этот момент, как объясняет Patio11, «уже невозможно изменить предположения, которые легли в основу целого ряда экранов и обмена данными между ними. Вы заперты в рамках уже готового продукта, и все, что можно сделать, – попытаться решить проблему плохого понимания правовой среды подбором формулировок на экранах». Вот почему объединение всех специалистов в одну команду и даже устранение физической и организационной дистанции между ними является столь действенным инструментом. Такая организация позволяет отфильтровать неправильные предположения и плохие решения в самом начале процесса.

Кроме того, это удивительным образом сказывается на моральном духе коллектива. Все в команде Atlas идентифицируют себя прежде всего как члены команды, а не просто как работники. Представляясь, вам говорят не «Меня зовут Сюзан, я работаю в команде поддержки пользователей над проектом Atlas», а «Меня зовут Сюзан, я работаю в команде Atlas, которая занимается поддержкой пользователей». Проще говоря, подчеркивают принадлежность не к компании Stripe и службе поддержки пользователей, а к команде Atlas. Служба поддержки пользователей – то самое место, где компании нередко разъединяют тех, кто работает с клиентами, и команду, создающую продукт. Это приводит к тому, что люди начинают думать о себе как о винтиках в машине. «Они видят, что работа здесь – это получил задание, выполнил задание. Через некоторое время такое отношение надоедает, что выливается в высокую текучесть кадров», – объясняет Patio11.

В команде Atlas все совершенно не так. Люди настолько привязываются к ней, что отказываются от перехода в другие отделы, даже если это открывает возможности для роста. Более того, они чувствуют аналогичную связь и с клиентами, добиваясь такого взаимодействия, которого, как говорит Patio11, «он не видел ни в одной другой команде».

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

В ноябре 2017 г., когда с момента запуска Atlas прошел примерно год, на очередном совещании команды поддержки пользователей разговор пошел о том, почему внезапно вырос поток вопросов клиентов о налогах. Patio11 поинтересовался, о каких налогах они спрашивают, – известно, что компании платят налог с продаж, налог на прибыль, налог на заработную плату и т. д., – и услышал в ответ: «О чем-то под названием “франшизный налог”».

Как опытный предприниматель, Patio11 сразу же вспомнил сложность расчета годового франшизного налога в штате Делавэр, который должна платить каждая компания. Понятно, что шквал вопросов обрушивается на разработчиков в тот момент, когда Департамент налогообложения франшиз штата Делавэр (опять этот ужасный департамент!) начинает рассылать компаниям свои ежегодные напоминания о наступлении срока уплаты налога. Пользователи обращались за помощью к Atlas, обещавшему помогать им во всех сложных ситуациях.

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

Только представьте, насколько заманчиво решить очередную проблему своих клиентов – фактически заполнить налоговую декларацию, избавив от необходимости возиться с невразумительным сайтом штата Делавэр. Сначала инженеры инстинктивно ответили: «Налоги выходят за рамки нашей компетенции». Однако Patio11, как лидер, увидел здесь скрытую возможность. У миллиона компаний уходит по два часа в год на заполнение налоговой декларации в штате Делавэр, и если команда Atlas потратит несколько недель на создание соответствующий функции, то она сэкономит миллионы часов рабочего времени для них и, по сути, сделает человечество более эффективным.

Patio11 уже не раз составлял налоговые декларации и съел собаку на них, поэтому он мог описать программу, которая упростила бы этот процесс для клиентов. Впрочем, существовала одна закавыка. Полуавтоматическое заполнение форм клиентами могло оказаться проблематичным из-за наличия двух способов расчета налога: способа A и способа B. В принципе, стартапы всегда должны использовать способ B. Разработчики Atlas задались вопросом, можно ли рекомендовать клиентам сразу перейти к способу B, но юристы в команде полагали, что подобное слишком близко к юридической консультации. Инженеры предложили компромисс: программа по умолчанию предлагает способ B, но предупреждает о том, что если юрисконсульт рекомендует использовать способ A, то нужно обращаться непосредственно в администрацию штата Делавэр. Такое предложение устроило команду юристов.

Таким образом, разработчики взяли непредвиденную потребность клиента, превратили ее в юридически сложное решение, которое экономило клиентам массу времени, и согласовали его с командой юристов. Если бы юрист не был в одной комнате с командой, он мог бы ответить: «Нет, о чем вообще речь? Мы не можем давать клиентам юридические консультации». Однако он вник в проблему и взялся решать ее вместе со всеми. При таком подходе удалось быстро начать работу над программой и создать ее к моменту подачи налоговых деклараций.

Инженеры разработали функцию расчета налогов, причем достаточно быстро, чтобы включить ее в следующую версию Atlas. Программа рассылает клиентам напоминания о необходимости уплаты налогов и помогает определить их сумму. Процесс, который раньше отнимал два-три часа, теперь занимает меньше минуты. «Мы здорово поработали, но этого не произошло бы, если бы представитель службы поддержки клиентов не сказал тогда на совещании: “Срок уплаты налогов прошел полгода назад, и клиенты уже спрашивают о наших планах”», – вспоминает Patio11.

Этого не произошло бы, если бы инженеры из команды Atlas были изолированы от остальных. Подобное удалось потому, что команда находилась в одном вместе и все участвовали в принятии решений. У инженеров нет собственных специальных совещаний, а вот у маркетологов, специалистов по работе с клиентами и юристов они есть. Но когда собирается команда Atlas, в совещаниях принимают участие все. Таким образом, никто не отрывается от клиентов и может дать им все необходимое. Они – единый мозговой центр, обслуживающий клиентов.

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

Итак, вам нужно, чтобы члены команды и команда в целом верили в важность своего дела. Эта внутренняя мотивация возникает не вследствие вдохновляющих речей или большой зарплаты. Она – результат знания того, что ваша работа оказывает реальное влияние на жизнь людей.

В большинстве компаний директивы движутся через организационную структуру сверху вниз. Но в Twilio, Stripe и других компаниях, верящих в небольшие команды, все наоборот. Собеседники – а это часто инвесторы – спрашивают меня, почему мы даем так много самостоятельности небольшим командам, позволяем им самим определять приоритеты и планы действий. Я отвечаю: «Кто лучше них знает, как обслуживать клиентов? Я сижу здесь и разговариваю с инвесторами, а они общаются с клиентами. Как вы думаете, кто знает больше о том, что мы должны сделать для наших клиентов?»

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