Interesuje Cię nasza oferta?

Administratorem Pani/Pana danych osobowych jest SI-Consulting Sp. z o.o. z siedzibą we Wrocławiu (53-111), ul. Ślężna 118, zwana dalej „Spółką”, która przetwarza Pani/Pana dane osobowe w celu odpowiedzi na zadane za pomocą formularza zapytanie. Zgodnie z ustawą z dnia 29 sierpnia 1997r. o ochronie danych osobowych (t.j. Dz. U. z 2014 r., poz. 1182 z późn. zm) przysługuje Pani/Panu prawo wglądu do treści swych danych oraz ich poprawiania lub żądania usunięcia.


Jak skutecznie zarządzać projektem i zespołem projektowym ABAP?

 

Marek Garbacz

Niniejszy przewodnik stara się odpowiedzieć na pytania nurtujące wielu programistów ze zdobytym już pewnym bagażem doświadczeń zawodowych, którzy chcą kontynuować swoją ścieżkę profesjonalisty w kierunku zarządzania zarówno projektami rozwojowymi, jak i zespołem projektowym. Występując niejednokrotnie w roli w lidera zespołu programistów brakowało mi informacji, porad czy sugestii, w jaki sposób rozwiązać pojawiające się problemy dotyczące samego zespołu, budżetu, zakresu projektu czy wiedzy. Do większości odpowiedzi dochodziłem samodzielnie, dlatego postaram się przynajmniej w części podpowiedzieć na co zwrócić uwagę, żeby stawać się coraz bardziej efektywnym konsultantem wiodącym ABAP i liderem zespołu programistycznego w projektach developerskich i wdrożeniowych SAP.

 

Ustal na samym początku zasady współpracy

Jeżeli sam konstruujesz zespół, któremu będziesz przewodził, staraj się dobrać jak najbardziej kompetentnych ludzi w zakresie budżetu, którym dysponujesz.

Przewaga w zespole osób dysponujących sporą wiedzą popartą wieloletnimi doświadczeniami może skutkować z jednej strony ciekawszymi pomysłami, z drugiej strony może natomiast powodować konflikty przy budowaniu wizji rozwiązania. Dodatkowo, zatrudnienie wysoko wykwalifikowanych pracowników pociąga za sobą adekwatne koszty. Z kolei zespół składający się w większości z juniorów, to mniejsze koszty, ale dłuższy czas implementacji rozszerzeń oraz konieczność wzmożonego nadzoru merytorycznego.

Najszybciej jak to możliwe, zorganizuj spotkanie wstępne z zespołem. Jeżeli się nie znają, przedstaw wzajemnie członków zespołu, a następnie ustal zasady współpracy i komunikacji, zarówno pomiędzy nimi, jak i z Tobą. Zwróć uwagę na precyzyjne zdefiniowanie reguł raportowania (kiedy, co, w jakiej formie) oraz zgłaszania problemów i zagrożeń. Pamiętaj o ryzyku nieukończenia prac w terminie i zakładanym budżecie. Nie obawiaj się wprowadzić własnych, nawet ostrych czy wymagających zasad. Skoro jesteś liderem, to nim bądź!

Zig Ziglar: „Nie możesz działać w sposób rozbieżny z tym, za kogo się uważasz.”


Przestudiuj wymagania biznesowe i uczestnicz w tworzeniu specyfikacji funkcjonalnych

Jedną z pierwszych części każdego projektu wdrożeniowego lub rozwojowego jest spotkanie użytkowników końcowych lub ekspertów biznesowych w celu zrozumienia wymagań biznesowych, które muszą być wdrożone w systemie SAP podczas fazy realizacji. Najlepszym sposobem, aby zebrać wszystkie wymagania biznesowe jest przeprowadzenie warsztatów. Upewnij się, że jeżeli dany moduł SAP będzie wdrażany, konsultant z tego modułu będzie zaangażowany w takie spotkanie. Kiedy już wszystkie wymagania biznesowe zostaną zebrane, konsultanci modułowi SAP lub/i eksperci biznesowi stworzą szczegółową specyfikację funkcjonalną. Zapoznaj się koniecznie z wszystkimi takimi specyfikacjami.

