Naš proces: Distribucioni kanali

Beleška: Ovaj članak je spremljen za naš kompanijski wiki i tu je prvi put objavljen. U pitanju je deo živog procesa koji koristimo pri Active Collab razvoju. Proces stalno usavršavamo u skladu sa novim saznanjima, što praktičnim, što teorijskim. Ukoliko vam se ovaj tip tekstova sviđa, ostavite u komentaru dole sva pitanja ili teme o kojima biste želeli da pišem u budućnosti.

Distributivni kanali su način da razgraničimo više grupa korisnika, u skladu sa komforom koji imaju prema nestabilnom softveru i eksperimentalnim mogućnostima, i da im isporučujemo softver u skladu sa time.

Naš proces i sistem za isporuku softvera nam omogućava da “gađamo” jedan ili više kanala sa novim verzijama, kao i da neke mogućnosti uključimo ili isključimo u skladu sa kanalom na koji je softver isporučen.

U Active Collab projektu imamo četiri distributivna kanala, tri specifična za Cloud naloge i jedan za korisnike koji sami hostuju Active Collab:

Edge je kanal koji se koristi za testiranje u produktivnom okruženju, ali bez mušterija. Njega koristimo za potrebe finalnog testiranja i kako bi dokumentacioni i business development team imao pristup mogućnosti dovoljno pre nešto se isti nađe pred mušterijama.

Naš produkcioni Active Collab je uvek na ovom kanalu, a master grana treba da bude dovoljno stabilna da ne slomi našu produkciju. Čak i da se desi da “slomimo Edge”, taj momenat nas dovoljno “zaboli” pošto nam je potreban za rad, tako da je tim motivisan da problem što pre reši.

Beta je kanal na koji puštamo mogućnosti za koje želimo malo više testiranja sa samim korisnicima, pre nego što ih pustimo svima. Ovaj kanal koristimo za usability i beta testiranje kako bi finalna verzija mogućnosti bila unapređena u skladu sa rezultatima tih testiranja.

Ukoliko se mogućnost ne ispostavi kao pun pogodak, možemo da razmislimo o daljim unapređenjima, a možda čak i o izbacivanju mogućnosti iz softvera, bez prevelikih komplikacija i posledica po korisnike.

Mušterije same mogu da se jave da budu ubačene na ovaj kanal, a broj je kontrolisan. Idealno je da broj korisnika na beta kanalu bude maksimalno 10% ukupnog broja aktivnih korisnika, kako ne bi previše ljudi bilo izloženo testiranju i nestabilnosti. Takođe, ova grupa bi trebalo da je relativno mala kako ne bi vršila veliki pritisak na razvojni tim i podršku.

Stable je kanal čije mogućnosti dobijaju svi Cloud korisnici. U pitanju je kanal na koji puštamo samo verzije za koje smatramo da su pogodne za opštu upotrebu.

Self-hosted je poseban distributivni kanal koji koristimo za distribuciju verzije softvera koju mušterije sa licencama hostuju kod sebe na serverima. Obično prati Stable kanal ili kasni par manjih inkremenata iza tog kanala, pošto je u pitanju verzija koja se distribuira korisnicima kod kojih nemam platformu pod kontrolom, pa samim tim želimo da naš softver bude što stabilniji.

Definicije ovih kanala i njihova svrha je strogo definisana, a proces isporuke softvera na njih u potpunosti automatizovan.

4D i OHIO

Dnevno rešavam stotinak mailova. Ima tu svega: podrške, transkripti razgovora sa mušterijama, notifikacija iz našeg sistema o poslu na kome se radi, ostalih poslovnih mailova i (najmanje)​ lične pošte. Iako ne bih mogao reći da je zatrpan mailbox sam po sebi uzrok stresa, definitivno pomaže pošto sam primetio da tenzija raste sa brojem stvari koje su mi "otvorene" (nezavršene).

No, u zadnjih mesec dana sam počeo da koristim izuzetno jednostavan pristup kojim jako brzo čistim i lični mail i podršku. Svodi se na primenu dva jednostavna principa koja opisuju dve skraćenice: 4D i OHIO. Znam da su skraćenice i glupe i da bacanje istima nedvosmisleno pokazuje želju govornika da se svidi ili ostavi utisak pametne i informisane osobe. Ipak, ovde ću se držati skraćenica zašto je mail nešto sa čime radim svakodnevno, a skraćenice pomažu da se principi lako zapamte i još lakše koriste, pa postaju skoro kao mantre.

4D samo kaže da treba da uradite jednu od ove četiri stvari kada primite mail:​

  • Do It - Uradi šta treba odmah umesto da ostaviš za kasnije. Postoji gomila stvari koje mogu da se reše za manje od dva minuta i bolje ih je uraditi odmah, nego ostavljati za kasnije.
  • Defer It - Ako ne možeš da rešiš sada, odloži za kada možeš. Ja svoje stvari beležim u Things i arhiviram mail, ali za ovo može poslužiti i neki folder, podsetnik, parče papira itd.
  • Delegate It - Prebaci nekom drugom da dalje rešava. Ovo je česta stvar na podršci. Mailove šaljem dalje na verifikaciju problema, da se reši neki bug, pomogne mušteriji itd.
  • Delete It - Najslađa D u listi. Brišem sve što mogu, a arhivu ne organizujem. Kada je gotovo, više nije bitno.

Za razliku od 4D, koji kaže šta da se radi, OHIO kaže kako da se radi: Only Handle It Once. Svaki ponovni povratak poruci koju ste već pročitali bez da je rešena je nepotrebno trošenje vremena i pažnje. Onog momenta kada vidim mail, rešim šta ću sa njim i ne vraćam mu se (osim ako nije odložen). Jednostavno.

​Sparrow, Inbox Zero

​Sparrow, Inbox Zero

Dodatak: U momentu pisanja, help desk kaže 0/0 (prazan inbox, prazan moj queue), a Sparrow pokazuje Inbox Zero. Stoji da je tehnika čist productivity porn, ali meni lepo radi posao.

Microsoft - umiruća platforma?

U zadnjih par dana smo radili na uprošćavanju izgleda email obaveštenja koja activeCollab šalje korisnicima. Kroz par kratkih dizajn iteracija smo došli do onoga što nam se sviđa i na meni je bilo da dogovoreni dizajn prekodiram. 

Notification

Meni se ovaj dizajn svideo jer jasno naglašava akciju, nije grafički težak i može brzo da se prolazi kroz niz obeveštanje i vide bitne informacije. Vrlo brzo sam iskodirao verziju koju Gmail i Sparrow korektno prikazuju, ali problemi su krenuli onog momenta kada sam upalio Outlook i pogledao kako se stvari u njemu vide.

