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

Вот еще один хороший пример: несколько лет назад в наших офисах появился торговый автомат, битком набитый клавиатурами, мышами, адаптерами питания для ноутбуков и т. п. Вместо внесения денег вы сканируете свой бейдж и получаете необходимое вам оборудование (которое отслеживается в целях бухгалтерского учета и бережливого использования). Это своего рода контракт нашей ИТ-команды на обслуживание сотрудников. Для исключения бесконечных походов сотрудников в ИТ-службу для получения аппаратного ключа или клавиатуры был создан четкий интерфейс (торговый автомат), процесс (отсканируйте бейдж, и получите мышь) и даже ценник. Это новый способ взаимодействия команд со стандартным интерфейсом для совместной работы.

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

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

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

Stripe atlas: Создайте команду, похожую на единый мозговой центр

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

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

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

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