Dopilnuj, żeby dokumenty przekazywane przez konsultantów zawierały wszystkie niezbędne, a możliwe do wskazania szczegóły techniczne, różne scenariusze biznesowe i jasno zdefiniowane oczekiwane cele. Dobrze zdefiniowany dokument specyfikacji funkcjonalnej, oprócz opisu procesów, powinien zawierać schematy w postaci diagramów UML i scenariusze przypadków testowych (test cases). Niezwykle ważne jest, żeby taki dokument został uzgodniony i podpisany przez klienta przed kolejnymi krokami projektowania i implementacji rozwiązania.

Nie bój się odsyłać konsultantom źle napisanych specyfikacji! Pamiętaj, że osobiście jesteś odpowiedzialny za dostarczenie rozwiązania według tego, co przygotują.


Przygotuj dokument standardów programowania i nazewnictwa rozszerzeń ABAP

Stworzenie dokumentu standardów programowania i nazewnictwa rozszerzeń ABAP to obowiązkowe zadanie menedżera zespołu developerskiego ABAP. Sporządź taki dokument w formie przewodnika, w którym zawrzesz wszelkie normy i wytyczne dotyczące tworzenia rozwiązań programistycznych, wydruków czy interfejsów. Zbiór taki powinien zawierać ustalone konwencje nazewnictwa dla wszystkich tworzonych obiektów programistycznych, które będą wykorzystywane w projekcie, tj. m.in. klas projektowych, programów, modułów funkcyjnych, klas, obiektów słownika ABAP, przestrzeni nazw, itd. Dodatkowo, dokument powinien zawierać zasady modularyzacji kodu w zależności od stopnia skomplikowania rozwiązania.

Dobrą praktyką jest utworzenie szablonu programu zawierającego komentarze i predefiniowane sekcje (podprogramy, zdarzenia) oraz ustalenie zasad nazewnictwa stosowanego w kodzie programu (ustalenie prefiksów zmiennych, parametrów, nazw procedur i podprogramów, itp.). Pamiętaj o zwróceniu uwagi zespołowi na pełne i jasne komentowanie tworzonego kodu. Ma to szczególne znaczenie w przypadku większych zespołów, które często pracują na tych samych obiektach w systemie. Ustalenie konwencji nazewnictwa z jednej strony ułatwia utrzymanie spójnego podejścia do programowania, z drugiej zaś pomaga innym programistom oraz analitykom funkcjonalnym i technicznym w rozszyfrowywaniu i śledzeniu (debugging) kodu.

Jeżeli w firmie wdrożeniowej, którą reprezentujesz, obowiązują już ustalone i sprawdzone standardy programowania, naturalnie wykorzystaj je do celów projektowych.

Andrzej Majewski: „Im kto ma mniej zasad, tym łatwiej je porzuca.”

Przydziel odpowiednie kompetencje do poszczególnych zadań

Ważnym elementem powodzenia projektu programistycznego jest dostosowanie kompetencji rozumianych jako zdolności praktycznego wykorzystania umiejętności i wiedzy w pełni wystarczające do samodzielnego wykonywania określonego zadania w projekcie. Właściwe wykorzystanie kompetencji osoby w działaniach projektowych przekłada się na stopień realizacji celów tej osoby, co z kolei wpływa na stopień realizacji celów całego zespołu, a idąc dalej – całego projektu.

Konkretyzując – wykorzystaj osoby o wysokich kompetencjach do projektowania architektury rozwiązań, analizowania aplikacji czy transakcji bardziej zaawansowanych technologicznie (np. w pełni obiektowych) lub tworzenia wysoko specjalizowanych skomplikowanych rozszerzeń klienckich. Niebagatelną role odgrywa tutaj znajomość specyfiki zaangażowanych modułów systemu, a w szczególności logiki działania miejsc na styku, które integrują procesy zarówno pomiędzy modułami, jak i pomiędzy SAP a systemami zewnętrznymi. Niestety, osoby o najniższych kompetencjach skazane są na tworzenie prostszych raportów czy wydruków.

W przypadku większych rozwiązań zastanów się, czy nie warto podzielić realizację zadania pomiędzy kilka osób. Łatwiejsze podzadania przydziel juniorom, trudniejsze i integrujące konsultantom o większym doświadczeniu. Zwróć uwagę, że zbyt duże rozdrobnienie zadań wcale nie sprzyja przyspieszeniu realizacji całości. Z własnego doświadczenia wiem, jak niekomfortowa była praca kilkunastu wzajemnie blokujących się programistów nad jedną transakcją…

