O prowadzeniu projektów,usługach, informatykach ...

Z Adamem Korczowskim, dyrektorem Altkom Akademia i Renatą Bresińską, szefem zespołu programistów, rozmawia Marian Łakomy.

Z Adamem Korczowskim, dyrektorem Altkom Akademia i Renatą Bresińską, szefem zespołu programistów, rozmawia Marian Łakomy.

Wszyscy mają jakieś dane, ale mało kto wie, co ma naprawdę...

Renata Bresińska: Opowiem tu historyjkę, obrazującą podejście ludzi do swych danych. Przenosiliśmy w pewnej firmie dane z dawnego systemu do nowej aplikacji. Okazało się, że nie ma żadnej dokumentacji dawnego systemu, a co gorsze, osoba odpowiedzialna za te dane nie widzi potrzeby posiadania dokumentacji. Firma nie miała nawet schematu swej bazy danych. Oczywiście, myśmy to rozkodowali, przez miesiąc zajmowaliśmy się przenoszeniem danych z dawnej aplikacji do nowej bazy. Udało się nam przenieść jakieś 80% danych. Mówię szefowi firmy: "Przecież po to robię panu dokumentację, żeby takie sytuacje się nie powtarzały. Jeżeli bowiem pewnego dnia zaprzestaniemy współpracy, to zostanie pan "na lodzie", nie wiedząc, co jest w Pańskiej bazie danych".

Uzyskałam odpowiedź: "Po co mi to?" Wygląda to dokładnie tak, jakby ludzie nie potrafili uczyć się na własnych

błędach.

Wprawdzie - jak słyszę - udało się Pani przekonać tych ludzi do konieczności posiadania dokumentacji bazy danych i kompletnej informacji o swych danych. Co mamy jednak zrobić, aby przekonać każdego użytkownika jakiejkolwiek bazy danych o konieczności posiadania dokumentacji?

RB. Wydaje mi się, że jest to sytuacja o tyle typowa, że właściwie wszędzie przywiązuje się za małą wagę do oprogramowania. Oprogramowanie to taka szczególna rzecz, której ani dotknąć nie można, ani nie ma jak zaksięgować... Świadomość informatyczna, co do wagi i znaczenia oprogramowania jest wśród użytkowników bardzo niska.

Wydaje się więc, że jest jeszcze sporo do zrobienia...

Adam Korczowski: Od kiedy pamiętam, programiści domagali się, aby ich produkt był traktowany poważnie. Ale byli praktycznie bez szans, bo nie istniało prawo autorskie. Poza tym, ludzie nie zdawali sobie sprawy z tego, czym może się skończyć fakt zabierania się za poważne oprogramowanie. Dotąd było tak, że jak ktoś miał dużą maszynę, to na ogół miał oprogramowanie. Ludzie nie bardzo zdawali sobie sprawę z tego, gdzie kończy się to, co jest myślą techniczną stojącą za systemem. Po prostu system działał i wszystko było w porządku.

Mówimy tu, że użytkownicy nie doceniają oprogramowania. Ale czy my, informatycy, sami je doceniamy? No bo jeżeli mała firma, dwu- lub trzyosobowa wyprodukuje jakiś program, choćby system finansowo-księgowy, to czy chętnie udostępnia swemu klientowi choćby wspomniany już schemat bazy? I nie wiadomo, jaki jest pożytek z tego, że sami dobrze zachowają dane o swym produkcie...

RB. Zgadza się. To jest zjawisko nagminne. Po roku nawet sami nie wiedzą jak działa ich program.

AK. Żaden programista nie lubi komentarzy w programie, uważając że dokumentowanie programu przeszkadza mu w twórczej pracy.

RB. Przyznaję, że rola szefa zespołu jest w tym względzie wyjątkowo niewdzięczna. Nikt nie chce pisać dokumentacji do programów; programista uważa, że odrywają go od pracy. Życie udowadnia, że nawet jemu samemu się to opłaca.

