Wielu z nas, tj. osób związanych z szeroko rozumianym tworzeniem stron WWW, spotkało się zapewne z problemem różnego rozumienia projektu przez różnych ludzi za niego odpowiedzialnych. Mówimy zwykle wtedy dużo o potrzebie dobrej komunikacji (słusznie), szef o tym, że nie wszyscy mogą decydować, przypominamy sobie, że “klient nasz pan” itd. Warto natomiast zastanowić się, z czego tego rodzaju problemy w ogóle wynikają.

O ile stworzenie witryny nie jest przedsięwzięciem prywatnym, konkretne decyzje dotyczące jej zawartości i formy podejmowane są często z udziałem wielu osób odpowiedzialnych za różne aspekty projektu, począwszy od właściciela serwisu i szefa projektu, na grafikach i programistach skończywszy. Każdy członek zespołu projektowego posiada własne mniemanie na temat tego, co w Sieci jest dobre, ponadto istnieje naturalny mechanizm rzutowania własnych upodobań i uprzedzeń na wszystkich internautów. Ktoś ten rozdźwięk kiedyś trafnie zobrazował (www.agiledeveloper.com):

Tak oto rozstrzyganie poszczególnych kwestii staje się niekiedy próbą sił. Szkodliwą, ponieważ cierpi na niej spójność witryny, będącej ostatecznym rezultatem pracy.

Chociaż struktura zespołu projektowego zależna jest od modelu organizacyjnego firmy, można dostrzec pewne typowe role i postawy z nimi związane. Art Kleiner opisuje dwa zasadnicze sposoby postrzegania przedsięwzięcia WWW - kulturę promocji i kulturę rzemiosła (Corporate Culture in Internet Time). Przedstawiciele kultury promocji (kadra menadżerska, dział marketingu, handlu) koncentrują swoje działania na zewnątrz firmy, starają się przyciągnąć maksymalną ilość kapitału, zdominować rynek, pozyskując strategicznych partnerów generujących zyski, skłaniając klientów do wielkich inwestycji itp. Od wykonawców projektów oczekują oni rezultatów nie tylko sprawnych, ale także atrakcyjnych marketingowo, do tego przy minimalnych nakładach pracy.

Przedstawiciele kultury rzemiosła (projektanci, programiści, testerzy) chcą natomiast w pierwszej kolejności zrozumieć cel projektu, następnie znaleźć optymalne do niego dojście. Potrzebują jasnych wytycznych, rzadko umieją działać pod presją - dla programisty ważniejsza od czasu wykonania pracy jest jej jakość.

Trudności w komunikacji potęgują to zróżnicowanie interesów. Kwiecisty język i styl przynoszący sukces pracownikom szczebla strategicznego/zarządzającego nie pozwala precyzyjnie zarządzać działaniami pracowników szczebla wykonawczego. Brak wzajemnego zrozumienia utrudnia kompromis pomiędzy: programistą, który w możliwie prosty sposób chce udostępnić użytkownikowi określony zestaw funkcjonalności, projektantem (grafikiem), który chce wykazać się inwencją twórczą, a pracownikiem działu handlowego, który chce część przestrzeni serwisu przeznaczyć na zyskowną reklamę. Jeśli przedsiębiorstwo nie wypracowało wcześniej rzeczowego procesu decyzyjnego, ostateczne decyzje, czasem bez odpowiedniej analizy, podejmuje wówczas szef projektu (szkodzi tutaj mit silnego menadżera, kierującego się zawsze celną intuicją), albo też klient, który płacąc ma prawo głosu, ale na kwestiach związanych w szczególności z użytecznością i dostępnością WWW zna się z reguły słabo.

Jakie jest z tego wyjście?

Wydaje się, że sama świadomość wzajemnych odmienności i brak przeświadczenia o własnej słuszności mogą zdziałać całkiem sporo. Duża odpowiedzialność leży po stronie menadżera projektu, który nie powinien brać na siebie każdej decyzji, a raczej starać się powierzyć je osobom najlepiej do różnych kwestii predysponowanym. Jednak najlepszą metodą, aby uniknąć subiektywnych decyzji w procesie tworzenia witryny, odbieranej również w subiektywny sposób, będą testy użyteczności z udziałem zwykłych, niezwiązanych z projektem internautów. Dadzą one obiektywną ocenę zastosowanych w serwisie rozwiązań i będą niepodważalnym głosem w sporach pomiędzy członkami zespołu projektowego.