Comments 4
А как-же классика жанра - микроменеджмент?
Вы, как важный и ответственный начальник, должны постоянно держать руку на пульсе разработки! Собственно главная ваша функция в проекте - это постоянный пинг разработчиков с вопросами плана - Ну как там дела с багом/фичей? Долго еще делать? Сколько там осталось? Почему так долго? Идеально, когда каждый разработчик видит вашу вовлеченность в проект и понимает особую важность задачи, поэтому он должен минимум раз в полчаса отвечать на запрос руководителя, иначе вы тряпка, а не руководитель, и никакого авторитета у вас не будет!
Это самая злая классика жанра. И текст отличный, спасибо :)
Кстати, напомнило старый мем про рыбу и дайвера, который разбивает моллюска молотком: https://memepedia.ru/ryba-s-bolshoj-golovoj-smotrit-na-dajvera/#post-gallery-45e46c_0.
Больно читать от обилия сленга
У нас строго блюдут безумные цепочки согласований, раньше тоже надо было распечатывать любое ТЗ или правки к нему и ходить по отделам собирать подписи. И не важно, что замечаний по электронному варианту могло и не быть, но как только появлялся бумажный экземпляр в ход шли правки ручкой, которые потом переносились в электронный документ и так по кругу. Насколько я знаю, у моего коллеги один из согласующих так правил док 9 раз, каждый раз после внесения своих же правок. Сейчас согласовывал док с 13 подписями... Благо теперь это в электронном виде и не надо ходить на поклон.
Еще нравится, когда через боль и страдания согласованное решение через время объявляют неправильным и удивляются, как такое вообще могли подписать и накидывают под конец разработки к поддержке еще парочку крайне нужных фишек, хотя в момент обсуждения яро отстаивалось наличие сугубо 1 и никак не более.
В целом все из перечисленных пунктов в той или иной степени есть.
Как сломать взаимодействие продуктовой команды: 5 вредных советов и антикейсов