Apie kirpyklas

Į kirpyklas užsuku retai. Todėl dažniausiai būnu gauruotas. O kadangi esu informatikas ir daugiausia laiko praleidžiu prie kompiuterio, tai turbūt tie gaurai niekam ir nemaišo.

Šiandien jau pribrendo laikas vėl nueiti į kirpyklą (turbūt antrą kartą šiais metais – negi pradedu dažniau į kirpyklas vaikščiot)? Nueinu, žiūriu, kad mano kirpėjos nėra. Tiek to, jeigu dabar nenukirps plaukų, tai turbūt vėl ateisiu tik po pusmečio. Tai sakau kerpam..

– Kaip kirpsim? – klausia kirpėja.

– Nežinau, kaip norit.

– Visi iš pradžių sako, kaip norit, o paskui pyksta, kad blogai nukirpau. – guodžiasi kirpėja.

– Tai kirpkit, kad atrodyčiau gražiau. Nesvarbu trumpai ar ne. Aš gi informatikas… – beveik pradedu teisintis mąstydamas, kad mane vis tiek visi kreivai nukerpa – verpetingą galvą turiu.

Tai ir nukirpo. Žiūriu į veidrodį ir mąstau, gerai čia ar blogai, kad pasakiau “kaip norit”. Bo gavosi truputį kitaip negu visada…

Use Time Efficiently

Koks tikslas būti uberproduktyviu visą savaitę, jeigu šeštadienį sustoji ir nieko nebeveiki? Per pirmadienį, penktadienį “sutaupytas” laikas labai greitai būna išsvaistomas šeštadienį.

Trumpas dialogas prieš kovą per dziudo treniruotę

– Any injuries?

– No yet.

Įdomu, kuris labiau nusiteikęs laimėti? Klausimas “Any injuries” (turi traumų?), galėtų reikšti, kad varžovas jaučiasi stipresnis ir nori žinoti ar gali kovoti visa jėga, ar geriau kovoti atsargiau, kad dar labiau nesutraumuoti. Atsakymas “Not Yet” (Kol kas ne) iš vienos pusės galėtų reikšti (bring it on, mada…, i’m gonna kill ya), kad čia tu esi stipresnis varžovas. Iš kitos pusės, tai galėtų reikšti, kad priešininkas turėtų kovoti atsargiau su tavim, kad netyčia nesužalotų.

Ale, reikalavimų rinkimas (o ypač dviprasmybių naikinimas) ir knygų skaitymas apie tai, paveikia ne tik mano darbą, bet ir laisvalaikį (jeigu nusivarymą nuo kojų treniruotėje galima laikyti laisvalaikiu).

Estimates don’t need to be perfectly accurate as much as they need to be useful.

Skaitau “Software Estimation: Demystifying Black Art”. Jau nuo pirmojo skyrio autorius pateikia įdomių minčių apie projekto estimates (laiko įvykdymui įvertinimą?) ir targets (prieš tai skaitytoje knygoje buvo vartojame frazė “goals”, tačiau man priimtinesnė “targets”): kuom jie skiriasi ir kuom jie panašus.

Įsivaizduok, kad ruošiesiai kelionei į Londoną (tarkim, aplankyti kolegą pūkį). Namuose turi du lagaminus: vieną tokį mažą raudoną, kuris labai tiktų kaip rankinis bagažas, ir Ryanair netgi leistų jį įsinešti į lėktuvo saloną. Kitas lagaminas juodos spalvos, daug talpesnis ir didesnis – galėtum susikraut savo (ir dar draugės) rūbus. Bet kadangi skrisi vienas, tai svarstai kurį lagaminą pasirinkti. Su mažuoju raudonu lagaminu, nereikėtų “check-in”intis, nereikėtų vėliau grįžus Kauno oro uoste laukti valandą eilėje, kol galėsi pasiimt lagaminą. Tačiau nesi tikras ar visi rūbai, kuriuos norėtum pasiimt, į jį sutilps. Svarstydamas kaip pasielgti, sumeti visus rūbus ant lovos (šalia raudonojo lagamino) ir pasvarstęs įvertini, kad “turbūt tilps”.

