To, co jest

Z trzech elementów: założeń, części elementarnych i konstrukcji - dokładna jest tylko konstrukcja i tylko ona może być wspomagana komputerowo. Formułowanie założeń jest sztuką, opis części elementarnych nauką i w tych dziedzinach sieć neuronowa naszego mózgu radzi sobie znacznie lepiej niż sztywne algorytmy. W przypadku konstrukcji sprawa może wyglądać różnie. W zasadzie zawsze najlepiej byłoby znaleźć formalną drogę - od składowych do celu, nie zawsze jednak w praktyce jest to możliwe ze względu na jej złożoność. Na przykład w szachach (jeszcze bardziej w starojapońskiej grze w go) umysł ludzki radzi sobie całkiem nieźle w porównaniu z komputerem, mimo precyzyjnych celów i precyzyjnych danych wejściowych. Są jednak przypadki, gdzie zasady działania są względnie proste, ale liczba danych całkowicie przekracza możliwości ludzkiej percepcji. W tych warunkach szybko realizowany algorytm przez komputer zdecydowanie góruje, trzeba jednak uzupełnić jego działanie o pozostałe dwa elementy.

I tu właśnie następuje konfliktogenny styk projektanta z użytkownikiem. Projektant potrzebuje precyzyjnego opisu, użytkownik nie może go dać, bo taki nie istnieje. Gdzieś tam jest podobny konflikt między naukowcem a inżynierem, związanym z opisem części elementarnych, trzeba jednak przyznać, że nie dotyczy on informatyków. Części elementarne, którymi się oni posługują, są już sformalizowane - producent sprzętu komputerowego (a ściślej biorąc producent układów scalonych) bierze odpowiedzialność za styk z prawami przyrody. Nieścisłości, jakie bywają w tym opisie, wynikają raczej z błędów konstrukcji niż z nieprecyzyjnych pomiarów, te za to powodują awarie, za które informatyk nie ponosi odpowiedzialności.

Klucz w reagowaniu na zmiany

Wróćmy więc do styku projektanta z użytkownikiem - czy ich konflikt jest rozwiązywalny. Niezaprzeczalny sukces techniki komputerowej wskazywałby, że tak. Jest tak w istocie pod warunkiem kompromisu. Użytkownik musi zgodzić się na formalny opis założeń (a więc na zamrożenie ich na jakiś czas), projektant - wziąć pod uwagę, że założenia te nie są ostateczne, użytkownik będzie miał prawo w przyszłości je zmienić. Ważne jest tylko, aby czas "życia" założeń był dłuższy niż okres realizacji systemu powiększony o czas jego amortyzacji. Wynikają stąd ważne wnioski, z których mało kto zdaje sobie sprawę. Po pierwsze, uproszczone założenia muszą mimo wszystko prowadzić do celu, a więc muszą zadowalać użytkownika. Jeżeli nie umiemy takich założeń podać, lepiej będzie całkowicie zrezygnować z budowy systemu i działać raczej intuicyjnie. Przynajmniej nie poniesiemy kosztów.

Po drugie, istniejący system ma sam w sobie znikomą wartość - będzie spełniał zadanie tylko do czasu, gdy uproszczenia okażą się zbyt duże, a stanie się to wcześniej czy później. Znacie państwo uczucie, gdy program, który na początku fascynował swoimi możliwościami, po pewnym czasie, po opanowaniu wszystkich jego funkcji, irytuje nas sztywnością. Ja doświadczam tego w stosunku do każdego programu, z którym pracuję trochę dłużej. Prawdziwą wartość ma natomiast mechanizm ciągłego dostosowywania algorytmu do wciąż zmienianych założeń. Kto jest w posiadaniu takiego mechanizmu, a wchodzą w jego skład nie hardware czy software, ale przede wszystkim ludzie i know-how, może być pewien sukcesu.

Jeśli spojrzy się z takiego punktu widzenia, kradzież programów nie ma najmniejszego znaczenia - złodziej odcina się przecież w ten sposób od producentów. Kupno programów ma sens tylko wtedy, gdy sprzedawca gwarantuje stały rozwój produktu. W sytuacji gdy otoczenie, w którym działamy, jest szybkozmienne, najlepiej zbudować w firmie swój dział rozwoju oprogramowania, o ile tylko stać nas na to i potrafimy zapewnić ciągłość jego działania. Producent zewnętrzny może nie nadążać wówczas z dostosowywaniem rozwiązań technicznych do procesów biznesowych. A przecież dynamika zmian współczesnego środowiska biznesowego staje się coraz większa.