Tu jest miejsce na Twoja reklamę! Szczegóły współpracy...

sierpień 16th, 2006

Paul Klipp – Nasz Człowiek

Kategoria wpisu: Wszystkie, Wydarzenia: - Agnieszka Maćkowiak @ 21:24

Rozmowa z prezesem Lunar Logic Polska

Paul Klipp pełni funkcję Prezesa Zarządu oraz starszego kierownika projektu w firmie Lunar Logic Polska, dostarczającej oprogramowanie w systemie inżynierii oprogramowania „agile” we współpracy z firmą Lunar Logic z siedzibą w Eugene, Oregon, USA.

Agnieszka Maćkowiak: Jak długo mieszka Pan w Krakowie?

Paul Klipp: Od września 2004. Zawsze lubiłem Kraków. Pierwszy raz przyjechałem tu w 1999 roku. Pracowałem wtedy w Częstochowie i często przejeżdżałem przez Kraków. Wydawało mi się, że mieszkanie tutaj sprawiałoby mi przyjemność. Ludzie są przyjaźnie nastawieni, miasto jest piękne, kawiarnie przyjemne.

Dlaczego wybrał Pan Kraków na siedzibę Lunar Logic?

W latach 1988-1989 pracowałem jako wykładowca ekonomii i spraw międzynarodowych w środkowej Europie. Wykładałem wtedy gościnnie na uniwersytetach w całym regionie, m.in. w Czechach, na Węgrzech, w Polsce i w Rumunii. Wybierając miejsce na siedzibę Lunar Logic bazowałem na tych doświadczeniach. Brałem pod uwagę Kraków, Gdańsk, Pragę, Budapeszt, Bukareszt, Tallin, Warszawę i Wrocław. Ponieważ wybór miasta wiązał się z wyborem nowego miejsca życia, kierowałem się przy wyborze zarówno prywatnymi preferencjami jak i wynikiem procesu eliminacji. Potrzebowałem lokalizacji, która spełniałaby wszystkie warunki: dobre warunki biznesowe, duży poziom znajomości języka angielskiego (ponieważ rynkiem docelowym naszej firmy jest rynek anglojęzyczny), umiarkowany koszt pracy. Mogłem przenieść siedzibę LL dalej na wschód i obniżyć koszt pracy, nawet zachowując jakość, jednak Kraków szczęśliwie spełniał wszystkie te warunki. Jest miejscem, gdzie chciałem mieszkać, koszt pracy jest umiarkowany, jest duża liczba wykwalifikowanych pracowników (dzięki dwóm głównym uczelniom: AGH i UJ, prawie wszyscy moi pracownicy skończyli AGH) i zdrowe warunki dla prowadzenia działalności gospodarczej.

Skąd pochodzą klienci Pańskiej firmy? Czy są wśród nich polskie firmy?

Prawie wszyscy nasi klienci to klienci zagraniczni. Mieliśmy tylko dwóch polskich klientów.

LLP jako jedna z nielicznych firm na rynku polskim wykorzystuje system “agile”. Dlaczego zdecydował się Pan na jego wykorzystanie?

Powody były trzy: ze względu na wynikające z tego korzyści dla programistów, dla klientów i dla kierownika projektu.

Klientom ”agile” oferuje dużo większą wydajność, niż jakikolwiek proces, z którym miałem do tej pory do czynienia. Daje im większą kontrolę nad projektem, pozwala zobaczyć co się z nim dzieje, pozwala poprawiać projekt, kiedy zmieniają się ich wymagania ze względu na zmiany na rynku lub po prostu ze względu na to, że tak naprawdę nie w pełni zdawali sobie sprawę z własnych potrzeb.

Programistom “agile” umożliwiło zwiększenie własnej konkurencyjności na rynku. Programiści lubią pracować w ten sposób, gdyż “agile” daje im większą elastyczność, możliwość bardziej kreatywnej pracy, pozwala odgrywać ważniejszą rolę w zespole. W przeciwieństwie do sytuacji, w której pracują w bardzo zhierarchizowanej strukturze, w której jest stos specyfikacji technicznych, których należy się trzymać, jeden architekt, który mówi dokładnie co i jak zrobić. To wszystko sprawia, że zmienia się wysoko wykwalifikowanych, posiadających dużą wiedzę pracowników w ”coding monkeys”. W “agile” programiści współpracują z klientem, co daje im świadomość pozytywnych efektów ich pracy, ich wkładu, a także lepsze zrozumienie funkcjonalności i przyczyn dla których pewne rzeczy powinny być zaprogramowane w określony sposób.