Henry Ford: „Żadne zadanie nie jest szczególnie trudne, jeśli podzielisz je na mniejsze podzadania.”


Zadbaj o dodatkowy budżet motywacyjny

Menedżer bez budżetu motywacyjnego jest jak napastnik bez jednej nogi. Musi się nieźle nagimnastykować, żeby osiągnąć swoje cele. Ale po co utrudniać sobie życie ? Wystąp do kierownictwa projektu o tzw. budżet motywacyjny. Jeżeli jednak procedury projektowe tego nie przewidują, a Ty nie masz wystarczającej siły przebicia, musisz wygospodarować go sam.

Przeanalizuj swój budżet całościowo. Zbierz wszystkie zadania i skrupulatnie oceń ich rzeczywistą pracochłonność. Dowiedz się wśród konsultantów funkcjonalnych i programistów lub sprawdź w swoich dotychczasowych doświadczeniach, czy ktoś nie realizował podobnych zadań w przeszłości – może dysponuje prawie gotowym rozwiązaniem, które wystarczy tylko dostosować, a Ty będziesz mógł zaoszczędzić.

Zanim przekażesz budżety poszczególnych zadań członkom zespołu, skoryguj każdy z nich o 10-15 % i stwórz coś na kształt rezerwy. Po co to wszystko? W cyklu projektowym zwykle przychodzi taki moment, gdy w natłoku zadań i zbliżających się terminów ich oddania, niektórzy członkowie zespołu zaczynają narzekać na zmęczenie i ogrom pracy, jaki im przypadł. W szczególności, gdy sytuacja wymaga pracy po godzinach, czy w dni wolne, motywacja drastycznie spada. Właśnie w takim momencie należy skorzystać z rezerwowego budżetu i zmotywować zespół do wytężonej pracy.

Oliver Wendell Holmes: „Musimy żeglować czasem z wiatrem, czasem pod wiatr, ale żeglować, nie dryfować ani stawać na kotwicy.”


Regularnie spotykaj się z własnym zespołem

Regularne (np. cotygodniowe) spotkania lidera z zespołem mają na celu zadbanie o kilka ważnych aspektów współpracy jego członków poprawiających efektywność grupy.

Przede wszystkim poprawiają komunikację wewnątrz grupy, pozwalając każdemu z jej członków na wypowiedzenie na forum zarówno obaw i wątpliwości, jak i podzielenie się pozytywnymi wrażeniami z właśnie opracowywanego rozwiązania. Jednocześnie spotkania takie powinny służyć identyfikacji wszelkich trudności, na które napotykają programiści, w szczególności ci mniej doświadczeni. Ty, jako lider grupy, możesz nakierować takie osoby wykorzystując swoją wiedzę i doświadczenie. Możesz im również przydzielić bardziej doświadczonego „opiekuna” i określić dla niego zakres udzielanego wsparcia.

W procesie integracji zespołu ważne jest budowanie zaufania pomiędzy jego członkami, co prowadzi do powstania otwartej i swobodnej atmosfery wewnątrz grupy, która sprzyja generowaniu bardziej kreatywnych pomysłów.

Spotkania mają też na celu wyznaczanie kolejnych celów (zadań) oraz kontrolę ich realizacji. Zadbaj o przekonanie, że każdy jednakowo przyczynia się do realizacji wspólnego celu, jakim najczęściej jest terminowe i wysokie jakościowo zakończenie prac projektowych.

Na spotkaniach ustalaj i wyrażaj jasno podział ról i odpowiedzialności, w szczególności gdy kilka osób pracuje nad jednym rozwiązaniem.

Guy de Maupassant: „Spotkania z ludźmi czynią życie warte przeżycia.”


Wyznaczaj zadania krótko i długoterminowe. Ustal priorytety.

Na początku projektu zbuduj narzędzie, za pomocą którego będziesz w stanie w dowolnym punkcie projektu określić status realizacji prac swojego zespołu. Kierownictwo projektu często zadaje takie pytania w najmniej spodziewanym momencie. Tym narzędziem może być w najprostszej postaci arkusz kalkulacyjny zawierajmy listę spriorytetyzowanych zadań, terminów realizacji oraz przydzielonych do nich opiekunów i wykonawców.