Ukratko: "Mikrosofte, koji k???" Znao sam da Outlook ima slabu rendaljku koju deli sa ostalim alatima u Office paketu, ali nisam bio svestan da ću morati da se vraćam u 1998. Čak je i IE6 miljama ispred rendering endžina koji Outlook 2010 ima u sebi. Posle par sati frustracije i eksperimentisanja, došao sam do nečega što koliko toliko liči na originalni dizajn i stao kada je prosta funkcionalnost postignuta. Od mene toliko… Finese će dobiti fini klijenti, a Outlook dobija tek toliko upeglan dizajn da se ne raspada.

Umiruća Platforma

I tu dolazimo do jednog zanimljivog momenta, do koga je doveo proces kompletno poguban po sam Microsoft: Microsoft platforma prestaje biti bitna u očima mnogih developera! Kompanija ima mnogo korisnika, ali već godinama gubi grupu ljudi koju bih opisao kao vrh koplja - opinion-makere, programere i dizajnere koji prave zanimljive aplikacije i proizvode, tech novinare… Ti ljudi više ne koriste Microsoftove proizvode, na konferencije za štampu koje organizuje Microsoft dolaze sa Mac laptopima ili iPadima, testiraju za Windows na kraju, kada razmišljaju o nekoj inovaciji, retko kao polaznu tačku uzimaju Microsoft platformu itd. 

Nesumnjivo je da je Microsoft previše velik da bi propao i može sasvim lepo da živi u svom "malom mehuru" godinama, možda čak i decenijama, bez većih problema. Međutim, to je put umiruće platforme. Vrh koplja je okrenut na drugu stranu i samo je pitanje vremena kada će za sobom povući i dobar deo ostalih korisnika.

Working Effectively with Legacy Code

Evo jedan članak u duhu knjige koju upravo čitam: Working Effectively with Legacy Code. Misija je izmeniti klasu koja pravi izveštaje na osnovu praćenog vremena i troškova u activeCollab 3 tako da podržava više valuta.

Wewlc

Podrška za više valuta je dodata u međuvremenu i sistem za izveštavanje je nije svestan, tako da trenutno meša babe i žabe (troškove napravljene u Eurima tretira isto kao i troškove napravljene u dinarima i dolarima i samo ih sabira).

Problem je što trenutno ne postoje apsolutno nikakvi testovi za klasu za izveštavnje, pa:

  1. Nisam siguran da li klasa radi kako treba bez ikakvih izmena. Malo sam se igrao i sve deluje OK, ali nisam baš 100% siguran da sam pokrio sve slučajeve.
  2. Ukoliko krenem sada da prepravljam kod, nisam siguran da li će novi kod raditi kako treba bez mnogo ručnog njakanja izveštaja sa znanim podacima. Može to da radi neko drugi umesto mene (QA), ali bi se time krug između izmene i testiranja produžio na sate u najboljem slučaju (dane realno) što je previše sporo i troši vreme dve osobe umesto jedne.

Izveštavanje podržava prikaz individualnih zapisa ili sumiranih podataka, plus četiri načina grupisanja u oba slučaja, tako da baš treba vremena za ručnu pripremu podataka i testiranje. Iz tog razloga, prvi korak je napisati automatizovan test koji će nam potvrditi da kod radi ono za šta je originalno napisan da radi:

Test tracking reports

Pošto koristim activeCollab Timer da pratim vreme, znam koliko mi je vremena bilo potrebno da postavim testove: 1 sat i 15 minuta efektivno. Uzimajući da iz svog dana retko kada uspem da izvučem više od 3 sata efektivno programiranja, to stvarno deluje kao jako mnogo vremena za posao koji tehnički ni na koji način nije unapredio proizvod: ni jedna nova mogućnost nije dodata, ni jedna stranica nije ubrzana, ni jedna labela u sistemu nije prepravljena da bude jasnija…

Međutim, ono što je to uloženo vreme donelo je postavljanje sigurnosne mreže za sve današnje i buduće izmene koje će se desiti toj klasi. Pa krećemo…

Prvo što sam uradio je refaktorisao metod koji barata sumiranim izveštajima. U momentu kada je pisan, delovalo je da će prost switch raditi posao, ali je metod vremenom prerastao 300 redova koda. Kada sam ga rastavio i ponovo sastavio tako da koristi više pravilno imenovanih metoda, poterao sam ranije napisane testove da vidim da nisam nešto u međuvremenu pokvario. 10 sekundi kasnije testovi su mi rekli da klasa radi na identičan način kao i ranije, iako je sada osetno jednostavnija za čitanje i ispravke. Lepo!

Nakon refaktorisanja ide i onaj deo zbog čega je cela priča i počela: dodavanje mogućnosti izveštaja da sumiraju podatke kada je u sistemu definisano više valuta. Pre nego što se bacim na prepravljanje koda same klase, prvo treba da se napiše test koji proverava naša nova očekivanja. Naravno, pošto je ovo urađeno pre nego što smo stvarno i dirali kod, test neće proći:

Test tracking reports 2

Možda zvuči malo glupo pisati test pre koda, ali to je cela poenta iza Test-Drive Development pristupa. Pisanjem testa pre pisanja koda imamo priliku da lepo ispišemo očekivanja i uočimo neke rane problem u dizajnu.

Ovo je zanimljiv momenat. Ranije bih počeo ovde, međutim u ovom konkretnom slučaju iza sebe već ima dva sata efektivnog programiranja, a kao rezultat tu su sistem kojim mogu oceniti da li izmene koje budem napravio rade kako treba, plus je sam rad sa klasom jednostavniji jer sam neke komplikovane delove refaktorisao.

Idemo lagano - sada treba da izmeniti klasu da zadovoljili nova očekivanja. Uz izmenu klase i test se možda promeni na nekim mestima koja bih još dodatno da pokrijem, a koja sam prevideo kada sam ga pisao. Kada je sve gotovo, dobijemo lep rezultat:

Test tracking reports 3

activeCollab Timer kaže: 45 minuta za novu funkcionalnost, plus 2 sata ranije za pisanje testova i refaktorisanje.

Ovakav pristup programiranju je investicija u kvalitet softvera koji će biti poslat klijentima (najskuplji je bug koji korisnik nađe), kao i u budući razvoj. Modifikovanje bilo koje klase je osetno jednostavnije ukoliko već postoji test za nju, tako da će razvoj postajati lakši ako se sistematski prolazi kroz postojeći kod i pišu testovi za njega, iako sama aplikacija u međevremenu raste i postaje komplikovanija.

I za kraj, proces, ukratko:

  1. Postavimo testove koji proveravaju da li postojeći kod radi na očekivani način;
  2. U svakom kodu uvek ima nešto da se refaktoriše, tako da uzmemo lepo pa prepravimo par stvari, kako bi kod bio čitkiji, a buduće izmene lakše;
  3. Prepravimo testove tako da proveravaju naša nova očekivanja i poteramo ga iako znamo da neće proći. Korisno je videti tačke u kodu na kojima nova očekivanja nisu ispunjena;
  4. Prepravimo klasu tako da zadovoljava nova očekivanja;
  5. Otvorimo jedno 'ladno jer smo sebi i kolegama upravo uštedeli sate posla u budućnosti, a korisnicima napravili kvalitetnije rešenje koje će manje pucati i za koje ćemo lakše i brže objavljivati unapređenja i ispravke.