Dla kierownika projektu, cóż, to bardziej odpowiada mojemu stylowi. Jestem osobą zorientowaną na proces. Nie jestem jednak zwolennikiem niczego, co wymaga ogromnej ilości czasu..Idea siedzenia i spisywania całej funkcjonalności w postaci dokumentacji technicznej, lub spędzania godzin na negocjowaniu funkcjonalności z klientem nie pasuje do mojego stylu. “Agile” wymaga mniej intensywnego, lecz bardziej zorganizowanego podejścia od kierownika projektu. Wymaga spójności i dyscypliny, co osobiście wolę od spędzania połowy czasu poświęconego na projekt na spisywaniu tego, co ma zostać zrobione, a drugiej połowy na spisywaniu tego, co poszło źle.

“Agile” wymaga dużo współpracy ze strony klienta. Jak przekonuje Pan do tego klientów?

Poza kilkoma wyjątkami, większość naszych klientów to inne firmy produkujące oprogramowanie, firmy, które mają więcej projektów, niż są w stanie zrealizować, lub firmy, których projekt posuwa się zbyt wolno i potrzebują pomocy. Dużo prościej jest przekonać takich klientów do używania “agile”.

Uważam, że tradycyjny proces składania ofert jest destrukcyjny dla klienta. Osobiście nigdy nie biorę w nim udziału. Jeżeli projekt wszedł w fazę składania oferty, a ja zostałem poproszony o wzięcie w niej udziału, ponieważ klient chce ze mną pracować, nie zgadzam się. Każdy klient, który uważa, że może osiągnąć cel najniższym kosztem, sygnalizuje, że nie zależy mu na jakości oprogramowania. “Agile” polega na tworzeniu oprogramowania wysokiej jakości. Dzisiaj przez moje biurko przewinął się kontrakt, w którym oczekiwano propozycji z ustaloną ceną i zakresem funkcjonalności. Każdy, kto wie cokolwiek o oprogramowaniu, zdaje sobie sprawę z tego, że można mieć dowolne połączenie dwóch z trzech cech: zakres funkcjonalności, ustalony koszt, lub jakość. Każdy, kto prosi o ustalony zakres funkcjonalności i koszt mówi Ci, że nie ma dla niego znaczenia jak złej jakości będzie oprogramowanie. Jedyny sposób na dostarczenie oprogramowania wysokiej jakości przy ustalonej cenie to zmniejszenie nacisku na pełną funkcjonalność.

W jaki efektywny sposób wyjaśniam to klientom, szczególnie tym, którzy oczekują ustalonej ceny? Mówię im, że projekty informatyczne zawsze związane są z ryzykiem. Każdy, kto miał do czynienia z takimi projektami zdaje sobie sprawę, że żaden z nich nie przebiega zgodnie z planem. Nie można dokładnie określić kosztu wytworzenia oprogramowania. Jeżeli klient wymaga ustalonej ceny, muszę wziąć pod uwagę ryzyko, więc podnoszę cenę tak, aby uwzględniała ryzyko. To prowadzi do jednej z dwóch sytuacji. Sytuacja pierwsza: wszystko pójdzie zgodnie z planem i projekt zamknie się w dużo mniejszym budżecie niż przewidziany. Mimo to klient zapłaci ustaloną wcześniej cenę, a ja będę miał duży zysk. Sytuacja druga: źle ocenię ryzyko i realizacja projektu będzie mnie kosztowała dużo więcej. Koszty wytwarzania oprogramowania są bardzo duże, w związku z czym, jeżeli projekt przekroczy budżet o kilka procent, zacznie poważnie szkodzić firmie, jeżeli przekroczy budżet o 10 procent stanie się finansową katastrofą. Ludzie mogą zaprzeczać, ale zdrowy rozsądek podpowiada, że jeżeli firma zmierza do finansowej katastrofy to wywierany jest duży nacisk na to, by obniżyć jakość tak, aby jak najszybciej pozbyć się projektu. Więc efekt ustalonej ceny jest taki, że albo klient znacznie przepłaca, albo otrzymuje produkt o niskiej jakości. Kiedy wyjaśniam to klientowi, jego naturalną reakcją jest pytanie o alternatywy. I wtedy opowiadam mu o “agile”.

Czy pracował Pan wykorzystując “agile” dla polskiego klienta?

