Утром читаю статью Проектный менеджмент в бигтехе (https://habr.com/ru/companies/fuse8/articles/818627/) Статья прикольная, однозначно советую. Можно заглянуть за кулисье того, как ведутся проекты в бигтехах.

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

Но отдельно мне в статье понравился факторный анализ «плохих подходов». Чем понравился? Я тут решил нырнуть в проект одного из опытных менеджеров и выяснил, что он собрал комбо из этих «плохих подходов».

Хочется воскликнуть, ну как же так-то? Ну тут же нет ничего нового, а вы все сидите опытные менеджеры-менеджеров и так косячите?

Однозначного ответа у меня нет 🤷🏻 На самом деле всегда влияют некие внешние и внутренние факторы. Ты хоть 1000 раз можешь знать и уметь правильно, но обстоятельства могут вынуждать тебя делать по другом.

Хз, кто как, я придерживаюсь правила: делай все возможное, в тех обстоятельствах, в которых находишься.

А вот и факторы:

1️⃣ Разработчики не участвуют в оценке задач, на результаты которой команда полагается в ходе спринта. Это часто встречающаяся боль, и, кажется, один из самых простых способов демотивировать разработчиков – вплоть до ухода из компании. А еще так команда подписывается на ложные или недостижимые цели.

2️⃣ Меняющиеся требования при наличии выделенных PM плохо воспринимается разработчиками. В командах, где проекты ведут техлиды, обычно проще справиться с натиском постоянно меняющихся требований. Поэтому подход, при котором руководитель проекта не может оградить команду от изменения требований, респонденты оценивают плохо.

3️⃣ Низкая удовлетворенность процессами при подходе, когда команды не могут изменить неудачный подход к управлению проектами. Об этом говорили респонденты из компаний, где все команды следуют одной и той же методологии. Это пример директивного руководства. Хоть он и работает порой  в областях, не требующих особой креативности, это все же плохой способ создания продуктивных команд разработчиков. Если команды могут менять свои процессы на собственных условиях, удовлетворенность и производительность растут.