Перевод статьи «Symptoms of a dysfunctional team».
Я сменил много мест работы (с 2012 года – восемь), а значит, и много команд. Одной из причин частой смены работы был тот факт, что многие из команд, к которым я присоединялся, оказывались чрезвычайно дисфункциональными. В этих командах было сложно завершать работу, а также не было четкого понимания целей.
Когда вы еще на старте своей карьеры, сложно понять, правильно ли функционирует ваша команда. Однако, есть некоторые симптомы-индикаторы больших проблем культурного или технического характера, которые в итоге могут приводить к дисфункциональности.
Сверхурочная работа подразумевается сама собой
Самый заметный индикатор проблем – вы регулярно работаете больше 40 часов в неделю, хотя платят вам только за 40. Сфера разработки известна своей культурой сверхурочных работ и профессиональным выгоранием.
Переработка означает, что слишком много работы планируется на слишком маленький промежуток времени. Общеизвестно, что сверхурочная работа плохо сказывается на продуктивности. Исследования, проведенные в 2004 году, позволили получить четкие цифры падения производительности.
Короткие периоды «авралов» (1-2 недели работы по 50 часов вместо 40) имеют потенциальные преимущества, но в остальных случаях спад производительности перевешивает пользу от дополнительной работы. Именно так: люди, работающие больше 60 часов в неделю, добиваются меньших результатов, чем люди, работающие по 40 часов.
Долгие циклы обратной связи
Одна из самых больших утечек продуктивности связана с долгими циклами обратной связи. Когда вы меняете строку кода, сколько времени проходит, прежде чем вы сможете сказать, что код работает? Благодаря современным инструментам и языкам время этого цикла может измеряться десятками секунд, если не меньше. Но это может зависеть от сферы, в которой вы заняты.
Маленькие промежутки времени, которые тратятся на выполнение рутинных задач, в итоге накапливаются. Особенно, если эти задачи выполняются часто.
Например, если на запуск сборки уходит некоторое количество минут, подумайте о том, сколько часов длится простой команды в целом.
Но помимо случаев сборки есть и другие, где оптимизация зависит от разработчика. Если на переходы по UI или ввод данных уходит каждый раз по 10 секунд, то в масштабах нескольких недель разработки потери могут измеряться уже часами. Изменив код таким образом, чтобы устранить некоторые этапы ручного труда, вы заметно увеличите скорость вашей работы в целом.
Что касается времени на сборку, тут все зависит от того, насколько хорошо ваша команда владеет нужными инструментами.
Недостаток опыта в использовании инструментов
Если инструмент неправильно настроен, используется без оптимизации или вообще предназначен для других задач, чем те, которые решает ваша команда, самым заметным индикатором этого всего будет длительный цикл обратной связи.
Время, которое уходит на сборку (как при разработке, так и при деплойменте), а также время, необходимое для настройки локальной среды разработки, являются отличными показателями общего уровня знаний вашей команды, а также опыта в использовании инструментов.
Одной из распространенных причин недостатка опыта в работе с инструментами является погоня за трендами вместо решения проблем по мере их возникновения. За это часто критикуют фронтенд-разработчиков, но я наблюдал такое и в бэкенде: все эти большие данные, serverless, ИИ, Docker, микросервисы. Все они являются полезными, инновационными инструментами, но использование новейших инструментов, в которых не разбираешься, гораздо хуже, чем использование более простой, но при этом более знакомой инфраструктуры.
Если вы сами не понимаете какой-то инструмент, вам будет сложно сказать, разбирается ли в нем остальная команда. Однако вы можете поговорить с коллегами и попытаться выяснить, какие задачи он должен решать. У команды должен быть четкий ответ на вопрос, почему используется именно этот инструмент, почему он был выбран среди других.
Также может случиться, что у вас просто нет тех проблем, для решения которых создан определенный инструмент. Узнать об этом можно, поговорив с людьми вне команды, например, на конференциях, митапах или онлайн.
Плохо настроенные инструменты могут служить одной из причин другого распространенного синдрома дисфункциональности – простоев.
Частые простои
Простои должны быть редким явлением, которое случается только в результате какого-то постороннего события или стечения обстоятельств. В здоровой среде простои анализируются. Затем, чтобы избежать таких случаев в дальнейшем, на основе этого анализа вносятся изменения в процедуры или инфраструктуру.
Однако для эффективного анализа нужно глубокое понимание того, что пошло не так и какие изменения можно внести. Поверхностное знание инструментов помешает все это сделать. Если проблема простоя решается путем «выключить и включить», возможность для обучения обычно утрачивается.
В целом, простои могут иметь разные причины. Это могут быть проблемы производительности или сбои в деплойменте. Если у вашей команды длительный рабочий цикл, устранение мелких багов в конце каждого модуля работ может занимать длительное время. Все эти баги накапливаются и в конечном итоге приводят к сбоям в продакшене или неправильному деплойменту. Хуже того, те же проблемы могут помешать вам поднять сервис и запустить его снова.
Это замкнутый круг, и компании, которые не могут решить фундаментальные проблемы, лежащие в основе ситуации, в конечном итоге могут оказаться на грани краха.
Чрезмерно жесткие процедуры
По мере накопления опыта и продвижения по карьерной лестнице вам будет нужна все большая гибкость для завершения работ. Вам никогда не удастся в совершенстве расставить приоритеты, вы всегда будете находить проблемы в коде, с которым работаете. А такие невидимые концепции как производительность, поддерживаемость и вспомогательная инфраструктура редко бывают в приоритетах менеджера продукта. Для уравновешивания ситуации в хорошо управляемых компаниях обычно есть позиции руководителей-инженеров, но часто все это ложится на плечи обычных разработчиков.
Ограничения в процедурах могут стать рефлекторной реакцией на повторяющиеся задержки поставки функционала (которые часто случаются из-за длительных циклов разработки) или частые простои. Если у разработчиков существует дисбаланс между разработкой функционала и внутренними работами, строгие процедуры могут быть способом дать разработке высший приоритет. Также подобные ограничения могут служить своеобразным «пластырем» для хлипких инструментов сборки: «просто следуйте этой процедуре и все будет хорошо».
Помимо сказанного, чрезмерно жесткие процедуры могут быть симптомом проблем в руководстве.
Лидерство без очевидного участия
Если вы попробуете проанализировать, какую роль в команде играют лидеры, она должна быть очевидной.
Менеджер проекта помогает расставлять приоритеты в задачах, обеспечивает наличие всей информации, необходимой для выполнения этих задач. Техлид заботится о том, чтобы используемые инструменты и процедуры позволяли поставлять код быстро и без ошибок. Продуктовый менеджер следит за тем, чтобы создаваемый продукт отвечал нуждам конечных пользователей.
В зависимости от вашей собственной роли в команде, вам, конечно, может не казаться очевидной роль каждого из этих людей, но все они должны вносить свой вклад в продвижение команды к цели.
Если ни коллеги, ни вышестоящие лица не могут внятно объяснить, чем занимаются отдельные лидеры в команде, эта команда имеет большие проблемы с руководством. Когда люди, ответственные за принятие решений, увиливают от своих обязанностей, процессы и технологии начинают разваливаться. Со временем проект может увязнуть в техническом долге, время людей будет тратиться впустую, а поставляемые фичи могут оказываться бесполезными.
Организационные показатели, не имеющие отношения к конкретным результатам
OKR (Objects and Key Results – цели и ключевые результаты) и KPI (Key Performance Indicators – ключевые показатели эффективности) это уже навязшие на зубах словечки. Они стали популярны после выхода одноименных книг. Идея, стоящая за ними, прекрасна: организации должны быть способны определять, приводят ли застрачиваемые усилия к результату. Однако, если все эти OKR или KPI не имеют отношения к позитивным результатам для команды или организации, они остаются лишь числами, которые используются для микроменеджмента.
К сожалению, вы как рядовой сотрудник вряд ли сможете на это повлиять. Вы даже можете не знать об этих показателях, поскольку они выводятся по результатам за квартал или даже за год.
Что делать при выявлении этих проблем
Все эти проблемы часто встречаются в организациях независимо от их размеров. Причины их могут уходить корнями в культуру компании.
Не существует решения этих проблем, подходящего для все случаев, и уж точно для исправления ситуации недостаточно уметь распознать проблему. Чаще всего бывает необходимо внесение каких-то изменений на уровне менеджеров. Если ваша собственная позиция находится на несколько рангов ниже, вам будет сложно на что-либо повлиять.
Однако нужно иметь в виду, что все эти проблемы в первую очередь сказываются именно на рядовых работниках.
В здоровой компании ответственные лица могут понимать, что что-то идет не так, но не иметь достаточно информации для выявления проблемы. Если это затрагивает вас лично, можете встретиться с менеджером и обсудить это с глазу на глаз.
Если же организация не имеет возможности или желания меняться, это сигнал к тому чтобы освежить свое резюме и начать подыскивать варианты.
Также следует учесть, что проблемы могут существовать не в организации в целом, а в отдельной команде. Поговорите с коллегами из других команд об их опыте. Возможно, они помогут вам решить проблему. Как вариант — возможно, вам удастся перейти в другую команду внутри той же компании.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]