TheTarPit

przeanalizujmy to spokojnie

Dowolny klient, odbiorca dowolnego systemu infomatycznego, mimo kilku niezaprzeczalnych zalet ma zawsze jedną podstawową wadę — nie umie powiedzieć czego chce. To jest pewnik, zagwarantowany przez definicję klienta jako takiego — sam z siebie nie umie sformułować wymagań na jakimś zadowalającym poziomie technicznej szczegółowości. A nawet jeśli czasem mu się wydaje, że umie, jeśli na przykład ma swoich informatyków, który zechcą przygotować specyfikację wymagań, to wychodzi to tak, że wszyscy byliby szczęśliwsi gdyby klient takich rzeczy w ogóle robić nie próbował.

Przyczyny takiego stanu rzeczy są dosyć oczywiste — klient zamawiający system informatyczny żyje w zupełnie innym świecie niż (potencjalny) producent (potencjalnego) oprogramowania i w związku z tym posługuje się zupełnie innym zestawem pojęć.

We often claim that customers don't know what they want, and then we expect them to tell us anyway. But does it make sense to expect customers to select from among the multitude of options when they don't even know what those options are? Should we expect them to describe their needs articulately when they may not excel at the language of description? Is it wise to expect them to relate every essential detail, when the details they notice are not the ones we need?

Naomi Karten

Picture Perfect

Sposobów radzenia sobie w takiej sytuacji jest oczywiście wiele i niemal wszystkie zawierają jakiś element prototypowania i przedstawiania klientowi potencjalnych rozwiązań^[1]. Jednak mimo, że problem zrozumienia o co chodzi klientowi jest jednym z najpoważniejszych problemów podczas produkcji systemu na zamówienie (i nie tylko zresztą), to większość członków prawidłowo zorganizowanego zespołu nie powinna się w ogóle nad nim zastanawiać, ani przez moment. Dlatego, że istnieje analityk.

Rola analityka jest w takiej sytuacji (czyli niemal zawsze) najważniejszą rolą w projekcie informatycznym. Programiści napiszą wszystko co im projektant zaprojektuje (zwłaszcza jeśli są zdolni i cierpliwi, a przeważnie tacy są, wbrew pozorom). Projektant zaprojektuje techniczne rozwiązanie każdego, najbardziej dziwnego wymagania. System powstanie i będzie robił cuda, jednak będzie miał zerową wartość jeśli rozminie się z potrzebami i oczekiwaniami klienta. Banał? Oczywiście. Niestety jak większość banalnych faktów, również ten jest nader często ignorowany.

Trudno określić jakie cechy powinien mieć dobry analityk w projekcie informatycznym. Z jednej strony musi znać (lub umieć szybko poznać) dziedzinę biznesową klienta, musi się umieć dogadać "ich językiem" o "ich sprawach". A z drugiej — musi umieć to przedstawić w sposób zrozumiały dla projektanta. Słowem — taki tłumacz "z polskiego na nasze". Druga konieczna cecha to umiejętność rozmowy z klientem. I to zarówno rozmowy w celu dowiedzenia się pewnych faktów, znalezienia odpowiedzi na mnóstwo pytań od projektantów i programistów, ale również, mówiąc wprost, w celu manipulowania klientem zasugerowania klientowi właściwych odpowiedzi dla uzyskania ... szeroko pojętych obopólnych korzyści.

Niedawno byłem przypadkowo świadkiem rozmowy naszego analityka z klientem. W pewnym momencie zakrywa słuchawkę ręką i szeptem mówi do mnie:

— ale jestem miła... aż mi niedobrze...

No, ja bym tak nie umiał...

Komentarze

Brak komentarzy do tego wpisu.