Staraj się śledzić wykonanie poszczególnych zadań wyznaczając osobom odpowiedzialnym okresowe raportowanie zaawansowania prac. Pamiętaj, żeby sprawdzać zarówno stopień realizacji zadania (np. procentowo) jak i wykorzystania budżetu danego zadania, gdyż te dwa parametry nie zawsze idą ze sobą w parze.

Przed rozpoczęciem fazy realizacji staraj się określić zaangażowanie poszczególnych członków zespołu i zakomunikuj wszystkim, jakie będzie ich obciążenie w dłuższym okresie czasu.

Następnie przydzielaj na kolejnych spotkaniach zadania krótkoterminowe. Nie polecam przydzielania wszystkich zadań krótkoterminowych jednocześnie na początku projektu. Zdarzają się sytuacje, gdy programista nie zaczyna pracy od zadań o najwyższym priorytecie, tylko od tych, które ocenia jako najłatwiejsze do realizacji. Druga sytuacja negatywna to równoległa realizacji kilku zadań, która nie pozwala skupić się na jakości wykonywanej pracy.

Oczywiście możesz zdefiniować zadania zastępcze, np. w przypadku, gdy trzeba czekać na doprecyzowanie specyfikacji przez konsultanta czy klienta. Pamiętaj jednak, żeby jasno o tym zakomunikować osobie wykonującej.

Tim Ferriss: Brak czasu jest tak naprawdę brakiem priorytetów."


Pilnuj zatwierdzania zmian zakresu

Zadaniem menedżera zespołu ABAP w projekcie jest pilnowanie, żeby wszelkie wprowadzane zmiany zakresu zadań rozwojowych były przed realizacją zaakceptowane przez klienta. Jeżeli zadbasz o odpowiedni podpis na dokumencie, który będzie zatwierdzeniem danego rozszerzenia czy zadania programistycznego, z pewnością pomoże Ci to w synchronizacji zadań zarówno z pozostałymi zespołami wdrożeniowymi, jak i kierownictwem projektu. A to z kolei będzie miało wpływ na utrzymanie Twojej części projektu w zdefiniowanym czasie i budżecie.

Julio Cortázar: „Jedyną rzeczą niezmienną w człowieku jest jego chęć zmieniania.”


Pomagaj merytorycznie

Jako programista ABAP z pewnością nie raz spotkałeś się z problemami natury technicznej. W miarę możliwości staraj się pomagać mniej doświadczonym kolegom z zespołu. Odpowiadaj na pytania, a jeżeli nie znasz od razu odpowiedzi, przeanalizuj problem i wskaż możliwe ścieżki jego rozwiązania.

Zwróć uwagę na niedoświadczone osoby, które o nic nie pytają, albo twierdzą, że nie mają problemów. To wcale nie znaczy, że wszystko wiedzą i praca idzie im jak po maśle. Wykaż się inicjatywą i sam sprawdź postępy ich pracy. Koszt przejrzenia kodu oraz badanie jego optymalności i wydajności na etapie projektowania jest dużo niższy, niż później, w fazie testów i poprawek, a co gorsza po starcie produktywnym.

Dobrą praktyką jest zaplanowanie z osobami mniej doświadczonymi krótkich spotkań, które mają na celu przegląd ich kodu. Możesz prowadzić je sam, albo wyznaczyć do nich konsultantów seniorów. Pamiętaj, że nie mają one na celu pokazać młodym programistom, jak niewiele jeszcze umieją, ale pomoc im w szybszym rozwoju oraz zapewnić spójność i efektywność ich pracy.

Wiesław Trzaskalski: „Czasami podaje się komuś pomocną dłoń, żeby mieć go w garści.”


Pomyśl o sobie

Istotnym elementem zarządzania realizacją zadań w projekcie jest komunikacja z organami nadrzędnymi, czyli m.in. kierownictwem projektu. Jeżeli mamy do czynienia z mniejszym projektem rozwojowym, możesz być jednostką bezpośrednio kontaktującą się z klientem.

