Zastanawialiście się kiedyś, jakie korzyści niesie za sobą posiadanie wiedzy technicznej na stanowisku Kierownika Projektu oraz jakie wyzwania mogą pojawić się w przypadku jej braku?
W tym artykule postanowiliśmy przyjrzeć się temu tematowi, a naszymi przewodnikami są Maria Feldek oraz Mateusz Herjan, mentorzy kursu TechMind, którzy dzięki swojemu doświadczeniu mają unikalne spojrzenie na istotę umiejętności technicznych Kierownika Projektu.
Czytajcie dalej, aby przekonać się czy Kierownik Projektu IT powinien posiadać zaplecze techniczne, co osoba na tym stanowisku musi wiedzieć o testowaniu oraz jak może zyskać uznanie w oczach zespołu programistów.
Opowiedzcie nam trochę o sobie, gdzie teraz pracujecie? Czym się zajmujecie?
Maria Feldek: Jestem testerem oprogramowania z 3 letnim doświadczeniem. W swojej pracy odpowiadam m.in. za testy funkcjonalne, testy regresji, testy API, Load testy oraz piszę testy automatyczne. Pracowałam na wielu zróżnicowanych projektach i współpracowałam z kilkunastoma PMami. Dzięki temu mam porównanie, wiem jakie zachowanie i przygotowanie techniczne kierownika projektu sprawdza się w praktyce, jakie podejście do pracy i współpracowników daje największe efekty.
Mateusz Herjan: Pracuję teraz w jednej z Amerykańskich firm produktowych dostarczającej rozwiązania typu survelliance dla Stanów Zjednoczonych, Hiszpanii i Turcji. Obecnie jestem technicznym liderem dwóch zespołów programistów oraz architektem systemów informatycznych.
Czy kierownik projektu powinien posiadać wiedzę techniczną
Maria Feldek: Kierownik projektu powinien posiadać wiedzę techniczną przynajmniej w podstawach. Dlaczego?
- Pomoże mu to zrozumieć bieżące problemy zespołu developerskiego a także lepiej zarządzać projektem.
- Będzie w stanie samodzielnie rozpisywać user story i tworzyć odpowiednie subtaski.
- Będzie wiedział co jest w stanie zrobić backendowiec a co full stack.
- Na spotkaniach scrumowych będzie mógł być bardziej w temacie i utrzymywać je na odpowiednich torach.
Mateusz Herjan: Wiedza techniczna jest dla kierownika projektu niezbędna, ponieważ pracuje on z osobami technicznymi. Na pierwszy rzut oka może się wydawać, że od technicznych spraw jest Technical Leader. Ale to kierownik projektu tworzy most pomiędzy światem klienta a światem technicznym.
Kierownik projektu nie musi w 100% znać się na technologii w której tworzony jest projekt – od tego jest rzeczywiście Tech Leader i programiści ale podstawowa orientacja w aspektach technicznych pozwoli mu na stworzenie porozumienia z członkami zespołu tak jak robi to z klientem. Według mnie taka postawa jest konieczna w celu stworzenia dobrej współpracy która będzie owocować lepiej planowanymi zadaniami i dokładniej estymowanym czasem pracy.
Co powinien wiedzieć dobry Project Manager o testowaniu
Maria Feldek: 7 zasad testowania to podstawa. Według mnie najważniejsze z nich, o których PM powinien pamiętać to: „Wczesne testowanie oszczędza czas i pieniądze” oraz „Testowanie gruntowne jest niemożliwe”. Dobrze jest też znać różnicę między testami regresji a retestami i zdawać sobie sprawę z tego jak ważne jest sprawdzenie newralgicznych funkcjonalności przed każdym releasem.
Mateusz Herjan: Przede wszystkim Project Manager powinien wiedzieć o tym, że testowanie zajmuje dużo czasu. Jeżeli zajmuje mało to znaczy, że nie jest dobre. Wiele razy spotkałem się też z podejściem, że testy nie są ważne i że jakoś można się bez nich obejść.
Testy są obowiązkowym elementem rozwoju oprogramowania. Nie ma odstępstw od tej reguły. I dodatkowo: istnieją różne rodzaje testów robione na różnych etapach tworzenia oprogramowania. Warto poznać je wszystkie bo nie wszystkie muszą być robione przez testerów.
Jakie trudności może napotkać kierownik projektu bez wiedzy technicznej na starcie kariery
Maria Feldek: Z doświadczenia wiem, że może to być np. brak poszanowania ze strony developerów. Nie ufa się komuś kto nie ma najmniejszego pojęcia o tym czym zarządza.
Kolejną trudnością kierownika bez wiedzy technicznej może być niezrozumienie problemów w projekcie i brak umiejętności by im zaradzić. Taki kierownik projektu może być sfrustrowany gdy np. termin oddania funkcjonalności się przedłuża.
Byłam świadkiem tego, że gdy trzeba było przesunąć release ze względu na problemy z bazą danych, PM który nie rozumiał w czym problem zarzucił developerom, że specjalnie rzucają mu kłody pod nogi. Przykry to był obrazek.
Jakiej rady udzieliłbyś/abyś osobom, które wahają się przed zdobyciem umiejętności technicznych?
Maria Feldek: Nawet jeżeli ktoś z góry zakłada, że nie jest techniczny i że sobie nie poradzi to lepiej jednak podjąć to wyzwanie, bo wiedza o tym czego nie umiemy już jest krokiem do sukcesu.
Mateusz Herjan: Na pewno przygotujcie się, że nie będzie to krótka podróż. Technologii informatycznych jest dużo i cały czas pojawiają się nowe. Na początku mogą wydawać się skomplikowane i niekiedy rzeczywiście takie są, ale wraz z nabytym doświadczeniem będziecie kojarzyć coraz więcej ich aspektów.
Polecam pytać się osób technicznych jak co działa i jak jest skonstruowane. Nie widziałem jeszcze żeby osoba która jest żywo zainteresowana elementami budowy systemu nie dawała sobie rady jako kierownik projektu.
Jak zyskać uznanie w oczach developerów jako PM?
Maria Feldek: Z tego co udało mi się zaobserwować w trakcie mojej zawodowej kariery to największe uznanie w oczach developerów zyskuje PM, który swoją postawą wykazuje chęci do jak najlepszego zapoznania się z projektem. Elastyczność i umiejętność rozwiązywania konfliktów też się przydaje.
Warto pamiętać o tym, żeby nie przedłużać spotkań scrumowych i nie mnożyć ich bez potrzeby. Developerzy potrzebują skupienia i takie częste spotkania (a w szczególności te, które dałoby się załatwić jednym mailem) mogą ich na dłuższą metę irytować.
Znowu z mojego testerskiego punktu widzenia, PM zyskuje wtedy gdy potrafi przedłożyć jakość nad goniące terminy. Lepiej oddać coś później, ale działające niż świecić oczami przed klientem w terminie.
Mateusz Herjan: Jedna złota rada: jak dołączysz do zespołu to nie staraj się zaczynać od wielkiej zmiany. Siedź, obserwuj i poznawaj projekt. Możesz się pytać i czytać dokumentację. Gdy już będziesz dobrze obyty z projektem i zespołem, wtedy możesz śmiało proponować zmiany które zmienią projekt na lepsze.