Bardzo ciężko jest osiągnąć kompromis między koniecznością szybkiego realizowania projektu a dokładnością produkowanej dokumentacji. Użytkownik chciałby swój produkt mieć jak najszybciej. I jeżeli zastanowimy się dlaczego większość poważnych projektów jest opóźnionych i nie mieści się w budżecie, to nie wynika to stąd, że nie da się oszacować ich pracochłonności, ani określić kosztów wykonania. Jeżeli poprawnie przeprowadzi się analizę i zrobi projekt, to można dość dokładnie powiedzieć, kiedy uda się zakończyć dzieło i za ile.

Jeżeli jednak powiemy o tym zamawiającemu, to on nigdy nie zgodzi się na jego realizację. Każdy chce mieć wynik od razu. Raczej mówi się użytkownikowi to, czego on oczekuje, a potem i tak opóźnienia zrzuca się na przyczyny obiektywne.

Już dawno zauważono fakt, że programista to taki specyficzny gatunek ludzi, dla którego najgorszą karą jest konieczność pisania dokumentacji. Można ludziom narzucić konieczność posługiwania się określoną metodyką, pisania dokumentacji, ale czy nie należy im tego jakoś ułatwić?

RB. Ten problem dotyczy nie tylko dokumentowania, ale jest szczególnie ważny w testowaniu. Kiedyś wyczytałam, a potem sprawdziłam w działaniu, że najbardziej skuteczną metodą testowania jest tzw. inspekcja programu. Niekoniecznie z wydruku, może odbywać się ona na ekranie. Najpierw programista pisze moduł programu, potem go dokumentuje. I na tym etapie przeprowadza kontrolę jego poprawności: czy rozumie, jak jego program działa. Musi przeczytać program i zrozumieć go.

AK. A jeszcze lepiej, jeśli musi komuś wytłumaczyć, jak jego program działa. Wystarczy poprosić, aby wytłumaczył to koledze.

RB. Jak pokazuje moje doświadczenie, w taki sposób da się wykryć prawie 80% błędów.

AK. Przypomina mi się przy tej okazji historyjka z wykładowcą, który ma niesłychanie tępego studenta. "Tłumaczę mu raz, nie rozumie; tłumaczę drugi raz - nie rozumie; tłumaczę trzeci raz, ja już zrozumiałem a on nadal nie rozumie". Tłumacząc komuś, programista ma szansę przekonać się czy naprawdę wie, co napisał w programie.

Analiza i projekt

Wróćmy jednak do dokumentacji, ale nie samego programu...

AK. Istotnie, dokumentacja zaczyna się nie na etapie programu. Trzeba zacząć od dokumentowania rozmów z klientami. Zawód analityka, który się teraz tworzy, był kiedyś praktycznie nieznany. Po co jakiś analityk? Mówiło się klientowi: "Siądzie tu programista i napisze Panu program". Teraz zawód analityka nabrał znaczenia, są to ludzie, którzy zarabiają duże pieniądze. Ale nie bez powodu. Są to bowiem ludzie, którzy muszą mieć znakomity kontakt z klientem, zdobyć jego zaufanie i wydobyć od niego informacje. Na dodatek będą przez kilka tygodni przeszkadzać wszystkim w pracy.

Jeżeli jeszcze pojawiają się ludzie z Price Waterhouse czy innej firmy o uznanej renomie, to wszystko jest dobrze. No ale jak zjawia się jakaś mała polska firma, to nie dość, że jest traktowana dość obcesowo, to tak naprawdę nie stać jej na prowadzenie prawdziwej inżynierii oprogramowania.

Współczesnego samochodu, wyposażonego w całą masę elektroniki, łącznie z komputerem pokładowym, nie da naprawić bez specjalistycznego sprzętu.

Tak samo jest ze współczesną informatyką. Bez wyposażenia narzędziowego pewnych rzeczy się nie zrobi. Prof. ...Turski powiedział kiedyś, że jest programowanie i pisanie programów. Programowanie to jest sztuka. Zaś napisanie programu, który realizuje jakieś zadanie, to na dobrą sprawę jest praca dla uczniów szkoły średniej.

RB. Wróćmy jednak do naszego analityka. Uważam, że zrobienie dobrego modelu obiektu przynosi wiele korzyści. Nawet za pomocą ołówka i papieru, bez żadnego narzędzia. Dokładne przyjrzenie się temu modelowi daje naprawdę bardzo dużo.

