Kto chce rządzić ludźmi, nie powinien ich gnać przed sobą, lecz sprawić, by podążali za nim! Monteskiusz

Jak zabrać się do projektu o budżecie równym Produktowi Krajowemu Brutto Polski? Co jest ważne: metodyka, procesy, narzędzia,ludzie? Nie ma pytań dobrych ani złych. Wszystkie są dozwolone, bo na żadne z nich nie ma właściwej odpowiedzi. Można tylko mnożyć wątpliwości, obiekcje i zastrzeżenia. Tak też pod koniec lat 80. działo się wśród kadry oficerskiej odpowiedzialnej za strategiczne projekty Departamentu Obrony USA. A że w opisywanym kraju szanuje się pieniądze podatników, zainwestowano i uczyniono wiele, by znaleźć skuteczne rozwiązanie tej kwestii. W tym celu m.in. powołano Instytut Inżynierii Oprogramowania (sławny SEI), który był odpowiedzialny za systematyczne wspieranie inicjatyw DoD, czyli wypracowanie metod zwiększających skuteczność realizacji projektów, zmniejszających straty i poprawiających jakość. Jednym z pierwszych kroków było opracowanie procedury weryfikacji podwykonawców i kontrahentów DoD. Bo jak sami nie wiemy, co i jak robić, to może warto przynajmniej ustalić kryteria wyboru i uwiarygodnienia tych, którzy twierdzą, że umieją? Szybko jednak okazało się, iż przeprowadzone badania weryfikacyjne podwykonawców dostarczają wniosków bardziej ogólnych. Wśród setek przebadanych firm wykryto pewne prawidłowości i wzorce rozwoju procesów wytwórczych oprogramowania. Firmy dojrzewają do jakości i produktywności zgodnie z pewnym powtarzalnym procesem, który można spróbować opisać. W ten sposób powstał model CMM, który umożliwia ulokowanie procesów firmy na określonym poziomie dojrzałości, spełniając pierwotny postulat DoD, wiadomo - firma dojrzała da sobie radę z projektem lepiej niż firma niedojrzała.

Z drugiej strony, CMM daje firmom wskazówki i wytyczne, jak szybciej i skuteczniej "dojrzewać", tak by spełnić postulaty modelu. W projakościowym klimacie początku lat 90. idea 5-stopniowej drogi rozwoju organizacji produkującej oprogramowanie zyskała oszałamiającą popularność. W podnoszenie poziomu dojrzałości zgodnie z opisanym w CMM modelem referencyjnym setki i tysiące firm na całym świecie zainwestowały olbrzymie pieniądze, ale jakiś czas temu o CMM ucichło. Podobnie jak o standardzie ISO 15504, który miał być nowocześniejszym i - co ważne - międzynarodowym następcą CMM.

CMM jednak nie "umarł", powraca w postaci nowego standardu CMMI! Obserwuję w związku z tym zwiększone zainteresowanie standardem i procesem certyfikacji. Dlaczego? Jak wiele innych inicjatyw projakościowych, np. ISO 9000, także model CMM wydaje się bardzo atrakcyjny dla organizacji i menedżerów szukających metod zwiększenia kontroli nad procesami organizacyjnymi oraz niezależnej, obiektywnej "certyfikacji", która ma potwierdzić gwarancje bezpieczeństwa dla klienta. Certyfikat ma dużą wartość marketingową dla tych, którzy pełnią rolę zewnętrznego dostawcy rozwiązań informatycznych dla dużych i bogatych, a więc wymagających klientów. Ma on także znaczenie dla wewnętrznych działów produkcyjnych w dużych korporacjach, które w ten sposób starają się poprawić swój wizerunek w oczach klientów zewnętrznego i wewnętrznego. Po drugiej stronie są oczywiście organizacje rządowe i prywatne, które używają tego samego modelu jako narzędzia do prześwietlania swoich potencjalnych dostawców i podwykonawców. W ten sposób CMM staje ramię w ramię z ISO 9000 i kilkoma innymi standardami jakości.

Niezaprzeczalnym faktem jest dzisiaj to, że CMM jest standardem przemysłowym w zakresie doskonalenia procesów wytwórczych oprogramowania. Zawiera bowiem nie tylko kompendium najlepszych praktyk w dziedzinie inżynierii oprogramowania, ale także przemyślany wzorcowy sposób ich wdrażania. CMM ma jednak wady. Pamiętajmy, że powstawał w czasie, gdy obowiązującą religią było zapewnianie jakości przez "budowanie powtarzalnych procesów". Takie podejście musiało siłą rzeczy odbić się na skrzywieniu CMM w stronę standaryzacji zarządzania i działań "ubezpieczających jakość" (quality assurance). Odpowiedzialność za te elementy systemu jakości jest rozłożona między ściśle określone procedury i osobiste zaangażowanie kadry kierowniczej. CMM nie mówi jednak, jak produkować dobre oprogramowanie. To podobne podejście do jakości produkcji zaczerpnięte z tego samego źródła jak w przypadku ISO 9000. Można się z tym nie zgadzać, ale tak jest, gdyż taka jest istota certyfikowanego systemu jakości.

I jest to główny zarzut "ruchu oporu" przeciwko wdrażaniu CMM. Że niby hamuje inicjatywę, opóźnia pracę, zmienia produkcję w biurokrację itd. Jest temu przeciwstawiane podobno "zdrowe" podejście obecne w lekkich metodykach - nie proces, a ludzie, nie procedury, a zasady itp. Nie chcę dyskutować o racjach obu stron, ale jedynie zwrócić uwagę na podnoszony najczęściej problem zniewolenia "prawdziwych developerów" przez procedury i procesy. Ucieknę się tu do militarnego porównania.

Kiedy żołnierzom jest potrzebny "regulamin walki"? Wtedy, gdy liczą się skala i potrzeba jasnego zdefiniowania ról dla dużej liczby uczestników działań teatru wojennego. Wtedy, gdy działania są rutynowe i konkurencyjność uzyskujemy dzięki lepszemu, szybszemu i tańszemu robieniu tego, co konkurencja robi, ale źle. W działaniach specjalnych, innowacyjnych, unikalnych i nierutynowych regulamin zawodzi. W takich sytuacjach najlepsze praktyki mogą okazać się niewystarczające, bo odnoszą się do tego, co się sprawdziło w przeszłości. Siły specjalne nie polegają na regulaminach. Są zmotywowane, dobrze wyszkolone, inteligentne i zintegrowane. Osiągają cele, których nikt przed nimi nie osiągał. I udaje im się, dlatego że łamią wszystkie zasady uważane w normalnym świecie za niezmienne.

Czy zatem mamy konflikt, czy wzajemne uzupełnianie się różnych podejść? To warte przemyślenia, tym bardziej że już niedługo otworzą się bramy Unii Europejskiej, w której nasi producenci oprogramowania będą musieli walczyć o przetrwanie. Czy przyjmą koncepcję zawodowych i regulaminowych armii tradycyjnych, czy uderzeniowych sił specjalnych - czas pokaże.

Tomasz Byzia jest dyrektorem ds. rozwoju firmy Premium Technology.