Do sukcesu przez porażki

Oryginalny post: Fail Early, Fail Often

Autor: Jeff Atwood

Scott Hanselman uważa, że umieszczanie certyfikatów branżowych w podpisie jest niezręczne:

Jeśli nierozsądne byłoby umieszczenie w CV wyników egzaminów ze studiów, to czemu umieszczenie

Scott Hanselman, MCSD, MCT, MCP, MC*.*

jest rozsądne? Posiadanie certyfikatu znaczy tyle, że jesteś w stanie przyswoić dużą dawkę wiedzy technicznej. Chwileczkę. Proponuję podpisywanie się w następujący sposób:

Scott Hanselman, 11 dużych projektów zakończonych sukcesem, 3 projekty Open-Source, 1 projekt zakończony gigantyczną porażką

Czyż tak nie byłoby lepiej?

Owszem, ja się zgadzam. To właśnie projekty, nad którymi pracowałeś, powinny stanowić Twoje referencje. Uważam jednak, że Scott umieścił je w złej kolejności. Powinieneś podkreślić liczbę projektów, nad którymi pracowałeś i które zakończyły się porażką.

Jednak jak zdefiniować sukces projektu? Czy cele zostały zrealizowane? Czy projekt zarabia pieniądze? Czy użytkownicy lubią wytworzone oprogramowanie? Czy ktoś go w ogóle jeszcze używa? Naprawdę ciężko powiedzieć. Przez pewien czas pracowałem w środowisku, gdzie każdy projekt kończył się sukcesem. Nikt nie chciał spowiadać się z ograniczeń, kompromisów i problemów w oprogramowaniu, nad którym pracował i które zostało wypuszczone w świat. Osoby zarządzające projektem chciały być postrzegane jako osoby odnoszące sukces. Powodowało to, że czuliśmy się jak uczestnicy dziwnych zawodów informatycznych, w których każdy projekt, mimo wszystko, jest zwycięzcą. Użytkownicy, z drugiej strony, nie byli już takimi szczęśliwcami.

Sukces jest względny i ulotny. Porażka natomiast jest rzeczą trwałą. Jeśli naprawdę chcesz wiedzieć, czy ktoś jest kompetentny w tym co robi, zapytaj go o jego porażki. W zeszłym roku cytowałem artykuł na temat przewidywania sukcesów i porażek chirurgów:

Charles Bosk, socjolog z Uniwersytetu Pensylwania, przeprowadził pewnego razu serię wywiadów z młodymi lekarzami, którzy bądź to zrezygnowali, bądź zostali wyrzuceni ze specjalizacji neurochirurgicznej, w celu ustalenia co wyróżnia chirurga, któremu udało się utrzymać na specjalizacji.

Bosk wywnioskował, że o wiele bardziej niż techniczne umiejętności lub inteligencja, do osiągnięcia sukcesu (utrzymanie się na specjalizacji) liczyło się posiadanie odpowiednich cech charakteru -- pragmatycznego umysłu, który świadom jest możliwości porażki i jej potencjalnych konsekwencji. Kiedy przeprowadzałem wywiad z chirurgiem, który został wyrzucony, zazwyczaj kończyłem wywiad cały roztrzęsiony. Chciałem usłyszeć przerażające historie o tym, co zrobili źle, ale problem był taki, że oni nawet nie zdawali sobie sprawy z tego, że to co zrobili było złe. W trakcie wywiadów wypracowałem pytania, po zadaniu których mogłem stwierdzić z dużą dozą prawdopodobieństwa, czy ktoś będzie dobrym neurochirurgiem czy też nie. Były to takie pytania jak: "Czy kiedykolwiek popełniłeś błąd? Jeśli tak, jaki był twój najgorszy błąd?" Ludzie którzy odpowiadali: "Ojej, nigdy nie popełniłem błędu" lub "Wynik leczenia był zły, ale to ze względu na czynniki, na które nie miałem wpływu" -- byli dla mnie najgorszymi kandydatami na neurochirurga. Natomiast praktykanci którzy mówili: "Popełniam błędy cały czas. Zdarzyła się okropna rzecz wczoraj i było to ...". To właśnie oni byli najlepsi. Mieli tę umiejętność, by przemyśleć wszystko, co zrobili i byli w stanie wyobrazić sobie, jak sprawy potoczyłyby się, gdyby postąpili inaczej.

