Jeśli coś idzie nie tak, jakbyśmy tego chcieli, to nie zakładajmy od razu, że jest to wina tych, którzy ujawnili nam ten problem.

Jak często zdarza się, że zlecający wykonanie zestawu konkretnych raportów otrzymuje w to miejsce ich generator oraz wykonane, jakby przy okazji, zlecone raporty? Istotne jest tutaj spostrzeżenie, iż powstają one przy okazji, co w praktyce często oznacza, że oczekiwana ich postać i zawartość informacyjna odbiegają od oczekiwań użytkownika. Dlaczego? Prawdopodobnie gros czasu pracy przeznaczonego na tworzenie raportów spożytkowano na pracę nad generatorem. Z uwagi na to, iż w czasie przeznaczonym na wykonanie raportów nie można wykonać generatora, to więc, co szumnie nazywane jest generatorem, ma tak wiele ograniczeń, że nie sposób uzyskać oczekiwanej postaci raportów. Jakie rozwiązanie proponują programiści, gdy się okaże, że raporty muszą zostać zmienione, gdyż nie uwzględniają wielu istotnych wymagań użytkownika? Oczywistą propozycją jest przebudowa generatora, dzięki niej zwiększą się jego możliwości.

W efekcie, zamiast wykonanego zadania i rozwiązanego problemu, wciąż mamy nie zaspokojone potrzeby użytkownika, pracujących ponad normę programistów i w miejsce jednego - dwa produkty do utrzymywania i rozwoju w przyszłości. Na szczęście, liczba gotowych produktów o zaawansowanych funkcjach tworzenia i formatowania raportów jest dzisiaj tak duża, że opisane przeze mnie zachowania powoli przechodzą do lamusa. Ważne jest jednak, aby sobie uzmysłowić mechanizm, z jakim mamy do czynienia.

Kontrola bez urazy

Czemu tak naprawdę ma służyć kontrola prac? Jeśli wprowadzamy ją tylko po to, aby ocenić zespół realizujący zadanie, to znacznie mniej nakładów poniesiemy, zaniechając kontroli, a spokojnie czekając na produkt końcowy. Angażowanie siebie i członków zespołu w weryfikowanie postępu prac tylko po to, aby ocenić zespół, nie ma sensu. Ocenie powinna służyć jasna - wypowiedziana na początku prac - deklaracja celów, jakie należy osiągnąć, i miar sukcesu. Sama ocena powinna się odbyć po zakończeniu prac. Dlaczego więc kontrolować zespół? Czy nie mamy zaufania do naszych pracowników? Czy uważamy, że będą się "obijać"? Czy podejrzewamy, że wykonają produkt słabej jakości? Przecież znamy ich nie od dziś, są dobrze motywowani i chcą wykonać kawał dobrej roboty - po co więc ich kontrolować? Przede wszystkim trzeba sobie i im uzmysłowić, że kontrola ma umożliwić kierownikowi odpowiedź, na ile dobrze i skutecznie przygotował on proces produkcyjny. Tak naprawdę kontrola nie służy do oceny postępowania zespołów, ale do oceny trafności decyzji i dalekowzroczności kierownika. Wiedza o tym, jak zespół wykonuje produkt, jakie jest tempo pracy i przyczyny ewentualnych problemów, to wiedza o tym, jak trafne i skuteczne były decyzje menedżera projektu. To wiedza o tym, na ile dobrze zorganizowany jest proces wytwórczy. Kierownik, który chce skutecznie działać, musi taką wiedzę posiadać, a członkowie zespołu, dbając o własny, dobrze pojmowany interes, powinni mu takiej wiedzy dostarczać.

A jednak strach

Dlaczego więc boimy się kontroli? Z pewnością dlatego że może ona ujawnić nasze niedostatki, bolączki czy nieudolności. Przy wprowadzaniu kontroli do procesu wytwórczego niezwykle istotna jest postawa kierownictwa wobec stwierdzonych osobistych zawinień. Jeśli jedyną reakcją jest kara (jakkolwiek miałaby się ona przejawiać), wówczas działania kontrolne bardzo szybko zdegenerują się, a kontrole zespołów przerodzą w zabawę w policjantów i złodziei. Niezwykle istotne jest to, aby dostrzeżone braki kompetencji były sygnałem do podjęcia odpowiednich działań wspierających zespół: przygotowania odpowiednich szkoleń, zasilenia zespołu specjalistami odpowiedniej klasy, zmiany organizacji prac, być może w ostateczności zmniejszenia zakresu prac i przekazania trudniejszych zadań innym zespołom.