Gražiai sulankstai visus rubūs (gal net susuki juos, kad nesusiglamžytų – nice trick), ir dedi vieną po kito į raudoną lagaminą. Likus dar kelioms maikutėms ir vieniems džinsams, matai, kad visi rūbai į raudonąjį lagaminą nebetilps. Ką tokiu atveju darai? Ar bandytum rūbus dar labiau suspausti, tikėdamasis, kad visdėlto kaip nors jie sutilps? O jeigu vėl netelpa, gal bandytum sugrūsti juos naudodamas jėgą ar netgi pašokinėdamas ant lagamino? Vėlgi, paskutiniams rūbams netilpus, belieka dvi galimybės: palikti tau patinkančią maikutę ir džinsus Lietuvoje, arba viską sukrauti į didesnį lagaminą.

Aš darbe kartais jaučiuosi panašiai, kai manęs paklausia per kiek laiko pabaigsiu šitą darbą (kai jis dar nepradėtas daryti)? Kurį lagaminą pasirinkti? Spėju, ši situacija pasitaiko daugumoje programinės įrangos kūrimo projektuose.

O pirmojo skyriaus pagrindinė idėja būtų ta, kad projekto laiko įvertinimas neturi būti tikslus. Mano vadovas tikrai nenori žinoti, kad aš per dvi dienas intercompany dokumento valdymo iš esmės nepakeisiu. Jeigu jo tikslas (target), turėti produktą po triejų dienų, mano tiksliausias laiko įvertinimas (estimate), turėtų skambėt maždaug taip: esu 60 procentų tikras, kad per reikalavimus galima patenkinti per dvi dienas, arba 90 procentų tikras, kai tai būtų galima padaryti per penkias dienas. Turint tokį pradinį laiko įvertinimą, pagrindiniu darbu lieka rizikos valdymas (apie kurį dar neskaičiau).

Estimates don’t need to be perfectly accurate as much as they need to be useful.

Reikalavimų analizė – one book down, two more to go

Baigiau skaityti “More About Software Requirements”. Įdomi knyga – suskaičiau per savaitikę, per dienas skirdamas apie valandą laiko. O knyga įdomi turbūt dėl to, kad pastaruoju metu buvau pakankamai dažnai atakuojamas klausimų “kiek laiko užtruksi? per kiek laiko padarysi? per kiek laiko padarytum, jeigu labiau pasistengtum? tai pasakyk apytiksliai, kiek laiko užima tai padaryti?”.

Prisirinkęs keletą naudingų patarimų, prisėdau šiandien prie jau kažkada “įvertintų” (estimates provided) mini projektukų, ir perrašiau reikalavimų dokumentus. Šįkart, kiekvienas reikalavimų punktas yra netgi labai “testable requirement” (True, False… decision trees). Pažiūrėjau į prieš tai mano duotus “turbūt padarysiu” laikus, ir nusprendžiau, kad mano spėjimai buvo pakankamai sėkmingi iki šiol. Tačiau, pasirašius aiškesnius reikalavimus, matai daug ryškesni vaizdą, ką ir kaip reikės daryti. Ties kai kuriais punktais, netgi galiu pasakyti, kiek tai užtruks (hey, kur ši knyga buvop anksčiau?).

Tai pat bandau pasidaryti keletą excel failiukų, kuriuose galėčiau sekti savo sugaištą laiką reikalavimų dokumento parašymui/taisymui/developmentui/nenumatytų (pasikeitusių) reikalavimų atsiradimui ir jų įgyvendinimui. Sudėtingiau turbūt objektyviai įvertinti sugaištą laiką. Tačiau, be tokios informacijos apie sugaištą laiką, ateities “estimates” bus tik spėliojimai, o ne apytiksliai įvertinimai.

C:StudySoftware Requirements kataloge guli dar dvi knygos

  • Software Requirements, Second Edition
  • Software Estimation – Demystifying the Black Art

Pirmas kartas

Šiandien (kaip ir kiekvieną trečiadienį) po darbo su kolegom lėkėm pabėgiot – porą nedidelių ratų nuo London Brigde iki Tower Bridge.

Bėgam ir žiūrim… ogi, pakelia Tower Bridge – ta proga, turėjom pasiteisinimą vietoj bėgimo šiek tiek pažingsniuot ir pailsėt. Einam, einam, o aš ir sakau, kad jau du metai kaip Londone gyvenu, bet dar pakelto Tower Bridge’o nesu matęs. Kolega, tokiu visai rimtu balsu pareiškia, kad jis irgi nematęs dar – o Londone jau 9 metus gyvena.

Visada būna pirmas kartas?

Navision projekto reikalavimų analizė – Ko nori?