Jednostavan trik za kreiranje novih fajlova

Kada sam se pre dve i po godine prebacivao sa Windowsa na Mac, jedna od prvih stvari koju sam primetio da mi nedostaje je mogućnost kreiranja novog fajla u folderu direktno iz Findera. U Windows Exploreru je to lako - desni klik kada ste folderu, pa iz New menija izabereš tip koji hoćeš da kreiraš.

Toga na Mac OS-u nema... U jednom momentu sam čak i kreirao Automator akciju za kreiranje novo fajla, ali je nisam previše koristio pošto je bila previše zavučena i nezgrapna. Čak je i otvaranje Terminala, navigacija do foldera i kucanje edit (ili mate u zavisnosti od toga koji sam tekst editor tada koristio) komande bilo zgodnije od nje.

Amater, šta reći :) Međutim, juče uzmem da pročitam stvari koje su mi ostale nepročitane i naletim na članak koji opisuje kako su različiti operativni sistemi pristupali odnosu fajl menadžera i aplikacija, kao i kreiranju novih fajla. Na kraju članka ima i jednostavan trik kako da omogućite lako kreiranje novih fajlova, kao i fajlova na osnovu šablona u Finderu.

Trik se oslanja na ugrađeno ponašanje u Finderu - kada krenete da premestite nešto iz zaključanog foldera, sistem će umesto premeštanja napraviti kopiju.

new-file-info.jpg

Ispratite sledeće korake i sve će vam biti jasno:

  1. Napravite folder "New File" negde gde vam neće smetati (ja sam ga stavio u svoj home folder)
  2. U njemu napravite niz praznih fajlova. Ja imam "New Text File.txt", "New PHP File.php" i "New HTML File.html" (plus jedan folder, čisto za testiranje)
  3. Desni klik na "New File" i otvorite Get Info dijalog. U General sekciji otkačite Locked opciju kao na slici
  4. Kada ste to završili, prevucite folder u Dock i kreirajte Stack

Sada je dovoljno da uzmete i prevučete fajl iz "New File" Stacka u folder gde želite da kreirate novi fajl i Finder će temo napraviti kopiju koju dalje možete da koristite kako vam je volja:

Najbolja stvar je što fajlovi ne moraju da budu prazni, pa možete imati i template. Uz to, niste ograničeni samo na fajlove. Imate strukturu foldera i fajlova koju uvek koristite za projekte? Kreirajte template folder, nabacajte u njega sve što inače koristite i to je to - celu strukturu ćete kasnije kopirati prostim prevlačenjem. Još jedna dobra stvar je da je folder zaključan, tako da nećete moći da greškom ispreturate, izmenite ili obrišete svoje fajlove. Da biste to mogli da uradite, moraćete prethodno da otključate folder što je dodatni stepen "zaštite" od brljanja.

new-file-stack.jpg

Toliko od mene. Pročitajte gore pomenuti članak za detalje i "teorijsku podlogu" o ovoj prilično jednostavnoj operaciji koja je iz nekog razloga uvek zakomplikovana na svim platformama.

Priprema oglasa za posao

U zadnjih godinu, dve sam bio u prilici da napišem par oglasa za različita otvorena mesta u firmi. Daleko bilo da me je to učinilo ekspertom, ali kroz tih par oglasa i gledanje na oglase drugih firmi, iskristalisao se prost šablon za njihovo pisanje:

  • Ukratko opišite kompaniju i njenu delatnost. Cilj je da se, bez previše uvijanja i okolišanja, kaže čime se kompanija bavi i zašto bi to trebalo da bude zanimljivo kandidatu.
  • Navedite za koje mesto želite da nađete zaposlenog. Ime pozicije treba da bude relativno kratko (max par reči) i da bude jasno istaknuto (zaseban pasus, velika slova itd).
  • Nakon imena, opišite aktivnosti koje radno mesto uključuje. Lista bi trebalo da bude dovoljno opširna da lepo prikaže posao, a opet ne toliko dugačka da smori ljude.
  • Nako što ga opisali, kažete šta pružate kandidatu za obavljanje navedenog posla - fleksibilno radno vreme, prijatno okruženje, konkurentnu platu, bonuse i dodatke itd.
  • Na samom kraju, navedete tača očekivanja koja kandidat mora da zodovolji da biste ga uzeli u obzir - stručna sprema, poznavanje jezika, tehnologije, očekivano iskustvo, lokacija itd.

Svim ovim stavkama zatvarate krug - ko ste, šta vam treba, šta pružate za to i koja su vaša minimalna očekivanja. Primer oglasa koji prati ovaj šablon, a koji smo nedavno koristili da bismo popunili jedno otvoreno mesto možete videti u jednom starijem Area51 članku: Oglas za posao:

customer-replations-oglas.jpg

Za kraj samo napomena da je šablon iz prakse, ne iz HR udžbenika ili pravilnika neke kompanije. Dovoljno je opšt i jednostavan da se može primeniti na većinu oglasa, ali sam siguran da postoje i situacije kada neće raditi posao.

Ako imate neke dodatne primere ili komentare, znate šta vam je činiti :)

SVN merge

subversion.jpgStvarno ne bih mogao da zamislim kako bismo izlazili na kraj sa poslom da nema SVN-a. Trenutna operacija je sledeća - četiri programera koja svakodnevno rade na dve razvojne verzije aplikacije koja će uskoro prebaciti 200 hiljada redova koda (samo naš kod, bez dodatnih biblioteka kao što je Smarty i SwiftMailer), plus na održavanju sajta koji je u potpunosti custom razvijan. Nije to ništa veliko (probajte da zamislite tim od 30 programera koji rade na legacy sistemu koji ima par miliona redova koda), ali bez sistema kao što je SVN bi nastao pravi haos. Iako je nezamenljiv alat koji stvarno pomaže da bolje završavamo posao, neke stvari su i dalje dosta nezgodne. Kao što rekoh, uvek paralelno radimo na dve grane aplikacije - održavanje stabilne grane (v1.1) i glavnoj grani koja donosi nova veća unapređenja i koja je uglavnom nestabilna (v1.2). Kada su stvari tako postavljene, s vremena na vreme izmene iz v1.1 treba da ubacimo u v1.2 koji je odavno krenuo svojim tokom; tj. treba da mergeujemo stabilni branch u trunk (trunk je glavna razvojna grana).

Proces ubacivanja izmena iz jedne grane u trunk koji se već 6 meseci razvija samostalno definitivno ne deluje kao naivan posao. SVN tu pomaže, ali je to i dalje proces koji zna da uzme i do po par sati i gde dosta toga može da pođe na loše. Evo kako to radimo:

1. Nađemo reviziju kada je zadnji put rađen merge (revizija XXXX u daljim komandama). Ovo je bitno jer merge izmene između te revizije i trenutne revizije u grani ubacivati u trunk. Ako omašimo reviziju i navedemo pogrešnu, možemo primeniti pogrešne izmene.

