Manifest Agile – czyli co się pod tym kryje (część V) – kolaboracja z klientem

W poprzednim poście „Manifest Agile – czyli co się pod tym kryje (część IV)” starałem się wyjaśnić zawiłości płynące z tłumaczenia angielskiego słowa working na język polski. W tym artykule również nie zabraknie językowych zawiłości :).
Kolaboracja z klientem obraz

Kolaboracja z klientem ponad formalne umowy

W słowniku języka angielskiego słowa „collaboration” ma definicję: the action of working with someone to produce something. Słownik języka polskiego sugeruje jednak coś trochę odmiennego: współpraca z niepopieraną przez większość społeczeństwa władzą, zwłaszcza z władzami okupacyjnymi dodając, że dawniej oznaczało to po prostu współpracę.

W oryginale autorzy użyli słowa collaboration, którego pochodzenie bierze się od łacińskiego „collaborare” czyli „pracować razem”. Zapewne z powodu negatywnego wydźwięku tego słowa, autorzy użyli formy współpraca, co nie do końca oddaje idę płynącą za tym postulatem. Trochę innego spojrzenia nabiera ten postulat, gdy sięgniemy do definicji opisywanej w informatyce np. poprzez 3C Collaboration model. Ta naukowa definicja określa kolaborację, jako połączenie poprzez odpowiednie relacje: komunikacji, koordynacji i kooperacji. Takie ujęcie tego terminu lepiej wyznacza ramy jego znaczenia.

Z naukowego punktu widzenia elementy składające się na 3C model mają swoje własne definicje. Upraszczając, kiedy mówimy o komunikacji to myślimy tylko o wymianie komunikatów bez sprecyzowanego celu, gdy mówimy o koordynacji to mamy na myśli zespół działań regulujących (np. proces lub pracę) dążących do osiągnięcia celu procesu niekoniecznie związanego z celem całego przedsięwzięcia. Gdy spojrzymy na kooperację to mamy do czynienia z działaniem grupy związanym z osiągnięciem wspólnego celu. Czym więc jest kolaboracja? Jak już wspomniałem, kolaboracja to taki mix tych trzech terminów, dlatego też można pokusić się o taką interpretację: to zbiór skoordynowanych działań komunikujących się jednostek, działających w ramach grupy, dążących do osiągnięcia wspólnego celu i celów indywidualnych. Oczywiście, nadal nie wyczerpuje to całkowicie zagadnienia kolaboracji, ale mam nadzieję, że chociaż trochę udało mi się wyjaśnić intencje autorów manifestu. Ten postulat to tak naprawę wezwanie do ciągłego komunikowania się, świadomego zarządzania pracą i dostosowywania się (dotyczy zarówno dostawcy jaki odbiorcy usługi wytwarzania oprogramowania) w celu osiągnięcia tego, co jest ich wspólnym celem (w tym przypadku działające oprogramowanie).

Oczywiście nie bez znaczenia jest druga część tego postulatu, w której autorzy zaznaczają, że to nie „formalne umowy” są istotne, a ciągła kolaboracja. Idąc tutaj za głosem wielu, przytaknę i przypomnę, że w tradycyjnym zarządzaniu duży nacisk kładzie się na formalne ustalenia i umowy. Gdy spojrzymy na takie metodyki jak Prince2 czy PMI, to jakakolwiek zmiana zakresu projektu w trakcie trwania projektu jest uzależniona od zapisu w dokumentacji. Klasyczne podejście wymusza traktowanie zmian zakresu (np. zmian wyglądu UI’a) jak zło konieczne, za które częstokroć klient musi zapłacić ekstra. W tym postulacie zwrócono uwagę na to, że z jednej strony wytwórcy oprogramowania powinni być bardziej elastyczni, a z drugiej zaś strony odbiorca usługi powinien być świadomy tego, że skoro prosi o nieformalne zmiany to może się spodziewać, że wpłynie to na pozostałe parametry projektu (np. czas lub budżet). Stąd w metodach zwinnych (np. SCRUM) zaleca się rolę przedstawiciela klienta (t.j. Product Owner). Do obowiązków takiej osoby należy dbać o to, żeby finalny produkt spełniał wymagania klienta, niekoniecznie te spisane w kontrakcie, ale na pewno te które są potrzebne gdy projekt się kończy.

Jeśli macie jakieś przemyślenia co do tego postulatu to zachęcam do zadawania pytań i dzielenia się opinią w komentarzach.

Wpis opublikowany w Dynamika Rozwoju BLOG i otagowany , , , przez .
Lukasz

O Lukasz

Absolwent wielu kierunków (Project Management, Inżyniera Oprogramowania, Informatyka Stosowana, Pedagogika), doktorant nauk o zarządzaniu na Uniwersytecie Ekonomicznym. Pracownik dużej międzynarodowej korporacji z wieloletnim doświadczeniem zdobytym na stanowiskach menadżerskich (Project Manager) i podczas pełnienia dodatkowych funkcji (Team Leader, Scrum Master, wewnętrzny trener trenerów). Członek Rady Dolnośląskiej Grupy IPMA (zastępca przewodniczącego), posiada szeroką wiedzę i kompetencje z obszaru zarządzania projektami, pracy zespołowej i rozwiązywania konfliktów - potwierdzone wieloma publikacjami i szeregiem certyfikatów (IPMA C/D, Scrum Master, ….). Aktywny zawodowo trener z wieloletnim doświadczeniem (setki przeszkolonych osób).

Dodaj komentarz