AK. Czy Pan wie jakie jest najprostsze narzędzie technologii obiektowej? Zwykła tablica magnetyczna suchościeralna, do której można przyczepiać obrazki i rysować na niej. Służy ona przede wszystkim do przekonania ludzi, zajmujących się projektem informatycznym, że ważna jest metodyka, nauczenie się metodyki...

Użytkownik i jego wymagania

Wróćmy do naszego projektu informatycznego. Każda firma mówi klientowi: "Zrobimy Panu w tej aplikacji wszystko, czego Pan oczekuje". Jednakże na ogół klient nie wie, czego ma oczekiwać.

RB. Istnieje takie słynne powiedzenie użytkownika: "Będę wiedział o co mi chodzi, jak zobaczę produkt".

Właśnie, co z tym użytkownikiem robimy? Bo tak naprawdę dla wspomnianego już analityka nie jest problemem zebranie wymagań użytkownika, tylko raczej powiedzenie mu, czego on ma oczekiwać od programu...

RB. Uważam, aby zrobić dobrą analizę problemu, trzeba mieć sporą wiedzę z dziedziny, dla której pracujemy. Nie ma analityka, który może zrobić dobrą analizę każdego problemu. Nawet najlepsze podstawy ogólne i doświadczenie nie wystarczą. Firmy na Zachodzie zajmują się w określonymi dziedzinami, zwłaszcza wymagającymi specjalistycznej wiedzy. Jeżeli temat jest dla analityka zrozumiały, to jest w stanie zrobić dobrą analizę problemu.

Częsta jest sytuacja, że użytkownik mówi tylko o rzeczach specyficznych, nigdy nie mówi o rzeczach dla niego oczywistych. Gdyby więc oprzeć analizę tylko na tym, co mówi użytkownik, to marnie byśmy wyszli.

Eksperci

Co z tym fantem zrobić?

RB. Musimy mieć wspomaganie ekspertów z dziedziny, dla której robimy program.

A czy nie powinni oni chociaż trochę znać się na informatyce?

RB. Myślę, że nie ma takiej potrzeby. Od tego jest szef projektu, który powinien mieć jednak ogólne pojęcie o zagadnieniu. Na początku, gdy prowadzi się analizę, nie zajmujemy się jego realizacją informatyczną; analizujemy sam problem. Dopiero później, gdy pytamy, jak należy go rozwiązać, zapewne trzeba rozszerzyć zespół o specjalistów, np. w zakresie komunikacji różnych maszyn. Próba rozwiązania dużego problemu jednoosobowo lub małym zespołem musi skończyć się klęską.

Jaki więc powinien być skład zespołu do opracowania aplikacji dla np. banku czy fabryki farmaceutycznej?

RB. Potrzeba przynajmniej dwóch analityków, lepiej trzech. Przynajmniej jeden specjalista od zagadnień, które informatyzujemy. Czasem potrzeba tych specjalistów wielu, zwłaszcza, gdy występują różnorodne problemy. Specjaliści ci na ogół są potrzebni przez cały czas opracowania aplikacji.

Przeprowadziliśmy już analizę zagadnienia. Co dalej?

RB. Wykonujemy projekt, czyli prezentujemy wszystkie możliwe rozwiązania, co już trochę zaczyna zachodzić na etap implementacji. Określamy architekturę sprzętu, systemy operacyjne, narzędzia których użyjemy do zrealizowania projektu.

Koszty projektu

AK. Analiza ma określić na czym polega problem, a projekt pokazuje, jakie jest jego rozwiązanie i ile będzie kosztowało.

Doszliśmy chyba do niesłychanie ważnego etapu projektu - określenia kosztów.

RB. Wydaje mi się, że żaden poważny zespół nie powinien podawać kosztu realizacji projektu na samym jego początku. Niestety, bardzo trudno jest przekonać potencjalnego klienta, że nie da się określić kosztu projektu informatycznego przed etapem projektu. My próbujemy podawać koszt wykonania analizy problemu. Dopiero potem możemy podać całkowity koszt wykonania projektu.

