Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Ловушка улучшения сотрудничества

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

Это я и называю «ловушка улучшения сотрудничества».

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

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

В технологических командах такими интерфейсами обычно являются API и хорошая документация. Когда команде Programmable Voice нужно куда-то позвонить, они делают запрос через API на уровень Voice Connectivity. Такой четко определенный контракт на обслуживание между командами обеспечивает стабильный, предсказуемый и задокументированный способ взаимодействия и даже предусматривает выставление счетов за предоставленные услуги. Подобная практика не ограничивается технологическими командами. В других подразделениях организации можно применять аналогичные принципы взаимодействия. Например, ваша юридическая команда тратит много времени на переговоры о контрактах с клиентами вместе с командой продаж, но есть ли у них четкий «API» для взаимодействия? Как заключается новый контракт? Как отслеживается прогресс в работе? Сколько «стоит» нанять штатного адвоката и учитывается ли это в себестоимости продаж? Представьте себе юридическую команду с платформой самообслуживания, где продажники могут взять утвержденные заготовки, не требующие участия адвоката. Это был бы отличный продукт! Многим продажникам это должно понравиться, поскольку такая платформа ускоряет цикл заключения сделок и требует меньше «сотрудничества» с юридической командой.

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

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

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

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

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

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