2. Na disk checkoutujemo svež kod iz trunka. merge radi tako što upoređuje određenu reviziju grane sa najsvežijim kodom u grani i te izmene ubacuje u work copy u kome smo. Dakle, imamo svež trunk, i iz terminala dođemo do njega:

cd /Library/WebServer/Documents/activecollab trunk/activecollab

Nakon toga radimo merge:

svn merge -rXXXX:HEAD "REPOSITORY-URL/activecollab/branches/REL 1.1"

Kada znam da je bilo dosta izmena, obično odradim dry run koji lista izmene koje će napraviti, bez da ih primeni na sam kod. Dosta korisno da vidite koliko će vam glavobolje merge zadati:

svn merge -rXXXX:HEAD --dry-run "REPOSITORY-URL/activecollab/branches/REL 1.1"

3. Pustimo merge komandu da radi posao. Kada merge naleti na konflikt, možete ga razrešiti ili ostaviti razrešenje za kasnije. Iako SVN nudi više opcija ja lično koristim samo tri komande:

p - postpone (razreši kasnije), mf - mine force (razreši koristeći kod iz trunka), tf - their force (razreši koristeći kod iz grane).

4. Commitujemo work copy. Sada kada su sve izmene primenjene i konflikti razrešeni imamo nov, svež i up-to-date trunk.

I za kraj dva saveta. Prvo, često radite merge. Najveća sranja sam imao kada sam puštao da se nakupe meseci izmena. Tada sam morao da odvajam po celo veče samo za merge. Sporo, mučno i traćenje vremena. Drugo, automatizujte proces. Sad ću da sednem i napišem script koji će mi skinuti veći deo merge procesa sa vrata. Razrešavanje konflikata je i dalje nešto što ću morati da nadgledam i ručno rešavam, ali veći deo operacija može da ide automatski.

Vaša iskustva i saveti sa SVN-om i branchevima?

Zgodna organizaciona tehnika za usavršavanje

Pre neki dan sam pisao o jednoj tehnici za usvajanje dobrih navika. Cela priča se može svesti na to da treba da se menja jedna po jedna navika, a ne više odjednom i da se novoj navici posveti 30 dana. Ukoliko se pokaže da se navika ne uklapa u vaš stil života ili da vam ne pomaže, super - odustanete od nje i znate da vam nije radila posao.

Zanimljivo je kada u knjizi koja je prevashodno namenjena organizacijama koje žele da usvoje lean način razmišljanja naletite na tehniku za rešavanje problema i usavršavanje koju odmah možete da primenite i u svakodnevnom životu.

pdca.jpg

Plan-Do-Check-Act (PDCA) je četvorostepeni proces koji se koristi kako bi se došlo do boljeg rešenja određenog problema ili dosegao određeni cilj. Koraci su:

  1. Plan - Definišemo problem i pretpostavimo da bi određeni proces pomogao u rešavanju problema. Zanimljiva tehnika iz "The Hitchhikers Guide to Lean": rečenica formulisana kao "Ako ... očekujem ..." dovoljna je da se pokrije ovaj korak. Na primer: "Ako počnem zdravije da se hranim, očekujem da ću biti zdraviji i da ću manje novca trošiti na hranu" ili pak "Ako počnem da ustajem rano očekujem da ću biti odmorniji, pre završavati posao kako bih imao više vremena da se posvetim drugim stvarima".
  2. Do - Unosimo izmenu na osnovu plana. 30-to dnevna posvećenost iz prethodnog teksta deluje kao dobro odmeren period za većinu izmena koje mi padaju na pamet, ali verujem da za neke složenije stvari treba više vremena.
  3. Check - Nakon vremenskog perioda određenog u Plan koraku merimo ostvarene rezultate.
  4. Act - U ovom koraku gledamo u kakvom su odnosu ostvareni rezultati sa onim što smo očekivali. Da li se osećam zdravije? Odmornije? Da li trošim manje novca na hranu? Ovo je korak gde se najviše uči jer sada pored pretpostavke imamo i stvarne podatke na osnovu kojih možemo da izvučemo neku pouku, vidimo gde se grešilo i kako cela stvar može da se unapredi itd. Usvajaju se delovi koji su doneli rezultate, na greškama se uči i krug se ponavlja.

Proces je iterativan i ponavlja se iznova kako bi se stvar na kojoj radimo dalje usavršavala. Ono što je meni lično zanimljivo je jasno definisanje očekivanja u prvom koraku. Ranije sam pravio niz grešaka tako što sam počinjao izvesne stvari bez jasno definisanog cilja i načina kako da merim da li napredujem, tapkam u mestu ili nazadujem.

Za više informacija: PDCA na Wikipediji. Autor dijagrama: Karn G. Bulsuk.

The Toyota Way - 14 principa upravljanja

the-toyota-way.jpg

Da počnem sa time da je moje iskustvo sa auto-industrijom i proizvodnjom fizičkih proizvoda nikakvo. To je jedan od razloga zašto mi je "The Toyota Way" zapela za oko. Drugi razlog je što sam na više mesta nailazio na lean production, lean software development i slične koncepte, a mnogi navode Toyotu kao firmu koja je otišla najdalje u primeni lean razmišljanja u proizvodnji i poslovanju.

Knjiga se ne bavi alatima, već principima i o tome kako se ti principi uklapaju u priču jednog od najvećih proizvođača automobila današnjice. Iako se u dosta navrata pominju alati i tehnike koje Toyota koristi, autor se njima ne bavi mnogo, već ih samo pominje u kontekstu principa koji opisuje.

"The Toyota Way" počinje tako što ukratko opisuje Toyotu kao kompaniju, njen nastanak i put od male privatne firme do jednog od najvećih proizvođača automobila na planeti. 14 principa upravljanja je navedeno i ukratko opisano odmah na počeku da bi ih autor kasnija poglavlja detaljno objasnio.

Princip 1: Odluke se baziraju u skladu sa dugoročnim planovima i principima, čak i po cenu kratkoročnih finansijskih rezultata. Kompanija treba da nađe sebi svrhu, ponaša se odgovorno i kreira vrednost svojim kupcima, društvu i ekonomiji. Odluke i delovanje se usmerava ka ostvarenju dugoročnih planova, a ne kratkoročnih rezultata.

Na primer, jedan od Toyotinih principa je da ne optušta radnike kada su vremena loša. Sada je prilika da vidimo da li će kompanija biti dosledna ovom principu. U situaciji u kojoj se danas nalazi auto industrija, teško je ne misliti na troškove, pad prodaje, gubitke i smanjenje istih.

Princip 2: Proces treba da bude tok kako bi problemi isplivali. Sirovi materijal prolazi kroz tok i konstantno se transformiše do finalnog proizvoda. Svi koraci od početka do kraja se mogu podeliti na one koji donose i na oni koji ne donose vrednost mušteriji. Potrebno je maksimizovati vrednost, uz stalno smanjenje aktivnosti koje ne dodaju vrednost - "otpada".