AK. Tu jest właściwe pole do popisu dla prasy komputerowej. Należy ludziom uświadamiać, że jeżeli zamierzamy realizować projekt informatyczny, to przetarg można rozpisać dopiero po wykonaniu analizy projektu. A czy mamy zamiar zlecić analizę uznanemu zespołowi specjalistów, czy rozpisać na nią przetarg, to już mało ważne. I tak koszt tego etapu jest niewielki w porównaniu z kosztem całego przedsięwzięcia. Przecież nie można określić kosztów pracy bez zakreślenia jej ram. To tak jakby rozpisywać przetarg na dom, bez określenia czy budujemy dom mieszkalny, czy biurowiec.

RB. Nazwijmy ten etap studium problemu czy analizą. Musi on jednak odbyć się przed rozpisaniem przetargu.

AK. Na dobrą sprawę z analizy jeszcze nie wyniknie, co zostanie zrobione. Dopiero w etapie projektu można określić wymagania krytyczne dla sukcesu projektu, co trzeba wykonać a co można pominąć. I na tej podstawie da się dokładnie określić koszty i terminy wykonania.

RB. Powszechnie przyjmuje się, że dokładne koszty projektu da się określić dopiero po etapie projektu, to jest po wykonaniu ok. 60% pracy.

I tu pojawia się poważny problem. Kto kupi taką koncepcję realizowania projektów?

RB. Jest to rzeczywiście trudna sprawa. My jednak upieramy się przy tym, aby nie podawać żadnych kosztów przed wykonaniem analizy. Co najwyżej możemy podać bardzo szeroki zakres przewidywanych kosztów, z dokładnością wręcz do rzędu wielkości (np. 50-150 tys. zł).

AK. Co wtedy robi klient? Na ogół zaczyna sobie zdawać sprawę, że za poważny system informatyczny musi zapłacić duże pieniądze, np. 80-150 tys. zł. Tylko nadal nie wie, co za to dostanie! Może się okazać, że jak wybierze ten pozornie tańszy projekt za 80 tys. zł, to faktycznie będzie to projekt droższy, niż ten za 150 tys.

Nie znając zakresu pracy nie można określić, który projekt jest faktycznie droższy. Może wystarczy ten droższy, ale kompletny projekt, ograniczyć do połowy i już będzie tańszy od tego pozornie tańszego, a na dodatek da się go kontynuować, jak już klient będzie miał pieniądze.

Czy projekt tańszy jest istotnie tańszy?

Dlaczego więc potencjalni klienci postępują tak, jak to powszechnie obserwujemy: wybierają zawsze ofertę tańszą.

AK. Procedury przetargowe, niewiedza... Czasem jest też taka sytuacja, że klient wie jaką kwotę ma do wydania i nie

przyjmie do realizacji projektu droższego. Co zresztą wykorzystują bezwzględnie niektóre firmy, przedstawiając

słabe oferty, ale nie przekraczające tej kwoty. Tymczasem korzystniej by było przyjąć ofertę droższą, ale kompletną i

dającą się rozwijać. Wystarczy ją trochę przykroić.

Praktycznie zaś powinno odbywać się to w ten sposób, że w przypadku przedsięwzięcia za 100 tys. zł, przewidujemy z góry wydanie ok. 20 tys. zł na analizę. I wykonujemy ją niezależnie od tego czy później będziemy realizować projekt za 50 tys., czy 100 tys. zł. Ograniczamy go do naszych możliwości finansowych, ale przed podjęciem pracy wiemy dokładnie, co mamy do zrobienia.

Kiedyś - w zupełnie innej sytuacji - denerwowało mnie dość brutalne podejście kontrahenta zagranicznego, który pytał, ile mamy pieniędzy do wydania. Tymczasem on był doświadczony na tyle, aby szukać produktów jedynie w naszym zasięgu, nie zaś wszystkich z tej branży. Tak powinno być z projektem informatycznym. Jak już będziemy wiedzieć, co mamy do zrobienia i ile mamy na to pieniędzy, możemy dokładnie zakreślić ramy projektu.

Uczciwa firma przedstawi ofertę dającą maksymalne zadowolenie klienta za wydane przez niego pieniądze. Nie będzie zaś usiłowała wykorzystać tej wiedzy do wpychania mu czegokolwiek, byle w cenie.

Jak rozpoznać taką uczciwą firmę?

