Kokybė ar greitis? Kas svarbiau?

Dirbdamas Lavasoft‘e ir Adform‘e savo kailiu įsitikinau (ir visus aplink įtikinėjau), jog greitą produktų kūrimą ir vystymą galima užtikrinti tik nuolat rūpinantis kokybe. Dabar kuriu startup‘ą WoraPay, kur, kaip ir kiekviename startup’e, greitis yra svarbiausia.

Taigi kaip su kokybe? Ar galima užtikrinti gerą kokybę dirbant greitai? Arba iš kitos pusės, ar galima visada palaikyti gerą kokybę, kad kurtume greitai?

Speed

Žodis „kokybė“ yra bereikšmis

Pirmiausiai man reikėjo suprasti, jog vienas žodis „kokybė“, neturi jokios prasmės. Ar „produktas yra kokybiškas“ iš tikrųjų yra toks pats klausimas „ar šis kompiuteris yra geras“. Jei jūs este bent kiek susijęs su IT, galiu lažintis, kad kažkas iš draugų, giminių, pažįstamų, besirenkant naują kompiuterį šį klausimą jums yra uždavęs :).

Taigi koks buvo atsakymas? Tikriausiai klausimas: „o ką tu ketini su tuo kompiuteriu daryti?“. Tik išsiaiškinus ar žmogus naudos kompiuterį Word‘ui pasileisti ir naršyklėje interneto naujienas paskaityti, ar jis yra video filmų, ar žaidimų fanas, galima klausimą bent kiek teisingiau atsakyti. Taigi kai kalbame apie kokybę, visada svarbus kontekstas.

Kokybė yra verslo poreikis

Iš pavyzdžio apie kompiuterį labai aišku, jog kontekstas, tiesiogiai apibrėžia verslo poreikį: kas ir kokiu tikslu kompiuteriu naudosis. Taip pat yra ir kuriant programinę įrangą. Praleidus šiek tiek laiko išsigryninti kas ir kokiu tikslu (daugiausiai), naudosis tam tikra funkcija, jūs galite aiškiai apsibrėžti kokios kokybės jums reikia.

Pavyzdžiui, mūsų noras buvo kuo greičiau suteikti galimybę žmonėms pabandyti WoraPay mokėjimų mobiliu telefonu sistemą, kad gauti jų nuomonę apie paslaugą (ar ji įdomi, ar jie naudos, kas trukdys naudoti ir pan.). Tam mes paleidome labai paprastą www.worapay.com tinklalapį, kur galima susikurti paskyrą, į App Store patalpinome mūsų dar ne iki galo išlaižytą aplikaciją, o Apollo boulinge, Vilniaus Akropolyje (kur galima iš tikrųjų atsiskaityti su mobiliu telefonu), padėjome savo pačių greitai sumaketuotą instrukciją.

Be abejo, greitai gavome pastabų, jog tekstas puslapyje ne visai taisyklingas (ir ištaisėme iš karto), jog aplikacijos paveiksliukas ne visai tiksliai įmontuotas į telefoną puslapyje, jog yra klaidų aplikacijoje (apie kurias žinojome ir apie kurias nežinojome). Ar mes padarėme nekokybišką darbą? Pažiūrėkite į aukščiau paryškintą žodį, mūsų tikslą: pabandyti. Nei viena iš aukščiau paminėtų problemų nesustabdė nei vieno norinčiojo pabandyti aplikaciją, taigi verslo poreikis buvo įgyvendinta su 100% kokybe.

Produkto kokybė

Bet čia produkto paleidimas, procesas, jūs pasakysite, o kaip apie pačio produkto kokybę? Iš tikrųjų, tinka tos pačios taisyklės. Pvz. dabar mes atnaujiname API, kurį naudoja kasų  (POS) programinė įranga. Be abejo, API pasidengėme automatizuotais testais. Keičiant API, reikėjo liesti kodo dalį, kurią naudoja ir per naršyklę veikianti sistema. Programuotojas manęs paklausė ar čia taip pat rašyti testus. Aš atsakiau – ne. Jis buvo nustebęs: „kodėl tu toks nepastovus, vienur nori 100% kokybės, o kitur tau ji nerūpi. Kaip čia suprasti?“. Mano atsakymas buvo klausimas: „o prisimeni kada mes žadame paleisti per naršyklę veikiančią sistemą vartotojams?“. „Tu sakei, kad kažkada vėliau“ – prisiminė programuotojas ir tada jau pats suprato – „vadinasi, tada ir pasirūpinsime šios dalies kokybe, teisingai? Nes dabar investuoti laiko į tai ko gali ir visai netekti naudoti, yra beprasmiška“.

Įgyvendinti verslo poreikį, reiškia kurti greitai ir kokybiškai

Taigi kaip supratote, kurti greitai ir kokybiškai tikrai galima. Sunkiausia dalis kurią reikia išsiaiškinti yra verslo poreikis arba kitais žodžiais: kam ir kokią problemą mes norime išspręsti. Visa kas tiesiogiai susiję su šios problemos sprendimu, mes turime atlikti su 100% koncentracija, užtikrinant gerą veikimą dabar ir susikuriant saugumo tinklą nuo ateities pokyčių (automated regression tests). Visa kas neprisideda prie verslo poreikio įgyvendinimo, reikia padaryti su minimaliomis pastangomis, t.y. greičiausiai, o jei įmanoma, iš viso nedaryti.

Verslo ir techniniai žmonės turi vienodai suprasti kokybę

Be abejo, norint įgyvendinti aukščiau aprašytą scenarijų, kurti greitai ir kokybiškai, jūs turite užtikrinti, jog verslo žmonės išaiškintų jums tikslus, o techniniai žmonės, neužsiimtų kodo gražinimu iki begalybės ir visur (o taip, mes taip mėgstame spręsti sunkias technines užduotis, nesvarbu ar jų reikia verslui ar nelabai 😉 ). Kitaip sakant, reikia abipusio susikalbėjimo ir supratimo. O čia ir prasideda sunkiausias Scrum meistrų, projektų vadovų ar techninių lyderių darbas. Tad sėkmės jums! Man jau trijose įmonėse tai pavyko, vadinasi tai tikrai įmanoma.

 

Sutinkate su tuo kas parašyta aukščiau? Turite kitokį požiūrį į kokybę? Būtų įdomu sužinoti jūsų nuomonę komentaruose.

 

 

Tagged with: , , ,
Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausi mokymai
Data Mokymai - Lektorius
2017 m. gegužės 22-23 d. Certified Scrum Master (CSM) - Alexey Krivitsky
2017 m. gegužės 23-24 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler
2017 m. gegužės 17 d. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas
2017 m. gegužės 18 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas
2017 m. gegužės 18-19 d. ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 600 38860

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 600 38860