7 kartus iš 10 (laužiam statistiką iš piršto ir savo patirties – bet skamba tikrai geriau, negu “labai dažnai”), pasitaiko, kad konsultantas pirmąjį susitikimą pradeda nuo klausimo “Tai, ko Jūs norėtumėt?” (arba, jeigu pavyzdžiui konsultantas porą metų pagyveno Anglijoje, tai turbūt klaustų “Kaip mes Jums galėtume padėti?”) – iš karto lyg ir leisdamas suprasti, kad ohoho kokie mes esam kieti, ir galima pasiūlyti beveik viską. Na, jeigu konsultantas yra “pardavėjas”, ir jam knieti parduoti kuo daugiau “apmokęstinamų valandų”, tai ant jo pykti dėl tokio klausimo nelabai galima. Tačiau, jeigu šitą klausimą užduoda žmogus, kurio darbas surasti ir surinkti reikalavimus būsimam projektui (suprast, interpretuoti klientų netikslius norus, į šiek tiek suprantamesnę kalbą navision programuotojams o ir galų gale būsimiems vartotojams), tai jam reikėtų gerokai su liniuote per pirštus užvažiuot.

Tokie abstraktūs klausimai “Ko Jūs norėtumėt? Kokie Jūsų reikalavimai?” apskritai turėtų būti ištrinti iš konsultanto žodyno. Daugumos konsultatų (ką ten konsultantų, vos ne visos navision partnerių industrijos) tikslas yra (ar bent jau turėtų būti) – išspręsti klientų verslo problemas (ir žinoma, už tai gauti patenkinamą atlygį). Taip laimi abu – klientas, kad ir turėdamas pradinių išlaidų, tikisi sutaupyti ateityje dėl tinkamo problemos sprendimo. O konsultantas, gaudamas atlygį už gerai išspręstą problemą, tikisi ir ateityje sėkmingai spręsti kitas verslo problemas. Gi, dažniausiai problema atsirande dėl verslo procesų (ar jų supratimo ir valdymo) pasikeitimo (jeigu žiūrint giliau, tai nauja verslo sistemos problema – pradinių sistemos reikalavimų pasikeitimas).

Klausimai, kuriuos vertėtų paklausti, pradedant rinkti reikalavimus naujam projektui:

  • Kokią verslo problemą stengiamės išspręsti? Kokias problemas naujas produktas turėtų išspręsti?
  • Koks šios problemos sprendimo tikslas? Kokius tikslus naujas produktas leis Jums įgyvendinti? (ko negalite padaryti dabar)
  • Kaip sėkmingas problemas sprendimas paveiktų Jūsų įmonės procesus?
  • Pagal kokius kriterijus Jūs nuspręsite, kad problema buvo išspręsta sėkmingai?
  • Kaip materialiai įvertintumėt sėkmingą problemos sprendimą? Ką ir kiek Jūs tikitės sutaupyti?
  • Kurie žmonės (ar žmonių grupės)iš Jūsų kompanijos galėtų paveikti projekto vykdymą?
  • Ar yra kitų projektų, kurie dabar vykdomi, kurie gali būti paveikti šio projekto?
  • Kurie įmonės procesai turėtų būti įtraukti į šito projekto reikalavimus? O kurie ne?
  • Kokios pagrindinės priežastys paskatintų Jus ar Jūsų kolegas naudotis nauju produktu (funkcionalumu)?
  • Kaip apibūdintumėt (įsivaizduotumėt) naują produktą (atskirais žodžiais, pavyzdžiui: greitas, paprastas, gražus, pigus, etc)?
  • Ar kurios nors specifinės produkto dalys yra svarbesnes už kitas?
  • Ar turite kokių nors specifinių taisyklių (standartai, naudojami procesai), kurioms produktas turėtų paklusti?
  • Kuom naujas produktas būtų panašus į sistemą, kurią turite dabar? Kuom jis būtų kitoks?
  • Kuriuos aspektus iš dabartinio produkto Jūs norėtumėt išsaugoti? Kurių būtų galima atsisakyti?
  • Kuris aspektas iš naujo produkto Jus labiausiai nudžiugintų?
  • Kuris aspektas iš naujo produkto galėtų būti Jums naudingiausias? Kuris duotų mažiausiai vertės?
  • Kas svarbiausia apie naują produktą?
  • Ar galite apibūdinti aplinką (software/hardware) kurioje produktas bus naudojamas?

