#мнение
Чистый ПМ - это как безалкогольное пиво

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

У 90% джунов и свитчеров взгляд именно такой: интерфейсы - это продукт, архитектура - это абстракция, а риски - а инраструктура то с чем девопс сам справится, релиз трейн, sdlc и тех эсселенс - ну на это должен быть тимлид

У меня очень много историй про таких товарищей:

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

Вторая
Когда я бегал по всей компании с проектом мгновенного обновления баланса, меня слушали как городского сумасшедшего.
Ну обновляется раз в 10 секунд, клиент дергает ручку, и что? - говорили ПМы.
А ЧТО заключалось в том, что это мешало быстродействию системы в ответ на покупки и совокупно иногда блокировал на секунды интерфейс. Чтобы сделать обновление моментальным, нужно было
- перепахать асинхронный пайплайн,
- навести порядок в ивентах,
- докинуть таймстемпы в топики,
- перестроить работу кафки

Проект больше года длился, буксовал в непонимании, да так и не был доведен полностью до конца

И здесь важно подчеркнуть одну вещь.
Технасмотренность -> это не про ПМ должен быть разработчиком.
Он не пишет код каждый день, не делает ревью, не дебажит прод.
Но ПМ, который не может хотя бы открыть графану и увидеть, что по ручке растут 500-ки, это как водители современных автомобилей на Зикре, которые толком ПДД не знают и припарковаться сами не могут

Делать вид, что понимаешь работу и управляешь ей, потому что процессы правильные описаны в Scrum-гайд и PMBoK-е, Я работаю с геликоптер вью, юноу . и правда управлять два разных подхода

Именно поэтому проджекты с технической насмотренностью всегда лучше:
-> они видят систему, а не тикеты;
-> понимают, как решения влияют на стоимость владения;
-> чувствуют, где ROI, а где красивая хотелка;
-> умеют отличить фичу от риска;
-> способны говорить с инженерами на одном языке;
-> и главное способны действительно коллаборироваться с своими сотрудниками.

P.S. А у тебя было такое, что ПМ уверял там всё нормально, пока инженеры уже собирали аварийный созвон?