Informatycy, podobnie jak ludzie innych zawodów, nie są wolni od wad. Najczęściej popełniane przez nich grzechy to: wyniosła postawa w stosunku do użytkowników, bałwochwalcze zapatrzenie w metodykę, nadmierne skupianie się na projektach, a także chęć kontrolowania wszystkiego.

Każdy członek zespołu informatycznego w swych zachowaniach popełnia błędy, choć nie zawsze ma tego świadomość. Gorzej, gdy traktuje je jako działania pozytywne i uparcie je powtarza. Oto lista siedmiu informatycznych grzechów głównych.

Arogancja

Arogancja informatyczna przyjmuje wiele form: od opowiadania dowcipów na temat użytkowników nie odróżniających klawisza Enter od Backspace, poprzez robienie zakładów: czy ONI będą mieli wreszcie dość naszej pomocy i zafundują sobie (za własne pieniądze) kurs obsługi Excela i Worda, aż po bezczelne odpowiadanie pytaniem: "A czy czytałeś instrukcję obsługi?" W gruncie rzeczy arogancja to makijaż ukrywający poważne zaniedbania w umiejętności kontaktowania się z użytkownikami.

Jaką pokutę zadać? Jeśli użytkownicy narzekają na złą współpracę z zespołem informatycznym, należy opracować harmonogram, który dałby informatykom możliwość spróbowania swoich sił na miejscu osób korzystających z systemów. Nawet jeśli nie nauczy ich to pokory we współpracy z użytkownikami, to przynajmniej będą mieli pewne rozeznanie w materii biznesu, który obsługują informatycznie z pozycji wszystkowiedzących guru.

Mania wielkości

Profesjonalni informatycy rozważają wszystko w kategoriach dużych systemów. Prowadzi to do rozszerzania projektów ponad miarę aktualnych możliwości, będąc wyrazem myślenia życzeniowego. Jeden analityk zaleci rozszerzenie pożądanych właściwości systemu obsługi zakupów o możliwość obsługi cyklu dostaw surowców, następny doda konieczność automatyzacji całego cyklu procesu produkcyjnego. Obydwaj oczywiście zgodzą się, że osoba, która zamówiła system, ma za ciasne horyzonty myślowe i nie wie, że nieuwzględnienie już dziś potrzeb całego przedsiębiorstwa pociągnie za sobą znacznie większe wydatki za kilka lat. Użytkownicy nazywają ten sposób myślenia "projektowaniem wszechświata". Denerwuje ich to, że zamiast projektu systemu, który zajmie się problemami dla nich istotnymi, muszą dyskutować z aroganckimi wszystkowiedzącymi "specjalistami", o produkcie niemożliwym do zrealizowania.

Najlepszym sposobem na to może okazać się przydzielenie takiego analityka do zespołu zajmującego się przystosowaniem używanego programu do wymagań użytkowników. Użytkownicy zapewne zażądają dokonania zmian w ciągu tygodnia (mając przy tym nadzieję, że specjaliści zrobią to w miesiąc), co złamie manię wielkości nasze-go analityka.

Skupienie na projektach

Grzech ten jest ściśle powiązany z dwoma poprzednimi. O ile arogancja często wynika z wątpliwości we własną wiedzę i umiejętności, a mania wielkości wskazuje zazwyczaj na potrzebę wykazania się za wszelką cenę, o tyle niewolnicze skupienie się na projektach za cel ma poprawę sytuacji własnej, stworzenie nowych szans na karierę w przyszłości. Kierownik dużego projektu informatycznego oczekuje promocji, mając nadzieję, że zostanie szefem działu informatyki - niekoniecznie zresztą we własnej firmie. Najlepiej gdyby nastąpiło to w połowie projektu, z chwilą pojawienia się trudności z jego terminową realizacją.

Duże projekty to najcięższy grzech główny informatyki. Wszystko, co trwa dłużej niż 9 miesięcy, ma wszelkie szanse ku temu, żeby nigdy się nie skończyć. Projekty udają się tylko wtedy, gdy widać pilną potrzebę ich zakończenia w sensownym terminie. Dobrze więc podzielić je na samodzielne części.

Jak poradzić sobie z takim szefem projektu? Niech przez pewien czas zajmuje się działem pomocy dla użytkowników.