O turbūt svarbiausias klausimas (kurį aš pats pakankamai dažnai pradėjau naudoti gyvendamas Anglijoje): Ko dar aš turėčiau Jūsų paklausti (”Is there anything else I should be asking you“)?

Kai pradėjau dirbti su Navision, buvau vartotojo vietoje – ir man pačiam teko ne kartą bandyti atsakyti į kartais keistai atrodančius klausimus apie tai, ko mūsų įmonė nori iš naujo funkcionalumo. Pakeitus darbą (t.y. išvažiavus atostogų į Londoną), dabar esu visiškai kitoje pusėje – žmogus, kuris tuos klausimus kartais užduoda, o kartais žmogus, kuris priima konsultanto “išverstus” atsakymus ir turintis juos įgyvendinti.

Įdomu, iš kokių kitų perspektyvų dar teks pažvelgti į Navision’ą ateityje?

Įvertinti, kiek laiko užtruks projekto įvykdymas, tai ne tas pats, kas užsibrėžti optimistišką tikslą

Kaip jau minėjau, po truputį pradedu draugauti su Navision’u. Kadangi esu informatikas, tai programuoti nėra taip baisu. Tačiau, kadangi mūsų kompanija pakankamai maža, tai tenka daugiau biški negu programuoti. Ir (kol kas) nedrąsiai jaučiuosi, kai reikia įvertinti, kiek laiko užtruks padaryti tą ar aną. Aišku, visada galima bandyti išsisukti su konsultantų mėgstamu posakiu “It depends…”, bet kol nedirbu business consultant, nereik naudot ne savo kozirių? O nedrąsumas tai… jeigu per daug optimistiškai pasakysiu, tai – vienas dalykas, kompanija mažiau uždirbs, antras dalykas – galiu nespėt? Jeigu per daug pesimistiškai pasakysiu, tai – vėl kompanija gali nebeuždirbt, nes klientas gali nuspręst, kad per brangu ir kaip apsieisim…

Suprask, su klientu pakalbėjai prieš pusvalanduką, ir pas tave ateina “account manageris” (kaip lietuviškai?), ir klausia “va, girdėjau kalbėjai su klientu apie reikalavimus – kiek užtruksi visa tai įgyvendinti?”. Pastebėjau, kad kažkaip mano stiklinis žvilgsnis account manager’ių neatbaido. Taigi, skaitom knygas toliau “More about software requirements: thorny issues and practical advice“… šiandien įveikiau antrą skyrių (turbūt lėčiau skaityti neįmanoma, nors iš kitos pusės, turbūt taip aktyviai mąstydamas dar jokios knygos nesu skaitęs).

Dažniausiai pasitaikanti programavimo klaida yra ne bug’as, o tiesiog skirtingas kliento ir programuotojo problemos sprendimo supratimas. Aga, idėja logiška, skaitom toliau. Kai skaitau knygą, mėgstu pasibraukti įdomesnes mintis (šįkart, kadangi skaitau CHM’ą, tai įdomesnes mintis tiesiog kopijuoju į notepad’ą).

Įvertinti, kiek laiko užtruks projekto įvykdymas, tai ne tas pats, kas užsibrėžti optimistišką tikslą!” – jeigu būčiau turėtų knygą kietais viršeliais tai rankos būtų sudrebėjusios beskaitant šitą… Taip, pamąsčius, kokias gi aš metodikas taikiau bandydamas įvertinti kiek laiko užtruksiu programuodamas? Turbūt… ką ten turbūt, tikrai kad jokių…

Nors, toliau skaitydamas šiek tiek nudžiugau, pasirodo, pats to nesuvokdamas taikiau “testable requirements” laiko įvertinimą. Mano noras užsirašyti reikalavimus pažingsniui, kad paskui pagal juos būtų pakankamai lengva tiek programuoti, tiek testuoti, turbūt praeityje man davė naudos (bo, tik vieną kartą teko vėluoti su deadline’u).

Tačiau, kad galėčiau rimčiau analizuoti savo darbo našumą, ir vietoj optimistiško spėliojimo, galėčiau drąsiau prognozuoti (nors software projektuose, prognozuoti žodžio iš vis neturėtų būti – taigi čia tik estimates, estimates, estimates) – reikėtų vesti kažkokią tai statistiką ir sekti savo “pakilimus/nusileidimus”. Aišku, yra dar vienas punktas, kuris kaskart gelbsti kailį – tai su kiekvienu developinimu auganti patirtis ir galimybė palyginti reikalavimus su prieš tai įgyvendinto projekto reikalavimais.

