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

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

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

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

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

Увы, ситуация такая на нашем рынке встречается довольно часто, особенно с гражданами которые пришли извне ІТ а не выросли из разработчиков/тестировщиков/аналитиков.