.gif){kind=small}
Artykuły
Sztuka tworzenia oprogramowania
Olgierd Skałowski
Na początku lat dziewięćdziesiątych kontakty z klientem w większości przypadków miały charakter merytoryczny. Było to spowodowane tym, że do rozmów z firmą oferującą aplikację, delegowano osoby, które miały wiedzę na temat przedmiotu potencjalnego kontraktu. Byli to najczęściej kierownicy działów użytkujących docelowy system.
Wszystko zmieniło się w połowie lat dziewięćdziesiątych, kiedy to duże, zachodnie firmy zaczęły uprawiać nowy styl marketingu. Sprzedaż software’u zaczęła ograniczać się do prezentacji slajdów i spotkań ze ścisłym kierownictwem firmy, na które przychodziła przedstawicielka handlowa. Nie miała ona wprawdzie wiedzy merytorycznej, ale za to była młoda i atrakcyjna... Taka transakcja mogła być jednak korzystna tylko dla jednej ze stron.
Pod koniec lat dziewięćdziesiątych pojawiła się opinia o złej jakości polskiego software’u. W tym czasie duże firmy wygrywały wielkie kontrakty metodami – nazwijmy je – nie do końca merytorycznymi. Były to przedsiębiorstwa, których jedynym celem było zawarcie umowy, czyli zwiększenie zysku, a nie sprzedanie i rozwijanie dobrych aplikacji. Nic więc dziwnego, że spowodowało to ugruntowanie się negatywnej opinii nt. oprogramowania tworzonego przez polskie firmy. Wystarczy przeczytać pierwsze strony gazet z tamtego okresu, by przypomnieć sobie o dużych wpadkach w branży IT. Nie mogło to pozostać bez echa. Najbardziej ucierpiały na tym niewielkie firmy, których jedynym orężem w walce z konkurencją była jakość rozwiązań, w którą w tej sytuacji mało kto wierzył.
Dopiero, gdy na początku 2000 roku do opinii publicznej dotarły informacje o sukcesach polskich informatyków, którzy wygrywali prestiżowe, międzynarodowe konkursy, negatywne nastawienie do polskich rozwiązań zaczęło się zmieniać. Społeczeństwo dowiedziało się, że mamy fantastycznych informatyków. Polscy programiści, w przeciwieństwie do swoich zachodnich kolegów, zazwyczaj mają wiedzę nt. całego realizowanego projektu.
Większość zachodnich programistów powinno się w zasadzie nazywać nie programistami, a koderami. Ich praca polega bowiem na oprogramowywaniu kawałka projektu bez znajomości całego tworzonego systemu. Ponadto bywa też, że projekt jest realizowany przez osobę, która nie zna możliwości środowiska deweloperskiego. W moim przekonaniu nie można stworzyć dobrego systemu, jeżeli główni wykonawcy nie uczestniczą w merytorycznej fazie jego projektowania, i jeśli nie uwzględnia się możliwości i ograniczeń narzędzi deweloperskich, a także doświadczenia programistów. Jeżeli chce się stworzyć optymalne rozwiązanie, to już w fazie projektu, poza wiedzą merytoryczną niezbędna jest pełna wiedza nt. sposobu tworzenia tego systemu.
Wychodzę z przekonania, że budowa aplikacji powinna być sztuką a nie odrabianiem pańszczyzny. Powiedziałbym, że jest to rodzaj specyficznego rzemiosła, i to rzemiosła artystycznego. Programowanie jest pracą interdyscyplinarną i kreatywną, w której umiejętność abstrakcyjnego, twórczego myślenia jest niezbędna, a jej efektem mogą być nieprawdopodobne algorytmy. Jakość tworzenia jest szczególnie ważna z tego powodu, że w cyklu życia systemu proces programowania wielokrotnie powraca. Jest to przecież cykl iteracyjny i stworzony kod zaczyna być doceniany dopiero po jakimś czasie.
Wróćmy jeszcze do drugiej połowy lat dziewięćdziesiątych, czyli do okresu „wilczego kapitalizmu”. W tym czasie niewielkie firmy, które chciały wygrywać merytoryką a nie marketingiem, zaczęły wypadać z rynku. Myślę, że obecnie ta sytuacja się odwraca. Odbiorcy mają coraz większą świadomość swoich potrzeb i wymagają coraz lepszego dostosowania (indywidualizacji). Ponadto doskonale wiedzą, że firma o większym przebiciu marketingowym, niekoniecznie “tworzy lepszy software”. Jest mnóstwo dowodów świadczących o tym, że małe przedsiębiorstwo może stworzyć bardzo dobre aplikacje.
Obecnie prezesi i właściciele przedsiębiorstw, w przeciwieństwie do decydentów z lat dziewięćdziesiątych, mają już świadomość, że eksploatacja aplikacji to proces i nie wystarczy tu dokonać jednorazowego zakupu. W system trzeba inwestować, trzeba go rozwijać, i stale nadążać za zmianami warunków wewnętrznych i zewnętrznych. Zdają sobie również sprawę ze swojej niewiedzy w dziedzinie systemów IT i nie podejmują już decyzji o zakupie bez porady konsultantów. Często też przekonują się, że kupno oprogramowania „szytego na miarę” jest w wielu przypadkach inwestycją bardziej efektywną.
Dzisiaj nieporównywalnie częściej, w stosunku do lat dziewięćdziesiątych, decyzje o zakupie software’u podejmują osoby, które mają w tym zakresie wiedzę merytoryczną. Wzrost konkurencji sprawił, że atrakcyjnie wyglądający sprzedawcy, którzy jednak nie mają wiedzy merytorycznej z zakresu sprzedawanego towaru, na nikim już nie robią wrażenia. Przeminął też mit, że duża firma gwarantuje wysoką jakość oprogramowania.
Jednak małe firmy, żeby przetrwać, muszą znaleźć sobie specjalizację. Powodem tego jest choćby tendencja polegająca na tym, że duża firma najczęściej chce współpracować z inną dużą firmą. Muszą nastąpić pewne przewartościowania, aby w Polsce nastąpiła stabilizacja warunków funkcjonowania małych i dużych firm. Po pierwsze, małe firmy muszą zacząć specjalizować się w określonych, kompletnych rozwiązaniach niszowych, które można stosować w różnych środowiskach informatycznych. Należy zaznaczyć, że taki proces już od jakiegoś czasu następuje. Po drugie, duże firmy muszą po partnersku traktować małe firmy i akceptować ich indywidualność. Po trzecie, odbiorcy muszą wiedzieć, co to jest system informatyczny, jakie znaczenie dla przedsiębiorstwa ma informatyka i jak powinno się nią zarządzać. Jak wiadomo, systemy informatyczne przetwarzają dane i produkują informacje, a więc są strukturami produkcyjnymi w klasycznym tego słowa znaczeniu. Bez uszczerbku dla kogokolwiek, można organizację systemu informatycznego porównać do organizacji wydziału produkcyjnego w przemyśle. Zauważalne są bardzo duże analogie – dział utrzymania ruchu, główny energetyk, główny mechanik, park maszynowy, inwestycje w środki produkcji, itd.
Wydaje mi się jednak, że większość decydentów nadal nie zdaje sobie sprawy z ogromnego znaczenia systemów informatycznych. Tymczasem każdą awarię wdrożonej aplikacji można porównać z awarią na hali produkcyjnej. Porównywalne mogą być nawet związane z tymi awariami straty. W organizacji pionów informatycznych muszą znaleźć się analogie do organizacji wydziałów utrzymania ruchu na produkcji.
Powszechne zrozumienie tych prawidłowości umożliwi lepszą współpracę dostawców i użytkowników rozwiązań informatycznych. Sądzę, że najbliższe 5 lat będzie okresem, w którym nastąpi jeszcze większe dowartościowanie pracy twórczej programistów i projektantów rozwiązań informatycznych.
Wszystko zmieniło się w połowie lat dziewięćdziesiątych, kiedy to duże, zachodnie firmy zaczęły uprawiać nowy styl marketingu. Sprzedaż software’u zaczęła ograniczać się do prezentacji slajdów i spotkań ze ścisłym kierownictwem firmy, na które przychodziła przedstawicielka handlowa. Nie miała ona wprawdzie wiedzy merytorycznej, ale za to była młoda i atrakcyjna... Taka transakcja mogła być jednak korzystna tylko dla jednej ze stron.
Pod koniec lat dziewięćdziesiątych pojawiła się opinia o złej jakości polskiego software’u. W tym czasie duże firmy wygrywały wielkie kontrakty metodami – nazwijmy je – nie do końca merytorycznymi. Były to przedsiębiorstwa, których jedynym celem było zawarcie umowy, czyli zwiększenie zysku, a nie sprzedanie i rozwijanie dobrych aplikacji. Nic więc dziwnego, że spowodowało to ugruntowanie się negatywnej opinii nt. oprogramowania tworzonego przez polskie firmy. Wystarczy przeczytać pierwsze strony gazet z tamtego okresu, by przypomnieć sobie o dużych wpadkach w branży IT. Nie mogło to pozostać bez echa. Najbardziej ucierpiały na tym niewielkie firmy, których jedynym orężem w walce z konkurencją była jakość rozwiązań, w którą w tej sytuacji mało kto wierzył.
Dopiero, gdy na początku 2000 roku do opinii publicznej dotarły informacje o sukcesach polskich informatyków, którzy wygrywali prestiżowe, międzynarodowe konkursy, negatywne nastawienie do polskich rozwiązań zaczęło się zmieniać. Społeczeństwo dowiedziało się, że mamy fantastycznych informatyków. Polscy programiści, w przeciwieństwie do swoich zachodnich kolegów, zazwyczaj mają wiedzę nt. całego realizowanego projektu.
Większość zachodnich programistów powinno się w zasadzie nazywać nie programistami, a koderami. Ich praca polega bowiem na oprogramowywaniu kawałka projektu bez znajomości całego tworzonego systemu. Ponadto bywa też, że projekt jest realizowany przez osobę, która nie zna możliwości środowiska deweloperskiego. W moim przekonaniu nie można stworzyć dobrego systemu, jeżeli główni wykonawcy nie uczestniczą w merytorycznej fazie jego projektowania, i jeśli nie uwzględnia się możliwości i ograniczeń narzędzi deweloperskich, a także doświadczenia programistów. Jeżeli chce się stworzyć optymalne rozwiązanie, to już w fazie projektu, poza wiedzą merytoryczną niezbędna jest pełna wiedza nt. sposobu tworzenia tego systemu.
Wychodzę z przekonania, że budowa aplikacji powinna być sztuką a nie odrabianiem pańszczyzny. Powiedziałbym, że jest to rodzaj specyficznego rzemiosła, i to rzemiosła artystycznego. Programowanie jest pracą interdyscyplinarną i kreatywną, w której umiejętność abstrakcyjnego, twórczego myślenia jest niezbędna, a jej efektem mogą być nieprawdopodobne algorytmy. Jakość tworzenia jest szczególnie ważna z tego powodu, że w cyklu życia systemu proces programowania wielokrotnie powraca. Jest to przecież cykl iteracyjny i stworzony kod zaczyna być doceniany dopiero po jakimś czasie.
Wróćmy jeszcze do drugiej połowy lat dziewięćdziesiątych, czyli do okresu „wilczego kapitalizmu”. W tym czasie niewielkie firmy, które chciały wygrywać merytoryką a nie marketingiem, zaczęły wypadać z rynku. Myślę, że obecnie ta sytuacja się odwraca. Odbiorcy mają coraz większą świadomość swoich potrzeb i wymagają coraz lepszego dostosowania (indywidualizacji). Ponadto doskonale wiedzą, że firma o większym przebiciu marketingowym, niekoniecznie “tworzy lepszy software”. Jest mnóstwo dowodów świadczących o tym, że małe przedsiębiorstwo może stworzyć bardzo dobre aplikacje.
Obecnie prezesi i właściciele przedsiębiorstw, w przeciwieństwie do decydentów z lat dziewięćdziesiątych, mają już świadomość, że eksploatacja aplikacji to proces i nie wystarczy tu dokonać jednorazowego zakupu. W system trzeba inwestować, trzeba go rozwijać, i stale nadążać za zmianami warunków wewnętrznych i zewnętrznych. Zdają sobie również sprawę ze swojej niewiedzy w dziedzinie systemów IT i nie podejmują już decyzji o zakupie bez porady konsultantów. Często też przekonują się, że kupno oprogramowania „szytego na miarę” jest w wielu przypadkach inwestycją bardziej efektywną.
Dzisiaj nieporównywalnie częściej, w stosunku do lat dziewięćdziesiątych, decyzje o zakupie software’u podejmują osoby, które mają w tym zakresie wiedzę merytoryczną. Wzrost konkurencji sprawił, że atrakcyjnie wyglądający sprzedawcy, którzy jednak nie mają wiedzy merytorycznej z zakresu sprzedawanego towaru, na nikim już nie robią wrażenia. Przeminął też mit, że duża firma gwarantuje wysoką jakość oprogramowania.
Jednak małe firmy, żeby przetrwać, muszą znaleźć sobie specjalizację. Powodem tego jest choćby tendencja polegająca na tym, że duża firma najczęściej chce współpracować z inną dużą firmą. Muszą nastąpić pewne przewartościowania, aby w Polsce nastąpiła stabilizacja warunków funkcjonowania małych i dużych firm. Po pierwsze, małe firmy muszą zacząć specjalizować się w określonych, kompletnych rozwiązaniach niszowych, które można stosować w różnych środowiskach informatycznych. Należy zaznaczyć, że taki proces już od jakiegoś czasu następuje. Po drugie, duże firmy muszą po partnersku traktować małe firmy i akceptować ich indywidualność. Po trzecie, odbiorcy muszą wiedzieć, co to jest system informatyczny, jakie znaczenie dla przedsiębiorstwa ma informatyka i jak powinno się nią zarządzać. Jak wiadomo, systemy informatyczne przetwarzają dane i produkują informacje, a więc są strukturami produkcyjnymi w klasycznym tego słowa znaczeniu. Bez uszczerbku dla kogokolwiek, można organizację systemu informatycznego porównać do organizacji wydziału produkcyjnego w przemyśle. Zauważalne są bardzo duże analogie – dział utrzymania ruchu, główny energetyk, główny mechanik, park maszynowy, inwestycje w środki produkcji, itd.
Wydaje mi się jednak, że większość decydentów nadal nie zdaje sobie sprawy z ogromnego znaczenia systemów informatycznych. Tymczasem każdą awarię wdrożonej aplikacji można porównać z awarią na hali produkcyjnej. Porównywalne mogą być nawet związane z tymi awariami straty. W organizacji pionów informatycznych muszą znaleźć się analogie do organizacji wydziałów utrzymania ruchu na produkcji.
Powszechne zrozumienie tych prawidłowości umożliwi lepszą współpracę dostawców i użytkowników rozwiązań informatycznych. Sądzę, że najbliższe 5 lat będzie okresem, w którym nastąpi jeszcze większe dowartościowanie pracy twórczej programistów i projektantów rozwiązań informatycznych.
