Dobry PM jest cenny. Ale bywa różnie z "dobrością", czasami w niektórych miejscach na PM ściąga się ludzi z zewnątrz, mających w historii zatrudnienia, że od lat są PM, a to od sprzedaży kartofli, a to od butów, od kredytów i nagle zostają PM od IT, gdyż przecież tyle PM-owali, więc pewnie wiedzą jak PM-ować... Zwykle takie coś kończy się katastrofą. A OP nie ma szczęścia.
Przedstawiam Wam owoc moich wieloletnich prac socjologicznych - algorytm dobrego PM (czyli takiego, jak np. moja skromna osoba :) ).
(oczywiście są pewne uproszczenia, charakter jest też ważny)
Nie uważam, że można być PM bez backgroundu (albo - można, ale wtedy najlepiej się nie odzywać i nie przeszkadzać, z nadzieją licząc, że zespół pod nim jest dobry i sam się zorganizuje). Najczęściej dezorganizuje to pracę, bo osobnik nie rozumie co jest robione po co, nie zareaguje, gdy dzieje się źle, bo nie wie kiedy dzieje się źle, poza sytuacją, gdy ugryzie go w tyłek deadline lub kopnie góra; a programiści nie są od tłumaczenia.
Wiedza przydaje się, aby wyczuć, gdy zespół zaczyna mieszać się w zeznaniach. PM bez wiedzy, gdy usłyszy Docker, albo nie daj boże Kubernetes, robi takie mądre oczy jak sznaucerek i tylko przytakuje, a PM z wiedzą konkretnie się wypyta - co jest zrobione, czy stoi, czy dopiero jest stawiane, rozumie które klocki są od czego i oceni jaki etap, przesunie ludzi w razie potrzeby, gdy gdzieś się zrobił zator. I nie musi szukać w Google, że AWS to już nie jest Akcja Wyborcza Solidarność :D Nie musi zaraz wnikać co jest czym zrobione i jak, ale powinien rozumieć duże klocki, ich zależność, złożoność i znaczenie dla postępów. Sporadycznie ratować sytuację może jeszcze dobra komunikacja na linii zespół<->PM, ale i tak uważam, że PM bez wiedzy jest jak dziecko we mgle.