AK. To jest dość łatwe do sprawdzenia. Tyle jest firm konsultingowych na rynku i taka konkurencja, że słabe firmy szybko wypadają. Oszczędnością będzie też znalezienie konsultanta, który odbierze pracę i stwierdzi czy została wykonana we właściwy sposób.

Problem znalezienia konsultantów o właściwych kwalifikacjach dotyczy zarówno zamawiających projekt, jak firm

konsultingowych.

Narzędzia i specjaliści

Tu pojawia się pytanie czy w Polsce jest dostateczna liczba fachowców do prowadzenia projektów informatycznych?

AK. Wydaje się, że wszyscy w Polsce są na początku drogi i naszą największą bolączką jest brak narzędzi oraz specjalistów sprawnie się nimi posługującymi. Powoduje to, że nadal wiele projektów realizuje się w sposób bałaganiarski, bez narzędzi i właściwej metodyki.

Mówiliśmy już o tym, że zespół prowadzący projekt musi godzić się na kompromisy, niezbyt zgodne z metodyką, efektywnością czy zasadami sprawnego działania...

RB. Z praktyki wynika, że życie zmusza nas do kompromisów. Jak dużych? Zbyt duże prowadzą na ogół do nieudanych projektów. Zaczyna się to już na etapie analizy i projektu. Użytkownik chce jak najszybciej mieć działający (nieważne jak) system, nam zaś zależy na zrobieniu dobrej analizy i projektu. W efekcie zmuszeni jesteśmy użytkownikowi coś szybko dać, żeby widział, że za swoje pieniądze może czegoś "dotknąć". Łatwiej można wtedy dojść do porozumienia.

Często więc dajemy użytkownikowi coś w rodzaju prototypu części aplikacji. On już może z niego korzystać (i nie protestuje, gdy przedstawiamy mu fakturę), my zaś możemy się skupić na właściwej pracy. Niestety, prowadzi to często do konieczności wprowadzania znacznych poprawek lub wręcz pisania tego modułu od nowa.

Czy oznacza to, że nie jest Pani zwolennikiem prototypowej metody opracowania aplikacji (Rapid Application Developement - RAD)?

RB. Tak istotnie jest. Co to znaczy np. prototyp aplikacji bankowej? Transakcja zrealizowana tylko w połowie? Istnieją pewne systemy, które można podzielić na moduły i dostarczyć klientowi szybko jeden moduł, ale kompletnie działający. Można to jednak zrobić wtedy, gdy mamy koncepcję rozwiązania całości.

Programy z półki

AK. Wszyscy chcą mieć system informatyczny. Ale dlaczego wpadli na pomysł, że muszą go mieć już. Przecież takie przedsięwzięcia planuje się na całe lata. Czy stawiając nierealne wymagania firmie informatycznej nie zdają sobie sprawy, że zgodzi się na nie jedynie firma nieuczciwa, która zawsze znajdzie obiektywne trudności, uniemożliwiające wykonanie projektu na czas i w przewidzianym budżecie?

RB. Znam taki przypadek, gdy duża firma zgłasza zapotrzebowanie na system obsługi księgowo-finansowej

dostosowany do ich potrzeb i chce ten system mieć za miesiąc! Oczywiście zawsze istnieje możliwość zakupienia

systemu z półki, ale klient nie może oczekiwać, że ktokolwiek dopasuje go do jego potrzeb.

AK. Ludzie muszą sobie zdać sprawę, że oprogramowanie z półki jest znacznie tańsze, ale też ta różnica w cenie wynika stąd, że nie mamy wpływu na jego kształt. Możemy je polubić lub nie. Kupując np. Excel mamy pewien zakres dostępnych możliwości, ale nie możemy sobie zażyczyć od Microsoftu, aby nam dorobił np. dodatkową funkcję. To samo dotyczy dużych systemów informatycznych, kupionych za grube tysiące (nowych) złotych. Jest czas na ich wdrażanie, gdy poprawia się jakieś usterki, ale nie zmienia się generalnej koncepcji programu, ani zakresu jego możliwości i zestawu funkcji.

Tu jest więc problem do rozstrzygnięcia: albo robimy coś poważnego na zamówienie i musimy mieć czas, albo kupujemy program z półki, ale musimy polubić jego możliwości.

