Warunkiem sukcesu dowolnego projektu informatycznego jest dobra jakość komunikacji między wszystkimi jego uczestnikami. Tymczasem stosunki między programistami a przedstawicielami biznesu przypominają raczej “przyjaźń” Toma i Jerry’ego. Można jednak i trzeba z takim stanem rzeczy walczyć.
“Co jest najważniejsze w zarządzaniu projektami?“ Pytanie padło podczas rozmowy kwalifikacyjnej na lidera zespołu programistów w niewielkiej agencji interaktywnej. “Komunikacja“ odpowiedziałem bez namysłu. “Jeśli nie dogadam się z programistami, projekt upadnie. Jeśli nie dogadam się z klientem, projekt upadnie. Jeśli programiści nie dogadają się ze sobą, projekt również upadnie.“ Tak jak upadło ich już wiele.
Tydzień temu odwiedziłem 49 spotkanie Aula Polska, na którym jeden z prezenterów przy okazji omawiania zgoła innego tematu nadmienił, że “to niesamowite co działy IT potrafią zrobić z wydawałoby się zero-jedynkową specyfikacją.“ Od razu przypomniałem sobie opinie kolegów-programistów w pracy, którzy na pół biura wyklinają osoby z “biznesu”, które nie potrafią określić czego chcą i w jaki sposób ma to być zrealizowane. Najwyraźniej obie strony nie potrafią się ze sobą dogadać i obie uważają, że wina leży po drugiej stronie.
Jest takie powiedzenie, które szczególnie upodobali sobie konsumenci w handlu detalicznym: “klient ma zawsze rację.” Pewien znajomy sprzedawca butów próbował mnie kiedyś przekonać, że nie jest prawdziwe, ale nie mogę się zgodzić. Prawda jest taka, że każdy z nas ma rację. Każdy z własnego punktu widzenia, przy posiadanej w danej chwili wiedzy i zakładając szczerość intencji, ma rację.
Problem tkwi oczywiście w punkcie widzenia, co w przypadku produkcji oprogramowania wygląda następujaco:
To tak, jakby obie grupy rozmawiały w zupełnie innych językach, posługując się innym słownictwem. Biznes prosi, żeby “na stronie wyników wyszukiwania znalazła się możliwość sortowania po tytułach“, a programista pyta “która strona?“, bo wyszukiwarek jest na stronie kilka – tekstowa, regionalna, zaawansowana, itd. i jeszcze możliwość ich łączenia.
A skoro mowa o językach, to jeszcze zabawniej robi się kiedy współpraca odbywa się ponad granicami i programista w jednym kraju otrzymuje prośby i zadania od osób w pięciu innych. Językiem wspólnym na ogół jest angielski, ale dla nikogo nie jest to język ojczysty, więc już na starcie zrozumienie bywa utrudnione.
Do tego dochodzi bariera form komunikacji. Siłą rzeczy niemożliwe jest spotkanie twarzą w twarz z każdym zainteresowanym. Pozostaje więc opierać się na komunikacji elektronicznej – z reguły mailach lub komentarzach dopisywanych w systemach śledzenia błędów i zadań. Na dodatek programiści nie przeszli treningu dla sprzedawców, więc nie jest dla nich naturalne złapać za telefon i wyjaśnić problem dzięki temu znacznie efektywniej.
Wszystko to składa się na stan obecny, w którym obie strony klną na siebie siarczyście.
Wina leży oczywiście po obu stronach. Trudno oczekiwać od programistów, że zrozumieją zawiłości procesów biznesowych, dla których piszą oprogramowanie. Trudno też od biznesu oczekiwać, że nauczy się modelu MVC i zacznie samodzielnie analizować błędy zapytań w AJAX. Jeśli już znajdzie się osobę, która potrafi się poruszać zarówno w świecie technologii jak i biznesu, to powinno się ją szybko awansować na szefa zespołu lub projektu, a w filozofii Agile na Scrum Mastera.
Wszystkich natomiast należy wytre(s)nować w stosowaniu podstawowych zasad komunikacji:
Odpowiedzialność za jakość komunikacji w dowolnej grupie ponosi menadżer, który nad tą grupą stoi. Każdy z nich powinien na swoim biurku, lub innym dobrze widocznym miejscu, postawić tabliczkę: “Komunikacja, głupcze!“
