Z Jimem Highsmithem, prezesem firmy Information Architects i dyrektorem e-Project Management Practice w The Cuttter Consortium, rozmawia Przemysław Gamdzyk.

Kiedy studiowałem informatykę na Uniwersytecie Warszawskim, na zajęciach z kierowania projektami informatycznymi uczono mnie zupełnie czegoś innego niż Pan głosi. Czy środowisko informatyczne nie traktuje Pana jak szarlatana?

Często. Informatycy wychowani w tradycyjnych regułach automatycznie odrzucają to, co nowe, to, co nie przystaje do modelu postępowania stawianego do tej pory za wzór. Nie podoba im się to, ale nie zadają sobie trudu, żeby rzeczywiście zastanowić się nad alternatywą. To prawie religijne przekonanie, że również w informatyce rygorystyczne stosowanie poprawnych reguł inżynierskich, poprzedzone dokładnym planowaniem, powinno dać efekt. Wciąż odrzuca się myśl, że może to wcale nie jest tak, że projekt można dobrze zrealizować za pierwszym razem. Być może uda się osiągnąć zaplanowane rezultaty, ale wcale nie muszą to być te wyniki, o które rzeczywiście chodzi. Sukcesem nie jest realizacja planu, ale spełnienie faktycznych wymogów biznesowych klienta. Zaś próba sformułowania idealnego planu może zająć kilkanaście miesięcy i nigdy się nie skończyć.

Zmiany, jakie pojawiają się w założeniach i specyfikacji programu, są normą. W tradycyjnych metodach zawsze stanowiły problem. Sukces osiąga się w drodze sprawdzania alternatyw, uczenia się na porażkach i rzeczach udanych. Tworzenie oprogramowania nie jest procesem mechanicznym. Podobnie jak życie jest zbyt nieprzewidywalne, by dało się wtłoczyć w graficzne schematy. To coś organicznego, nieliniowego i niedeterministycznego. Złożonego oprogramowania się nie buduje. Ono ewoluuje.

Czyli trudno mówić tutaj o inżynierii. Proponuje Pan rozwiązanie alternatywne, które wydaje się jednak bardzo trudne, jeśli nie niemożliwe, do praktycznego zastosowania.

To nie jest tak. Kiedy swoje recepty prezentowałem dużym amerykańskim wytwórcom oprogramowania, chociażby Microsoftowi, to oni się dziwili - "i cóż w tym takiego znowu nowego?". Rzeczywiście, różne elementy i warianty tych metod wykorzystują na co dzień. Oni są przecież praktykami. Metody formalne stosowane są najczęściej przy realizacji dużych rządowych projektów.

Zawsze powtarzam, że nie ma jednego dobrego rozwiązania. Różne rzeczy przystają do odmiennych sytuacji. Tradycyjne budowanie oprogramowania zgodnie ze schematem CMM (Capability Maturity Model) doskonale sprawdza się tam, gdzie potrzebne jest standardowe rozwiązanie funkcjonujące w statycznym, przewidywalnym otoczeniu. W wielu miejscach tradycyjne metody zawodzą na całej linii. Każdy widzi, jak wiele projektów się nie udaje. Może właśnie tam warto spróbować czegoś innego?

Co przekonało Pana do metod adaptacyjnych?

Przez długie lata działałem wykorzystując "twarde" metodologie. Dopiero przed 10 laty zaczęło mnie zastanawiać, dlaczego właściwie to, co te metodologie zalecają, nie przystaje do faktycznego sposobu mojej pracy. Gdy zacząłem się rozglądać, okazało się, że nie tylko ja dostrzegam takie rozdarcie. Tradycyjny model nie przystawał do obserwowalnej praktyki!

Zacząłem od skrócenia cyklu realizacji poszczególnych części projektów. W technikach adaptacyjnych zamiast zadaniami, czasem i budżetem zarządza się ludźmi, relacjami pomiędzy nimi, a co najważniejsze, wartością dla klienta.

Być może dlatego najszybciej nowe techniki przyjmują firmy, które są użytkownikami informatyki. One są zainteresowane namacalnymi rezultatami. Wolniej do metod adaptacyjnych przekonują się firmy informatyczne. Co ciekawe, krajem, który poszedł najdalej w stosowaniu formalnych metod w wytwarzaniu oprogramowania, bynajmniej nie są Stany Zjednoczone. To Indie. Byłem tam na początku tego roku na zaproszenie jednej z największych indyjskich firm informatycznych. Otrzymali już najwyższy certyfikat zgodności z modelem CMM - co jest rzeczą nieosiągalną dla większości firm tworzących oprogramowanie w krajach zachodnich. Starają się być maksymalnie poprawni, by wobec zagranicznych partnerów - którzy zamawiają u nich oprogramowanie - stać się wiarygodnymi.