Żargon

To główny grzech analityków, którzy chcą pokazać, że znają się na czymś, o czym użytkownik końcowy nie ma pojęcia. Po co używać znanych wszystkim terminów, skoro pojawiły się nowe? Jest to szczególnie przydatne, gdy zamawiający projekt opanował już dawną terminologię i zaczyna rozumieć o co chodzi w projekcie. Jeżeli więc użytkownik wie, co to znaczy analiza strukturalna, natychmiast wprowadzane są terminy JAD i RAD. Dumnie objaśniane, że oznacza to wspólne opracowanie projektu (Joint Application Development) i szybką ścieżkę opracowania aplikacji (Rapid Application Development). Gdy użytkownik poinformuje, że już od dawna wspólnie z informatykami opracowuje aplikacje i wcale nie zmierza do spowolnienia procesu ich opracowania, wskazuje mu się, że za JAD i RAD stoją poważne metodyki. Co oznacza tyle, że znaleźli się już analitycy, którzy napisali książkę o opracowaniu aplikacji w taki właśnie sposób.

Żargon musi się rozwijać, bo coraz więcej słów kojarzy się ze zdyskredytowanymi pomysłami. Na przykład termin CASE oznaczał kiedyś ogromne projekty, które nigdy się nie kończyły się pomyślnie. Trzeba więc było wymyślić coś innego - i tak powstało use-case analysis.

Jak wytępić używanie żargonu? Przydzielić osobę posługującą się nim najczęściej do pracy nad opracowaniem słownika terminologii systemowej. Potem pochwalić za dobrze wykonaną pracę i... zostawić przy niej, po to, aby słownik nie stracił aktualności.

Zapatrzenie w metodyki

Nic tak nie podważa wiary w ustalone metodyki prowadzenia projektu, jak sprecyzowanie terminów jego wykonania. Zwolennicy metodyk wierzą w to, że sztywne trzymanie się ich okaże się opłacalne, gdyż doprowadzi np. do zmniejszenia kosztów konserwacji programów. Często za grzechem tym stoi przyziemna potrzeba zapewnienia sobie kolejnej pozycji w CV, co umożliwi zdobycie lepiej płatnej pracy.

Jak sobie z tym radzić? Przedstawić koszt narzędzi wspierających ulubioną metodykę, często równoważny kosztom wynajęcia kilku programistów.

Potrzeba kontrolowania wszystkiego

Dobrze jest mieć ustalone standardy i procedury działania. Natomiast próba objęcia kontrolą wszystkiego kończy się źle. Różnica między jednym a drugim przypomina różnicę między jedzeniem a obżarstwem - jedno jest niezbędne, drugie szkodliwe. Słowem kluczem, którym posługują się zwolennicy wszechmocnej kontroli, jest zapobieganie. Mamy z nią do czynienia podczas dyskusji o tym, jak zapobiegać instalowaniu "dzikich" kopii programów przez użytkowników. Ma miejsce także wtedy, gdy mówi się o kłopotach z użytkownikami, zamiast zajmować się ich problemami.

Jaka rada? Najlepiej zmusić informatyków, by "świecili" przykładem. Żadnych własnych programów, a każde złamanie ustalonych reguł będzie karane natychmiastowym zwolnieniem z pracy.

Mentalność dostawcy

Trzeba stale pamiętać o tym, jaka jest rola i dla kogo pracuje zespół informatyczny. Typowy syndrom dostawcy prowadzi do uznania pozostałych działów firmy za "klientów", zmuszania do podpisywania formalnych kontraktów na świadczenie usług i opracowywania projektów. W ten sposób informatyk staje się dostawcą, a nie partnerem. Trudno tu o pokutę, istnieje natomiast ryzyko wiecznego potępienia. Firma może po prostu zmienić dostawcę - rozwiązać dział informatyki, a świadczenie usług informatycznych zlecić dostawcy niezależnemu.

Dobre stosunki informatyków z szefami i pracownikami przedsiębiorstwa są podstawą istnienia działu, a więc udanej kariery jego członków. Bardzo łatwo je zniszczyć przez nie przemyślane posunięcia, drobne lub większe grzechy, z których tylko część została tutaj wymieniona.

Jedyne rozwiązanie: nie grzeszyć!