Najlepsi programiści uwielbiają porażki -- a tak naprawdę mają na ich punkcie obsesję. Jeśli zapomniałeś już, jak łatwo jest popełniać krytyczne błędy, to najprawdopodobniej poniesiesz kolejną porażkę. I tym powinieneś się martwić.

Michael Hunter idzie krok dalej. Zachęca nas do częstego ponoszenia porażek:

Jeśli Twoja rodzina zachęca Cię do ponoszenia porażek, to zaliczasz się do szczęściarzy. Jeśli naprawdę urodziłeś się pod szczęśliwą gwiazdą, to również Twoi nauczyciele to robią. Nauka nie płynie z samej porażki, ale z analizy jej przyczyn, próby wyciągnięcia i sformułowania wniosków oraz próby ponownego zmierzenia się z problemem. Z biegiem czasu da Ci to głębokie zrozumienie obszaru wiedzy, którym się zajmujesz (może to być zarówno programowanie, mieszanie kolorów lub cokolwiek innego) -- dzięki temu się uczysz. Ćwiczysz w ten sposób swój mózg, co jest dobre samo w sobie, plus wiedza, którą zdobyłeś, zwiększa Twoje szanse na sukces w nowych sytuacjach.

Im większa liczba projektów zakończonych porażką w twoim portfolio, tym lepiej. Jeśli raz na jakiś czas nie poniesiesz porażki, znaczy to, że nie starasz się wystarczająco mocno.

Musisz wytężyć swoje siły, by znaleźć granice swoich możliwości, a następnie je przekroczyć. Dodatkowo upewnij się, że poniesiesz spektakularną porażkę w czasie pracy nad następnymi projektami.

Data publikacji oryginału: 1 maja, 2006

3 komentarze:

flatron pisze...

Projekt, który z hukiem upadł nie miał żadnych szans powodzenia od samego początku.
Był grubo niedoszacowany, a klient ciągle zmieniał swoje zachcianki.

Handlowiec chciał się koniecznie wykazać. Zaniżył więc 6-krotnie wycenę projektu i taka umowa została podpisana.
Do realizacji przydzielono 3 osoby, a powinno być 8-10. Harmonogram prac też był absurdalnie napięty.
Klientem była większa firma, nastawiona roszczeniowo. Mimo projektu funkcjonalnego, który był parafowany na każdej stronie, powstało 5 aneksów.
Absolutnie niczego to nie zmieniło, bo klient na każdej kolejnej prezentacji zmieniał zdanie, a nikt nie śmiał protestować.
Programiści pracowali po 12h, czasami w soboty i niedziele, zdarzało się również 36h non-stop. Prace jednak wcale nie posuwały się na przód, bo zamiast dodawać nową funkcjonalność w kółko zmienialiśmy już stworzoną.

Przy okazji dwa razy zmieniało się kierownictwo w naszej firmie i nowi ludzie tłumaczyli nam, że jeszcze mamy szanse doprowadzić projekt do końca,
żebyśmy się postarali, pracowali ciężej itp. Naszych argumentów nikt nie chciał słuchać.

Na końcowej prezentacji klient nam przerwał i zaczął tłumaczyć jak to powinno działać. Produkt był zgodny ze specyfikacją, ale klient go nie odebrał.
Ponieważ przez ciągłe modyfikacje czas realizacji mocno się wydłużył, naszej firmie groziły kary za opóźnienia. Ostatecznie wszyscy się rozeszli, a projekt trafił do koza.