Princip 3: Pull sistem se koristi kao mera za sprečavanje jednog od osnovnih otpada - prekomerne proizvodnje. Svaki korak u procesu je mušterija koja "kupuje" materijal od prethodnog koraka. Ideal je pružiti mušteriji ono što joj treba, kada joj to treba i tačno u količini koja joj treba. Ovakav pristup se bazira na pull principu - umesto da prethodni koraci "guraju" materijal i orijentišu se prema svojoj proizvodnji (push), kod pull sistema naredni koraci "povlače" šta i kada im je potrebno od prethodnog koraka.

Između koraka se pravi mali inventar čija je uloga "peglanje" toka, ali se uvek teži smanjenju inventara i što savršenijem toku.

Pošto je ponašanje mušterija nepredvidivo, plan proizvodnje se pravi dnevno kako bi se što brže odgovorili na zahteve i smanjio broj jedinica proizvoda koje mušterije ne žele.

Princip 4: Proizvodnja se ujednačava kako bi mogli da se isporuče predvidivi i konstantni rezultatu. Treba odstraniti preopterećenje ljudi i mašina i ujednačiti proizvodnju. Uvek je bolje konstantno raditi uz optimalno opterećenje, umesto imati neujednačenu proizvodnju gde u nekim trenucima ljudi nemaju šta da rade, dok u drugim ne mogu da stignu da isporuče poručeno. Taiichi Ohno, otac Toyota Production Systema ovo poredi sa basnom o zecu i kornjači.

Princip 5: Potrebno je razviti kulture gde se staje kako bi se rešio problem i kvalitet postigao iz prve. Ogromna prednost toka je da problemi isplivavaju kada jedna od ćelija u toku ima problem. Pošto je u pitanju tok, problem mora biti rešen što pre kako se tok ne bi zaustavio. Takođe mora da bude rešen temeljno kako tok ne bi bio ugrožen u budućnosti.

Koriste se alati za detekciju grešaka i vizuelne kontrole koje nedvosmisleno pokazuju da problem postoji i gde se nalazi vođama timova. Svaki zaposleni ima dozvolu i obavezu da zaustavi proizvodnju ukoliko naiđe na problem.

Ceo tok ne staje odmah jer između koraka postoje male zalihe koje ga peglaju, ali one traju jako kratko tako da problem treba da bude rešen što pre.

Princip 6: Bez standardizacije i predvidivosti procesa nije moguće kreirati tok. Treba koristiti proverene i standardizovane akcije za koje se zna koliko traju kako bi proces davao predvidive rezultate. Bez toga je nemoguće imati tok.

Iskustvo stečeno ponavljanjem izvesne akcije će pokazati najbolje prakse koje treba da postanu standard, ali tu proces ne staje. Treba dozvoliti slobode kako bi radnici mogli da eksperimentišu i unapređuju proces. Unapređenja koja se pokažu kao dobra postaju deo standarda.

Princip 7: Koriste se vizuelne kontrole kako bi se naglasili problemi i brzo komunicirale informacije. Vizuelni alat bi trebao da bude jednostavan i nedvosmisleno pokazuje da trenutna situacija odstupa od standardne. Treba izbegavati alate koji odvlače pažnju ljudi sa mesta na kome se stvaran rad izvršava.

Ljudi većinu informacija primaju vizuelno i Toyota insistira da se informacije tako komuniciraju. Jedan A3 papir sa dosta grafova i samo potrebnim informacija će bolje preneti potrebne informacije nego 50 strana sitno kucanog teksta koje niko ne želi da čita.

Princip 8: Koriste se samo proverene, stabilne tehnologije koje pomažu ljudima i procesima. Tehnologija treba da se koristi kako bi se zaposlenima pomoglo, ne kako bih ih zamenila. Mašina ne ume da uči i nije inovativna. Često je dobra ideja određeni posao raditi ručno pre nego što ga automatizujete kako biste ga bolje razumeli i unapredili.

Nove, nedokazane tehnologije mogu da ugroze tok tako da im treba pristupati sa rezervom i ubacivati ih u proces tek nakon što su se pokazale i zadovoljile testove. Ovo ne znači da ne treba podsticati ljude da isprobavaju nove stvari, već samo da se ne treba zaletati na nove tehnologije i koristiti ih bez detaljnog testiranja i ispitivanja.

Princip 9: Lidere treba razvijati iz sopstvenih redova. Dobar lider treba da razume ono što se radi i da svojim ponašanjem bude uzor ostalim ljudima koji rade u kompaniji. Lider treba da živi i diše kompanijsku kulturu i dobro poznaje procese unutar kompanije.

Autor navodi niz primerga gde su kompanije zapošljavale lidere spolja. Kada takva osoba uđe u kompaniju, često ima viziju gde želi da je odvede, ali ta vizija nije povezana sa kulturom firme i ne pusti uvek korenje.

Princip 10: Ulažite mnogo u razvoj individualaca i timova koji žive i dalje razvijaju kompanijsku kulturu. Kompanijska kultura je bitna na duge staze, a nju čine samo i isključivo ljudi, ne motivacioni posteri okačeni po zidovima. Sama kompanija i kultura treba da podstiču ljude da se razvijaju i napreduju.

Timski rad se uči. Kreiranje timova koje čine stručnjaci iz različitih oblasti pomažu bržem rešavanju problema jer se isti sagledavaju iz više različitih perspektiva. Takođe se smanjuje "otpad" u komunikaciji kada problem rešava više odvojenih specijalizovanih jedinica (npr. stručnjaci za aero-dinamiku, dizajneri i mašinci bi trebalo da rade zajedno na dizajnu novog vozila kako bi kroz direktnu komunikaciju pre došli do boljeg rešenja).

Princip 11: Dobavljače i partnere treba poštovati i motivisati da se razvijaju i unapređuju. Pomoć se pruža kroz podršku, obuku i konstantne izazove. Ukoliko očekujete od partnera da zadovolji vaše visoke standarde i uz to mu pomažete da ih dosegne, pomažete mu da bude bolji. Naravno, očekivanja treba da budu realna i takva da obe strane dobijaju.

Princip 12: Idi na lice mesta da bi spoznao šta je problem i rešio ga. Ovaj princip se zasniva na tome da odluke treba donositi tako što se proces posmatra i na osnovu posmatranja dođe do dubokog razumevanja procesa.

Menadžment ne bi smeo da donosi odluke na osnovu izveštaja, informacija iz treće ruke i pretpostavki, već da ode na "izvor" problema, analizira ga i tamo ga reši, čak i ako to podrazumeva da zasuče rukave i zaprlja ruke.

Princip 13: Odluke se donose sporo, kroz konsenzus i razmatranje što većeg broja alternativa. Sve strane koje odluka pogađa treba da budu uključene u proces odlučivanja kako bi se izbegla situacija da je izmena pomak unazad i čini rad jako teškim pojedinim grupama čija je perspektiva previđena.

