Zespół specjalistów – Jak skutecznie się porozumieć? Cz.2.

Programistów często postrzegamy jako osoby ceniące sobie bardziej walory życia wirtualnego niż rzeczywistego, które żywią się wyłącznie kawą i mają ograniczone umiejętności komunikowania się. Nie znam przepisu na to, jak z programisty zrobić mistrza retoryki, ale spróbuję podpowiedzieć, jak zwiększyć efektywność i ułatwić współpracę zespołu, którego celem jest stworzenie dobrego projektu internetowego.

Wbrew powszechnej opinii praca programistów opiera się w ogromnym stopniu na interakcjach. Istotna ich część przebiega pomiędzy uczestnikami odległymi zarówno fizycznie, jak i kulturowo, często za pośrednictwem środków komunikacji nie pozwalających zobaczyć oraz usłyszeć rozmówcy. Im większy projekt, tym więcej zadań, często także większa liczba osób pracujących nad nimi. Stąd też, aby projekt się udał i spełniał maksymalnie oczekiwania klienta, należy się skutecznie komunikować i planować poszczególne etapy prac.

Co wpływa na sukces projektu?

Dobrze przygotowana specyfikacja

Rozbudowany projekt powinien mieć szczegółową specyfikację, która ułatwi pracę wszystkim członkom zespołu. Więcej informacji na temat przygotowania specyfikacji znalazło się w pierwszej części tego cyklu: Jak skutecznie się porozumieć? Cz.1. Relacja web developer – klient.

Niewłaściwie przygotowana dokumentacja projektu może stać się przyczyną wielu zmian i poprawek. Może się zdarzyć również tak, że klient nie otrzyma takiego produktu, jaki zamówił. Jednak dobra specyfikacja to nie wszystko. Kluczowe będzie również jej dokładne omówienie z zespołem i weryfikacja w trakcie prowadzenia prac, co pozwoli ograniczyć liczbę nieporozumień.

Poniższa grafika, doskonale obrazuje sytuację, w której na poszczególnych etapach tworzenia i realizacji projektu pojawiły się nieporozumienia.

 Etapy budowy systemu informatycznego dla przedsiębiorstwa – businessballs.com

Klient rzadko kiedy określa swoje wymagania w 100%. Ba! Często sam dokładnie nie wie, czego chce. Stąd też osoba kontaktująca się bezpośrednio z klientem ma za zadanie przygotować precyzyjną specyfikację, albo jak najdokładniej przedstawić wizję klienta osobie, która taką dokumentacje sporządzi.

Następnie specyfikację należy omówić i zweryfikować z klientem, co pozwoli na samym początku zmniejszyć ilość niepotrzebnych nieporozumień. Dobrze przygotowana specyfikacja pozwoli także ograniczyć koszty, które będą się zwiększać wraz z kolejnymi poprawkami.

Efekt prac należy skontrolować i sprawdzić czy spełnia założenia ustalone z klientem. Następnie powinno się zweryfikować praktyczność projektu – testując go, a pojawiające się błędy od razu naprawić.

Dokładny opis projektu oraz stosowanie wyżej wymienionych czynności zwiększy szansę na przygotowanie produktu, przydatnego klientowi.

Posługiwanie się tym samym językiem

Wypracowanie wspólnego języka w grupie projektowej jest bardzo ważne. W skład zespołu wchodzą nie tylko programiści, ale także osoby odpowiedzialne za marketing, kontakt z klientem, graficy, czy też, albo przede wszystkim, manager projektu, który może, ale nie musi być programistą i wtedy jest to naprawdę ważne, aby umiał porozumieć się z podległymi mu programistami.

W przypadku, gdy prowadzący projekt, nie rozumie tego co mówi do niego programista i jedynie bezmyślnie przytakuje, założone przedsięwzięcie ma niewielkie szanse na to, aby zakończyć się sukcesem.

Konsultowanie zmian

W trakcie realizacji projektu nie unikniemy zmian, czy to wskazanych przez klienta, czy też programistę. Zmiany w przypadku których czas realizacji, manager projektu potrafi oszacować oraz wie, że programista w jego zespole będzie potrafił je wykonać w określonym czasie nie wymagają omawiania. W pozostałych sytuacjach należy skonsultować się z zespołem, szczególnie z osobami, które bezpośrednio mają realizować zmiany. Dzięki temu ograniczamy możliwość pojawienia się nieprzyjemnych, stresujących sytuacji i spięć pomiędzy członkami zespołu.

W przypadku nieprzekazania na czas programiście informacji o zmianach w projekcie, możemy wydłużyć czas jego pracy. Wykona on zadanie według wcześniejszych ustaleń lub według własnego uznania, co będzie się wiązało z poprawkami, a nawet przygotowaniem od nowa pewnych elementów czy funkcjonalności. A to oznacza stratę czasu i… pieniędzy.

Weryfikacja wykonanych zadań

Realizując projekt, należy wraz z zespołem ustalić poszczególne etapy prac oraz czas ich wykonania. Następnie należy weryfikować ich realizację. Jest to bardzo ważne, gdyż w takich projektach praca jednej osoby jest zależna od drugiej. Stąd też przestrzeganie terminów, ale także informowanie o braku możliwości wykonania zadania w określonym czasie, jest bardzo ważne.

Porządek

W przypadku, gdy tworzymy coś wspólnie, kiedy efekt naszej pracy przekazywany jest kolejnej osobie, która następnie go przetwarza, musimy pamiętać o odpowiednich oznaczeniach i opisach.

Przykładowo, gdy programista otrzymuje materiały od grafika, dobrze opracowana, opisana i sklasyfikowana dokumentacja z pewnością ułatwi i przyspieszy pracę.

