Иногда даже лучшие практики можно улучшить
Любой, кто читает мои материалы, знает, что у меня есть четкие идеи о лучших методах формирования инженерных команд. И они, вероятно, знают, что эти лучшие практики сосредоточены вокруг некоторых основных тем:
- Команды должны формироваться с учетом автономии — межкомандная зависимость должна быть сведена к минимуму.
- Команды должны формироваться вертикально (по продуктам или бизнес-функциям), а не горизонтально (по техническим функциям).
Все, что я испытал, и все, что я прочитал, только укрепило эту точку зрения. Тем не менее, время от времени я сталкивался с ситуациями, когда реальность не совсем согласовывалась с этими передовыми практиками — по крайней мере, не там, где речь шла о некоторых мелких деталях.
Поэтому я начал более глубоко размышлять об этих деталях. Я также читаю книги (и слушаю подкасты), чтобы прояснить свои мысли. Один из моих недавних фаворитов — Team Topologies Мэтью Скелтона и Мануэля Паиса. Эта книга обеспечивает надежную теоретическую основу для структурирования организаций, оставаясь при этом прочно укорененной в реальном мире. Важно отметить, что авторы приводят убедительные доводы в пользу хорошо структурированных команд не из башни из слоновой кости, а из траншей. Это также помогло найти ответы на вопросы, которые у меня были о моем подходе к структуре команды.
Давайте посмотрим на некоторые из них сейчас.
Не каждый член команды должен выполнять одну конкретную функцию
В таких статьях, как Что такое кросс-функциональная команда? я обсуждаю идею вертикальных или доменных команд; то есть команды, сформированные вокруг конкретной бизнес-функции. Правильно сформированные команды представляют собой то, что мы называем кросс-функциональными командами. То есть они состоят из людей, выполняющих любые технические функции, необходимые для достижения бизнес-задачи цели.
В таких случаях я часто включаю диаграмму, подобную этой:
На этой диаграмме команды представлены вертикальными группами (Оплата, Оплата и Поиск). Таким образом, технические функции представлены горизонтальными группами (Графический дизайн, Внешняя инженерия и т. д.). Это говорит о том, что каждый член команды выполняет одну из этих функций. Другими словами, если для проекта требуется фронтенд-инжиниринг (например, кто-то с опытом работы с React), бэкенд-инжиниринг (например, программист на Java) и инжиниринг данных (например, кто-то, умеющий работать с Beam), тогда команде потребуется три человека. отдельные люди: по одному на функцию.
Я работал с командами, где это действительно имело место, особенно в организациях с жесткими функциональными границами. Но во многих случаях такой подход не имеет смысла. Во-первых, некоторые организации могут допускать большую гибкость между ролями. Один инженер может легко владеть и React, и Java (и Beam, если уж на то пошло). В такой организации может быть выгодно, чтобы отдельные лица играли несколько ролей. У нашей команды может быть веб-приложение, тесно связанное с серверной службой. В таком случае может быть выгодно, чтобы один инженер отвечал за оба.
Существует также предел идеального размера вертикальной команды. Это часто выражается как каноническая команда двух пицц Amazon, что обычно означает не более семи-девяти членов команды. Если команде требуется, скажем, от десяти до двенадцати различных функциональных ролей, то это означает, что в команде больше ролей, чем у нас есть слотов для заполнения. Кто-то должен будет удвоить.
Именно на это обращает внимание Team Topologies. Скелтон и Паис советуют не навязывать каждому члену команды одну роль. Вместо этого отдельные команды могут состоять из «универсалов и нескольких специалистов».
Вертикальные команды должны быть постоянными
В некоторых из моих предыдущих статей я обсуждал долголетие межфункциональных команд, ориентированных на предметную область. Есть два основных варианта:
- Эфемерный: периодически формируются команды для достижения определенной цели. Например, может потребоваться разработка новой функции для клиентов. Сотрудники необходимых функциональных областей стягиваются в команду, задачей которой является проектирование и создание этой функции. После завершения проекта команда фактически расформировывается, а участники впоследствии присоединяются к другим командам.
- Постоянные. Команды формируются один раз с целью владения определенной областью бизнеса. Эта команда не только проектирует и создает все артефакты, связанные с этой областью бизнеса. Затем команда остается вместе, чтобы поддерживать, улучшать (и, когда это уместно, устареть) свои артефакты.
Раньше я немного колебался на эту тему. Я всегда рекомендовал, когда это возможно, стремиться ко второму варианту. Мы должны предпочесть, чтобы наши кросс-функциональные команды жили вечно. Но если это невыполнимо или мы встречаем сопротивление, то недолговечные кросс-функциональные команды лучше, чем отсутствие кросс-функциональных команд.
Хватит болтать.
Наши кросс-функциональные команды должны быть постоянными. Они должны владеть своими соответствующими бизнес-доменами в долгосрочной перспективе.
Почему?
Это не команды тигров
Не так давно я обсуждал идею кросс-функциональных команд с коллегой. И назвал их командами тигров. Это сразу же показалось мне неправильным взглядом на эти команды. Команды тигров, безусловно, полезная концепция. Но их цель совершенно иная, чем у команд, ориентированных на предметную область. Они существуют для того, чтобы решить конкретную проблему как можно быстрее. Как только проблема решена, команда немедленно расформировывается.
Это заставило меня задуматься о командах, ориентированных на предметную область, в новом свете, отчетливо контрастирующем с командами тигров. Команды должны быть недолговечными, только если их целью действительно является решение одной проблемы. Но это не характерно для предметно-ориентированных команд. Поддержка бизнес-домена почти никогда не требует выполнения только одной задачи. Вместо этого включает в себя создание, поддержку и развитие многочисленных артефактов (программного обеспечения и прочего). Это включает в себя изучение и становление экспертами в самой области. Ничего из этого не может произойти с эфемерными командами.
Команды, ориентированные на поток
В «Командных топологиях» Скелтон и Паис используют интересный термин для того, что я назвал «вертикальными» или «ориентированными на предметную область бизнеса» командами. Вместо этого они называют их «потоковыми» командами.
Неудивительно, что они очень тщательно выбирали этот термин. Они явно избегают других общих названий, таких как «группа продукта» или «команда разработки». Во-первых, эти термины могут быть слишком узкими и применимыми не ко всем типам организаций. Некоторые организации могут вообще не иметь представления о продукте. Более того, они не отражают природу того, для чего предназначен этот тип команды.
Напротив, заявление о том, что команда связана с «потоком», подразумевает, что существует постоянный поток работы, с которым команда должна справиться. Работа в этом потоке может включать в себя что-то вроде:
- Запросы функций от клиентов
- Отчеты об ошибках
- Создание нового функционала
- Обработка новых требований соответствия
Другими словами, для команд, занимающихся определенной сферой бизнеса, не существует момента времени, когда команда «завершает» свою работу. Для таких вертикально ориентированных команд нет большого смысла формироваться для решения конкретной задачи, а затем расформировываться.
Доверие и опыт
Команды работают более эффективно, когда их члены доверяют друг другу. В этом контексте доверие относится не только к ощущению психологической безопасности. Это также относится к созданию общего понимания проблемного пространства (это похоже на вездесущий язык в терминах Дизайн доменного диска).
Конечно, командам нужно время, чтобы развить это доверие. Точно так же, учитывая достаточно сложную область, отдельным членам команды потребуется время, чтобы набраться опыта. Будут концепции, присущие предметной области, и члены команды смогут по-настоящему понять их только на собственном опыте. Команда может даже вывести новые концепции.
Имея все это в виду, чем дольше команда остается вместе, тем лучше она может работать. Эфемерные команды на самом деле лишь поверхностно раскрывают свой потенциал.
Говорим ли мы, что устоявшиеся команды никогда не могут измениться?
В этот момент мы можем задаться вопросом, не является ли эта позиция слишком жесткой. Ведь, как говорится, единственная постоянная в жизни — это перемены. Реальность такова, что со временем нам может понадобиться изменить структуру наших команд. Как нам сделать это, не нарушая преимущества, которые мы получили от постоянных команд?
Во-первых, давайте рассмотрим некоторые причины, по которым нашим командам может потребоваться измениться. Например, мы можем обнаружить, что одна из наших команд стала слишком большой. Как мы обсуждали ранее, нам обычно требуется не более семи-девяти участников в одной команде. Если команда разрослась до такого размера, то ее члены рискуют потерять доверие и сплоченность, которые они построили. Когнитивная нагрузка команды также, вероятно, вырастет до большой. Более того, это, вероятно, признак того, что команда взяла на себя слишком большой размах. На этом этапе нам может понадобиться разделить команду на две отдельные команды.
Мы также можем испытать фундаментальные сдвиги в бизнесе. Например, направление бизнеса может закрыться. В этом случае смысл существования этой команды перестает быть. Если у команды больше нет поступающей работы, ее, возможно, придется распустить, а ее членов перевести в другое место. В качестве альтернативы может быть запущено новое направление бизнеса, и в этом случае нам может потребоваться переманить членов из других команд (или, возможно, нанять новых людей для укомплектования новой команды).
Однако есть много причин, которые не являются оправданием для перетасовки наших команд. Одним из наиболее распространенных является изменение структуры отчетности. Частые смены руководства, конечно, сами по себе разрушительны. Но когда они приводят к реструктуризации вертикальных команд, они служат серьезным препятствием для повышения производительности. Я сосредоточусь на этом понятии — что структуры отчетности не должны приравниваться к вертикальной структуре команды — в следующей статье.
Так что, конечно, мы можем быть вынуждены — при случае — изменить структуру наших вертикальных команд. Но делать это следует редко и только в тех случаях, когда:
- нам нужно сделать это, чтобы сохранить доверие команды, управление когнитивной нагрузкой и производительность (как в случае слишком большой команды)
- у нас нет выбора из-за фундаментальных изменений в бизнесе
Мы не должны вносить произвольные изменения в наши команды только потому, что изменения происходят где-то еще в нашей организации.
Межкомандное взаимодействие должно определяться контекстом
Я всегда считал, что инженерные организации должны стремиться свести к минимуму взаимодействие между командами. Например, в статье Всегда ли совместная работа — это хорошо?» я утверждаю, что то, что обычно называют сотрудничеством между командами, на самом деле часто представляет собой ряд вредных зависимостей, которые подавляют производительность.
При этом трудно отрицать, что командам действительно иногда нужно работать вместе. Как же нам примирить эту реальную потребность команд во взаимодействии с реальностью, согласно которой усиление межкомандного взаимодействия часто снижает производительность?
Здесь снова Скелтон и Паис ясно представляют некоторых жильцов, которые отражают то, что я сам осознавал. Во-первых, не существует единой неоднозначной корзины, определяющей все взаимодействия в команде. Вместо этого есть несколько ключевых режимов взаимодействия. И эти режимы могут быть полезными или вредными, в зависимости от того, как они используются.
Возможно, самый простой для понимания режим — это X-as-a-service. Допустим, в нашей организации есть команда платформы. Эта команда создает инструменты, помогающие нашим вертикальным командам выполнять свою работу. Такие инструменты могут включать
- конвейер обмена сообщениями, позволяющий передавать сообщения между командами.
- инструменты, которые помогают команде легко развертывать свои услуги у поставщика облачных услуг.
Я узнал, что лучший способ для этого — автоматизация или самообслуживание. Другими словами, вертикальным командам не нужно полагаться на членов команды платформы, чтобы они выполняли работу за них; скорее, команда платформы должна создавать свои инструменты таким образом, чтобы вертикальные группы могли использовать их напрямую. Таким образом, они не будут заблокированы собственной невыполненной работой команды платформы.
Другой способ взаимодействия — фасилитирование. Предположим теперь, что наша организация использует определенную структуру или методологию. Наша организация может сформировать команду, все члены которой являются экспертами в этой структуре/методологии (которую Скелтон и Паис называют командой поддержки). себя в данной вертикальной команде. Они будут обучать эту команду фреймворку/методологии до тех пор, пока она не приобретет необходимое понимание и опыт. Типичный пример, который я видел, — Agile Coaches. Организация может сформировать такую поддерживающую команду, каждый член которой работает с одной или вертикальными командами, чтобы помочь им внедрить и применять гибкие методы.
Наконец, мы подошли к самому сотрудничеству. Обычно я путаю сотрудничество с более общим термином взаимодействие. Более того, я утверждаю, что сотрудничество/взаимодействие следует свести к минимуму, где это возможно. Однако Скелтон и Паис отмечают, что совместная работа является полезным способом взаимодействия при правильном использовании. В частности, совместная работа выгодна, когда командам нужно собраться вместе, чтобы исследовать или изобрести что-то новое.
Конечно, если две команды объединятся, то получится команда примерно в два раза больше, чем обычная команда. Таким образом, они будут отказываться от преимуществ меньшей команды, таких как:
- Повышение доверия между членами команды
- Возможность для любого члена команды полностью понять проблемное пространство
и обменивать их на:
- Снижение доверия и знакомства между членами команды
- Повышенная когнитивная нагрузка
По этой причине сотрудничество между командами должно быть временным — с четкой конечной целью — и должно осуществляться только с полным осознанием компромиссов. Как только цель достигнута, команды должны снова разделиться для выполнения своей работы.
Последние мысли
Полезно разрабатывать теории и лучшие практики, которые помогут нам продуктивно работать. К сожалению, реальность иногда противоречит передовой практике. Когда это происходит, нам нужно сделать паузу, чтобы уточнить или изменить наши теории.
Это то, что эта статья стремилась сделать. В частности, он предложил разъяснение передовой практики автономных вертикальных команд в следующих областях:
- Функция члена команды: вместо того, чтобы каждый член команды выполнял одну функцию в команде, нам часто нужно или хочется, чтобы отдельные члены выполняли более одной роли.
- Постоянство команды: мы не должны формировать наши команды с целью их расформирования в будущем. Вместо этого мы должны формировать команды на долгосрочную перспективу, редко их модифицируя.
- Режимы взаимодействия. Хотя мы хотим избежать взаимозависимостей между командами, существуют здоровые режимы взаимодействия, которые могут возникать между командами разных типов.
Находите эту историю полезной? Хотите узнать больше? Просто подпишитесь здесь, чтобы получать мои последние истории прямо на ваш почтовый ящик.
Вы также можете поддержать меня и мое творчество — и получить доступ к неограниченному количеству историй — став участником Medium сегодня.
Подпишитесь на DDIntel Здесь.
Посетите наш сайт здесь: https://www.datadriveninvestor.com
Присоединяйтесь к нашей сети здесь: https://datadriveninvestor.com/collaborate
