Specyfika prowadzenia projektów www

Polecamy artykuł Marcina Witka, opublikowany w Linux.PL pod poniższym tytułem. Opisuje on specyfikę tworzenia rozwiązań internetowych dla małych i średnich przedsiębiorstw. Podpisujemy się pod nim.

Specyfika prowadzenia projektów WWW

W małych i średnich firmach

Pobieżne spojrzenie na postawiony w temacie artykułu problem nieuchronnie owocuje wnioskiem, że rynek opartych o WWW projektów dla mikro- i miniprzedsiębiorstw jest pełen projektów trudnych, pełen niezadowolonych klientów i sfrustrowanych wykonawców. Niniejszy artykuł jest wspartą wieloletnim doświadczeniem próbą spojrzenia nań z dystansu i ma na celu próbę podkreślenia czynników odróżniających projekty, których proces produkcyjny przebiega bez przeszkód, od tych, w których jest on trudny i niezwykle kosztowny dla obu stron w nim uczestniczących

Tworzenie oprogramowania działającego na platformie WWW (stron, sklepów internetowych, systemów wspomagających procesy biznesowe) dla firm zatrudniających nie więcej niż kilkanaście osób, w znaczącym stopniu odbiega od modeli opisanych „książkowymi” metodykami zarządzania projektem. Częstym zjawiskiem jest to, że odbiorca usługi nie tylko nie widzi potrzeby pracy koncepcyjnej, poprzedzającej właściwą fazę produkcji oprogramowania, ale także nie postrzega jej jako „pracy” w ogóle. Z drugiej strony, wykonawca usługi często nie tylko nie ma odpowiednich zasobów, by przeprowadzać z klientem rozmowy mające na celu edukację w tym zakresie, ale także nie posiada odpowiedniej wiedzy na temat przedprodukcyjnego przygotowania produktu. Mimo tych ograniczeń, ze względu na najczęściej niewielki zakres projektu (strona firmowa, prosty system CRM, wdrożenie sklepu internetowego open source) oraz elastyczność i dostępność narzędzi wykorzystywanych przy produkcji oprogramowania (platforma LAMP), wykonane projekty mogą być dobre jakościowo i łatwe w utrzymaniu.

Porozumienie ponad podziałami.

Truizmem jest stwierdzenie, że kluczową dla powodzenia projektu sprawą jest porozumienie pomiędzy odbiorcą usługi a jej wykonawcą (wszyscy chyba widzieli stary jak świat obrazkowy żart „to, co klient zamówił” – „to, co opisywał projekt” – aż do „to, czego klient naprawdę potrzebował”). Sedno sprawy tkwi jednak w tym, że w przypadku opartych o WWW projektów dla małych i bardzo małych firm, odbiorca i wykonawca to najczęściej pojedyncze osoby, brak jest pośrednich struktur organizacyjnych (działu IT u klienta i działu kontaktu z klientem u wykonawcy) pomiędzy odbiorcą a wykonawcą. Jest to istotne ze względu na daleko posuniętą specjalizację w różnych dziedzinach tak wykonawców, jak i klientów. Sprawia ona, że jedyne osoby uczestniczące w projekcie mają problemy z jasnym i pełnym odbiorem informacji udzielanych przez drugą stronę i brak jest kogokolwiek, kto posiadałby przynajmniej podstawową wiedzę umożliwiającą porozumienie się obu w istotnych dla powodzenia projektu tematach (możliwościami technologii i dobrymi zwyczajami wykonania z jednej strony a procesami biznesowymi w konkretnej branży i konkretnym przedsiębiorstwie z drugiej). Skutkuje to nie tylko pomijaniem aspektów uznanych za „oczywiste” przez stronę projektu posiadającą odpowiednią wiedzę, ale także tych uznanych za „nieistotne” przez stronę takiej wiedzy nieposiadającej.