Większość naszych dotychczasowych klientów, to klienci ze Stanów Zjednoczonych i z Wielkiej Brytanii, nie z Polski. W mojej opinii większość polskich kontraktów na oprogramowanie przyznawana jest firmom, które złożą najniższą ofertę, polscy kllienci wolą też kontrakty o ustalonej cenie i zakresie funkcjonalności. Uważam, że to podejście nie jest najlepsze z punktu widzenia klienta. Dopóki polscy klienci nie zdadzą sobie sprawy z tego, że oferty o ustalonej cenie i ustalonym zakresie funkcjonalności im szkodzą i dopóki nie zaczną zwracać większej uwagi na jakość oprogramowania, nie będę miał zbyt wielu okazji realizować tutaj projektów z wykorzystaniem „agile”.

Czy któryś z projektów prowadzonych przez Pana z wykorzystaniem “agile” zakończył się porażką?

Nie. Czyż to nie jest zdumiewające? Nie dość, że każdy z naszych projektów prowadzonych z wykorzystaniem “agile” zakończył się powodzeniem, to jeszcze każdy z nich został dostarczony na czas i zmieścił się w budżecie mniejszym niż przewidziany.

Jakie technologie są według Pana technologiami przyszłości w aplikacjach internetowych?

Boję się odpowiadać na to pytanie, ponieważ każdy ma swoje ulubione technologie. Sugerowanie, że czyjaś ulubiona technologia umrze śmiercią naturalną, nawet jeżeli to już się stało, jest niebezpieczne.

Jeżeli chodzi o wschodzące technologie, moją ulubioną jest Ruby i Rails Framework. Znacznie obniża koszty wytwarzania oprogramowania, pozwala programistom skupić sie na jakości i funkcjonalności. Nie twierdzę, że eliminuje trudności techniczne. To przyjemna nowa technologia. Żaden z moich pracowników nie znał Ruby, kiedy go zatrudniałem. Zaczęliśmy go używać 1,5 roku temu. Przyjąłem wtedy stażystkę, która chciała nauczyć się czegoś nowego. Była szczególnie zainteresowana nowymi technologiami. Pracowaliśmy wtedy nad wewnętrznym projektem dla naszego partnera. Zaproponowałem, żeby zrealizować go z wykorzystaniem Ruby on Rails, o którym czytałem. Tak też zrobiła. I polubiła tą technologię. Z czasem więcej naszych programistów zainteresowało się Ruby. W tym samym czasie coraz częściej pytano nas o Ruby, ponieważ zaczęło zyskiwać popularność w Wielkiej Brytanii.

Panuje opinia, że wykorzystanie Ruby on Rails skraca czas wytworzenia aplikacji dziesięciokrotnie. Z mojego doświadczenia wynika, że 2,3-krotnie, co mimo wszystko jest znaczącym zyskiem.

Jednym z efektów naszej pracy z Ruby jest projekt Ruby Time Tracker, udostępniany na licencji “MIT open – source license”. Zapraszamy do współpracy nad projektem wszystkich, którzy są zainteresowani tworzeniem aplikacji z wykorzystaniem Ruby. Jest to program, z którego rozwijaniem powinni poradzić sobie początkujący programiści Ruby.

Co Pan myśli o społeczności IT w Krakowie? O poziomie wykształcenia, motywacji?

To jest główny powód, dla którego ulokowałem tu siedzibę firmy. Poziom umiejętności, poziom wykształcenia, pracowitość są tutaj zdumiewające. Kierowałem projektami informatycznymi w Stanach Zjednoczonych i, ryzykując wpakowanie się w kłopoty, mogę powiedzieć, że polscy pracownicy mają lepszą etykę zawodową niż amerykańscy. To imponujące, w jaki sposób podejmują zadania, ekscytują się nimi, biorą odpowiedzialność za projekt na wszystkich poziomach. Ich entuzjazm i chęć zrozumienia przyczyn, dla których mają robić pewne rzeczy, ich pomysłowość to jeden z czynników dla których klienci chcą z nami pracować. Ponieważ lubią dostawać tego typu informację zwrotną i widzieć ten entuzjazm. Nie widziałem tego w żadnym innym miejscu na świecie.

Wymienił Pan zalety Krakowa. Z jakimi przeszkodami spotkał się Pan zakładając tu działalność?

Było ich kilka. Proces zakładania firmy jest bardzo żmudny. Współpracowałem z efektywnymi prawnikami, bardzo drogimi i efektywnymi prawnikami, którzy pomogli mi przejść przez proces zakładania firmy w mniej więcej 3 miesiące. Więc przychodząc do Krakowa z dobrym pomysłem, dobrym wsparciem i dużymi pieniędzmi mogłem zacząć działalność dopiero po 3 miesiącach. Są miejsca, w których wygląda to dużo dużo gorzej. Ale są też miejsca w których wygląda to dużo lepiej. Nie wiem jak to wygląda w Europie, ale w Stanach założenie działalności gospodarczej nie trwa dłużej niż tydzień.