Menadžeri intervjuisani u knjizi kažu da je mnogima jako teško da nauče da treba da zastanu i dobro preispitaju alternative pre nego što krenu sa implementacijom ideje. Treba zastati, analizirati alternative i tek kada se odabere najbolji put krenuti sa radom, brzo, temeljno, ali i oprezno.

Princip 14: Kompanija treba neprekidno da uči kroz konstantno unapređenje i osvrtanja na ono što je urađeno. Kada je proces stabilan treba koristiti stalno unapređenje kako bi se neefikasnosti i otpad uvidele u procesu. Kada kompanija koristi minimum inventanra, greške i otpad jako brzo isplivaju i mogu se rešiti.

Znanje treba da ostane u firmi i da nastavi da se razvija. Radno okruženje treba da bude što stabilnije bez velike smene radnika i kroz spora unapređenja. Lideri i naslednici se oprezno biraju i kreiraju dugim radom u kompaniji.

Nakon svakog projekta treba zastati, pogledati urađeno i uvideti greške i propuste. Kada su greške i propusti identifikovani, treba u naredne projekte treba dodati mehanizme koji će pomoći da se iste više ne ponove.

Što se mene lično tiče, stvarno mi je prijalo da pročitam nešto što nema previše veze sa razvojem softvera i ostalim temama koje me pretežno zanimaju, a da je opet moguće povući niz paralela sa našom situacijom. Većina principa je univerzalna i važi kako za malu softversku firmu tako i za giganta koji zapošljava stotine hiljada ljudi širom planete. Sa druge strane, neki principi se baš i ne uklapaju. Male firme koje tek rastu treba da razmišljaju o kulturi koju grade, ali im u tom stadiju verovatno nije bitan trening naslednika.

Najveći problem knjige je što je dosta jednostrana i pristrasna. Ne postoji savršen sistem, nije moguće da Toyota sve radi kako treba i da ostali proizvođači neke stvari ne rešavaju bolje. Perspektive drugih proizvođača, bivših i sadašnjih radnika i saradnika, a ne samo trenutnog menadžmenta su stvari koje nedostaju pa knjiga ima dosta jednostran pristup. Da se razumemo, to je ne čini lošom, ali ostavlja par nepopunjenih rupa i zahteva da se neke stvari uzmu sa rezervom.

Vista - Boot Camp - Fusion

Pre par dana su nam stigle dve Vista licence, za nove laptope. Za razliku od starih mašina gde su Windows instalacije bile kasične virtualne mašine unutar Mac OS-a, sa novima smo odlučili da idemo na dual boot variajntu.

vista-bootcamp-fusion.jpg

Evo je procedura:

  1. Pokrenete Boot Camp Assistance aplikaciju (nalazi se u /Applications/Utilities) i kažete da želite novu Windows instalaciju. Aplikacija će vam omogućiti da kreirate novu particiju i nakon toga tražiti od vas da ubacite instalacioni disk i restartujete računar.
  2. Računar će se restartovati i ide klasična Windows instalacija (offtopic: da li sam se ja tripujem, ili Vista installer traži mnogo manje informacija od ranijih Windowsa?)
  3. Kada se instalacija završi i ulugujete se sa Windows nalogom, izbacite Windows i ubacite Leopard instalacioni disk koji ste dobili uz računar. Na disku se nalaze svi potrebni drajveri plus Boot Camp Control Panel alat. Ovaj alat vam omogućava da konfigurišete hardver i da restartujete računar tako da se pri sledećem startu pokreće Mac OS (Restart in Mac OS).

Nema cimanja sa više diskova sa drajverima, dodatnim softverom za particionisanje diska itd. Sve što je potrebno je Windows i Leopard instalacioni diskovi i malo vremena.

Veliki smor kod dual boot setupa je to što treba da restartujete računar u drugi OS ako vam treba neki fajl ili program. Takođe, ne možete da koristite paraleleno dva operativna sistema. Proizvođači alata za virtualizaciju su uvideli problem tako da sada alati kao što je VMware Fusion bez problema koriste postojeće Windows particije na disku i mogu da ih podignu kao virtualne mašine.

bootcamp-partition.jpg

I dva mala dodatka za kraj:

  1. Kada palite računar, možete birati particiju sa koje da se bootuje sistem tako što držite pritisnut taster Alt.
  2. Oliver mi reče da Boot Camp može da pravi problema ako je disk već particionisan. Nisam imao slične probleme, ali ipak prenosim - ako se Boot Camp buni, a vi imate više od jedne particije na disku, moguće da je to uzrok problema.

UPDATE: Zašto dual boot, a ne klasična virtualna mašina? Zato što ponekad Windowsu zatrebaju SVI dostupni resursi, kao za partijicu novog Call of Duty-ja na primer :)

call-of-duty.jpg

MacBook Pro, Time Machine i migracija podataka

Danas smo se malo provozali do Beograda, da se vidimo sa drugarima, popričamo o novostima koje se spremaju za jednu od skorijih verzija activeCollab i, u povratku, pokupili nove laptope. Kako nam rekoše kod distributera, mi smo ćapili prve zvanično uvezene MacBook Proove poslednje generacije. Outgeek that! :)

mbp.jpg

Ranije, kada sam menjao mašinu ili reinstalirao operativni sistem trebalo mi je minimum par sati, a ponekad i dana da je natenane podesim - aplikacije, razvojno okruženje itd. Znam, može to i mnogo brže, ali jednostavno nikada nisam koristio alate kao što je Norton Ghost.

Od kada sam počeo da koristim Leopard koristim Time Machine - izuzetno lak način backupovanja sistema koji je po defaultu uključen u Mac OS. Zahvaljujući postojećem backupu i mogućnosti importovanja profila iz backupa na drugi računar, novi MacBook Pro je doveden u funkcionalno stanje za 15, 20 minuta. Sve što je trebalo da uradim je da uštekam disk na kome se nalazi Time Machine backup iMaca koga koristim u kancelariji i pustim aplikaciju da migrira podatke.

Stvari koje nisu uvezene, a da sam ih do sada primetio su:

  1. Podešavanja web servera nisu bila uvezena. httpd.conf, konfiguracioni fajl sa definicijama virtualnih hostova i hosts fajl samo ručno kopirao. Nakon restarta web servera sve je lepo proradilo.
  2. MySQL po defaultu nije bio startovan i nije migrirano podešavanje da se automatski startuje sa startovanjem računara.
  3. Morao sam ručno dodati latinicu i ćirilicu u Input meni.

To je manje više to za sada. Sve ostalo je, koliko vidim, na mestu - aplikacije, sistemska podešavanja, dokumenti, lozinke... Prijatno sam iznenađen koliko je ceo proces jednostavan i koliko vremena štedi.

PHP.JS

phpjs2.png