Przykładem „oczywistości” może być konieczność wytłumaczenia klientowi, czym różni się opcja „drukuj” przeglądarki internetowej od opcji „drukuj” pliku PDF otwartego w przeglądarce. Z drugiej strony (na przykładzie faktycznie wykonanego intranetu dla biu- Specyfika prowadzenia projektów WWW Pobieżne spojrzenie na postawiony w temacie artykułu problem nieuchronnie owocuje wnioskiem, że rynek opartych o WWW projektów dla mikro- i miniprzedsiębiorstw jest pełen projektów trudnych, pełen niezadowolonych klientów i sfrustrowanych wykonawców. Niniejszy artykuł jest wspartą wieloletnim doświadczeniem próbą spojrzenia nań z dystansu i ma na celu próbę podkreślenia czynników odróżniających projekty, których proces produkcyjny przebiega bez przeszkód, od tych, w których jest on trudny i niezwykle kosztowny dla obu stron w nim uczestniczących W małych i średnich firmach Specyfika prowadzenia projektów WWW w małych i średnich firmach www.lpmagazine.org 39 cji, istotne jest stosowanie powszechnie rozumianego języka. Używane pojęcia i prezentowane komunikaty nie muszą dokładnie prezentować całości wiedzy, którą przekazałoby pojęcie branżowe, muszą natomiast być zrozumiałe dla drugiej strony.

Dla przykładu, klient nie musi wiedzieć, czym różni się TCP/IP od HTTP. Istotną dla niego informacją jest, że pewne rzeczy „zostaną przesłane siecią”. Wykonawca z kolei nie musi mieć pojęcia o tym, czym różni się „sznur krawędziowy” od „obszycia szwów” (na przykładzie faktycznie wykonanego systemu dla dostawcy tapicerek samochodowych) – wystarczy mu informacja, w którym przypadku powinien uwzględnić który parametr.

Przejrzystość procesu produkcji.

Powszechnie (niestety) spotykaną praktyką jest nieinformowanie odbiorcy usługi o postępach procesu produkcji, jeśli postępy te nie dają fizycznego rezultatu lub ich rezultat nie posiada pełnej funkcjonalności. Najczęściej zjawisko to przybiera formę dostarczania w pełni gotowego wyniku danej iteracji projektu, co, w połączeniu z częstym brakiem formalnych iteracji, oznacza, że klient widzi od razu produkt „gotowy” i nie ma świadomości ilości wykonanej pracy. ra księgowego) może to być konieczność wyjaśnienia, czym różnią się „przychody i koszty finansowe” od „pozostałych przychodów i kosztów”.

Przykładem „nieistotności” może być na przykład potrzeba wyjaśnienia, dlaczego logo firmy powinno znajdować się w lewym górnym rogu layoutu. Z drugiej strony – konieczność opisania, dlaczego w systemie intranetowym potrzebne są dwa raporty prezentujące te same informacje, ale w odmiennej formie.

Hermetyczny język.

Każda branża posiada swój własny żargon. To również jest truizmem, jednak wśród ludzi zaangażowanych w intensywną pracę we własnej branży popularne jest zapominanie o fakcie, że żargon i w ogólności „język branżowy” jest nie tyle niejasny, co absolutnie niezrozumiały dla ludzi spoza danej dziedziny. Używanie takiego rodzaju komunikacji, co więcej, domaganie się od drugiej z uczestniczących w projekcie stron, by takie komunikaty rozumiała, jest prostą drogą do zwiększenia niezadowolenia z projektu już na etapie produkcji i dostarczenia produktu o niskiej jakości.

W przypadku projektu, w którym – jak pisałem – brak jest struktur „pośredniczących” w komunika- Reklama 40 8/2010 PRAKTYKA

W takim przypadku również zaniedbania i nieporozumienia na etapie tworzenia wymagań projektu (których główne przyczyny wymieniłem w poprzednich punktach) skutkują dostarczeniem ostatecznej wersji produktu, który nie spełnia wymagań klienta. Sprostowanie niejasności powoduje w istocie konieczność rozpoczęcia takich działań, które powinny być objęte osobnym projektem (przebudową gotowego produktu).

Z drugiej strony, zwykłe udostępnianie klientowi bezpośredniego wglądu w wersję produkcyjną projektu skutkuje często przekonaniem, że produkt jest wadliwy i błędny, ponieważ w trakcie procesu produkcji nie ma możliwości zapewnienia poprawnego działania całości systemu.

Rozwiązaniem może tu być bieżące raportowanie postępu prac, dające klientowi poczucie kontroli nad przebiegiem projektu, a w przypadku dostarczania produktu w wersjach produkcyjnych – jasna i powtarzana za każdym razem informacja, które jego elementy zostały już zamknięte, które są w trakcie wykonywania, a które dopiero czekają na rozpoczęcie pracy.

