Jak nie dopuścić do powstawania niewłaściwych rozwiązań

Jakość produktów informatycznych jest w dużej mierze pochodną sposobu patrzenia pracowników na produkt i proces, w którym on powstaje - to po prostu wypadkowa specyficznego klimatu, jaki panuje w firmie.

Jakość produktów informatycznych jest w dużej mierze pochodną sposobu patrzenia pracowników na produkt i proces, w którym on powstaje - to po prostu wypadkowa specyficznego klimatu, jaki panuje w firmie.

Jedna z polskich firm informatycznych postawiła sobie za cel wysłanie w ciągu roku każdego pracownika na z góry określoną liczbę szkoleń. W pierwszej chwili, kiedy o tym usłyszałem, wydawało mi się to niczym nie uzasadnioną rozrzutnością. Jak to, nie mając planu projektów, nie znając liczby i rodzaju realizowanych zadań z góry ustalamy, że każdy ma zaliczyć określoną liczbę dni szkoleniowych? Zamysł ten jest jednak tak prosty w swojej istocie, że nie można odmówić mu słuszności. Jeśli nasi pracownicy nie będą chcieli się szkolić i korzystać ze zdobytej wiedzy, to jest oczywiste, że firma ma nie tych pracowników, których potrzebuje. Jeśli nie określi ona swojej strategii rozwoju, to rzeczywiście będzie niepotrzebnie wydawać pieniądze na nieprzydatne jej szkolenia. Uzasadnienie szkolenia jedynie posiadanymi w danym momencie projektami jest działaniem krótkoterminowym i z pewnością nie wynika ze strategii firmy. Tak więc powyższy, bardzo prosty i niezwykle łatwo mierzalny cel wyraża głęboką prawdę: inwestycja w ludzi jest inwestycją długoterminową i konieczną, zwłaszcza w branży informatycznej.

Grupa moich znajomych zaraz po studiach podjęła pracę w polskim oddziale jednej z zachodnich korporacji. Przez pierwszych kilka miesięcy zostali oni "przepuszczeni" przez serię szkoleń, zapoznających ich z produktem, który mieli dalej rozwijać. Standardy produktów poszczególnych kategorii, procedury postępowania w przeróżnych sytuacjach, normy zachowań oraz przegląd istniejących produktów i rozwiązań - jednym słowem kilkanaście tygodni poświęconych na zapoznanie się z dorobkiem korporacji w danym zakresie. Obserwując zachodnie korporacje działające w naszym kraju, z łatwością dostrzegamy różnicę (z dnia na dzień chyba coraz mniej widoczną) w podejściu do przygotowania pracownika do pracy oraz dbaniu o jego zawodowy rozwój. Stojące za tymi firmami nierzadko kilkudziesięcioletnie doświadczenie pozwoliło im na wkomponowanie szkoleń w cykl rutynowych działań firmy, a koszty ich organizacji są stałą pozycją ich budżetów.

Co umie nowy pracownik?

Cykl wytwarzania pojedynczego programu jest dzisiaj stosunkowo krótki. Program lub moduł w większym systemie to nakład pracy na poziomie kilku, może kilkunastu "osobotygodni". Zlecając taką pracę nowemu pracownikowi, można stosunkowo łatwo i szybko rozpoznać jego możliwości i umiejętności w zakresie kodowania. Znacznie więcej problemów sprawia sprawdzenie umiejętności analityka czy projektanta. Tutaj okres między powstaniem specyfikacji wymagań lub dokumentacji projektowej a oddaniem do eksploatacji powstałego na ich podstawie gotowego produktu jest zdecydowanie dłuższy. Biorąc pod uwagę konieczność zapoznania się z zagadnieniem, zebrania i opracowania wymagań, aż po testowanie i wdrożenie produktu, czas ten trzeba liczyć już nie w tygodniach, lecz w miesiącach. Nie ulega wątpliwości, że wykształcenie dobrej klasy analityka czy projektanta jest bardziej kosztowne niż zdobycie dobrej klasy programisty. Czy tutaj należy szukać przyczyn, dla których w wielu projektach w ogóle się nie projektuje, tylko od razu przystępuje do kodowania?