Ta historia nie nauczyła mnie niczego, bo nie mogła.
Nie miałem wpływu na treść umowy, na przydział pracowników do projektu i na czas realizacji. Mojego krzyku nikt nie słuchał.
Jaki niby błąd popełniłem jako programista? Powinienem był się zwolnić zamiast harować ponad siły?

Według nieoficjalnych danych około 60-80% projektów informatycznych upada. Sądzę, że większość z winy kadry zarządzającej.

mg pisze...

Pozwolę sobie o komentarz do artykułu ;)
Jeff Atwood w powyższym poście wrzucił do jednego worka porażki projektów spowodowane różnymi rzeczami.

Zgadzam się z Tobą, że w przytoczonej przez Ciebie sytuacji miałeś niewielki wpływ na rozwój sytuacji.
Z punktu widzenia pracodawcy próba doprowadzenia projektu do końca jest zrozumiała.
Projekt informatyczny jest pewnego rodzaju inwestycją (płace programistów, grafików itp.)
W zależności od sposobu podpisania umowy, pieniążki za projekt są wpłacane m.in. w ratach w trakcie trwania projektu jako zaliczka,
bądź dopiero po pozytywnym odbiorze. Pracodawca może najczęściej liczyć na zysk tylko i wyłącznie, jeśli projekt zostanie doprowadzony do końca.
W przypadku zaniechania projektu musi się liczyć z dużymi stratami. Niewiele pracodawców może na takie starty sobie pozwolić. W przeciwnym razie
mogę mieć problemy z płynnością itp. Niemniej tak jak z każdą inwestycją, wycofanie się jego realizacji w porę może ograniczyć potencjalne dalsze straty.
Ale do tego trzeba odwagi ;)

Z punktu widzenia programisty taka sytuacja też jest fatalna. Praca nad takim projektem, jak np. Twój, musiała być frustrująca.
Praca po godzinach, ciągła walka z czasem itp. Mam nadzieję, że zapłacili. Bo z tego co wiem zdarzają się też takie sytuacje,
w których programiści pracują na umowy zlecenie/dzieło i w przypadku porażki projektu, kaski nie dostają.
Programiści czasami lepiej przewidują sukces, bądź porażkę projektu niż niejeden PM. W końcu to oni pracują z kodem i najlepiej wiedzą jaki Armagedon w kodzie spowoduje kolejna zmiana wymagań. I być może wiedzą, że to wszystko nie ma sensu. Ale wychowano nas, by nigdy się nie poddawać.
Niemniej rezygnacja z pracy w takim projekcie jest często, moim zdaniem lepszym wyjściem.


Dlatego też, tak wielka odpowiedzialność moim zdaniem spoczywa na kadrze zarządzającej. Porządnie spisana umowa, która temperuje niesformnego, zmieniającego zdanie, niekontaktowego klienta, porzadnie przeprowadzona analiza wymagań może moim zdaniem zmniejszyć prawdopodobnieństwo takich sytuacji.


Artykuł według mnie mówi o porażkach projektów, w których programista jest odpowiedzialny za sukces bądź porażkę projektu (a nie kadra zarządzająca). Dobrym przykładem mogą być na przykład małe start-up'y. I tu się zgodzę z Atwoodem, że w porażka w takich projektach jest najlepszą nauką.

Greg pisze...

"Nauka nie płynie z samej porażki, ale z analizy jej przyczyn, próby wyciągnięcia i sformułowania wniosków oraz próby ponownego zmierzenia się z problemem. Z biegiem czasu da Ci to głębokie zrozumienie obszaru wiedzy, którym się zajmujesz"
Dlatego w następnym projekcie z rodzaju "marszy ku klęsce" szybciej rozpoznasz sygnały i albo będziesz głośniej krzyczeć, albo się ewakuujesz żeby odnieść jak najmniej własnych obrażeń.

Jednak nie wydaje mi się to odpowiednie do wpisania w cv - pracodawca może nie zrozumieć tego skarbu, który ze sobą przynosimy ;)

Prześlij komentarz

Related Posts with Thumbnails