Стоит ли менеджеру делать работу за других?

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

Когда вы пытаетесь быть менеджером и разработчиком в одном лице, страдают не только ваши нервные клетки, но и качество всего проекта. Первоначально вас назначили управлять процессом, не так ли? Но если команде приходится регулярно тушить пожары, и на это не хватает рук настолько, что даже менеджер засучив рукава садится за клавиатуру и начинает кодить, это значит, что PM он, скажем прямо, так себе. Сами мы в такой ситуации не были, но знаем менеджеров, которые знают других менеджеров — и вот они так делали. Закончилось все, мягко говоря, не очень.

Почему так бывает?

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

Многозадачность убивает продуктивность

Многозадачность

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

Профессор университета Миннесоты Софи Лерой объясняет это так:
«Для полного переключения на новую задачу необходимо перестать думать о предыдущей. Но результаты показывают, что полностью отключиться от незаконченной задачи очень трудно, и поэтому новую задачу мы делаем хуже».

Итого: за день вы не успеваете выполнять все менеджерские функции, чем  п̶р̶о̶в̶о̶ц̶и̶р̶у̶е̶т̶е̶ г̶̶̶н̶̶̶е̶̶̶в̶̶̶ З̶̶̶е̶̶̶в̶̶̶с̶̶̶а̶̶̶  создаете снежный ком из задач. Не надо так.

Время — деньги

Время — деньги

В сутках по прежнему 24 часа, из них 8-10 рабочих часов. Вы распланировали сроки сложного и большого проекта, набрали команду (или работаете с тем, что осталось от прошлого менеджера / проекта), утвердили scope с заказчиком, который с упоением и надеждой в глазах смотрит на вас, верит в ваш профессионализм и то, что все пройдет быстро и не больно. Насколько быстро пойдет работа, на этом этапе, зависит как раз от РМ-а. Если же менеджер тратит время на то, что не входит в его обязанности, он не выполняет свои настоящие задачи в полной мере и тратит драгоценное время клиента.

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

Много лишнего времени? Проверьте ничего ли не было потеряно и все ли риски учтены.

Делая чужую работу, вы не растете как специалист

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

Члены команды не понимают своей роли в команде

Не на

Этот пункт вытекает из предыдущего. Как бы вам понравилось, если бы во время совещания с клиентом в переговорку вошел QA и сказал, что на самом деле сроки проекта были определены неправильно, и вообще-то его можно выкатить за неделю? Когда вы делаете за людей их работу, они перестают понимать зачем вы их наняли и начинают искать себе более интересное занятие. Одно дело, если это занятие — залипнуть в facebook, хуже, когда они начинают редактировать свое резюме и ставить статус “В активном поиске” уже не в социалочках.

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

Вжух, и доверие исчезает

Вжух, и доверие исчезает

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

Кто будет отвечать за косяки в технической части проекта?

Не на своем месте

Сегодня вы РМ, завтра немного пишете на Java, после обеда поднимаете упавший сервер, а по четвергам заказываете еду на всю команду и проводите ритуальные танцы с бубном.

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

Кто будет отвечать за это и переделывать за вами? Что вы скажете клиенту? Будете говорить о косяке как менеджер или как тот, кто запорол задачу?
А когда вы будете теперь решать управленческие проблемы?
Так много вопросов и так мало ответов.
На самом деле все куда проще: не готов отгребать и переделывать — не берись.

Запомните: если в вашей работе найдут ошибки, а их всегда найдут, при желании, то вы будете виноваты не только в них, но и во всех ошибках проекта, кто бы и когда их ни сделал.

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

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


Автор: Анастасия Столетняя

Говорят на тему “Стоит ли менеджеру делать работу за других?

  1. Руслан

    Хорошая статья! Особенно согласен про косяки, за которые потом нужно будет отвечать. Спасибо за материал)

Оставить комментарий

Ваш e-mail не будет опубликован.