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.
Ispratite sledeće korake i sve će vam biti jasno:
- Napravite folder “New File” negde gde vam neće smetati (ja sam ga stavio u svoj home folder)
- 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)
- Desni klik na “New File” i otvorite Get Info dijalog. U General sekciji otkačite Locked opciju kao na slici
- 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.
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.
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:
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
Stvarno 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?
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.
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:
- 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”.
- 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.
- Check – Nakon vremenskog perioda određenog u Plan koraku merimo ostvarene rezultate.
- 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.
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.
