Jak uniknąć wykonywania tych samych rzeczy wielokrotnie?

Dopóki produkty wewnętrzne, nie przeznaczone do bezpośredniej sprzedaży klientom, nie będą uznawane przez kierownictwo firmy za równie ważne i niezbędne do zapewnienia jej rynkowego sukcesu, dopóty nie można myśleć o skutecznym mechanizmie budowy i wykorzystania komponentów wielokrotnego użycia do tworzenia produktów rynkowych.

Dopóki produkty wewnętrzne, nie przeznaczone do bezpośredniej sprzedaży klientom, nie będą uznawane przez kierownictwo firmy za równie ważne i niezbędne do zapewnienia jej rynkowego sukcesu, dopóty nie można myśleć o skutecznym mechanizmie budowy i wykorzystania komponentów wielokrotnego użycia do tworzenia produktów rynkowych.

Wielokrotne użycie jest na stałe i od początku wkomponowane w informatykę. Parametryzowalne wołania funkcji i procedur są podstawą istnienia każdego programu. Każdy budowniczy programu z uwagą i skupieniem konstruuje biblioteki, tak aby później jak najmniej się napracować. Cecha ta jest bardzo dobrze widoczna wśród "rasowych" programistów, którzy często, nawet jeśli nie ma wyraźnej potrzeby, zamiast gotowego, uszytego na miarę rozwiązania, dostarczają definiowalny, parametryzowalny, nadający się prawie do wszystkiego komponent. Zastanawiające jest zatem to, że dążenia do uzyskania komponentów wielokrotnego użytku często stają się - zupełnie wbrew oczekiwaniom - przyczyną opóźnień w projektach i powiększania się ich pracochłonności. Komponenty okazują się często produktami jednokrotnego użycia, przyczyniając się do utrwalenia opinii, że w teorii reuse jest z pewnością możliwy, ale w przebogatej, otaczającej nas rzeczywistości praktyczne prawie się go nie wykorzystuje. Dlaczego? Ujmując w skrócie: reuse nie jest narzędziem realizacji strategicznych celów firmy, toteż nie jest wkomponowany w jej codzienne życie.

Bariera komunikacji i wsparcia

Mając samodzielnie do wykonania program i decydując się na budowę biblioteki, wiem, że będzie ona mi dostępna i będzie rozwijać się zgodnie z moimi oczekiwaniami i potrzebami. Kiedy wielkość produktu przekracza indywidualne możliwości, szukam takich osób, z którymi łatwo nawiązuję kontakt, do których mam zaufanie, że poczynione z nimi uzgodnienia będą obowiązywać. Naturalną linią podziału stają się niezależne od siebie komponenty programu, a problem porozumienia się między sobą nie jest niczym strasznym. Jeśli z programu opracowuje się system, muszę zbudować zespół. Kiedy urasta on do wielkości, która przekracza magiczną dla naszego pojmowania otoczenia liczbę siedmiu osób, motywacja do poszukiwania dalszego wsparcia zaczyna maleć. Budowanie znacznie większego zespołu traci sens, gdyż zarządzanie nim jest trudnym zadaniem, wykraczającym poza wiedzę i doświadczenie programistów. Poszukiwanie wsparcia w innych zespołach również nie ma sensu. Czas poświęcony na ustalenia z innymi zespołami będzie na tyle długi, że bardziej opłaca się samemu napisać dany fragment oprogramowania niż czekać na uzgodnienia tego z innymi. Możliwości rozwoju zaczynają się ograniczać do możliwości naszego zespołu. Jeśli wówczas poważnie pomyślimy o komponentach wielokrotnego użycia i wynikających stąd korzyściach, to w realizowaniu tego zamierzenia musi pomóc organizacja firmy bądź projektu.

Zbyt wiele pytań

