Sekret góry lodowej, odkryty

Oryginalny post: The Iceberg Secret, Revealed

Autor: Joel Spolsky

"Nie mam pojęcia, co jest nie tak z moimi deweloperami", myśli CEO. "Wszystko szło tak dobrze, gdy zaczęliśmy projekt. Przez kilka pierwszych tygodni zespół szalał i stworzył świetny prototyp. Od tego czasu jednak wszystko zwolniło do żółwiego tempa. Oni po prostu nie pracują już tak ciężko." Wybiera driver Callaway Titanium i wysyła wózek golfowy po lodowatą lemoniadę. "Może jeśli zwolnię kilku leniwców, to zapali im się grunt pod nogami!".

W międzyczasie, rzecz jasna, deweloperzy nie mają pojęcia, że coś idzie nie tak. W istocie, wszystko jest w porządku. Dotrzymują terminów.

Nie pozwól, by przydarzyło się to Tobie! Zdradzę Ci mały sekret o tych typkach z menedżmentu bez wiedzy technicznej, który spowoduje, że Twoje życie stanie się milion razy łatwiejsze. To naprawdę proste. Gdy poznasz mój sekret, nigdy więcej nie będziesz miał kłopotów z pracą z nie-technicznymi menedżerami (dopóki nie wdasz się w kłótnię o współczynnik restytucji ich kijów golfowych).

Jest całkiem oczywistym, że programiści myślą w jednym języku, a MBA - w innym. Myślałem przez jakiś czas nad problemem komunikacji w zarządzaniu oprogramowaniem, jako że jest dla mnie dość jasnym, że władza i wynagrodzenia gromadzą się przy tych rzadkich jednostkach, które wiedzą, jak tłumaczyć z programistycznego na menedżerski.

[Image]

Odkąd zacząłem pracę w przemyśle informatycznym prawie każde oprogramowanie, nad którym pracowałem było czymś, co można nazwać oprogramowaniem "spekulatywnym". Znaczy to tyle, że oprogramowanie nie było tworzone dla konkretnego klienta - było budowane z nadzieją, że miliardy ludzi je kupią. Wielu programistów nie może jednak pozwolić sobie na taki luksus. Mogą być konsultantami rozwijającymi projekt dla pojedynczego klienta lub wewnętrznymi programistami pracującymi nad skomplikowanym, korporacyjnym czymśtam do księgowości (czy czymkolwiek innym, co Wy, wewnętrzni programiści, robicie; to jest dla mnie raczej zagadkowe).

Czy kiedykolwiek zauważyliście, że w tych projektach dostosowanych do potrzeb klienta, tą najbardziej powszechną przyczyną niedotrzymania terminów, porażek i ogólnej beznadziei jest to, co sprowadza się do "Ten (tu wstaw przekleństwo) klient nie wiedział, czego chciał"?

Poniżej mamy trzy wersje tej samej patologii:

  1. Cholerny klient ciągle zmieniał zdanie. Najpierw chciał architekturę Klient/Serwer. Następnie przeczytał o XMLu podczas lotu w magazynie Delta Airlines i zdecydował, że musi mieć XMLa. Teraz przepisujemy całość tak, by korzystała z flotylli małych robotów Lego Mindstorms".
  2. "Zbudowaliśmy to dokładnie tak, jak tego chcieli. Kontrakt precyzował wszystko w najmniejszych szczegółach. Dostarczyliśmy dokładnie to, co opisywał kontrakt. Kiedy to jednak dostarczyliśmy, byli załamani".
  3. "Nasz nieszczęsny spec od działu sprzedaży zgodził się na kontrakt ze z góry ustaloną kwotą za stworzenie czegoś, co było generalnie niewyspecyfikowane, a prawnicy klienta byli dostatecznie ostrzy, żeby wymóc klauzulę w kontrakcie zwalniającą ich z płatności do czasu "zaakceptowania przez klienta", więc musieliśmy stworzyć zespół 9 ludzi pracujących nad ich projektem przez dwa lata by otrzymać ledwie 800$".
Jeśli jest jedna rzecz, którą należałoby wwiercić w głowy ciężką wiertarką 2500RPM DeWalt'a wszystkim młodszym konsultantom, to to: Klienci Nie Wiedzą, Czego Chcą. Przestań Oczekiwać Od Klienta, Że Będzie Wiedział Czego Chce. To się nie wydarzy. Musisz z tym żyć.