Problemy nie przewidywane

Często rezygnujemy z projektowania, ponieważ pierwsze wytworzone dokumenty projektowe prezentowały inne oprogramowanie niż to, które ma powstać. Podczas kodowania okazuje się, że projekt jest nieprzydatny, gdyż natrafiamy na problemy, które nie były przewidziane w dokumentacji, i musimy szybko podjąć się ich rozwiązania. Dlaczego tak się dzieje? Ponieważ mamy niedoświadczonych projektantów lub zbyt mało czasu poświęciliśmy na projektowanie systemu. Jeśli niepowodzenie dokumentów projektowych sprowadza się do braku odpowiedniego czasu przeznaczonego na ten etap wytwarzania, to droga do naprawy jest prosta. Gorzej, jeśli problem wynika z braku wiedzy o tym, które elementy dokumentacji są tylko ozdobnikiem, a które będą potrzebne i pożyteczne przy kodowaniu i testowaniu. Wiedza taka to przede wszystkim zasługa doświadczenia i przyjętego sposobu pracy. Jeśli doświadczenie to jest udokumentowane w postaci zdefiniowanego cyklu wytwórczego, to pierwszy krok mamy za sobą. Nie uchroni to nas przed bezmyślnym wpisywaniem w zdefiniowane szablony bezużytecznych treści. Co najwyżej pomoże przy szkoleniu swojej kadry, ułatwi sterowanie procesem jej kształcenia.

Oczywiście częstą przyczyną, dla której projekt staje się nieaktualny, są zmiany wymagań, które pojawiają się "za pięć dwunasta" i wówczas "ratując" terminy nie aktualizuje się projektu. Doświadczenie pracowników - zamiast do produkcji produktów wysokiej jakości - służy do wytwarzania produktów wysokiej rentowności. Na razie, niestety, w naszej rzeczywistości cele te są od siebie niezależne.

Głód nowych wyzwań

W produkcji oprogramowania najcenniejsza jest wiedza poszczególnych pracowników. Zarządzanie kadrą oraz naborem pracowników stają się jednym z najistotniejszych, a niekiedy wręcz kluczowym czynnikiem sukcesu biznesowego firmy. Z jednej strony istotne jest dbanie o ich właściwy rozwój zawodowy. Z drugiej, konieczne jest kumulowanie wiedzy w firmie oraz umiejętna jej propagacja wśród innych pracowników i zespołów. Na to wszystko nakłada się stwarzanie możliwości kariery zawodowej.

Utkwił mi w pamięci przypadek jednej z firm, która zatrudniła niezwykle dobrze zapowiadającą się grupę sześciu "świeżo upieczonych" absolwentów jednej ze szkół. Młodzi ludzie byli bardzo dobrze przygotowani do zawodu, poprzez świadomy dobór przedmiotów profilujących ukierunkowani na inżynierię oprogramowania, odpowiednio umotywowani do wdrażania w życie dobrych inżynierskich praktyk, ponadprzeciętnie wyczuleni na dobrą inżynierską robotę. Bardzo cenny zastrzyk "świeżej krwi". Po pierwszym roku pracy odeszły z firmy trzy osoby, w drugim - kolejne dwie. Powód? Z jednej strony firma nastawiona była na eksploatację i drenaż posiadanej już przez nich wiedzy, z drugiej - nie mogła zrównoważyć tego "wyzysku" skutecznymi mechanizmami zasilania ich w nową wiedzę i nowe doświadczenia. Napływ nowych kompetencji był słabszy niż ubytek już posiadanych. I wcale nie dlatego że w firmie tej nie było ciekawych projektów, nowych technologii czy też odpowiednich fachowców i narzędzi. Brakowało mechanizmów, które pozwoliłyby osobie przydzielonej do konkretnego projektu nie ograniczać się do doświadczeń tego tylko projektu. Ograniczenie do zadań z niego wynikających było zbyt silne. Za mało czasu i możliwości zostawało na twórczą dyskusję, na wymianę myśli. I nie widać było perspektyw na zmianę tego stanu.

Upowszechnianie wiedzy