Metoda Scrum

SCRUM to metoda, która niewątpliwie pomoże zrealizować wyżej wymienione wskazówki. Jest to metoda zarządzania projektami, która nie wskazuje konkretnych i gotowych rozwiązań z których można skorzystać realizując dane zadanie, stanowi ona bardziej model działania, zapewniający pewne struktury i zasady, które można dopasować do indywidualnych warunków.

Założenia metody są proste – trudniejsza jest ich realizacja, ponieważ metoda ta wymaga od członków zespołu samodyscypliny.

Pracę nad projektem dzieli się na mniejsze części – nazywane sprintami. Przyjmuje się, że jeden sprint nie powinien trwać dłużej niż 30 dni. W praktyce, czas ten jest zróżnicowany w zależności od upodobań zespołu. Na koniec danego sprintu przedstawia się działający fragment produktu.

Każdy sprint rozpoczyna się planowaniem: na podstawie określonych priorytetów wybiera się oczekiwania klienta, aby podzielić je później na mniejsze zadania. Sprint powinien zakończyć się prezentacją wdrożonych wymagań klienta oraz ich omówieniem i podsumowaniem wraz z całym zespołem.

Tablica zadań (Task Board) w teorii: itkanban.com

Przykładowa tablica zadań: dfwscrum.wordpress.com

SCRUM ma wiele plusów:

• porządkuje i kontroluje interesy osób zaangażowanych w tworzenie projektu;
• organizuje komunikację i maksymalizuje poziom współpracy w zespole i poza nim;
• opiera się o samoorganizację, zwiększając produktywność zespołu;
• sprawdzi się w przypadku małych i dużych zespołów.

Warto spróbować

SCRUM może początkowo wydawać się kosztowny i ryzykowny, jednakże firma wdrażająca tę metodę ma szanse stać się bardziej elastyczną i otwartą. Dzięki temu będzie lepiej odpowiadać na oczekiwania rynku, zwiększając tym samym swoje szanse w zmaganiach z konkurencją.

Wyżej opisana metoda to tylko propozycja, która może nam pomóc w doskonaleniu komunikacji w zespole. Oczywiście, da się osiągnąć sukces bez jej stosowania, ale metoda ta może ułatwić współpracę i wykonanie projektu, maksymalnie spełniającego oczekiwania klienta.

Najważniejsze w pracy zespołu jest jednak atmosfera i zrozumienie, które powinno mieć miejsce zarówno w relacjach project managera z programistami, między programistami, czy też między grafikiem, a programistą. Podstawą dobrego projektu jest porozumienie się z klientem. Konflikty i spięcia wynikają najczęściej z niewiedzy, dlatego w miarę możliwości powinno się konsultować i rozmawiać z zespołem w trakcie wykonywania projektu.

Pół żartem, pół serio

Oto do czego może doprowadzić brak zrozumienia na poszczególnych szczeblach zarządzania:

• Programista do Szefa Programistów:
  – Nie jesteśmy w stanie napisać tego programu w zaproponowanym terminie. Więcej. Nie jesteśmy w stanie napisać go w ogóle. Wymagało by to bowiem całkowitej zmiany strategii firmy i wejścia w całkiem nową dla nas dziedzinę, a nikt z naszego zespołu nie ma odpowiedniego zasobu wiedzy z tej dziedziny. Moim zdaniem nie powinniśmy byli przyjmować tego zlecenia bez zastanowienia.
• Szef Programistów do Szefa Projektu:
  – Projekt wymaga zmiany założeń. W tej chwili nie mamy ludzi, którzy mogą się tego podjąć. Wymagało by to dodatkowego szkolenia. Moim zdaniem nie jesteśmy gotowi do podejmowania zadań tego typu
• Szef Projektu do Głównego Managera:
  – Projekt wymaga pewnych zmian strategii i niewielkiego doszkolenia paru ludzi. Moim zdaniem możemy ostrożnie podjąć ten temat.
• Główny Manager do Dyrektora:
  – Projekt udowodni klientom zdolności naszej firmy w zakresie elastycznego dopasowania się do potrzeb użytkownika. Moim zdaniem moglibyśmy podjąć się; tego zadania, ale pod pewnymi warunkami.
• Dyrektor do Szefa Sprzedaży:
  – Proszę przekazać informacje klientowi. Dyktuję: „Zlecili nam Państwo; projekt z dziedziny, w której nasza firma ma wieloletnie doświadczenie. Wykonaliśmy już wiele podobnych projektów dla bardzo znanych firm, a zatem Państwa zadanie zostanie wykonane w podanym przez Was terminie.”
• Szef sprzedaży do handlowca:
  – Mamy wieloletnie doświadczenie w tworzeniu tego typu aplikacji. Nie ma wiec żadnych problemów, aby obsłużyć tego klienta. Co więcej, możemy skrócić termin wykonania projektu, jeżeli konkurencja będzie nas naciskać nawet do tygodnia.
• Handlowiec do klienta:
  – Praktycznie mamy takie aplikacje gotowe. Wystarczy tylko poddać je odpowiednim modyfikacjom, aby dostosować je do potrzeb waszej firmy. Nie zajmie nam to dłużej, niż kilka dni.
• Klient do handlowca:
  – Czy mogę zatem prosić o wersję demonstracyjną na jutro?

Źródło:

Jemielniak D., Praca oparta na wiedzy: praca w przedsiębiorstwach wiedzy na przykładzie organizacji high-tech, Warszawa 2008

Metodyka SCRUM, http://mfiles.pl/pl/index.php/Metodyka_SCRUM