Ne sećam se kada mi se zadnji put neki PHP resurs učinio dovoljno zanimljivim da bih poželeo da blogujem o njemu. No, posle dugo vremena evo ga jedan. U pitanju niz osnovnih PHP funkcija implementiranih u JavaScriptu. Ako ste radili sa JS-om i padne vam na pamet kako bi bilo super da imate strcmp() ili md5() na raspolaganju, PHP.JS nudi rešenje.

Paket sadrži 190 portovanih funkcija. Nema potrebe sve da ih koristite - ponekad je dovoljno izvući jednu funkciju i prilagoditi je svojim potrebama ili pogledati kako je neko drugi rešio problem.

Za svaku pohvalu. Hvala ekipi na trudu!

Interface Mockups

Ranije sam obično bio ja taj koji je dobijao specifikacije i mockupe na osnovu kojih sam trebao da napravim nešto što radi kako je osoba koja ih je napravila zamislila. Kako vreme prolazi, sve više vremena provodim smišljajući i objašnjavaju aplikacije i pojedine njihove delove ljudima koji treba da ih naprave, a sve manje praveći ih. Nisam baš nešto ekstra srećan zbog toga, ponajviše zato što taj posao zahteva drugačiji skill set od onoga koji trenutno imam, tako da još uvek mnogo grešim i mnogo učim.

Evo je na primer jedna greška - grafitna olovka za crtanje interfejsa na papiru. Super je to što ne zahteva nikakav specijalan alat ili da budete blizu računara (olovka, gumica, dva lenjira i papir su sve što je potrebno), što se lako ispravljaju greške i što uvek lako možete da krenuti iz početka.

Problem u celoj priči je grafitna olovka koja ostavlja previše svetao trag, što čini fotokopije i scanove prebledim i neupotrebljivim. Ovim je digitalizacija i deljenje ovako napravljenih interfejsa među ljudima koji na njima treba da rade onemogućena.

Sada sedim sa 5, 6 nacrtanih screenova koje ću morati da dam nekom drugom kako bi on mogao da nastavi sa poslom, a ja, na moju ogromnu radost, te iste crteže moram da uradim iznova na osnovu bledih kopija kako bih imao svoj primerak. Sjajno!

Koji je "instrument" najbolji za crtanje ovakvih stvari? Ne mora da se briše, ali mora da ostavlja tamne, relativno tanke linije i da ne moram da brinem da ću da se usvinjim nakon svakog korišćenja (rapidografi otpadaju)? Čisto da znam šta da tražim kada sledeći put odem do knjižare.

fail.jpg

Tehnologija u pozadini

Nešto o čemu razmišljam u skorije vreme je kako povući alate u pozadinu i omogućiti ljudima da ih koriste, a da ne moraju da imaju stalan kontakt sa njima i kada taj pristup ima smisla.

time-machine-logo.gifPrimer jedne tehnologije koja se vodi tom logikom je Time Machine - backup softver koji dolazi uz novi Mac OS. Ne zahteva puno od vas - ako primeti slobodan hard disk ili particiju pitaće da li može da ga koristi. Recite Yes i to je to - od tog trenutka nadalje Time Machine će početi da pravi backupe i prestati da vas smara sa pitanjima.

"Nevidiljivost" ovog alata se ogleda u tome što se od vas ne očekuje ništa da bi on radio. Nastavljate da koristite računar kao i ranije, a Time Machine stoji u pozadini i radi svoje bez da vas cima ili da vi morate nešto da mu kažete. Kada vam zatreba fajl iz backupa on je na par klikova, ali do tad alat kao da ne postoji.

Softver za kolaboraciju i upravljanje projektima treba da radi na sličan način. Sama aplikacija je bitna menadžerima i ljudima koji upravljaju projektima, ali bi trebala da bude potpuno transparentna ostalim korisnicima. Oni bi trebali da mogu da je koriste bez potrebe da uče novu aplikaciju, novi interfejs, novi workflow. Idealno rešenje bi bilo kada bi sistem za upravljanje projektima i kolaboraciju bio sličan Time Machineu - vredan trudbenik koji radi u pozadini, integriše se sa ostalim aplikaciji i radi potpuno samostalno, a isplivava samo kada stvarno treba - da se izvuče neki izveštaj ili vidi kako stojimo i šta dalje.

Par saveta za držanje prezentacija

S vremena na vreme organizatori lokalnih konferencija i skupova budu dovoljno ludi pa me pozovu da održim prezentaciju. Predavanje mi baš i nije strogo vezano za posao tako da to radim relativno retko - 2, 3 puta godišnje. Uvek se između tih prezentacija desi gomila stvari tako da ne mogu nikada da koristim stari materijal. Ne sećam se da sam i jednom dva puta ispričao istu prezentaciju...

Suočen sa time da uvek pričam nove priče uz blage varijacije i činjenicom da nikada u životu nisam imao formalan trening koji bi me spremio za javne nastupe morao sam malo da se dovijam i mnogo da učim. U ovom tekstu ću navesti par saveta koji mi pomažu da spremim i održim prezentacije, a da se ne bunim previše i da sve izgleda što prirodnije i tečnije. Prvo jedan slajd iz prezentacije koju sam u maju držao u Zagrebu kao primer svega o čemu ću dalje pričati:

slajd.jpg

Minimum teksta na slajdovima

Neki ljudi su baš opsednuti natrpavanje teksta, slika pa čak i videa na svoje slajdove. Ja se držim varijante da su slajdovi tu samo kao pomoć. Pravim ih tako oni zahtevaju minimum pažnje. Malo teksta da ih publika brzo preleti, slike ako baš moraju, 0 animacija i efekata sa tekstom.

Ono što ću da pričam u narednih 5 minuta ljudi pročitaju u prvih 30 sekundi i dalje slušaju (ili spavaju). Nema ništa na slajdovima što bi im odvlačilo pažnju u sred priče.

Priča je ono što su došli da čuju, a ne da se dive mojim literalnim sposobnostima i animacijama između stavki prezentacije.

Naznačite šta je na sledećem slajdu

Prost trik koji sam prvi put koristio na Web.Startu u Zagrebu. Ranije sam imao problem sa stankom između slajdova. Pošto su prezentacije nove dešavalo mi se da ne znam šta je tačno sledeće. Tada sam morao da stanem, prebacim na sledeći slajd, vidim šta ide dalje i tek onda nastavim. Tu je bila nezgodna stanka u fazonu:

"Ummmmm..." - click - "Aha! Kada počnete da prodajete onda blabla"

Ovo "Ummmmm..." - click - "Aha!" treba da bude izbačeno. Rešenje je da dodate nešto kratko na dno slajda što će vam jasno reći šta je sledeće i omogućiti vam da ispričate priču koja "lepi" dva slajda. Nema pauze - sve je čista priča i lak prelaz bez stanke.

Ispričajte prezentaciju bar 3 puta

Jedini način da vaša priča zvuči dobro pred publikom je da ste je već par puta pričali. Naglas, tako da ste čuli svoje reči! Ništa ne zvuči bolje od dobro spremljene prezentacije. S druge strane ništa ne zvuči tako loše kao osobe koja je po prvi put izgovara (možda Jelena Karleuša, ali nećemo o tome).