RB. Tu może zresztą pomóc zrobienie wstępnej analizy wymagań i na tej podstawie, albo dobranie programu z półki albo podjęcie decyzji, ponieważ żaden gotowy produkt nas nie zadowala - robimy coś na zamówienie. Model wymagań pozwala dość dokładnie określić czy i na ile wystarcza nam oprogramowanie z półki. Zwykle 60-70% wymagań da się spełnić za pomocą oprogramowania z półki.

Zresztą firmy często nie potrafią wykorzystywać programów, które mają do dyspozycji. Czasem wystarczyłoby uzupełnić gotowy program za pomocą dodatkowego narzędzia, np. do tworzenia raportów czy formatek ekranowych i już mielibyśmy niezły wynik. Tu też kłania się problem szkoleń i ich właściwej organizacji.

AK. Narzędzia z dziedziny raportowania ad hoc z baz danych są bardzo przydatne. Kiedyś nawet najprostszy raport programista dostarczał w ciągu kilku dni albo tygodni; obecnie można to zrobić praktycznie od ręki. Takie narzędzia są niezbędne każdemu, kto chce efektywnie wykorzystywać swe dane...

Administrator danych

Wróciliśmy więc do początku naszej dyskusji o jakości danych, informacji o tym, co naprawdę mamy w bazie itd.

RB. Obecnie w dużym przedsiębiorstwie nie można się obyć bez osoby określanej mianem administratora danych (nie mylić z administratorem bazy danych). To on określa zakres danych w bazie, sposoby ich przechowywania, czas magazynowania, procedury sprawdzania wiarygodności itp. U nas ten problem jest całkowicie nie doceniany.

Administrator danych nie musi być informatykiem, za to musi dokładnie rozumieć potrzeby firmy, znać specyfikę jej działalności i wiedzieć dokładnie, co jest dla jej działania istotne, a co nie. Informatyka może go wspomóc, ale nie zastąpi.

AK. Można by tu powiedzieć, że ten temat powinien być przedmiotem analizy projektu informatycznego. Jednakże to w firmie powinna być osoba, która potrafi określić, po co w ogóle jest potrzebna rozmowa z informatykiem na temat bazy danych. Czy firmie jest potrzebna informatyka? I jakie ma przynieść korzyści.

Korzyści z informatyzacji

A jakie korzyści przynosi firmie system informatyczny?

AK. Prawda jest taka, że bardzo rzadko mówimy firmie, jakie korzyści może jej przynieść informatyzacja działalności. Czasem wynika to z braku naszego własnego przekonania o celowości takiej operacji w firmie, w której panuje totalny bałagan informacyjny. Informatyka go nie usprawni. Czasem zaś nie chcemy stracić klienta, któremu trudno pokazać korzyści w sposób namacalny i liczbowy.

Rzadko kto potrafi precyzyjnie przeliczyć system informatyczny na pieniądze. Albo na rozmiar produkcji, liczbę zatrudnionych czy konkretne oszczędności administracyjne.

Jak wynika z materiałów prasowych, najtrudniejszym problemem z jakich stykają się informatycy w dużych firmach jest potrzeba udowodnienia przydatności informatyki w firmie i pokazania korzyści jakie ona niesie. Jest to nie tylko nasza, polska choroba.

AK. Jest dużo takich imponderabiliów, trudno przekładalnych na konkrety: a to trzeba, wypada, odpadniemy z konkurencji itp. Da się jednak pewne z nich przełożyć na konkretne pieniądze.

RB. Podam konkretny przykład. Zajmujemy się informatyzacją pewnej firmy ubezpieczeniowej, która - podobnie jak inne takie firmy - pracuje przez sieć agentów. System informatyczny pozwoli im szybciej rozliczać agentów, pieniądze szybciej wejdą do obrotu, a to już są konkretne korzyści. Inny kłopot, z którym borykają się wszystkie firmy ubezpieczeniowe, to zawieranie ubezpieczeń w kilku miejscach i uzyskiwanie odszkodowania za tę samą szkodę w wielu firmach. To też się da przeliczyć na pieniądze.

AK. Nawet proste stwierdzenie czy wpłynęła już płatność, czy musimy klienta monitować jest ważne.

