rss

Jak developer z biznesem

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ć.

Michał Paluchowski, 26 marca 2010

Tom i Jerry

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.

Punkt widzenia zależy od punktu siedzenia

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.

Na językach

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.

Skuteczność komunikacji

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.

Walczmy o zrozumienie

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.

3 Little Words

Wszystkich natomiast należy wytre(s)nować w stosowaniu podstawowych zasad komunikacji:

  1. tu nie chodzi o ciebie. Komunikując się chcemy albo przekazać informacje – wtedy to nam zależy, żeby odbiorca je zrozumiał, albo chcemy otrzymać informacje – wtedy nam zależy, żeby je zrozumieć. Ego wyrzucamy za okno i zaczynamy się zastanawiać jak sprawa wygląda z punktu widzenia drugiej strony. Jeśli trudno to sobie wyobrazić, wystarczy spytać. Słuchać dopóki druga osoba nie skończy mówić; zadawać pytania; nie krytykowaćelementarne techniki w kontaktach z ludźmi.
  2. programiści nie piszą dla siebie. Programy, które tworzymy nie służą samym sobie, ani też nie służą do uszczęśliwiania kompilatorów. Służą do rozwiązywania problemów naszych klientów, które to problemy nie mają nic wspólnego z technologią. Aplikacje to tylko narzędzia. Stąd programiści powinni orientować się kiedy i do czego wykorzystuje się ich aplikacje, czemu na pewno pomagają regularne spotkania z użytkownikami końcowymi.
  3. biznes opiera się na zaawansowanych technologiach. Nie ma „zmiłuj się” dla osób, które po stronie biznesu sądzą, że obędą się bez wiedzy technicznej. Jeśli jeździ się samochodem to trzeba się nauczyć jak on działa, żeby móc bezpiecznie i skutecznie się poruszać. Jeśli korzysta się z oprogramowania komputerowego, to zdecydowanie trzeba znać przynajmniej podstawy tego, co znajduje się ‚pod maską’. Pytania „która strona?” stają się mniej irytujące, albo znikają całkowicie, kiedy biznes nauczy się przekazywać pełne i konkretne informacje o umiejscowieniu problemów.

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!