Отсутствие доверия, боязнь конфликта и др.

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

  1. Отсутствие доверия
  2. Страх конфликта
  3. Отсутствие приверженности
  4. Уклонение от ответственности
  5. Невнимание к результатам

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

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

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

Отсутствие доверия

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

Когда члены инженерной группы не доверяют друг другу:

  • Члены команды скрывают свои ошибки из-за страха
  • Руководитель группы часто связывается с членами команды, чтобы убедиться, что работа выполняется.
  • Руководитель группы выступает в роли привратника, который просматривает все запросы на слияние, прежде чем код можно будет слить.
  • Члены команды начинают защищать области программного приложения, в которых они работали, и не любят, когда кто-либо прикасается к их коду.

Но когда они доверяют друг другу:

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

Страх конфликта

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

Когда члены инженерной группы боятся конфликта:

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

Но когда конфликт принимается:

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

Отсутствие приверженности

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

Когда члены инженерной группы проявляют отсутствие приверженности:

  • Цели и сроки спринта часто не выполняются
  • Члены команды часто работают не над теми вещами
  • Стандарты качества кода не соблюдаются, и используются ярлыки

Но когда каждый член команды привержен достижению целей команды:

  • Цели и сроки спринта обычно выполняются (иногда с задержкой)
  • Каждый член команды работает над самой важной задачей в любой момент времени
  • Стандарты качества кода согласовываются и соблюдаются (и применяются форматировщиками кода, линтерами и наборами тестов, запускаемыми в конвейерах непрерывной интеграции).

Уклонение от ответственности

Команды разработчиков программного обеспечения должны требовать от каждого члена команды соблюдения стандартов, с которыми они согласились.

Уклонение от ответственности в основном связано со страхом перед конфликтом. Однако важно помнить, что когда мы говорим об ответственности, мы не имеем в виду наказание кого-либо каждый раз, когда он совершает ошибку. Мы также не имеем в виду, что вы должны быть грубыми по этому поводу. Вы можете привлечь кого-то к ответственности, но при этом относиться к нему с уважением.

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

Когда члены инженерной группы избегают ответственности:

  • Важные задачи не выполняются
  • Низкие показатели тянут команду вниз
  • Общая скорость команды снижается
  • Стандарты игнорируются, а качество кода снижается
  • Руководитель группы или менеджер — единственный, кто решает проблему плохой работы или другого плохого поведения.

Но когда члены команды несут ответственность друг за друга:

  • Важные задачи выполнены
  • Низкоэффективным рекомендуется улучшить или двигаться дальше
  • Общая скорость команды увеличивается
  • Стандарты поддерживаются, а качество кода остается высоким
  • Все члены команды чувствуют себя комфортно, возлагая ответственность друг на друга, а не только на руководителя группы.

Невнимание к результатам

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

Когда члены инженерной группы проявляют невнимание к результатам:

  • Цели и сроки спринта часто не выполняются
  • Может быть выполнено много работы, но это может быть неправильная работа или работа с низким уровнем воздействия.
  • Члены команды не проявляют интереса к своей работе или ответственности за нее
  • Кажется, что каждый член команды движется в другом направлении

Но когда члены команды уделяют большое внимание результатам:

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

Заключение

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

Преодолеть пять дисфункций команды разработчиков программного обеспечения невероятно просто в теории, но очень сложно на практике. И это именно то, что нужно, чтобы стать лучше в этом — практика, практика, практика.