Dlaczego podjęcie decyzji o wykorzystaniu gotowego komponentu przychodzi nam tak trudno? Czy dlatego że będziemy firmować czyjeś rozwiązanie? Czy dlatego że boimy się sytuacji, w której okaże się ono niewystarczające dla naszych potrzeb? Czy dlatego że będziemy uzależnieni od czyjejś wizji dalszego rozwoju tego produktu? Czy dlatego że nie wierzymy w możliwość uzgodnienia terminów realizacji? Czy dlatego że chcemy sobie udowodnić, iż również możemy zrobić taki sam produkt, tylko lepiej? Dlaczego w wykorzystaniu gotowego komponentu nie upatrujemy szansy na radykalne zmniejszenie nakładów naszej pracy na wytworzenie docelowego rozwiązania? Dlaczego w zastosowaniu gotowego półproduktu nie widzimy możliwości poprawienia jakości w naszym rozwiązaniu poprzez zmniejszenie ogólnej liczby błędów? Dlaczego w wymianie wzajemnych doświadczeń między zespołami nie dostrzegamy szansy na zawodowy rozwój? Dlaczego w budowaniu zaplecza technologicznego naszej firmy nie widzimy szansy na osobisty sukces? Pytania te prowadzą nas do pytania fundamentalnego: czy firma do realizacji swojej strategii biznesowej przewiduje miejsce na rozwój i utrzymanie produktów wewnętrznych? Dopóki produkty wewnętrzne, nie przeznaczone do bezpośredniej sprzedaży klientom, nie będą uznawane przez kierownictwo firmy za równie ważne i niezbędne do zapewnienia jej rynkowego sukcesu, dopóty nie można myśleć o skutecznym mechanizmie budowy i wykorzystania komponentów wielokrotnego użycia.

Osobista rywalizacja i wspólnota interesów

Stosunkowo łatwo przychodzi korzystanie z wzajemnych doświadczeń w ramach zespołu. Poczucie więzi oraz wspólnota interesów, jakie cechują jej członków, są zazwyczaj na tyle silne, że nie ma obaw, co do wzajemnej wymiany wiedzy i doświadczeń. Również rola kierownika, który ma bezpośredni wpływ na każdy odcinek pracy daje poczucie pewności, że rozwiązania będą powstawać w terminie i zgodnie z oczekiwaniami pozostałych członków zespołu. Korzystanie z doświadczeń innych grup firmy jest już znacznie trudniejszym wyzwaniem, które jest tym większe, im większa jest firma. I nie chodzi tutaj bynajmniej o sporadyczne formy wzajemnej pomocy, ale o stały, wbudowany w funkcjonowanie firmy, mechanizm przepływu wiedzy i doświadczeń. Dlaczego zespoły programistów pracujące w tej samej firmie tak często wykonują podobne fragmenty, tylko nieco inaczej? Komponenty takie muszą mieć rangę samodzielnych produktów, którym jest przypisana odpowiedzialność i podlegają one tym samym procedurom i procesom wytwórczym, jak produkty wytwarzane na zewnątrz firmy. W przeciwnym razie drastycznie spada zaufanie do półproduktów wytwarzanych przez poszczególne zespoły, gdyż brakuje jednego z najistotniejszych elementów - pewności, że produkt będzie utrzymywany i kierownictwo firmy nie wycofa się z finansowania jego dalszego rozwoju. Nie można polegać na komponentach, powstających jako produkty uboczne głównego nurtu wytwórczego firmy.

Postawa kierownictwa firmy w kreowaniu własnych komponentów wielokrotnego użycia jest niezwykle ważna również z innego punktu widzenia. Częstym pretekstem do wykonania własnego komponentu, nieznacznie różniącego się od istniejącego, są wymagania uzgodnione przez zespół z użytkownikiem. Pretekst przeradza się w niepodważalny argument, jeśli praca przebiega w pośpiechu. Zespół utrzymujący komponent wielokrotnego użycia, zaskoczony nagłą potrzebą jego użycia, nie ma czasu na przeprowadzenie zmiany. Powstanie kolejnego komponentu w następnym zespole staje się faktem. Tego typu konflikty interesów między dostarczeniem użytkownikowi na czas wymaganej przez niego funkcjonalności a doprowadzeniem do powstania kolejnego półproduktu o bardzo zbliżonych cechach do istniejącego powinny być adresowane do kierownictwa projektu (firmy) i tam rozstrzygane. Wydaje się, że tylko interes biznesowy związany z utrzymaniem w jednym miejscu komponentu wielokrotnego użycia może skłonić do rozstrzygania takich proble-mów na niekorzyść klienta (zapewne chwilową, ale tego klient może już nie chcieć zrozumieć).