Zamiast tego załóż, że będziesz musiał coś koniec końców stworzyć, a klient bedzie musiał to polubić, choć będzie nieco zaskoczony. TY musisz przeprowadzić badania. TY musisz wymyślić projekt, który rozwiąże problem klienta w zadowalający sposób.

Spróbuj wczuć się w ich sytuację. Wyobraź sobie, że właśnie zarobiłeś 100 000 000$ sprzedając swoją firmę Yahoo! i zdecydowałeś, że już czas na odnowienie swojej kuchni. Zatrudniasz doświadczonego architekta z poleceniem, by zrobił ją "tak odjechaną, jak Kuchnia Will'ego i Grace". Nie masz pojęcia, jak tego dokonać. Nie wiesz, że chcesz kuchenkę Viking'a i lodówkę Subzero - to nie są słowa z Twojego słownika. Chcesz, by architekt zrobił coś dobrego i dlatego go zatrudniłeś.

Goście od programowania ekstremalnego mówią, że rozwiązaniem jest wpuszczenie klienta do pokoju i wciągnięcie go w proces projektowania każdego kroku, jak członka zespołu. Wydaję mi się, że jest to nieco zbyt "ekstremalne". To tak, jakby mój architekt kazał mi się zjawiać podczas projektowania kuchni i pytać mnie o każdy najmniejszy szczegół. To jest dla mnie nieciekawe - jeśli chciałbym być architektem, to zostałbym architektem.

Tak czy inaczej, nie chcesz by klient należał do Twojego zespołu, czyż nie? Osoba wysłana przez klienta może się okazać jakimś biednym debilem z księgowości zesłanym do pracy z programistami ponieważ był najwolniejszym pracownikiem w dziale i ledwie zauważyliby jego nieobecność. Ty za to spędzisz cały swój czas przeznaczony na projektowanie wyjaśniając wszystko za pomocą jednosylabowych słów.

Załóżmy, że Twoi klienci wiedzą, czego chcą. Zaprojektuj to sam, opierając się na Twoim zrozumieniu dziedziny. Jeśli musisz spędzić trochę czasu na nauce dziedziny lub potrzebujesz eksperta by Ci pomógł, to w porządku, ale projekt oprogramowania to Twoje zadanie. Jeśli odrobisz zadanie domowe z dziedziny i stworzysz dobry interfejs użytkownika, klient będzie zadowolony.

Obiecałem Ci zdradzić sekret o tłumaczeniu z języka klientów (czy menedżerów bez zaplecza technicznego) o Twoim oprogramowaniu do języka programistów.

Czy wiesz, że góra lodowa jest w 90% pod wodą? Cóż, większość oprogramowania jest w tej kwestii podobna do góry lodowej - jest tam piękny interfejs użytkownika, bedący jakimiś 10% Twojej pracy, a 90% pracy programistycznej znajduje się pod spodem. Jeśli weźmiesz pod uwagę fakt, że około połowy Twojego życia to poprawianie błędów, to UI zajmie jedynie 5% Twojej pracy. Jeśli ograniczysz się jedynie do wizualnej części UI, pikseli, do tego, co mógłbyś zobaczyć w PowerPoint'cie, to mówimy o mniej niż 1%.

To nie jest sekret. Sekretem jest to, że Ludzie Nie Będący Programistami Nie Rozumieją Tego.

Z Sekretu Góry Lodowej płynie kilka bardzo, bardzo ważnych wniosków.

Ważny Wniosek Numer Jeden. Jeśli pokażesz nie-programiście ekran z interfejsem użytkownika 90% gorszym, ten będzie myślał, że program jest w 90% gorszy.

Nauczyłem się tego jako konsultant, gdy stworzyłem demo ważnego projektu webowego dla zespołu kierowniczego klienta. Projekt był niemalże w 100% zakodowany. Wciąż czekaliśmy na grafika, by wybrał czcionki i kolory i narysował odjechane trójwymiarowe zakładki. W międzyczasie użyliśmy prostych czcionek i czerni i bieli, było sporo paskudnie zmarnowanego miejsca na ekranie, generalnie nie wyglądało to za dobrze. 100% funkcjonalności już jednak było i robiło całkiem niesamowite rzeczy.