Istotnym, a często pomijanym aspektem jest w tym kontekście sposób raportowania błędów wersji produkcyjnej. Komunikaty niosące istotne informacje dla programisty są dla klienta niezrozumiałe, a ich forma najczęściej utwierdza go w przekonaniu, iż są to problemy poważne i powodują zwiększenie obaw co do jakości dostarczanej usługi. Tymczasem istotna informacja niesiona przez dowolny raport błędów jest taka, że prace produkcyjne trwają i dobrze jest, gdy klient otrzymuje wyłącznie taką informację, zamiast wielostronicowych, upstrzonych czerwienią stack trace'ów.

Zaangażowanie.

Jest to kolejny w niniejszym artykule truizm, jednak, ze względu na specyfikę projektów WWW prowadzonych w małych i średnich firmach, wart podkreślenia i ujęcia w osobnym punkcie. Analizowane w artykule projekty najczęściej są jednymi z wielu przedsięwzięć realizowanych równocześnie tak w firmie odbiorcy, jak i wykonawcy usługi, a z uwagi na niewielką liczbę pracowników, najczęściej są jednymi z wielu przedsięwzięć realizowanych przez pojedyncze osoby.

W takiej sytuacji niezwykle popularna jest prokrastynacja, czyli odkładanie potrzebnych działań na ostatni możliwy termin. Nie bez znaczenia jest tutaj także fakt, że projekty oparte o WWW ze względu na swą specyfikę nie posiadają wersji, w której fizycznie niemożliwe jest wprowadzenie jakichkolwiek zmian, z (skądinąd formalnie prawdziwym) przekonaniem, że pewne elementy projektu można zmienić „zawsze” – strona WWW czy oparty o LAMP intranet nie posiada wersji niezmienialnej w takim sensie, w jakim jest taką wersją np. odebrany z drukarni folder reklamowy. Prokrastynacja w tym ujęciu skutkuje nie tylko brakiem pola manewru w sytuacjach kryzysowych, ale również niemożnością przewidzenia takich sytuacji. Innym skutkiem jest ekstremalnie trudne zarządzanie zmianami w projekcie.

Bardzo istotne jest zatem obustronne zaangażowanie w bieżące sprawy projektu i zrozumienie potencjalnych skutków jego braku.

Podsumowanie.

Rynek tworzenia projektów opartych o WWW dla małych i średnich firm jest rynkiem specyficznym i niemieszczącym się w modelowych ramach określanych przez metodyki zarządzania projektem. Dzieje się tak z wielu względów, jednak większość z nich jest warunkowana przez fakt występowania minimalnych stanów osobowych w zespole projektowym tak po stronie klienta, jak i wykonawcy oprogramowania. Skutki bezpośredniego zaangażowania w proces produkcyjny pojedynczych osób z odmiennych branż są specyficzne i szersze niż wymienione w niniejszym artykule, jednak te, które zostały przedstawione, generują największe ryzyko niepowodzenia projektu, lub ukończenia go w sposób niesatysfakcjonujący tak dla klienta, jak i wykonawcy.

Do istotnych problemów należą więc problemy w komunikacji pomiędzy klientem a wykonawcą, które generowane są wprost przez obustronne zaangażowanie zawodowe w często bardzo odległych od siebie branżach i brak platformy pojęciowej sprzyjającej jasnemu formułowaniu wymagań i celów projektu.

Nie mniej problematyczny jest odpowiedni przepływ informacji pomiędzy stronami uczestniczącymi w projekcie. Uwarunkowania tego specyficznego segmentu rynku powodują, że jest on często utrudniony i niedostatki na tym polu owocują podwyższonym ryzykiem niepowodzenia projektu.

Odpowiednia reakcja na pojawiające się na obu polach nieporozumienia pozwala nie tylko sprawnie wykonanie większości projektów, ale daje też odpowiednią podstawę do uniknięcia problemów innych, niż wymienione w niniejszym artykule.

MARCIN WITEK Posiada ponad dziesięcioletnie doświadczenie w branży WWW, pracował na wielu poziomach zawodowego wtajemniczenia i z klientami różnej wielkości. Od 2009 roku współtworzy aplikację Isido.pl i specjalizuje się w produkcji systemów intranetowych na tworzonych dla zaspokojenia specyficznych, jednostkowych potrzeb Klientów.