Recenzija knjige: Getting Real (37signals)
Poslednja dva mjeseca sam bukvalno u raljama menadžmenta,
čitam paralelno po nekoliko knjiga na ovu temu, a eto nađoh vremena da isčitam i ovu svojevrsnu menadžment knjigu od Frieda i kompanije o kojoj sam već ranije mnogo pisao. Za prave poznavaoce filozofije i metodologije 37signals u suštini Getting Real ne donosi apsolutno ništa novo. Svakom ko je čitao njihove tekstove u poslednje dvije-tri godine na Signals vs Noise blogu toplo preporučujem da zaobiđe ovaj naslov.
Sam koncept knjige i organizacija sadržaja su odlično zamišljeni, ali nisam zadovoljan finalnom realizacijom. Čitajući knjigu, čitavo vrijeme sam osjećao nedorečenost koja je uslovljena po mom mišljenju brzinom pisanja, nedostatkom istinskog elana i željom autora da se knjiga što prije lansira na tržište. U stvari, Fried je kreirao osnovni koncept, izvadio stare tekstove iz naftalina zvanog SvN, upotrebio iste misli (bez većih revizija) u Hemigvejskom stilu pojednostavljivanja rečenica koje više počinje da vrijeđa intelekt čitaoca, a zatim iste te rečenice prebacio u imperativ. Ovim dolazimo do paradoksalne situacije da je kvalitet samog teksta u knjizi mnogo lošiji u odnosu na kvalitet SvN tekstova iz perioda prije lansiranja Basecampa. Nedorečenost je prisutna i iz samog koncepta da se napišu kratke pričice o jednoj misli na jednoj do maksimalno dvije strane, začini to primjerom iz prakse na pola strane i gotovo. Kada sam kod primjera iz prakse, očekivao sam da će biti kudikamo zanimljiviji i kvalitetniji, ali šta je tu je.
Šta bih mogao da napišem čitaocima koje slabo poznaju rad 37signalsa, a željeli bi da pazare i pročitaju knjigu? Iako knjiga ima solidne šanse da vas inspiriše u određenim segmentima, $19 koliko košta definitivno ne vrijedi. Iskusni interfejs dizajneri su se mahom već susretali sa konkretnim problemima (i rješenjima) koja se obrađuju u knjizi i sa tog aspekta oni tu neće naći ništa novo sem satisfakcije da se njihovo razmišljanje poklapa sa stavovima ljudi iz jedne uspješne kompanije kao što je 37s. Iskusni programeri bi trebalo da razmotre neke stavove o značaju interfejsa u projektovanju aplikacije, ali po mom ličnom mišljenju velike su šanse da isti brzo knjigu odbace kao nerealnu, jer pogađa tipičan programerski ego. Oni manje iskusni programeri pogotovo neće shvatiti iznesene stavove, pa njima preporučujem da zaobiđu ovaj naslov. Ko bi onda u stvari trebalo onda da pazari ovu knjigu? Po mom mišljenju početnici u interfejs dizajnu i projekt menadžeri. Početnicima bih preporučio da prođu uzduž i poprijeko kroz Getting Real, tu će svakako pronaći dosta dobru osnovu u samom razmišljanju i pristupu interfejsu koja će ih lišiti nepotrebnog lutanja po stilovima i školama dizajna. Što se tiče projekt menadžera, mislim da bi trebalo da pročitaju knjigu i razmotre veoma pojednostavljenu metodologiju kreiranja jednostavnih aplikacija u malim timovima sa ograničenim budžetom. Smatram da u Getting Real upravo menadžeri iz softverske industrije mogu naići na dosta inspirativnih momenata. Uprkos 37s propagandi, nažalost, u okruženju velikih timova, najveći dio stvari koja se propagira pod Getting Real etiketom, neće pronaći svoju primjenu.
Posebno bih se zahvalio kolegi Vuku Ćosiću, koji mi je poklonio primjerak ove knjige.
24 April 2006 |
Ilija Studen 940 days ago
Iskusni programeri bi trebalo da razmotre neke stavove o značaju interfejsa u projektovanju aplikacije, ali po mom ličnom mišljenju velike su šanse da isti brzo knjigu odbace kao nerealnu, jer pogađa tipičan programerski ego.
Bil’ bio toliko dobar da objasniš. Mislio si na hard core programere kojima je najbitnija stvar da “endžin” radi, a izgled ko šiša ili?
Marko Bijelić 940 days ago
Ne baš one zadrte hard core programere, ali mislio sam na iskusnije programere kao čitavu grupaciju. Evo ti jedan konkretna strana:
Interface First
“Design the interface before you start programming
Too many apps start with a program-first mentality. That’s a
bad idea. Programming is the heaviest component of building
an app, meaning it’s the most expensive and hardest to change.
Instead, start by designing first.
Design is relatively light. A paper sketch is cheap and easy to
change. html designs are still relatively simple to modify (or
throw out). That’s not true of programming. Designing first
keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your
product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It’s constantly being revised throughout
the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only
truly answer when you’re dealing with real screens. Designing
first keeps you flexible and gets you to those answers sooner in
the process rather than later.”
Eto, sad ti prokomentariši kako će minimum 80% programera da reaguje na ovo :-)
Inače, samo deset strana u knjizi je direktno posvećeno kôdu i to je glavni zaključak “less code”.
(Napomena: ovo poglavlje je javno dostupno za besplatan download sa sajta knjige. Inače evo vam i direktan primjer koliko je teksta na jednoj strani u knjizi)
Denis Radenkovic 939 days ago
bq. Posebno bih se zahvalio kolegi Vuku Ćosiću, koji mi je poklonio primjerak ove knjige.
Zar nije zabranjeno prenositi knjigu ;-)
Marko Bijelić 939 days ago
This book was prepared for vuk cosic and up to 10 co-workers.
(stoji u footeru svake strane)
Vuk je kupio grupnu licencu i između deset saradnika kojima prema licenci može prenijeti knjigu, poklonio i meni jedan digitalni primjerak ;-)
Petar Pavlovic 939 days ago
Ja sam dao $19 za tu knjigu, ali jos nisam stigao da je procitam (iako sam sample chapter “pojeo” za pola sata).
Sto se tice ovog sample poglavlja gde kazu da treba prvo dizajnirati interfejs, a onda kodirati, to je 100% ispravno. Ja, operisan od dizajna, hard-core progamer samo popljuvao to u startu. Medjutim, iz iskustva se vise puta pokazalo da ako ne znas kako ce ti interfejs izgledati, moze da se desi da
# ne znas sta sledece da uradis
# moras X puta da prepravljas dizajn aplikacije jer si nesto zaboravio ili ces dovesti korisnika u situaciju da ne zna sta odredjeni korak aplikacije radi.
Posto sam i dalje operisan od dizajna, onda samo radim prototipove interfejsa koji odrazavaju izgled i upotrebljivost finalnog proizvoda, a kasnije sa dizajnerom poradimo na konacnom izgledu.
I neka mi dizajneri kazu koliko ima dizajnera koji su stvarno dizajneri i onih koji su “dizajneri”. Razlika je u tome sto dizajneri treba da poznaju ponasanje prosecnog korisnika sajta, a ne samo da stave fancy boje, “raspale” po PhotoShop efektima i sl.
Mladen Jablanović 939 days ago
U svakom iole organizovanom razvoju softvera funkcionalna specifikacija prethodi bilo kakvoj implementaciji, tako da… mislim, ono… daj neko poglavlje u kome se kaže nešto novo. :)
Marko Bijelić 939 days ago
Lično u svom radu isključivo primjenjujem “interface first” filozofiju, to jeste pristup “interfejs je softver”. Problem je u tome što većina programera, a i dizajnera, ne zna šta je uopšte interfejs. E sada, do tog saznanja da je mnogo praktičnije da se interfejs prvi dizajnira, sam došao samostalno iskustvom kroz rad. Bio bih nekorektan, kada ne bih napisao da su 37signals tamo negdje u periodu 2002-2004. konstatno inspirisali i da sam od njih naučio mnogo toga. Prvenstveno sam zbog toga možda i posvetio mnogo tekstova o 37s na Biznisblogu (uključujući i jedan tekst u aktuelnom PC magazinu).
Kao što Boccio reče na paralelnoj dpt temi Iliji: “Ne uzimaj sebe za primer, tvoja zarada i reputacija govore dovoljno o profesionalnosti, pricamo generalno o programerima sa ovog podneblja…” Tako sam i ja mislio na generalne iskusnije programere sa ovog podneblja, a ne na kolege sa ove diskusije—profesionalce kao što su Ilija i Petar Pavlović, koji su do “interface first” koncepta došli kroz svoj praktički rad.
Mladen: što se tiče funkcionalne specifikacije, ovi iz 37s to striktno odbacuju, ali mislim da bi se o ovome naširoko moglo diskutovati. Lako je to odbaciti kada si sam sebi gazda, u klijentskim uslovima je to malo drugačije, pogotovo kod komplikovanijih softverskih projekata.
Mladen Jablanović 938 days ago
?! Kako misliš “striktno odbacuju”? Funkcionalna specifikacija ti upravo definiše interfejs od koga počinješ. Nisam dosad čuo ni za jednu jedinu uspešnu firmu koja ne koristi funkcionalne specifikacije.
Marko Bijelić 938 days ago
Evo preneseni dio poglavlja:
There’s Nothing Functional about a
Functional Spec
Don’t write a functional specifications document
These blueprint docs usually wind up having almost nothing to
do with the finished product. Here’s why: – Functional specs are fantasies
They don’t reflect reality. An app is not real until builders are
building it, designers are designing it, and people are using it.
Functional specs are just words on paper.
– Functional specs are about appeasement – Functional specs only lead to an illusion of agreement – Functional specs force you to make the most important
decisions when you have the least information – Functional specs lead to feature overload – Functional specs don’t let you evolve, change,and reassess
stariji tekst na 37s SvN”
+ noviji o istoj temi iz 2006
Mladen Jablanović 937 days ago
Interesantno. I vrlo pogrešno. Kao prvo, skice interfejsa su obično deo same specifikacije i ova njihova priča “nas dvojica čitamo istu specifikaciju na dva različita načina” nikako ne pije vodu. Pa ona se upravo piše zato i na taj način da minimizuje nesporazume! Nesporazume ne samo između izvođača i klijenta, već (nimalo manje bitno) i između članova samog tima. Nisu svi softverski timovi sastavljeni od tri superstar programera kao ovi što su iskodirali Basecamp. Čim postoji odvojena funkcija software analysta, specifikacija je jedino moguće sredstvo komunikacije sa programerima i dizajnerima. Ako su članovi još prostorno dislocirani (outourcing, anyone?), jednostavno drugi način jednostavno ne postoji.
Svima savetujem da dobro pročitaju Džoelov elementarni članak o specifikacijama http://www.joelonsoftware.com/articles/fog0000000036.html i ne zavaravaju se puno pričama hotshot dizajnera koji su u timu od par ljudi sami sebi napravili veb aplikaciju.
Marko Bijelic 937 days ago
To je to. Mada ja sam tu negdje između, po eklektičkom principu od 37s uzimam ono što mislim da ima smisla, uglavnom filtriram kroz “smisleni filter”, odnosno koliko je njihova filozofija zaista “Real” i koliko odskače od tima u vidu superstar trojke. Suština je da dobar dio njihovih stavova nije primjenljiv u prosječnom timu. Ono što je jedino teorijski moguće, jeste da kao project manger probaš da oformiš što manji tim ljudi koji odlično zajedno funkcionišu da bi mogao odgovarajuće da odradiš te projekte.
Igor Bogicevic 935 days ago
ima jos jedna bitna stvar, koliko je njihova “superstar trojka” bila dislocirana? istina je zapravo negde izmedju, tradicionalna forma spec-ova ume da bude prilicno bloat-ovana standardnim formatima, uvodom, razradom, zapletom itd. ali to nije dobar spec, to je samo opsiran spec. njhov pristup, koliko god da je efikasan u malom okruzenju 3 developera koji rade u istoj sobi (ok, ne obavezno u istoj sobi), bi imao niz katastrofalnih konsekvenci u bilo kojem vecem okruzenju – sorry, ali kada finansije i tim prerastu garazu, pravila developmenta koja su do tada vazila takodje odrastaju, ili entropija ‘pojede’ isti (retardirani development?).
Marko Bijelić 935 days ago
Bilo bi dobro da neko baci linkove kao praktičnim primjerima dobrih spec-ova, Joel je dosta dobro pojasnio stvari u tekstu koji je Mladen linkovao iznad. Baš upravo taj dio sa odrastanjem i širenjem tima je najbolja ilustracija za gotovo neizbježnu katastrofu. Oni su se potpuno, što graniči sa ego-trip-glopošću, ograničili na idealne uslove “superstar trojke” u kojima su oni radili i potpuno se vode idejom: ako je radilo kod nas, radiće i kod vas, ili barem (dobar) dio savjeta možete iskoristiti. Što je u suštini dosta promašena filozofija. Čitanje Getting Real je samo po sebi veoma primamljivo i dosta stvari je lijepo i jednostavno objašnjeno, ali u praksi vladaju totalno drugačija pravila.
Ja iskreno nisam nikada radio u okruženju većih timova, ali sasvim solidno poznajem rad malih timova (2-5) u kojima sam radio. Prije mjesec dana sam se uključio u mini eksperiment sa jednim IT start-upom koji je inicijalno u početku brojao 9 ljudi (5 u menadžementu) sa tendencijom rasta zaposlenih i uopšte sama faza planiranja tog projekta nije imala nikakva veze sa bilo čim napisanim u Getting Real. Uglavnom, pravovremeno sam okončao isti eksperiment ;)
Inače, ima još jedna stvar u ovoj knjizi i samoj filozofiji, a to je da se nigdje ne spominje bilo šta što je vezano za liderstvo, sem par usputnih savjeta o upravljanju projektom. O organizacija tima koji broji 4 i više članova i načinu menadžerisanja istog, nigdje ni traga ni glasa u čitavoj filozofiji.