Są organizacje wspierane przez rząd, których zadaniem jest przyciąganie dużych firm do Krakowa. Jeżeli masz 10 mln dolarów są ludzie, którzy sprawią że Twoje wejście do Krakowa będzie bardzo, bardzo proste. Przyciągają oni firmy typu Motorola, Sabre. Jednak według mnie, nie ma żadnego wsparcia, żadnej pomocy, żadnej porady dla małych przedsiębiorstw. Przynajmniej w Krakowie. Uważam, że moja firma, mimo że nie ma 10 mln dolarów, przyciąga milion dolarów z zagranicy do Krakowa każdego roku. To jak stały strumień miliona dolarów rocznie, który zasila krakowską ekonomię. Przede wszystkim przez kieszenie moich pracowników, właściciela budynku, itd. Moim zdaniem, dużo prościej jest znaleźć 10 osób takich jak ja, które przyniosą po 1 mln rocznie, niż jedną osobę z 10 mln. Chciałbym więc zobaczyć więcej wsparcia i zachęty dla małych przedsiębiorstw.

Rozmawiała: Agnieszka Maćkowiak

Liczba komentarzy: 5 »

  1. No, może w końcu coś się zmieni na naszym rynku dzięki takim ludziom jak Paul. Tak trzymać i powodzenia!!!

    Komentarz dodał Tomasz Gajewski - 17.08.2006 @ 15:03

  2. Bez przesady Tommy :) Jedna jaskółka wiosny nie czyni, ale zachęca do rozważań nad wiosną i działań. To co najbardziej mi siępodoba to człowiek, który sam nie jest programersem, ale dobrym menedżerem, inwestorem. Ilu znasz ludzi, którzy wiedzą lepiej niż Ty jak i co trzeba zrobić, a na problemy finanasowe patrzą, gdy komornik zabiera juz TV? Brawo Paul, tak trzymaj. Szkoda wielka, że w Toruniu CI się nei spodobało…

    Komentarz dodał Maciej Skórzyński - 21.08.2006 @ 08:51

  3. Znam “agile” od strony klienta i naprawde jestem przekonany o atrakcyjnosci tej metody. Jednak mam wrazenie, ze ceny Paula (tu bym upatrywal braku klientow z Polski), bez wzgledu na zalety systemu pracy jego firmy, w polskich realiach moga stanowic bariere nie do przebycia. Nie mowie o sprawie oszczedzania, ale raczej o przeplacaniu. Jako klient wole zaplacic 3-5 razy mniej za projekt, mimo ze praca nad nim moze wiazac sie z brakiem pewnych udogodnien, ktore wprowadza do pracy ‘agile’. A wcale nie sadze, aby efekt koncowy tego rozwiazania roznil sie drastycznie jakosciowo od projektu robionego w ‘agile’. Moze wysokie ceny to po prostu kwestia braku konkurencji firm pracujacych w tym systemie na polskim rynku.

    Komentarz dodał Karol - 22.08.2006 @ 11:56

  4. Karol - I’m speaking at the next meeting of the Polish Agile Users Group next week on the topic of selling agile practices. I haven’t successfully done it in Poland, as you say, but I also haven’t tried. I have sold others on the benefits of agile practices and I am eager to hear from a Polish audience about the difficulties they face convincing their managers and clients to adopt agile methods. If you are in Krakow next week, it would be very nice if you could attend. I have to disagree with you about the difference in quality between an agile project and one done by the lowest bidder. When scope is fixed and the bid is low, something has got to give and there’s only one of the triple constraints left. I’ve seen what software companies do when a project is over budget on a fixed price bid and it isn’t pretty. - Paul

    Komentarz dodał Paul - 23.08.2006 @ 22:36

  5. […] przeczytałem wywiad z Paulem Klippem, jakiego udzielił on na łamach portalu IT w Krakowie. Zapytany o to, czy jego […]

    Komentarz dodał Battle for Agility » Kontrakty o ustalonej cenie i zakresie - mitologia stosowana. - 30.12.2009 @ 21:20

Dodaj komentarz

Wydarzenia

    Brak wydarzen.

O Nas

Inicjatywa "IT w Krakowie" jest niedochodową i apolityczną organizacją pozarządową. Nasz cel to integracja, promowanie oraz rozwój społeczności informatycznej w Krakowie i regionie.
czytaj więcej

Archiwum