Co się stało w trakcie demo? Klienci przez całe spotkanie fascynynowali się wyglądem programu na ekranie. Nie rozmawiali nawet o UI. Po prostu o tym, jak wygląda. "To po prostu nie wygląda spoko", żalił się ich menedżer projektu. To wszystko, o czym byli w stanie myśleć. Nie mogliśmy ich zmusić do myślenia o rzeczywistej funkcjonalności. Oczywiście poprawianie projektu graficznego zajęło około jednego dnia. To było prawie tak, jakby myśleli, że zatrudnili malarzy.

Ważny Wniosek Numer Dwa. Jeśli pokażesz nie-programiście ekran, na którym interfejs użytkownika będzie w 100% piękny, ten będzie myślał, że program jest prawie skończony.

Ludzie nie będący programistami po prostu patrzą na ekran i widzą jakieś piksele. Jeśli piksele wyglądają tak, jakby to był program który coś robi, myślą "o matko, o ile trudniejsze może być sprawienie, żeby to faktycznie działało?".

Dużym ryzykiem jest to, że jeśli najpierw stworzysz prototyp UI, przypuszczalnie po to, by utrzymać dyskusję z klientem, to wszyscy będą myśleć, że już prawie skończyłeś. Gdy Ty spędzasz nastepny rok pracując "pod spodem", że tak powiem, nikt nie będzie widział, że coś robisz i będą myśleć, że to nic.

Ważny Wniosek Trzy. Dotcom z odjechaną, wypolerowaną stroną i jakimiś czterema podstronami dostanie wyższą ocenę niż wysoce funkcjonalny dotcom z 3700 lat archiwów i domyślnym szarym tłem.

Ach, moment, dotcomy nie są więcej warte. Nieważne.

Ważny Wniosek Cztery. Gdy polityka wymaga od różnych menedżerów bez zaplecza technicznego czy klientów "odłączenia" się od projektu, daj im kilka wersji projektu graficznego do wyboru.

Zmień układ niektórych rzeczy, zmień wygląd i działanie i czcionki, przesuń logo i zwiększ je lub zmniejsz. Pozwól im czuć się ważnym, pokazując im nieistotne dekoracje do pobawienia się. Nie są w stanie zaszkodzić Twojemu harmonogramowi w ten sposób. Niezłym pośrednim dekoratorem jest ciągłe dostarczanie próbek rzeczy do wyboru. Nigdy nie zajmą się dyskusją z klientem na temat umiejscowienia zmywarki. Trafi obok zlewu, bez względu na to, czego chce klient. Nie ma sensu marnować czasu na kłótnie o to, gdzie ma stanąć zmywarka, musi stać obok zlewu, nawet nie zaczynaj tematu; pozwól klientowi zająć się robieniem czegoś nieszkodliwego, jak na przykład zmienianiem 200 razy zdania czy użyć Włoskiego Granitu czy Meksykańskiej Dachówki czy Norweskiego Drewna Butcherblock jako blatu.

Ważny Wniosek Pięć. Gdy się popisujesz, jedyną istotną rzeczą jest zrzut ekranu. Spraw, by był w 100% piękny.

Nie myśl - nawet przez chwilę - że będziesz w stanie wykpić się prosząc kogokolwiek o wyobrażenie sobie, jak świetne może to być. Nie myśl, że zwracają uwagę na funkcjonalność. Nie zwracają. Chcą zobaczyć ładne piksele.

Steve Jobs to rozumie. O matko, on to naprawdę rozumie. Inżynierowie w Apple nauczyli się robić rzeczy, które tworzą doskonałe zrzuty ekranu - jak na przykład te nowe, fantastyczne ikony 1024x1024 w doku, nawet jeśli marnują wartościowe obszary. Tłum ludzi od pulpitu Linuksa szaleje na punkcie półprzezroczystych xtermów, które doskonale wyglądają na zrzutach ekranu, ale w rzeczywistości są denerwujące w użyciu. Każdego razu, gdy Gnome lub KDE ogłasza nową wersję, kieruję się prosto w stronę zrzutów ekranu i mówię: "Och, zmienili planetę z Jowisza na Saturna. Fajnie". Nigdy nie przykładam wagi do tego, co zrobili naprawdę.

Pamiętasz CEO z początku tego artykułu? Był nieszczęśliwy, bo jego zespół pokazał mu wspaniałe slajdy w PowerPoint'cie na początku - mocki stworzone w Photoshopie, nawet nie w VB. Teraz, gdy naprawdę pracują nad rzeczami pod maską wygląda na to, że nie robią nic.