RB. To samo dotyczy choćby prostej sprawozdawczości. Kiedyś trwało to tygodniami, a dobry system informatyczny "robi" ją w godziny. Jeżeli zaś weźmiemy przykład ubezpieczeń samochodowych, to mając dobry system można przeanalizować w jakim wieku kierowcy mają najmniej wypadków i oferować im najmniejszą stawkę. Podobnie można przeanalizować inne czynniki. W tym celu trzeba jednak w bazie "na wszelki wypadek" zawrzeć wiele informacji, które może teraz nie są potrzebne, ale przydadzą się za rok czy dwa.

Przyznaję, że rzadko spotykam się z zachętą firm do działania w takim kierunku. Zwykle mówią: "A po co nam to?"

Kłopoty z porozumiewaniem się

RB. Problem polega na tym, że między firmą informatyczną a klientem nie ma wspólnego języka. Obie strony traktują się z podejrzliwością, co do intencji. I tu brakuje kogoś, kto znając problemy firmy i możliwości informatyki stanowiłby coś w rodzaju rozjemcy. Musi to być jednak osoba z firmy, którą informatyzujemy lub wynajęty przez nią niezależny konsultant, ale znający dobrze specyfikę działania firmy.

Myślę, że w każdej umowie na informatyzację firmy powinno się eksplicite wskazać taką osobę, gdyż ułatwia to współpracę i przyspiesza realizację projektu. Nie może to być osoba na kierowniczym stanowisku, gdyż zwykle brak jej czasu na zajmowanie się projektem. Ponadto zawsze istnieje ryzyko, że pewne problemy, chwilowo najważniejsze dla firmy, przeważą nad ogólnym interesem i wpłyną niekorzystnie na jakość projektu. Krótko mówiąc, trzeba uważać, które sprawy są ważne tylko chwilowo, a które mają charakter długofalowy.

Tu dochodzimy do pytania czy firma powinna mieć informatyka lub nawet cały zespół informatyków na etacie?

RB. Jestem zdania, że tak. Nie powinni to jednak być ludzie, którzy sami piszą oprogramowanie dla firmy.

AK. Zwykle informatyk kojarzy nam się z programistą, a jest to zupełne nieporozumienie. Jeden z naszych kolegów mówi, że programistę zatrudnia się w razie potrzeby napisania programu, natomiast informatyk jest potrzebny stale. Popularny kiedyś zawód kodera, piszącego moduły programów zanikł, bo gdy korzystamy z narzędzi 4 generacji, wykorzystujemy możliwości komputera do wykonywania niewdzięcznej i żmudnej pracy kodowania. Informatyk może znać się na programowaniu, ale nie na tym polega jego praca.

Niestety, trudno będzie wytłumaczyć dyrektorowi firmy, że należy płacić człowiekowi tylko za to, że dużo wie o informatyce i o działalności swej firmy i wystarcza w zupełności, iż potrafi porozumiewać się z firmami informatycznymi tylko w celu sformułowania problemu.

RB. Myślę, że główny informatyk w firmie powinien znajdować się wysoko w hierarchii kierownictwa, aby móc zapewnić realizację jej celów strategicznych w produkcie informatycznym.

Praktyka zaś jest taka, że zespoły informatyczne są często oderwane od działalności firmy i nie wiedzą, jakie są jej cele strategiczne. Najczęściej zajmują się tylko konserwacją oprogramowania. Z danych statystycznych wynika, że konserwacja zajmuje ponad 80% czasu zespołu informatyków. Oni po prostu nie mają czasu myśleć o rozwoju.

AK. Z informatykami w firmie jest tak, jak z księgowymi: w małej firmie nie jest potrzebny, ale w większej jest niezbędny. Zresztą wydaje się, że informatyk w małej firmie będzie marnował swą wiedzę, więc nikt z ambicjami zawodowymi nie przyjdzie tam do pracy, bo po pewnym czasie przestanie być informatykiem.

Potrzeba usług

AK. Wydaje się, że takie potrzeby może załatwiać informatyk "na przychodne", z firmy usługowej, zajmujący się co jakiś czas, może raz na dzień, rutynowymi czynnościami, np. archiwizacją danych.

Czy są już takie firmy?

RB. Tworzą się. Zresztą wiele firm oferuje kontrakty na konkretne usługi.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200