Jako osoba odpowiedzialna za terminowe i jakościowe dostarczenie produktu w zakładanym budżecie jesteś zobowiązany, żeby dbać o powyższe aspekty. Pamiętaj, żeby na każdym etapie projektu pilnować właściwej i terminowej komunikacji z kierownictwem projektu i klientem.

Jeżeli nie jesteś w stanie samodzielnie rozwiązać problemów, czy dotrzymać terminu, wyprzedź fakty i poinformuj zwierzchników. Jeżeli brakuje Ci jakichkolwiek informacji, aby wykonać zadanie, wystąp jak najwcześniej o uszczegółowienie specyfikacji czy koncepcji, najlepiej w formie pisemnej (mailowej). Jeżeli nie otrzymasz odpowiedzi w terminie, zastanów się, czy natychmiast nie eskalować problemu wyżej.

Ze spotkań twórz notatki i protokoły, w których możesz zawrzeć terminy wykonania i przypisać osoby spoza twojego zespołu odpowiedzialne za wykonanie zadań. Monitoruj wykonanie zadań przez te osoby.

Albert Einstein: „Zapewnienie ochrony przed linczem stanowi jedno z najpilniejszych zadań, jakie stoją przed naszym pokoleniem.”


Nie rozpraszaj zespołu

Najgorsze, co może zrobić lider zespołu, to bezustanne odciąganie jego członków od wykonywania zadań. Kiedy napięte terminy przypominają o sobie, nie każ swoim ludziom poświęcać zbyt dużo czasu na raportowanie statusu. Pozwól im działać. Nie mieszaj faz – kiedy tworzymy rozwiązanie, to tworzymy, a nie testujemy czy dokumentujemy. Wyjątkiem jest sytuacja, gdy z przyczyn niezależnych nie mamy pełnej informacji, aby kontynuować prace nad zadaniami. Pamiętaj, że wszystko ma swoje miejsce i swój czas.


Zadbaj o dokumentację

Jeżeli przygotowałeś wcześniej odpowiedni szablon dokumentacji projektowej, twoim zadaniem jest tylko przypilnowanie wypełnienia jej przez programistów w odpowiednim momencie projektu. Sprawdź zawartość merytoryczną każdej dokumentacji. Postaw się w sytuacji osoby, która będzie kontynuować prace nad rozwiązaniem opierając się na wiedzy zawartej w dokumentacji. Czy na podstawie tego dokumentu będziesz potrafił zrozumieć rozwiązanie i bez trudu wprowadzić dalsze zmiany ?

Spotkałem się z dziesiątkami różnych formularzy dokumentacji technicznej. Od skomplikowanych, zawierających miejsce na wstawienie kodu programu (po co przenosić kod dostępny w systemie do dokumentu?), do zupełnie prostych, w których wystarczy kilka zdań na temat rozwiązania (czy tych kilka zdań pomoże komuś zrozumieć techniczne aspekty rozwiązania?).

Najlepszym wyjściem jest złoty środek – opis techniczny z listą tworzonych / modyfikowanych obiektów, co najwyżej z elementami meta kodu, w odniesieniu do postawionego problemu (rozszerzenia) w ujęciu funkcjonalnym. Innymi słowy, pokaż wyraźnie czemu i w jakiej sytuacji służyć ma rozwiązanie, a nie skupiaj się tylko na szczegółach technicznych rozwiązania.

 

Powyższe punkty oczywiście nie wyczerpują tematu, a niektórych aspektów zarządzania ledwie dotykają. Celowo również nie zamieściłem części może bardziej oczywistych punktów, ale jednocześnie według mnie mniej istotnych.

________________________________________________________________________________

O autorze

Marek Garbacz – Dyrektor Działu Technologii SAP SI-Consulting

Od kilkunastu lat uczestniczy w projektach wdrożeniowych systemu SAP dla różnych branż, pełniąc funkcję zarówno programisty – senior konsultanta ABAP, lidera zespołu programistów, jak i konsultanta wiodącego ABAP. Kilkukrotnie pełnił rolę koordynatora implementacji rozwiązań programistycznych opartych na technologiach SAP, a także rozwiązań, z których kilka można określić mianem produktów. Na swoim koncie ma ponadto doświadczenia w kierowaniu projektami technologicznymi.