Co możesz poradzić? Jak tylko zrozumiesz Sekret Góry Lodowej, łatwo się z tym pracuje. Zrozum, że jakiekolwiek demo pokazywane przez Ciebie w przyciemnionym pomieszczeniu z rzutnikiem będzie dotyczyło tylko pikseli. Jeśli możesz, twórz swoje UI w taki sposób, by rzeczy niedokończone wyglądały na niedokończone. Przykładowo, użyj gryzmołów zamiast ikon na pasku narzędzi zanim zaimplementujesz ich funkcjonalność. W trakcie budowy Twojego serwisu webowego możesz faktycznie rozważyć pominięcie pewnych ficzerów zanim je faktycznie zaimplementujesz. W ten sposób ludzie mogą obserwować, jak Twoja strona domowa rośnie z 3 poleceń do 20, w miarę przyrostu funkcjonalności.

Co ważniejsze, upewnij się, że kontrolujesz to, co ludzie myślą o harmonogramie. Dostarcz szczegółowy harmonogram w formacie Excel. Każdego tygodnia wyślij maila gratulującego sobie tego, że awansowałeś z 32% do 35% ukończonej pracy i jesteś na dobrej drodze do wydania 25 grudnia. Upewnij się, że to fakty dominują każde myślenie nad tym, czy projekt porusza się do przodu z odpowiednią prędkością. I nie pozwól swojemu szefowi korzystać z driver'ów Callaway Titanium. Nie obchodzi mnie jak bardzo chcesz, żeby wygrał. USGA zakazało ich i jest to po prostu nie w porządku.

Środa, Luty 13, 2002

11 komentarze:

DOzminkowski pisze...

Nigdy przykładam => Nigdy nie przykładam

sokzzuka pisze...

Jakież to prawdziwe :>

Konrad pisze...

Genialne! :D Proste, klarowne, z celnymi uwagami i sugestiami, przemawiającymi i zrozumiałymi metaforami - po prosu, genialne!

Teraz po proszę o to samo, w wersji lekko bardziej przystępnej dla menadżerów i na ich serwisach, forach, listach mailingowych, itd. ;)

murwazy pisze...

1000% prawdy :)

Anonimowy pisze...

prawda jak najbardziej, tylko czy to naprawdę programisty obowiązek, żeby przedstawiać rzeczy tak, żeby szefostwo to "łykało"?
Jeśli jestem freelancerem to jeszcze rozumiem, ale jak pracuje na etacie i robię coś dla pani z marketingu, która uważa się za moją przełożoną (w tym akurat projekcie) wysyłam jej screena z działającej strony i dostaje maila: "To nie może tak być!!!" to ktoś tu jest nie na swoim miejscu. I to nie ja jako szeregowy programista, tylko szanowna Pani przełożona, która nie potrafi zrozumieć czym się różni funkcjonalność od wyglądu.

Karol Stosiek pisze...

@DOzminkowski: dziękuję, poprawione. Widać nawet kilkukrotne przeczytanie przetłumaczonego artykułu nie ustrzega przed popełnieniem błędu :-)

Free pisze...

Święte słowa, amen w pacierzu. Smutna prawda. Cóż, sami zgotowaliśmy sobie taki los. Niestety, ale project manager, który nie jest programistą to średnie połączenie...

Anonimowy pisze...

Joela fajnie się czyta nawet jak nie pisze odkrywczych rzeczy. Niestety najczęściej bardziej zależy mu na elokwentym tekście udowadniajacym zgrabne tezy niż na rozważeniu za i przeciw, zalet i wad poruszanego tematu. W powyższym tekście zupełnie zapomina, że owymi makietami firmy zdobywają klientów, a pracownicy korporacji budżety na projekty. Często lepiej męczyć się ze swoją "górą lodową" którą zbudowało się w decydenckich głowach ale mieć klienta/pracę.

Kamil Brenk pisze...

Nie będę odkrywczy i powielę wcześniej wypowiedzane myśli: samo życie. Świetny artykuł.

Anonimowy pisze...

w kwestii tłumaczenia: "in-house programmers" to nie są domowi programiści :)

Karol Stosiek pisze...

W istocie, dzięki.

Prześlij komentarz

Related Posts with Thumbnails