-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDeveloper-vs-Project-Manager-001-Wiedza-o-projekcie.html
1 lines (1 loc) · 11.6 KB
/
Developer-vs-Project-Manager-001-Wiedza-o-projekcie.html
1
<!DOCTYPE html> <html lang="pl"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>Developer vs Project Manager 001: Wiedza o projekcie · Rafal Makara</title> <meta property="og:title" content=" Developer vs Project Manager 001: Wiedza o projekcie "> <meta property="twitter:title" content=" Developer vs Project Manager 001: Wiedza o projekcie "> <meta property="og:description" content=" Hi! I am Rafal and I am a generalist. I was an software engineer, project manager, product owner, scrum master, chief digital officer. I know about people, collaboration, project management, software development and business operations. "> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@rafalmakara" /> <meta property="og:image" content="https://rmakara.github.io/assets/20170615_header.jpg" /> <meta name="twitter:image" content="https://rmakara.github.io/assets/20170615_header.jpg" /> <meta name="description" content=" Disclaimer: W serii Developer vs Project Manager opisuję kontrasty dla granicznych położeń tych ról. Zachowuję świadomość istnienia specjalistów posiadając..."> <link rel="icon" href="https://rmakara.github.io//assets/favicon.ico"> <link rel="apple-touch-icon" href="https://rmakara.github.io//assets/apple-touch-icon.png"> <link rel="stylesheet" href="https://rmakara.github.io//assets/core.css"> <link rel="canonical" href="https://rmakara.github.io//Developer-vs-Project-Manager-001-Wiedza-o-projekcie"> <link rel="alternate" type="application/atom+xml" title="Rafal Makara" href="https://rmakara.github.io/feed.xml" /> </head> <body> <aside class="logo"> <a href="https://rmakara.github.io//"> <img src="https://avatars0.githubusercontent.com/u/1880231?v=4" class="logo-avatar"> </a> <span class="logo-prompt code">Back to Home</span> </aside> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <p class="menu"> <br /><br /> <a href="/">EN Articles</a> | <a href="/pl">PL Articles</a> <br /> <a href="/about">About me</a> | <a href="/help">How can I help?</a> | <a href="https://www.linkedin.com/in/rafalmakara/">My LinkedIn Profile</a> </p> <div id="content"> <article> <div class="divider"></div> <div class="center"> <a class="prev" href="/Gynveals-Mission-003-Optymalizacja">Previous article - Gynveal's Mission 003: Optymalizacja</a> </div> <div class="divider"></div> <h1 class="title">Developer vs Project Manager 001: Wiedza o projekcie</h1> <div class="center"> <time class="code">2017-06-15</time> </div> <div class="divider"></div> <blockquote> <p>Disclaimer: W serii Developer vs Project Manager opisuję kontrasty dla granicznych położeń tych ról. Zachowuję świadomość istnienia specjalistów posiadających wiele kompetencji miękkich oraz managerów posługujących się niskopoziomową wiedzą techniczną - te grupy świadomie pomijam.</p> </blockquote> <h1 id="dwa-punkty-widzenia">Dwa punkty widzenia</h1> <p>W swoim życiu pracowałem przez kilka tygodni jako filmowiec, sześć lat jako programista-tester-analityk-manager-architekt, trzy lata prowadziłem mini-3-osobową-firmę importującą towary z Chin i aktualnie od ponad roku staram się być project managerem. Każde z tych stanowisk zmuszało mnie do wykształcenia zupełnie innego sposobu postrzegania rzeczywistości. W serii krótkich artykułów porównam elementy różniące pozycje developera oraz managera. <strong>Porównania będą bazować na moich własnych doświadczeniach. Oznacza to, że te same kwestie osadzone w innym kontekście mogą okazać się nieprawdziwe.</strong></p> <blockquote> <p>Management is not a promotion. It is a career change.</p> </blockquote> <h1 id="wiedza-o-projekcie">Wiedza o projekcie</h1> <p>Branża IT skupia się na rozwiązywaniu problemów klientów, którzy korzystają z naszych usług. Powoduje to, że nabywana przez nas wiedza nie ogranicza się jedynie do pisanego kodu, a jednocześnie głęboko wchodzi w domenę na potrzeby której wytwarzamy dane oprogramowanie. W mojej historii poznałem trzy domeny, dotyczyły one produkcji mebli oraz ich sprzedaży na linii B2B, systemów płatniczych oraz eCommerce. Jak różniła się moja perspektywa w zależności od zajmowanego stanowiska?</p> <h1 id="software-developer">Software Developer</h1> <p>Zacząłem pracować jako programista na przełomie 19 i 20 roku życia. Można powiedzieć, że byłem dzieciakiem, który dość szybko dostał możliwość współpracy z firmami generującymi do kilkudziestu milionów złotych przychodu miesięcznie. Podczas niektórych delegacji do klientów, zdarzało mi się usłyszeć opinię o przysłaniu przedszkolaka do wdrożenia dużego oprogramowania. Po kilku tygodniach lub miesiącach współpracy z takimi firmami każda z nich ofiarowała mi swoje zaufanie i była w stanie powierzyć część odpowiedzialności za modyfikację oraz automatyzację procesów zachodzących w ich organizacjach. Przeprowadzane optymalizacje zazwyczaj wymagały znaczącej wiedzy dotyczącej meblarstwa, łańcucha dostaw, zamówień, logistyki, gospodarki magazynowej, fakturowania, analiz czy planowania produkcji. Skąd taki przypływ zaufania?</p> <p>Pracując nad dedykowanym dla branży meblowej, autorskim systemem ERP, który wytwarzaliśmy, miałem okazję poznać benefity wynikające z pracy w firmie produktowej. Naszymi produktami było kilka systemów kompleksowo obsługujących proces planowania zasobów przedsiębiorstwa. Fakt pracy nad tak małą liczbą (szalenie złożonych pod względem analitycznym) produktów oraz skupienia się tylko i wyłącznie nad branżą meblową pozwolił nam na wyspecjalizowanie się w danej domenie oraz gwarantował olbrzymią wiedzę o produkcie, który dostarczaliśmy. Spotkania z klientami stawiały nas w pozycji wygranej, ponieważ mieliśmy doświadczenie we współpracy z wieloma firmami meblowymi i w moment byliśmy w stanie znajdować rozwiązania problemów pojawiających się w firmach naszych klientów.</p> <p>Spędzanie 100% swojego czasu pracy bardzo blisko tworzonych rozwiązań oraz domeny daje olbrzymie poczucie pewności siebie, ponieważ gwarantuje szczegółową wiedzę, która utrudnia zagięcie nas podczas jakiejkolwiek rozmowy. W większości jest to wiedza odpowiadająca na pytania “co?” oraz “jak?”. Jednak w przypadku osób, których postrzegam jako senior developerów pojawia się również taka odpowiadająca na pytanie “dlaczego?”.</p> <p>Początkowa wiedza na tej ścieżce jest szczegółowa i dotyczy kolejno pojawiających się problemów. Dopiero seniorship daje możliwość spojrzenia długoterminowego.</p> <p>Gdy ktoś oczekuje od nas prezentacji wiedzy na stanowisku developera również jesteśmy w sytuacji komfortowej. Rzadko musimy odpowiadać na dowolne pytanie “na żywo”. Zazwyczaj jesteśmy obdarowani czasem na znalezienie rozwiązania, ułożenie odpowiedzi lub konsultację z zespołem - jeszcze przed legendarnym PMowym tekstem <em>“dowiem się i wrócę z odpowiedzią”</em>.</p> <h1 id="project-manager">Project Manager</h1> <p>W roli PMa mam dość małe doświadczenie bazujące na pracy tylko w jednej firmie, więc mój punkt widzenia jest ograniczony. Ostatni rok postawił mnie jednak w wielu sytuacjach. Miałem okresy w których przydzielone były do mnie 3 projekty, a również takie w których projektów miałem 8. Ta druga sytuacja sprawia, że ma się jedynie 40 minut dziennie na zajęcie się każdym z projektów. Nawet sytuacja w której nadzoruje się tylko 3 projekty pozwala na spędzenie nad każdym z nich maksymalnie 2-3 godzin dziennie. Zestawiając to z pozycją specjalisty poświęconego w pełni jednemu projektowi liczba ta jest niesamowicie mała. Nie pozwala na wnikliwe wchodzenie w szczegóły każdego wytwarzanego dla klienta elementu. Szybko doprowadza to sytuacji w której specjaliści z którymi się pracuje nabywają wiedzę zadaniową zdecydowanie przewyższającą tą którą dysponuje PM. Zakres obowiązków managera kierowany jest głównie w stronę budżetowania, rozliczeń, planowania długoterminowego, zarządzania ryzykami. Sprawia to, że w przydzielonych nam 40-120 minutach dziennie brakuje czasu na niskopoziomowe zaangażowanie w wytwarzane rzeczy. Doprowadza to do sytuacji w której możemy odczuwać dyskomfort przez dużą chęć pomocy zespołowi z którym pracujemy na poziomie zadaniowym, uniemożliwioną niskim poziomem wiedzy o zadaniach. Tworzy równiez sytuacje w których kontaktując się z klientami brakuje nam wiedzy o szczegółowych elementach systemu. Wtedy musimy potrafić wykorzystać umiejętności oraz wiedzę specjalistów, którzy nas otaczają. Do tego potrzebna jest relacja oparta na współpracy i zaufaniu, dzięki którym zawsze możemy liczyć na pomoc.</p> <p>Wiedza, którą dysponuje PM w pierwszej kolejności odpowiada na pytania “dlaczego?”, a w dopiero później na pytanie “co?”. Rzadko się zdarza, że PM zaangażowany jest w odpowiedź na pytanie “jak?”.</p> <p>Sytuacje w których jesteśmy stawiani (rozmowy z ludźmi) wymagają od nas natychmiastowego udzielania odpowiedzi. Często zahaczają o tematy w których nie jesteśmy tak kompetentni jak specjaliści. Tematyka rozmów jest rozszerzona o zagadnienia wysokopoziomowe jak biznes, harmonogramy, dostarczanie wartości dla klienta w czasie, zwrot z inwestycji.</p> <h1 id="podsumowanie">Podsumowanie</h1> <p>Obydwa powyższe punkty widzenia mają swoje plusy i minusy. Nie można jednoznacznie stwierdzić, że jedna ścieżka niesie za sobą więcej pozytywnych odczuć od drugiej lub wnosi do naszego życia mniej lub więcej stresu. Również problemy, które rozwiązujemy są skrajnie różne i nie można ich bezpośrednio do siebie przyrównać. Pozytywna lub negatywna ocena bazuje w większości na tym jakimi jesteśmy ludźmi, jakie emocje chcemy odczuwać i jakie problemy rozwiązywać podczas przechodzenia przez swoją ścieżkę zawodową.</p> <p>Streszczając cały artykuł do jednego zdania można powiedzieć, że programiści dysponują wyspecjalizowaną, szczegółową wiedzą o projekcie czasami nie zauważając większego obrazu, a managerowie skupieni są na ogóle i długoterminowym spojrzeniu, czesto z pominięciem szczegółów. Dla osiągnięciu sukcesu projektu konieczne jest wzajemne uzupełnianie się oraz partnerstwo między przedstawicielami obydwu ról.</p> </article> <div class="divider"></div> <div class="page-navigation code"> <a class="home" href="https://rmakara.github.io//" title="Back to Home">Back to Home</a> <br/><br/> <a class="next" href="/Komunikacja-i-jezyk-w-zespole">Next article: Komunikacja i język w zespole</a> </div> </div> <br/> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <div class="footer"> <span class="block">© 2023 Rafal Makara</span> <span class="block"><small></> Powered by <a href="https://jekyllrb.com/">Jekyll</a> and <a href="https://github.com/heiswayi/the-plain">The Plain theme</a>.</small></span> </div> </body> <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-92815270-1', 'auto'); ga('send', 'pageview'); </script> </html>