Ok, turbūt laikas būtų slink link lovos ir sapnuoti toliau Navision’ą…

O mąstant apie ateitį, tai svarstau kelių kolegų pasiūlymus, pradėt (ir kaip nors greitai pabaigt) AAT Qualification kursus. Protingi dėdės sako, kad tai turėtų man labai padėti bendraujant su įvairių įmonių CFOs. Tai ką, google’inam…

Apie reikalavimus (tiksliau, jų nebuvimą)

Pastaruoju metu tenka truputį daugiau laiko praleisti programuojant C/Side (suprask, Navision yra toks “special”, kad net savo programavimo kalbą turi – na, bet pats pasirinkau Dynamics NAV kelią, tai…). Aišku, geras jausmas, kai po tokių pirštų pamiklinimų, klientas pasako “it works like a charm… saves me half a day per week“. Tačiau, kartais pasitaiko, kai programavimas šiek tiek užsitęsia (sakydamas, kartais, turiu omeny praėjusį penktadienį, kai supposedly “trijų valandų” darbą pradėjęs daryti po pietų taip ir nepabaigiau.

Problema buvo – reikalavimai. O gal tiksliau pasakyti, jų nebuvimas. Aišku, laisvė programeriui turėtų būti geras dalykas – darai ką nori, ir už tai dar pinigus moka? Bet, kai atsakymo neturėjimas vienam klausimui iškelia dar porą klausimų, o šitie dar po du, ir t.t. Ką daryti tada?

Taigi parėjau namo, pagooglinau, pa’amazoninau, pasiknaisiojau šiek tiek po torrent’us, pakalbėjau su broliu, ir pasiruošiau ilgai savaitei skaitymo apie įvairius requirement gathering. O pradedam nuo “More About Sofware Requirements: Thorny Issues and Practical Advice“.

Perskaičiau kol kas tik porą skyrių (turbūt daugiau per dieną ir neskaitysiu, bo reikia dar suvirškinti, ką perskaičiau, ir kažkaip į visa tai pažvelgti “navision” akimis. Tačiau tiesos akimirkų “aha…” pasitaikė ir pirmuosiuose skyriuose.

Žiūrim, ką turim… 2009 pirmasis pusmetis

Kaip greitai bėga dienos (taip jeigu labai įsiklausyti, turbūt galėtum išgirsti kaip sensti?). Kadangi jau greitai birželis (o aš pataruoju metu nesu labai kantrus), tai sumąsčiau, kad būtų gerai paanalizuot, ką per praėjusį pusmetį nuveikiau. Kaip tikras informatikas prieš pasiimdamas tušinuką į rankas, visų pirma pagooglinau: how to review yourself. O pasirodo, tai pakankamai paprasta:

  • Sudarom sąrašiuką, ką gero (ar blogo) nuveikėm per pusmetį (na, straipsniukas, tai apie metus buvo, bet tiks ir pusmetis).
  • Greitu žvilgsniu prabėgam per sąrašiuką, ir pamąstom, kas iš nuveiktų darbų atrodo įdomiai ir netikėtai, o kas pakankamai nuobodžiai ir nuspėjamai.
  • Sprendžiant iš sąrašo, kas šiuo metu mano gyvenime atrodo svarbiausia?
  • Ką išmokau per pastarąjį pusmetį?
  • Ką norėčiau išmokti per ateinantį pusmetį?

Kai taip susirašai viską ant popieriaus lapo, atrodo, kiek visdėlto mažai nuveikiau per šitą pusmetį…

Nors, optimistiškai žiūrint (ta prasme, jeigu neskaičiuojant darbų kiekio), tai… yra ir gerų dalykų:

  • Rašant savo gyvenimo aprašymą (CV) jau turbūt galėčiau patenkinti daugumą Navision darbo skelbimų “reikalavimų“. Tiek praktikos ir patirties, tiek teorinių žinių atžvilgiu.
  • Lėtai ir neskausmingai baigiau pirmąjį mini-semestrą Open University. Business Studies yra pakankamai įdomus dalykas, turbūt reikėtų apsvarstyti tolimesnes studijų galimybes.
  • Greitai ir trumpai aplankėm Marselį. Turbūt galėtume dažniau, ką nors taip aplankyti. Nors gal būtų smagiau pakeliauti kur nors “ilgesnį laiką”. Kaip pavyzdžiui, atostogų į Londoną…
  • Nors šeštadienis praleistas šokant Ceroc atrodė daug žadantis, daugiau pašokti taip ir nebeišėjo.
  • Pradėjom bėgioti (nors ir labai nepastoviai) su kolegomis. Kad įdomiau būtų, užsiregistravom spalio (berods) mėnesį bėgti 10 mylių.
  • Sužinojau, kad twitterinti apie Navision’ą gali ir lietuviai…
  • Perskaičiau kelias įdomesnes knygas… O reikėtų daugiau ir dažniau paskaitinėt.

Žiūriu į praėjusį pusmetį, ir mąstau, kad nėra nieko nenuspėjamo ar įspūdingo. Įdomu, ką reikėtų daryti kitaip, kad po dar vieno pusmečio, toks “žiūrim, ką turim” įrašas atrodytų įdomesnis?

Trumpi pamąstymai apie krizę ir darbą Londone

Krizė, krizė – rėkauja per televizorių. Eeea, bet juk tai aš televizoriaus neturiu. O iš kur žinau? Iš draugų, kolegų… Vienas geras būdas išvengti krizės – nebežiūrėti televizoriaus. Antras būdas – … užteks ir pirmo.

O šiaip trumpas pastebėjimas pačiam sau – šiandien gavau tris headhunt’erių pasiūlymas eiti dirbti panašų darbą į kitas kompanijas (su šiek tiek didesniu atlyginimu, biškutą mielesniais benefit’ais). O bet tačiau… Du kartus skambino tiesiai į darbą (wtf, apie ką jūs galvojat?) ir kitas atsiuntė el. paštu. Šiaip, kai atsiliepi darbo telefonu (pas mus ofisas toks… bendras… be sienų) ir ramiu balsu sakai “ne, šiuo metu manęs jūsų pasiūlymas nedomina… gal paskambinkit…” – ir supranti, kad tave girdi visi, kyla dvejopas noras – arba mesti telefono ragelį… arba pakartot “pala, pala, kiek ten jūs siūlot?”

Visur matau vištieną…

Per pietus kolega Kyšanas pasiūlė nulėkt kur kartu papietaut (turbūt ne per seniausiai skaitė knygą “Niekada nepietauk vienas”). Tai nulėkėm iki Tower’io Waganamos. Akimis permetęs meniu greitai pasirinkau chicken ramen (taip, jau ne kartą sakiau, kad man tikrai patinka vištiena). Labai smagiai pabendravę grįžom atgal į ofisą ir kibom į darbus.

Po darbo grįžau namo, ir su ką tik egzaminą laikusia mergaite nusprendėm nukeliaut kur nors pavakarieniaut. Pasirinkome netoli esantį Indą (suprask, indų restoraniuką – paskutiniu metu, tai jeigu eini į parduotuvę – eini pas rusą arba pas turką, jeigu eini į restoraną – tai pas indą, jeigu alaus – tai pas babajų – emigrantai labai savotiškai apibūdina “kur”). Akimis permetęs meniu, susimąsčiau, ką pasirinkti. Ar chicken tikka masala ar tandoori chicken. Tik pabaigęs vakarienę, supratau, kad tiek pietums, tiek vakarienei kramsnojau vištieną (čia turbūt vištiena man biški labiau negu patinka).

Kažkodėl su mergaite bendraut buvo daug smagiau negu su kolega. Turbūt dėl to, kad lietuviškai. O gal dėl to, kad vynas skanus buvo. BLUE NUN. Mėlyna vienuolė – pavadinimas. Jeigu taip labai greitai, kokia pirma mintis? Man tai… prasigėrusi mėlynanosė vienuolė. Na, bet kaip skanu…

Pamąstymai apie meistriškumą

Antrą dieną aš įnikęs į knygą “Verslo menas” (galėtų dažniau UK būti nedarbo dienų, tai gal daugiau knygų pradėčiau skaityt?). Skaitau puslapį po puslapio, skyrių po skyrio, graužiu salotinį markerį ir vis galvoju – kažin kokių grybų reikia būti užvalgius kad taip pozityviai aprašyt kurią nors kompaniją. DELL, IBM, pietvakarių efektas, etc.

Iš vienos pusės atrodo lyg pigus verslo klasės straipsnis, iš kitos pusės – protingos mintys (kad ir truputuką per daug pozityvios) visada yra gerai. Skyrius “meistriškumo menas” vėlgi truputuką privertė pamąstyt apie darbą (mūsų kompaniją). Esame maža įmonė su dideliais klientais. Kad įtiktume klientams turime ne tik gerai atlikti savo darbą, bet ir turėti kažką daugiau negu turi kiti. Kažkada su kolegom prie alaus bokalų pub’e svartstėm, kad visdėlto nesam dideli, tačiau kiekvienas iš mūsų yra pakankamai stiprūs savo srityje, ir visi prisidedame prie kompanijos stiprėjimo. Tačiau ar galėtume nors vieną iš mūsų pavadinti “meistru”?

Žiūrint iš sporto pusės – meistriškumas yra pakankamai matomas dalykas – technika, greitis, patirtis, mąstymas, prisitaikymas. Kuo esi stipresnis (kuo didesnis tavo meistriškumo lygis), tuo geriau gali įvertinti savo varžovo sugegėjimus. Pavyzdžiui, dziudo – kai kuriems metimas varžybose gali atrodyti kaip paprastas metimas, tačiau tik varžovas, kuris pats treniravosi keletą metų kaip atlikti tokį metimą sugebės tinkamai įvertinti priešininko meistriškumą.

Todėl diskutuoti, ar kuris nors iš mūsų galėtų būti “meistriškumo pavyzdys” nelabai yra prasmės. Klientai to niekada nesupras. Kolegos turbūt visada tai pervertins. Tačiau susirasti keletą labai stiprių žmonių tavo darbo srityje (na, navision specialistai, kur jūs) ir užmegzti pažintis su jais, būtų labai sveikintinas dalykas.

Pamąstymui, jeigu nori būti geriausiu, tai turi:

  • Sužinoti, kas yra šiuo metu geriausias ir jį pažinti. Daryti, tai ką daro jis (arba daugiau) ir jį pralenkti?
  • Nuspręsti, koks turėtum būti, kad būtum geriausias, ir pažingsniui to siekti?

Norėčiau sudalyvaut kokiose dziudo varžybose.

Kokia yra laiko vertė?

Apie vienerių metų vertę klauskite sesijos neišlaikiusio studento;

Apie vieno mėnesio vertę klauskite neišnešiotą naujagimį pagimdžiusios motinos;

Apie vienos savaitės vertę klauskite savaitraščio redaktoriaus;

Apie vienos valandos vertę klauskite pasimatymo laukiančio įsimylėjėlio;

Apie vienos minutės vertę klauskite pavėlavusio į paskutinį traukinį žmogaus;

Apie sekundės vertę klauskite eismo įvykyje išgyvenusio žmogaus;

Apie milisekundės vertę klauskitę antrąją vietą olimpinėse žaidynėse laimėjusio sportininko.

Anonimas

Skaitau knygą (kurią jau senokai įsigijau iš manoknyga.lt ir buvau pamiršęs, kad ji kažkur vis dar yra) “Verslo Menas” ir mąstau ar mano dabartinė kompanija turi visas tas savybes, kurių reikia norint išlikti (ir/arba tapti geriausiais). Ko mums trūksta? Kodėl mes esame stiprūs ir vieningi?

Norėčiau kada nors įkurti kompaniją, kurioje žmonės norėtų dirbti. Kuri galėtų kažką pakeisti. Ir vėl aš su savo “kada nors”.

O šiaip šiandien rami sekmadienio diena. Geriu mergaitės padarytą kavą su kondensuotu pienu, klausaus kaimynų klausomos muzikos (aš tokios muzikos klausydavausi, kai žaisdavau counter strike studijų laikais, todėl dabar beskaitant, kartais akyse šmėstali headshot’ų vaizdai, mouse’o click’ai ir “yeah” atsidusimai) ir skaitinėju su geltonu markeriu rankose gana įdomią knygą. Paskutinė mano pasibraukta mintis buvo “Daugumos žmonių asmenybės yra labiau nuspėjamos, nei nenuspėjamos. Mano manymu, airiai yra labiau nenuspėjami dėl to, kad tiek daug geria“. Turiu kolegą airį. Kuris tikrai gali daug išgerti. T.y. kol nesutinka lietuvio. Tada nenuspėjamu tampa nebe airis, o lietuvis.