командная работа
February 18, 2019

Микроменеджмент и мотивация

Знаешь ли ты что микроменеджмент — это плохо? Кроме того, что это неэффективное расхдование времени и сил такого менеджера, это ещё и ужасно негативно сказывается на членах команды.

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

Однако, через некоторое время его проверки и тотальный контроль превращались в какую-то нездоровую манию.

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

Негативное влияние на команду

Тут надо понять, что в человеке всегда борятся две крайности. С одной стороны хочется брать на себя ответственность, для повышения своего "веса" в группе. Это по-сути и есть причина профессионального роста. Больше берешь на себя, ответственнее задачи, которые ты решаешь — качественнее рост, как специалиста. Другая сторона медали: желание идти по пути наименьшего сопротивления и боязнь и нежелание лишней ответственности.

На такую почву очень хорошо ложатся семена недоверия от тим-лида. Если твои ревью перепроверяют, то зачем ответственно подходить к ним? Во-первых, тебе не доверяют и нет смысла вкладываться в ревью. А во-вторых, ошибки, которые найдут после тебя, будут найденны тим-лидом до выхода в продакшн. То есть и от ответственности тебя избавляют. Не красота ли?

Рост очереди ревью.

Кстати, в команде не было механизма автоматического выбора ревьюера, а значит пулл-реквесты просто публиковались в общем канале в Слаке. И уже оттуда волонтёр брал себе PR на ревью. Обычно люди старались брать интересные им реквесты: либо те, что затрагивают "их" зону ответственности, либо те, что про интересные им фичи системы. Обрати внимание, в обоих случаях инженер был мотивирован на проведение хорошего ревью.

Что же произошло потом? Народ перестал брать реквесты на ревью. Ведь тим-лид и так пойдёт и просмотрит их. Зачем утруждаться?

Таким образом, среднее время ожидания пулл-реквеста повысилось, а у тим-лида начал образовываться завал. Ему постоянно приходилось пинать разработчиков и просить их провести ревью.

Поверхностные ревью.

Даже если инженер и брал код на ревью, он проводил его достаточно поверхностно, ведь он привык к тому, что его работу перепроверят после. Так мы получали бестолковые замечания в духе "переименуй эту переменную". Как-бы работа была проведена, замечание сделано. А толку от этого — ноль!

Отсутствие тестирования.

Самый опасный момент. Снизилось качество работы. Команда перестала хорошо и внимательно тестировать код перед публикацией PR.

Оно и понятно — зачем утруждаться, если всё равно придётся вносить правки (см предыдущий пункт). Как правило инженер не знает, какие правки придётся вносить. Велика вероятность того, что запросят изменение, которое приведёт к необходимости перетестировать всё заново.

Конечно, писались тесты, но именно на локальную верификацию фичи стали забивать. Оно и логично, тим-лид вскоре перепроверит.

Падение понимания работы системы.

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

Зачем? Ведь тим-лид проверит всю работу на соответствие реалиям бизнеса.

До этого ответственность лежала на плечах инженера, а значит он не только убеждался в корректности (проходит тесты) своего кода, но и вникал в суть и в бизнес-требования (делает ли код то, что действительно нужно и можно делать?).

В итоге вся команда, продукт и тим-лид страдали. Выбраться из такой ямы очень и очень трудно. Проще в неё не залезать.

Дополнительным бонусом стала пропажа инициативы со стороны инженеров. Они перестали ощущать ответственность за систему, перестали понимать принципы её работы (не детали, а именно общую картину), и таким образом пропала любая инициатива снизу. Трудно улучшать продукт на который тебе наплевать.

А ты встречал подобные деструктивные результаты от микроменеджмента?

Посты на эти и другие темы публикую в канале: https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Напоминаю, что мне можно задать вопрос или предложить свою тему для нового поста через форму обратной связи: https://goo.gl/forms/1G2206MfVzfoowHf2

Подписывайтесь и рассказывайте друзьям.

МS.