Kontrola często jest utożsamiana z działaniem bezdusznym, biurokratycznym i pozbawionym głębszego sensu. Co bowiem osoba przychodząca z zewnątrz może powiedzieć o moim produkcie, mojej pracy, moich problemach, uwarunkowaniach, w których realizuję produkt. Nic - poza machinalnym odnotowaniem terminu opóźnienia, niezgodności wykonanych produktów z zaleceniami i standardami, policzeniem pism i skarg od klienta. Wiadomo, że za tymi suchymi liczbami stoją ludzkie ambicje, osobiste zaangażowanie, obiektywne trudności, ogromny wysiłek, by sprostać postawionemu zadaniu. Dlatego nie wolno na podstawie tych suchych liczb, które wynikają z przeprowadzonych kontroli, podejmować restrykcji wobec kontrolowanego zespołu. Z drugiej strony, trzeba jednak pamiętać, że owa bezduszność jest pożądana. Zadaniem kontroli jest właśnie oderwanie się od tych uwarunkowań, w których funkcjonuje zespół wykonujący produkt, i obiektywne stwierdzenie stanu faktycznego. Te suche fakty dają nam obraz miejsc, gdzie leżą nasze problemy. W wyniku kontroli trzeba poddać analizie to, co budzi nasz niepokój, i dopiero na podstawie tej wnikliwej analizy wyciągnąć wnioski.

Jeśli od dłuższego czasu nie możemy zatwierdzić wymagań co do systemu, to nie zakładajmy od razu, że nasi pracownicy prowadzą analizę wymagań w sposób nieudolny. A może klient nie jest w stanie sformułować wymagań i boi się otwarcie o tym powiedzieć? A może formułowane wymagania są wzajemnie sprzeczne i nasi pracownicy ujawniają wewnętrzne konflikty u klienta. Jeśli stwierdzamy, że projekty są słabe i nie opisują dobrze powstającego systemu, nie zakładajmy od razu, że nasi projektanci to umysłowi degeneraci. A może zmiany założeń następują tak często i są tak znaczące, iż nie sposób utrzymać w ryzach spójności produktu i opisującego go projektu? A może dziedzina wiedzy, którą opisują, jest na tyle szeroka i złożona, że nie sposób w dostępnym im czasie sensownie opisać konstrukcji systemu? Jeśli powstające programy zawierają wiele błędów, to nie zakładajmy od razu, że ich przyczyną jest niechlujność i bałaganiarstwo programistów. Może po prostu nie mają oni wystarczającego doświadczenia w kodowaniu w tym środowisku? Być może projekt był zmieniany kilkakrotnie podczas kodowania? Jeśli produkt nie powstaje zgodnie z harmonogramem, to nie zakładajmy od razu, że jest to wynik "obijania" się poszczególnych pracowników. Może się zdarzyć, że w trakcie testów wykryli nie udokumentowane błędy systemu operacyjnego lub motoru bazy danych i musieli przebudować znaczną część systemu? A może integracja z innymi zespołami zawiodła i spowodowała poślizg? Jeśli coś idzie nie tak, jakbyśmy chcieli, to nie zakładajmy od razu, że jest to wina tych, którzy ujawnili nam ten problem.

Z konsekwencjami

Kontrola, aby była skuteczna, musi zakładać, że w jej wyniku zostaną wprowadzone zmiany procesu wytwórczego lub specyfikacji produktu lub też zostaną podjęte zmiany w alokacji zasobów. Kontrola musi być skierowana do tych, którzy tę pracę zlecili i ustanowili warunki jej realizacji. Aby wyniki kontroli stanowiły właściwe przesłanki do podjęcia decyzji, musi być ona niezależna od osób, które wykonują powierzoną pracę. Samo stwierdzenie, że zespół nie radzi sobie z produktem, to za mało. Trzeba jasno określić, dlaczego sobie nie radzi? Bo jest za słaby, ma niedoświadczoną kadrę, zdefiniowany zakres prac okazał się za duży na siły zespołu? Bo zmieniające się wymagania użytkownika skutecznie dezorganizują pracę, narzuty organizacyjne wprowadzone przez kierownictwo firmy są na tyle duże, że brakuje czasu na wykonanie produktu, traci czas na wykonywanie niepotrzebnych rzeczy? Bo trafił na problemy, które przekraczają jego siły i możliwości?

Pojawiające się problemy mówią nam wiele o jakości naszego procesu wytwórczego. Ważne jest, aby błędy były wskazywane i poprawiane, ale najważniejsza jest analiza, dlaczego zostały popełnione. Często pod presją czasu, po prostu zmęczeni i obarczeni innymi zadaniami, zapominamy o tym, co oczywiste. Jeśli nawet tego czasu mamy dużo, często nie wiemy, co trzeba sprawdzić. Ta wiedza, którą dysponuje doświadczona kadra, powinna przenosić się na pozostałych pracowników. Niezwykle pomocnym instrumentem są tutaj szablony i listy kontrolne. Oczywiście, wytworzenie szablonu czy listy kontrolnej to nie wszystko - trzeba zadbać o to, aby były one sprawdzane oraz, co najważniejsze, by sprawdzenie to nie odbywało się na pięć minut przed oddaniem produktu.

<hr>

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