За несколько лет работы я сменил несколько проектов и команд. Стек менялся: где‑то был Kotlin, где‑то классическая Java, где‑то вообще старый монолит на виртуалках.
Но самое сильное различие было не в технологиях.
Всё решали люди, которые руководят разработкой.
За это время я поработал с разными типами руководителей: от токсичного лида, которого боялась вся команда, до менеджера, который жил ради одобрения заказчика, и руководства, способного за пару месяцев развалить нормальный проект.
И самое неожиданное — один из них, при всех своих минусах, оказался для меня полезнее остальных.
В этой статье — три реальных кейса и то, чему они меня научили. И как каждый из руководителей влияет на разработку.
Токсичный лид, которого боялись все
На моём первом проекте у меня был лид, которого боялась вся команда.
Он не повышал голос и не устраивал скандалов, но разговаривал так, что после созвона хотелось закрыть крышку ноутбука. Любое предложение встречалось в штыки, решения не обсуждались, а попытка поспорить быстро заканчивалась тем, что ты оказывался «неправ».
Я попал на этот проект без опыта, но меня продали как мидла(рассказал об этом тут). Уже на первом созвоне я почувствовал холодный, отстранённый тон. Тогда я подумал, что, возможно, просто накручиваю себя.
Но довольно быстро стало понятно — нет, не показалось.
На дейликах нужно было подробно объяснять, чем ты занимался по часам. Любое обобщение сразу превращалось в уточняющие вопросы, после которых разговор уходил в детали, не всегда относящиеся к задаче.
Если у него что‑то спросить, он ответит, но заставит тебя чувствовать полным дураком.
А самая главная проблема была в том, что он не умел объяснять от слова совсем, не я один его вообще не понимал. Разговаривал и с аналитиками и с другими разрабами:
«А почему вы молчите? Почему ничего с этим не делаете?»
Ответ был у всех такой:
«Мы пытались, работаем с ним уже 3 года, ничего не помогает»
Тогда я был еще очень наивным и думал, что если захотеть, то точно сможем все поменять.
Но конечно, поменять отношение взрослого человека — очень тяжело, а порой и невозможно.
Душные созвоны, у него будто было следующее кредо:
«Если в мр нет замечаний, значит и аппрува нет»
В какой‑то момент количество итераций по одному MR стало критическим — задача возвращалась с новыми правками каждый раз, без чёткой фиксации, что именно нужно изменить.
Звонок:
«ПОЧЕМУ ТЫ МЕНЯ НЕ ПОНИМАЕШЬ, Я ЖЕ ВСЕ ПОНЯТНО ОБЪЯСНЯЮ, ЧТО С ТОБОЙ НЕ ТАК»
Я уже на нервах. Завтра у меня отпуск, а он не дает спокойной уйти:
«Так ты может сначала сам решишь, что ты хочешь, я уже переделываю все по 10 раз, мне это надоело уже»
В какой‑то момент он неожиданно остановил диалог и сказал:
«Сделай как считаешь нужным и закроем задачу»
Это был первый момент, когда я почувствовал, что могу не только подстраиваться, но и отстаивать своё решение.
Я проработал с этим лидом полтора года. Работать с ним было тяжело, и в моменте это скорее выматывало, чем помогало.
Но со временем я заметил, что начал меняться. Я перестал автоматически соглашаться, научился отстаивать свою позицию и аргументировать решения.
Его жёсткое ревью, которое тогда казалось избыточным, в итоге дало мне навык внимательно разбирать чужой код и задавать правильные вопросы. Позже я использовал это уже на других проектах.
Оглядываясь назад, я не могу сказать, что это был комфортный опыт. Но он оказался очень полезным.
Тогда мне казалось, что это самый сложный тип руководства, с которым можно столкнуться. Но следующий проект показал, что проблема может быть не в человеке, а в подходе.
Руководитель проекта, который ставит заказчика в приоритет
После ухода с первого проекта я чувствовал себя увереннее: казалось, что после сложного лида меня уже сложно чем‑то удивить.
Я попал на небольшой проект с понятными процессами: спринты, задачи, спокойный темп. Руководитель проекта казался адекватным — открытый, доброжелательный, без давления. Первое время всё действительно работало нормально.
Но постепенно в спринтах начали появляться «дополнительные» задачи. Сначала это выглядело безобидно — что‑то срочное, что‑то важное. Мы брали их в работу, не придавая особого значения.
Через некоторое время это стало системой. Любая новая просьба от заказчика сразу попадала в спринт, независимо от приоритета. Даже если команда уже была загружена, задачи просто добавлялись сверху.
на вопрос:
«Зачем мы это берём?»
«Заказчик попросил — значит, делаем»
В какой‑то момент мы начали постоянно переключаться между задачами: откладывать важные баги, бросать начатую работу и срочно делать то, что «нужно сейчас». При этом сроки по этим же задачам озвучивались заказчику заранее — иногда за день до дедлайна мы узнавали, что «обещали сделать к завтра».
Команда пыталась донести, что так работать невозможно: мы теряем фокус, не успеваем закрывать задачи и начинаем накапливать технический долг. Но это не влияло на ситуацию.
В какой‑то момент я решил проговорить это напрямую.
Он объяснил свою позицию просто:
«Если заказчик просит — мы делаем»
Я попытался возразить, что проблема не в самих задачах, а в их количестве и приоритетах: когда мы берём всё подряд, страдают и сроки, и качество.
Но этот аргумент не был принят — подход оставался тем же.
В итоге работа превратилась в постоянные переключения и горящие сроки.
Причина была не в сложности задач, а в подходе: приоритеты определялись не внутри команды, а внешними ожиданиями, которые менялись каждый день.
Со временем это привело к ожидаемым последствиям — снижению мотивации и выгоранию команды. Через пять месяцев я понял, что в такой системе не смогу работать эффективно, и принял решение уйти.
Насколько я знаю, после моего ухода команда практически полностью сменилась в течение нескольких месяцев.
В этом кейсе я впервые увидел, как попытка угодить заказчику может разрушить разработку. И в такой системе никакой опыт или мотивация уже не спасают.
После этого опыта стало понятно: когда ломаются процессы, работать становится тяжело. Но я ещё не знал, что бывает ситуация, когда ломается не процесс — а вся система управления.
Неуверенный руководитель проекта и предвзятое руководство
После ухода с предыдущего проекта я попал в команду, где всё работало так, как и должно работать.
Понятные процессы, адекватные сроки, современный стек. Тимлид держал баланс внутри команды, руководитель проекта — снаружи, не давая внешним требованиям ломать спринты.
Работа шла спокойно и предсказуемо: мы успевали делать задачи, закрывать баги и при этом не работать в режиме постоянного аврала. Это был первый проект, где я почувствовал, что процесс действительно выстроен.
Но в какой‑то момент объявили, что проект вместе с частью команды передают в другой департамент.
Это выглядело как обычная организационная перестановка. Тогда я ещё не знал, что именно с этого момента всё начнёт меняться.
После расформирования команды на бэке нас осталось двое. Само по себе это не выглядело критичным — объём работы был понятен, а проект уже был в активной фазе разработки.
Спустя неделю после перехода мой коллега по бэкенду написал заявление об увольнении. Это означало, что через две недели я останусь один на проекте.
Я сразу начал поднимать этот вопрос: объём задач был большим, и в одиночку поддерживать разработку было нереалистично. Руководитель проекта отвечал:
«Решу этот вопрос»
Через две недели коллега ушёл, и я действительно остался один.
С этого момента каждый дейлик сводился к одному и тому же: я говорил, что не справляюсь с объёмом задач и что проекту нужен как минимум ещё один разработчик. Ответы не менялись:
«Я все решу, в процессе».
Так продолжалось два месяца.
Со временем начали проявляться последствия. Качество кода снижалось, количество багов росло — задачи приходилось закрывать быстро, без возможности нормально прорабатывать решения.
При этом руководитель проекта не брал на себя ответственность за происходящее. Любая проблема в итоге сводилась к тому, что «команда не справляется».
Попытки обсудить ситуацию не давали результата: вопросы переадресовывались другим участникам команды, решения откладывались или вовсе не принимались.
В какой‑то момент это дошло до абсурда — меня, как единственного разработчика на бэкенде, начали подключать к созвонам с заказчиком и пользователями, чтобы я сам объяснял происходящее.
Это выглядело странно: вместо того чтобы выстраивать коммуникацию через руководителя или поддержку, ответственность фактически перекладывалась на разработчика.
Несмотря на сокращение команды, объём задач остался прежним. Новых людей нам не добавили, кроме одного разработчика спустя 2 месяца, но ожидания по срокам не изменились.
Через некоторое время высшее руководство решило, что проблема в исполнении, и взяло управление проектом на себя.
При этом у них не было погружения в проект: решения принимались быстро, без учёта текущего состояния системы и уже выполненной работы. Сроки озвучивались жёсткие и часто нереалистичные, что привело к регулярным переработкам, включая работу в выходные.
В результате команда всё чаще занималась переделками: задачи возвращались с новыми вводными, бОльшая часть работы оказывалась лишней, а общий прогресс замедлялся.
Обстановка постепенно ухудшалась — вместо стабильной разработки появился хаотичный процесс, в котором сложно было доводить задачи до конца.
Со временем стало заметно ещё одно — отношение к команде. На общих созвонах и при взаимодействии с другими командами было видно, что к новым участникам относятся иначе. Их предложения обсуждались, к их словам прислушивались. В то время как к нам, перешедшим из другого департамента, отношение было заметно холоднее. Это не было явно проговорено, но ощущалось на уровне коммуникации.
Я продолжал работать в таком режиме, пока не произошёл один случай.
Вечером в рабочем чате обсуждали хотфикс — команда не могла разобраться с багом. Я посмотрел описание и понял, что, скорее всего, знаю, где проблема: этот функционал писал я.
Я написал в чат, что могу помочь. Сообщение увидели, возражений не было.
В итоге я подключился после рабочего дня, потратил несколько часов, нашёл причину и вместе с тестировщиком проверил исправление. Хотфикс был готов, а мы радостные пошли спать.
На следующий день на дейлике меня публично раскритиковали за то, что я «отвлёкся от своих задач и этот хотфикс был НЕСРОЧНЫЙ».
Я попытался объяснить, что это был хотфикс и что я заранее написал в чат о помощи. Но это не изменило реакции — мне указали на неуважение к руководству и нарушение приоритетов.
В этот момент стало очевидно: в этой системе инициатива не только не поощряется, но и может обернуться проблемой.
Это стало для меня точкой, после которой я принял решение искать новую работу.
Показательно, что после моего ухода на проект довольно быстро нашли замену — ресурсы, которых «не было», внезапно появились.
Итог
За несколько лет я поработал с разными типами руководителей — от жёсткого лида до менеджмента, который полностью ломал процессы.
И главный вывод, к которому я пришёл: не все сложные руководители одинаково вредны.
Токсичный лид, с которым было тяжело работать, в итоге дал мне больше, чем казалось тогда. Я научился отстаивать свою позицию, аргументировать решения и внимательнее относиться к коду. Это был некомфортный, но развивающий опыт.
В то же время управленческие ошибки на уровне проекта и выше оказываются куда разрушительнее. Попытка угодить заказчику любой ценой приводит к потере приоритетов, постоянным переключениям и выгоранию команды. А отсутствие ответственности и понимания со стороны руководства превращает разработку в хаотичный процесс, где даже сильная команда не может показывать результат.
И, пожалуй, самый важный вывод — не стоит пытаться «перетерпеть» такие ситуации слишком долго. Опыт можно получить и без постоянного давления и хаоса.
Сейчас я работаю в команде, где процессы предсказуемы, а решения принимаются осознанно. И разница с предыдущими проектами оказалась гораздо больше, чем разница в технологиях.
Потому что в итоге именно люди и подход к управлению определяют, какой будет твоя работа — а не стек или громкость названия проекта.