Zato se zavucite u kupatilo (podrum, tavan, šta god vam odgovara) i ispričajte svoju prezentaciju 3 puta, od početka do kraja. Mnogo lakše ćete se osećati kada izađete pred publiku, vaša priča će biti tečnija, a vi izgledati i zvučati mnogo bolje.

I naravno - imajte nešto zanimljivo da ispričate. Ljude ne zanimaju stvari koje mogu da nađu na Wikipediji ili u arhivi sajtova kao što je SitePoint. Iznesite zanimljive brojeve, ubacite neke zanimljive anegodote, budite iskreni i uvek izaberite temu do koje vam je stalo. Tada neće biti nikakvih problema...

Prologue, Twitter i Status Update

Dve čudne stvari su se desile u zadnjih par nedelja:

  1. Pomenuo sam Prologue iako se nikada ne oduševljavam WordPress pluginima
  2. Koristio sam Twitter ali me nećete naći ni na jednom drugom Web 2.0 igralištu

Razlozi:

  1. Prologue me je po prvi put naveo da razmišljam o Twitter načinu komunikacije kao jako dobrom za grupe. Do tada mi se činio kao previše ličan i neozbiljan za korišćenje u poslu (trebalo je da znam bolje)
  2. Twitter sam ponovo počeo da koristim da vidim koliko je isti vredan kao komunikacioni kanal (iz lične perspektive, naravno)

Rezultat jedne ideje, jednog eksperimenta i mog oduševljenja njima je Status Update modul za activeCollab (priredio Goran Radulović, ja sam samo zvocao):

status-update.jpg

Ovaj modul vam omogućava da objavljujete kratke poruke sa bilo koje activeCollab stranice a da ne unosi previše smetnje. Workflow je sledeći: otvorite popup, napišete i objavite poruku, zatvorite popup i nastavite sa onim na čemu ste radili.

Kada ima novih poruka poslatih od drugih članova tima pojaviće se crveni bedž pored ikonice u toolbaru i dati vam do znanja da je objavljeno nešto novo. Nema iritirajućih animacija ili zvuka kao kod IM-a ili telefona. Trudili smo se da obaveštenja ne budu napadna i da govore "Ima novog sadržaja, pogledaj kada budeš imao vremena".

Stvarno sam zadovoljan modulom i prijatno iznenađen koliko ovakav vid komunikacije uz sva svoja ograničenja (posebno dužina poruke i odsustvo "oštrih" obaveštenja) može da pomogne boljoj komunikaciji u timu i produktivnosti.

Još nam samo ostaje da vidimo kako će activeCollab korisnici prihvatiti novi modul i kako će se cela stvar dalje razvijati...

Dva razloga zbog kojih je bitno prodavati što pre

Svi smo uglavnom čuli za release early, release often mantru, ali hajde da je malo preformulišemo - sell early, sell often! Što pre krenete da prodajete pre ćete imati:

  1. Kupce
  2. Novac

money.jpg

Recimo da pravite helpdesk aplikaciju i da ste planirali da je lansirate u oktobru. Planirali ste da cena bude oko $150. S obzirom kakve su cene helpdesk alata to je skoro pa džabe za alat koji radi posao. Međutim, ne možete da stignete da napravite sve što ste planirali za oktobar. Sredina decembra je mnogo realniji datum.

Uz pretpostavku da ćete u prvo vreme prodavati po jednu licencu dnevno i odlučite da sačekate decembra vi ste u gubitku celih $11.250. Pored toga izgubili ste i dva i po meseca direktnog kontakta sa korisnicima na osnovu kojih ste tačno mogli da znate šta je stvarno bitno, a šta ne. Verujte mi, vrlo su jasni, posebno kada je proizvod mlad i kada stvarno ima dosta manjkavosti. Možda to zbog čega ste pauzirali i nije toliko bitno, ali postoje neke druge stvari koje su show stopper za mnoge korisnike koji bi vam vrlo rado dali svoj novac.

Nemojte napraviti grešku i juriti gomilu featurea za verziju 1.0. Iako nemate sve mogućnosti koje ste planirali, zaokružite i kompletirajte ono što već imate i počnite da prodajete što pre je moguće. Prodaja i kontakt sa kupcima su neprocenjivi za svaki posao. Bićete više motivisani, osećaćete se sigurnije, a mogućnosti koje ste izostavili ćete ionako dodati vremenom ili zaboraviti jer se ispostavilo da su nebitne.

Social Proof

Social proof (društveni dokaz ili kako god da ga kod nas prevode) je pojava gde se ljudi oslanjaju na ponašanje drugih ljudi kako bi doneli odluke. U osnovi, stvar je prilično jednostavna - usled nedostatka informacija da samostalno doneseš odluke gledaš na ponašanje drugih uz predpostavku da grupa raspolaže sa više informacija i to uzimaš kao osnovu da doneseš odluku. Ovaj metod donošenja odluka je duboko usađen u naše mozgove i svi smo mu podložni, nema izuzetaka.

Social proof pominjem zato što je fascinantno koliko je jedinka zavisna od grupe, čak i u oblastima gde imamo osećaj da smo sami svoje gazde - u našim glavama. Sredina i ljudi koji nas okružuju imaju ogroman uticaj na naš način razmišljanja. Zato je pametno okružiti se pametnim ljudima, ali ponekad i povući se i jednostavno biti nasamo sa sopstvenom glavom neko vreme.

U kratkoj video reportaži koju sam gledao pre više od godinu dana sadašnji najbogatiji čovek na planeti je izjavio da je život u Omahi umesto u nekom od velikih poslovnih centara u Americi značajno uticao na način na koji vodi svoje poslove. Udaljen od kolektivnog zanosa koji vlada u poslovnim centrima imao je veće šanse da donese bolje odluke. Ili manje šanse da donese loše odluke... Kad se crta podvuče, na isto mu dođe.

Social proof je osnova mnogih pojava koje nas okružuju, ali i tehnika kojima se utiče na način na koji donosimo odluke. Naravno, tehnike su uglavnom razvili i usavršili prodavci. O njima možda neki drugi put... A možda i ne ;)

Zend Studio Profiler na Leopardu

Profiler je ubedljivo najbolji alat ukoliko tražite uska grla u vašim PHP aplikacijama. Da bi isti radio unutar Zend Studija treba vam Zend Debugger serverska ekstenzija. Ako koristite PHP i Apache koji dolaze uz Leopard primetićete da stvari baš i ne funkcionišu kako treba. Problem je u tome što Zend Debugger ne radi sa Apachem koji radi u 64-bitnim režimu kako je isti konfigurisan na Leopardu. Rešenje - ubijte Apache iz Sharing Preferences panela i poterajte ga u 32-bitnom režimu:

sudo arch -i386 /usr/sbin/httpd

Više detalja možete naći u ovoj diskusiji. Postujem sebi kao podsetnik pošto sumanjam da će ovo ikome zatrebati :)

profiling.jpg