U zarania projektu

O wykorzystaniu komponentów wielokrotnego użycia powinno się myśleć już na etapie zbierania i analizy wymagań. Czy jest to możliwe? Postawmy kilka pytań. Jaka jest wiedza pracowników o produktach, które powstają w jego firmie? I nie chodzi tu bynajmniej o znajomość sloganów reklamowych, ale o rzeczywistą znajomość tych produktów, ich architektury, zastosowanych tam rozwiązań i użytych do ich wytworzenia półproduktów. Jaka jest ich wiedza o planach rozwojowych poszczególnych produktów? Co im wiadomo o kierunkach badań i poszukiwań, jakie są prowadzone przez poszczególne zespoły? Odpowiedzi na te pytania mogą dać obraz tego, jak blisko (albo daleko) jest do sytuacji, w której komponenty wielokrotnego użycia stają się powszechną metodą pracy i sposobem myślenia o konstruowaniu oprogramowania.

W jakich sytuacjach chętnie sięga się po gotowe komponenty? Najczęściej chyba wtedy, gdy nie wystarcza czasu albo wiedzy, aby samemu napisać pewien element oprogramowania. Szuka się wtedy na rynku gotowego rozwiązania, które w najgorszym wypadku trzeba będzie przystosować do własnych potrzeb. Kupno produktów na rynku przychodzi stosunkowo łatwo, aczkolwiek im droższe komponenty, tym trudniejsza decyzja. Łatwiej wydać pieniądze niż kierować pracą zespołu wytwarzającego oprogramowanie. Produkt rynkowy ma zazwyczaj pewne referencje, a zatem odpowiedni poziom wiarygodności. Ocena funkcjonalności gotowego produktu jest zdecydowanie łatwiejsza niż spisanie wymagań i zaprojektowanie oprogramowania realizującego tę funkcjonalność. Jednak wiele tego typu inwestycji okazuje się inwestycjami chybionymi lub, wbrew wcześniejszym oczekiwaniom, jednokrotnego użycia. Dlaczego? Z tych samych powodów, z których nie stosuje się komponentów wielokrotnego użycia wytworzonych wewnątrz firmy. Zakupiony produkt nie uzyskuje rangi wewnętrznego produktu, za który ktoś odpowiada - za jego utrzymanie, rozwój i sposób adaptacji do własnych produktów. Często też wiedza o zakupionym produkcie, jego możliwościach i sposobach wykorzystania nie jest rozpowszechniana wewnątrz firmy.

To, jak firma zarządza posiadaną wiedzą (w tym informacją o produktach i komponentach), czy traktuje ją jak zasób, o który trzeba dbać i który wymaga utrzymania, jest dobrym miernikiem tego, jak nowoczesnym i dojrzałym jest ona organizmem. Nie powinna ograniczać się tylko do zbudowania mechanizmów komunikacji, które często sprowadzają się do poczty elektronicznej lub intranetu. Znacznie ważniejsza od wymiany informacji powinna być dla nas wymiana myśli. To, jak ktoś argumentuje, prowadzi wywód, dochodząc do określonych wniosków, jakie przy tym wkłada uczucie w poszczególne frazy, odbiera wątpliwości, reaguje na cudze problemy, to wszystko jest podstawą do budowania poczucia wzajemnego zaufania i pewności, że nikt nie jest sam podczas rozwiązywania problemów. Zaczynamy ufać, że wiedza i doświadczenie zgromadzone w firmie są nie tylko "do oglądania" (przeczytania w kolejnym e-mailu, zobaczenia na kolejnej stronie intranetu), lecz także "do wykorzystania" (z kimś mogę się spotkać, ktoś wysłucha moich problemów i pomoże mi je rozwiązać). Wbudowane w "krwioobieg" firmy mechanizmy wymiany informacji oraz idące w ślad za tym środki wspierające skuteczne porozumiewanie się stanowią fundament skutecznego wykorzystania komponentów wielokrotnego użycia. Reszta zależy od siły naszej wiary w to, że warto komuś zaufać.

Włodzimierz Serwiński jest pracownikiem Prokom Software SA, kierownikiem projektu Oprogramowanie KSI ZUS.