Jak zapewnić przepływ wiedzy? Istnieje zapewne wiele metod. Mogą to być obowiązkowy staż nowo przyjmowanego pracownika we wszystkich działach firmy, wewnętrzne publikacje lub wbudowana w mechanizmy firmy okresowa (np. co kilkanaście miesięcy) rotacja pracowników między poszczególnymi zespołami, a może regularne sesje projektowe itd. Metoda musi być dostosowana do firmy i jej specyfiki, ważne by każdy z pracowników uświadamiał sobie, że zdobywa w niej wiedzę potrzebną i jemu, i firmie. Zarządzanie wiedzą zgromadzoną w firmie powinno znajdować wyraz w pewnej instytucjonalnej formie, która zapewni jej gromadzenie i propagację.

Trudnym problemem, przed jakim staje kierownik, jest ocena rozwiązań proponowanych przez jego pracowników. Często wybór lepszego rozwiązania odbywa się drogą intuicji i zaufania do osoby, która je przygotowała. Zbyt wiele rozwiązań jest przez nas przyjmowanych "na wiarę". Jak często dokonując oceny proponowanego rozwiązania, zadajemy sobie pytanie: "Dlaczego w ten, a nie w inny sposób?" Zapewne w wielu przypadkach nie ma większego znaczenia, czy określona funkcjonalność zostanie osiągnięta w ten czy inny sposób - po prostu wystarcza nam i naszym klientom, że będzie ona osiągnięta. Zapewne także zaufanie, jakim obdarzyliśmy osobę proponującą dane rozwiązanie, jest wystarczające do uwiarygodnienia przygotowanej propozycji. Jednak brak chwili zastanowienia się przy podejmowaniu decyzji o sposobie wykonania zadania powoduje utratę cennego elementu, jakim jest wymiana myśli między poszczególnymi pracownikami. To właśnie w tego typu rozmowach powstają odpowiednie postawy i zachowania, to przy takich okazjach można skutecznie propagować zastosowanie dobrych rozwiązań w innych projektach. Również tego typu spotkania mogą skutecznie służyć przekazywaniu w naturalny sposób wiedzy przez bardziej doświadczonych pracowników ich młodszym kolegom.

Dobrze przygotowana sesja projektowa jest niezwykle silnym i skutecznym środkiem kształcenia kadry. Dlaczego więc tak często można spotkać się ze stwierdzeniami, że wspólne zebrania są stratą czasu? Być może przeszkodą jest tutaj brak odpowiedniej dokumentacji analitycznej i projektowej, przez co odbycie takiej sesji jest niemożliwe z braku materiałów, które mogłyby podlegać ocenie i być podstawą do dyskusji. Być może przeszkodą jest sposób prowadzenia sesji, który zamiast wyzwalać pracę zespołową i uzyskanie efektu synergii, prowadzi do konfrontacji alternatywnych rozwiązań i marnotrawienia wysiłku na utrzymanie status quo uczestników sesji. Być może zarówno kadra kierownicza, jak i szeregowi pracownicy nie potrafią docenić zysków, jakie przynosi wymiana i upowszechnianie posiadanej wiedzy, a nie jej gromadzenie i pielęgnowanie.

Jakość produktów informatycznych to bezpośrednio wynik jakości myślenia pracowników. To nie prosty efekt nabytych przez nich umiejętności i technik, to w dużej mierze skutek przyjętych zachowań, prezentowanej postawy wobec otoczenia, a także pochodna sposobu patrzenia na produkt i proces, w którym on powstaje - to po prostu wypadkowa specyficznego klimatu, jaki panuje w firmie, w której pracują. Ci, którym kultura firmy nie odpowiada, zmieniają ją i szukają swojego miejsca. Ci, którzy zostają w firmie, swoją postawą przyczyniają się do wzmocnienia istniejących w niej procesów. Jeśli nie chcemy, aby w naszych firmach powstawały nieadekwatne i niewłaściwe rozwiązania, dbajmy przede wszystkim o to, by pracownicy myśleli o dobrej robocie, podobnie jak ich doświadczeni i kompetentni kierownicy, i aby efektami swojej pracy świadczyli, jakie jest firmowe rozumienie dobrego procesu i produktu.

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

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

TOP 200