Niedoceniany czynnik ludzki

Z Hanem Van Loonem, profesorem na Uniwersytecie Nottingham Trent i University of Business and International Studies, rozmawia Antoni Bielewicz.

Z Hanem Van Loonem, profesorem na Uniwersytecie Nottingham Trent i University of Business and International Studies, rozmawia Antoni Bielewicz.

Na jakim etapie dojrzałości w zakresie kontroli jakości znajdują się dziś firmy tworzące oprogramowanie?

Trudno jednoznacznie odpowiedzieć na to pytanie. Są firmy bardzo zaawansowane, zwłaszcza jeśli chodzi o procesy i zasoby. To typowe firmy skupione na doskonaleniu procesu. Z drugiej strony wiele firm jest bardzo słabych. Zwłaszcza Europa jest pod tym względem mocno zapóźniona. Posługując się terminologią znaną choćby z CMMI (Capability Maturity Model Integration), czy normy ISO 15504, większość firm należałoby określić, że znajdują się na pierwszym bądź drugim poziomie dojrzałości. 2% osiąga poziom trzeci lub czwarty. Reszta zadowala się bardzo zgrubnym opisem procesów.

Czy nowoczesne metody zapewniania jakości oprogramowania mają jakieś braki?

Niewiele firm wciąż dostrzega znaczenie czynnika ludzkiego. Generalnie metody zarządzania można podzielić na trzy grupy - te skupione na: procesach, technologii i ludziach. Niewiele jest natomiast metod, które uwzględniałyby wszystkie te trzy czynniki na równi. Zwłaszcza czynnik ludzki jest mocno niedoceniany, zwykle kosztem nadmiernego przywiązania do procedur. Tymczasem w przypadku "pracowników wiedzy", a takimi niewątpliwie są programiści, ogromne znaczenie odgrywa ich wiedza, intuicja, czy możliwość dostosowywania się do zmieniających się warunków.

Uwzględnienie tych dodatkowych czynników gwarantuje sukces?

Niedoceniany czynnik ludzki

Han Van Loon

Może, ale nie musi. To zależy od stopnia dojrzałości ludzi i kultury organizacyjnej. Przykładowo, wszelkie lekkie metodyki programowania i prowadzenia projektów, takie jak Agile i XP (eXtreme Programming), mogą się sprawdzić w miejscach, gdzie panuje duża dojrzałość i dyscyplina. Pracownicy muszą sami umieć zwracać uwagę na jakość, a do tego w organizacji potrzebna jest dodatkowo osoba, która będzie w całości dedykowana do rozwiązywania problemów z nią związanych. Przy zastosowaniu tego typu lekkich metod nie można odkładać pewnych rzeczy "na później". Większość firm nie jest gotowa na stosowanie takich lekkich metod projektowania. Nie ma w nich prawdziwych zespołów projektowych, a ich współdziałanie nie kreuje żadnej synergii.

Stosowanie lekkich metod zarządzania projektami, takich jak Agile, wymaga wdrożenia zasad dyscyplinujących całą organizację, np. takich jak promowana przeze mnie metodologia STARS. Bez odpowiednich reguł, którymi kieruje się cała organizacja, a zwłaszcza jej menedżerowie, wszelkie lekkie metody zarządzania projektami - opierające się na ograniczonej liczbie informacji - nie mają sensu.

Te wszystkie lekkie metody w powszechnej opinii zakładają rezygnację z procesowego zarządzania przedsięwzięciem informatycznym...

To typowy błąd. Metody takie jak XP kładą nacisk na kontakt osoba-osoba. Wszystko jest jednak kształtowane w zgodzie z pewnymi procesami, znacznie mniej skrępowanymi procedurami, ale istniejącymi.

Czy lekkie metody prowadzenia projektów są na tyle uniwersalne, że nadają się do prowadzenia każdego rodzaju projektów?

W przypadku wielkich przedsięwzięć, takich jak chociażby realizowany przeze mnie projekt systemu do zarządzania ruchem statków, zawsze powstaje potrzeba pewnego dopasowania projektu do produktu, który tworzymy. Generalnie jednak w tym przypadku lepsze są "ciężkie metodologie".

Czy można w ramach jednej organizacji realizować projekty w oparciu zarówno o "ciężkie", jak i o "lekkie" metody projektowe?

W dużej mierze tak. Wprowadzając lekkie metody zarządzania, trzeba najpierw dokładnie przyjrzeć się członkom zespołu. W jaki sposób pracują? Jakie wartości wyznają? Jak podchodzą do nowych zadań? Z drugiej strony mogą one zadziałać skutecznie jedynie w miejscach, gdzie kultura organizacyjna umożliwia wypowiedzenie się wszystkich zainteresowanych. Gdzie każdy nawet najniżej wykwalifikowany członek zespołu projektowego ma szansę wyrazić swoją opinię.

Nie każdemu programiście odpowiadają też lekkie metody prowadzenia projektów. Niektórzy przyzwyczajają się bardzo szybko, innym przychodzi to z trudem, jeszcze inni z chęcią realizują 1, 2 projekty, potem jednak chcą wracać do znanych już wcześniej metod. To wynika poniekąd ze zróżnicowania pomiędzy ludźmi. Niektórzy wolą zastanowić się nad problemem, inni zaś najchętniej zaraz zabraliby się do roboty. Wszystko znów sprowadza się do czynnika ludzkiego.

To oznacza, że firmy programistyczne czeka jeszcze dużo pracy...

Niekoniecznie. Firmy konsultingowe pomagające we wdrażaniu standardu CMMI wytworzyły takie przekonanie, że wprowadzanie w firmie metod zarządzania jakością to wieloletni proces. Najpierw musimy osiągnąć poziom pierwszy. Potem, po 3, 4 latach drugi, potem kolejne. Takie działanie jest nieefektywne, choć pewnie korzystne z punktu widzenia firm doradczych. Ja namawiam klientów na zastanowienie się, które z procesów są kluczowe i doskonalenie przede wszystkim ich. Działając w ten sposób w ciągu 18 miesięcy, można doprowadzić każdy proces niemalże do doskonałości.

Jak to zrobić? Dokonując zmian i co pewien czas, np. co pół roku przeglądając ich efekty, także automatyzując część procesów, ale tylko tych, które zostały wcześniej dopracowane. Wiele razy byłem świadkiem sytuacji, w której automatyzowano niedopracowany proces. Efektem tego był tylko automatyczny bałagan.

<hr>Han Van Loon jest profesorem na uniwersytecie Nottingham Trent w Wlk. Brytanii i University of Business and International Studies w Szwajcarii. Jest specjalistą z zakresu zarządzania jakością i wiedzą. Jest też właścicielem firmy konsultingowej i twórcą metody zarządzania przedsięwzięciami STARS (http://www.starswebworx.ch/starsweb ).

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

TOP 200