Kaip sukurti gerą produktą ir pasiekti pripažinimą?

Praktiniai patarimai iš pasaulyje pripažinto produkto MagicDraw kūrėjų

Dr. Darius Šilingas, Šis el.pašto adresas yra apsaugotas nuo šiukšlų. Jums reikia įgalinti JavaScript, kad peržiūrėti jį.  
No Magic Europe sprendimų skyriaus vadovas
Šis el.pašto adresas yra apsaugotas nuo šiukšlų. Jums reikia įgalinti JavaScript, kad peržiūrėti jį.

 

Įvadas

Yra du pagrindiniai būdai, kaip kuriama programinė įranga. Pirmas – kurti programinės įrangos sistemą pagal individualų verslo organizacijos užsakymą. Antras – kurti programinės įrangos produktą, kuris gali būti parduodamas ne vienam užsakovui, o daugybei klientų. Pastarasis variantas daug sudėtingesnis kūrėjų organizacijai, nes reikalauja ilgalaikio produkto kūrimo ir vystymo, rinkodaros strategijos. Taip pat sudėtingiau surinkti tokio produkto funkcionalumo reikalavimus , kadangi nėra vieno užsakovo – reikia patenkinti kiek įmanoma daugiau skirtingų potencialių klientų poreikių. Tačiau sukūrus tinkamą produktą ir jį tinkamai įvedus į rinką, galima tikėtis didesnio pelno, nei kuriant programinę įrangą pagal užsakymus, ir užsitikrinti ilgalaikį pajamų šaltinį.

Dauguma Lietuvos programinės įrangos kūrimu užsiimančių įmonių kuria sistemas pagal verslo organizacijų užsakymus arba vysto pagal organizacijų poreikius pritaikomus produktus, kurie orientuoti vidinei Lietuvos arba Baltijos šalių rinkai. Šie produktai nėra platinami arba nėra populiarūs pasaulinėje rinkoje dėl įvairių priežasčių:

  • siauro fokuso į specifinius vidinės rinkos poreikius,
  • nepakankamai efektyvaus produktų kūrimo organizavimo neleidžiančio konkuruoti su užsienyje kuriamais produktais,
  • netinkamo produkto įvedimo į rinką ar vystymo strategijos,
  • nepakankamo dėmesio produkto vartotojams ar tiesiog nesugebėjimo palaikyti pakankamą kokybės lygį vystant produktą.

No Magic Europe, UAB darbuotojai jau 10 metų kuria programinės įrangos, techninės įrangos sistemų, verslo analizės profesionalams skirtą modeliavimo įrankį MagicDraw pagal amerikiečių kompanijos No Magic užsakymą. Šiuo metu šis įrankis vienas populiariausių tarp daugiau 100 UML įrankių siūlomų pasaulinėje rinkoje. MagicDraw UML naudoja 8000 vartotojų visame pasaulyje (licenzijų parduota 78 šalyse, o šių eilučių autorius 14 šalių vedė įrankio apmokymus), jį naudoja žymiausios pasaulio organizacijos – NASA, e-bay, Yahoo, Schenker, Lockheed Martin ir kt. Per 10 metų produkto kūrimo ir vystymo laikotarpį sukaupėme nemažai įvairios patirties, kurią ketiname perteikti seminare, skirtame 10 metų MagicDraw UML jubiliejui (pirma versija išleista 1998 metų liepos mėnesį). Keletą patarimų pateiksime ir šiame trumpame straipsnyje. Manome, kad jie bus naudingi programinę įrangą kuriančioms organizacijoms, ypač toms, kurios kuria ar ruošiasi kurti programinės įrangos produktus. Juk neveltui sakoma, kad “protingas mokosi iš svetimų klaidų” :) 


 

Inicijuojant produkto kūrimą būtina į išbandyti įmonės viduje prieš pateikiant į rinką. MagicDraw UML pirmosios versijos buvo naudojamos vidiniuose įmonės projektuose. Tik vėlesnės stipriai patobulintos versijos buvo pateiktos į pasaulinę rinką. Pradėjus naudoti produktą vidiniuose projektuose buvo ištaisyta daug netinkamo funkcionalumo ar tiesiog programavimo defektų. Viešam pardavimui pateiktos versijos prasidėjo ne nuo 1.0 (ko pagrįstai bijo daug kompanijų), o jų kokybė buvo palyginti aukšta. Dėl šių sprendimų atsiliepimai apie MagicDraw UML įrankį yra labai teigiami ir daug geresni nei apie daugumą konkurentų produktų. 
Produkto kūrimo inicijavimas – “treniruokitės ant kačių”


 

Produkto marketingas – aiškiai žinokite, kuo skiriatės nuo konkurentų

Norint parduoti produktą reikia tiksliai žinoti, kuo produktas skiriasi nuo konkurentų. Pradinių MagicDraw UML versijų marketingo strategija buvo žema kaina ir funkcionalumo paprastumas, kadangi vienintelis tuo metu rinkoje buvęs UML įrankis Rational Rose buvo pernelyg sudėtingas ir labai brangus. Vėliau atsiradus daugiau konkurentų, šią strategiją teko pakeisti. Šiuo metu pagrindiniai MagicDraw UML skiriamieji bruožai:

1) geriausias modeliavimo standartų palaikymas;
2) vartojimo patogumas (usability);
3) plačios konfigūravimo ir praplėtimo galimybės (vartotojai patys gali kurti papildomo funkcionalumo įskiepius, dokumentacijos šablonus, savo diagramas, nustatyti skirtingą vartotojo sąsajos detalumą skirtingo tipo vartotojams ir pan.);
4) kokybiška nemokama vartotojų pagalbos (user support) sistema bei
5) geras kainos ir vertės santykis.

Psichologai rekomenduoja apibrėžti 5±2 skiriamąsias savybes (mažiau nerimtai atrodo, o daugiau sunku sistemingai suvokti).


 

Pradedant kurti produktą, labai svarbu tinkamai pasirinkti technologijas, kurias naudosite kurdami produktą, nes vėliau bus labai sudėtinga ir pareikalaus daug resursų ir laiko pereiti prie kitų technologijų. Vienas iš geriausių būdų – išsirinkti labiausiai “gundančias” technologijas ir atlikti lygiagretaus prototipų kūrimo bandymą. Pradedant kurti MagicDraw, buvo renkamasi tarp programavimo kalbų C++ ir tuo metu palyginti naujos kalbos Java. Buvo suformuotos dvi projektų grupės, kurių viena pradėjo kurti prototipą naudodama C++, o kita – Java kalbą. Po kelių mėnesių palyginus rezultatus, paaiškėjo, kad Java technologijos leidžia dirbti daug efektyviau, todėl buvo pasirinkta Java kalba.Produkto kūrimo technologijos – išbandykite prieš pasirinkdami


 

Pasaulinei rinkai pateikiami produktai turi būti reguliariai atnaujinami, kadangi priešingu atveju klientams gali susidaryti įspūdis, kad produktas nebevystomas ir nepalaikomas, o tai labai greitai sustabdys produkto pardavimus. Pagrindinės MagicDraw versijos (major version) leidžiamos kas pusę metų, o po kiekvienos versijos išleidžiamas dar nedidelis atnaujinimas (minor version). Taigi produkto versijos leidžiamos maždaug 3 mėnesių ciklais. Mūsų patirtis patvirtina pasaulyje šiuo vyraujančią nuostatą, kad daugmaž tokia iteracijos trukmė yra optimali. Reikalavimai produkto funkcionalumui ir jų prioritetai kinta labai dinamiškai, todėl palyginti trumpos iteracijos leidžia adekvačiai reaguoti į rinkos poreikius. Nepamirškite ir pajuokauti, pavyzdžiui, po MagicDraw 12.5 versijos buvo išleista versija 14.0, nes 13 nelaimingas skaičius :) 
Produkto kūrimo procesas – iteratyvus kūrimas ir reguliarus versijų leidimas 


 

Produkto kūrimo komanda – reikalingas tolygus skirtingų specializacijų darbuotojų pasiskirstymas

Lietuvoje dar daugybėje organizacijų vyrauja požiūris, kad pagrindinė kuriamoji ašis – programuotojai, todėl jų projekto komandose būna daugiausiai. Pradinėje MagicDraw UML kūrimo komandoje taip pat buvo tik programuotojai ir projekto vadovas. Tačiau laikui bėgant paaiškėjo, kad tai tikrai neefektyvu – reikalinga specializacija ir nuoseklus įvairių funkcijų vykdymas. Šiuo metu MagicDraw komandoje išskirtos pagrindinės analitikų, projektuotojų/programuotojų ir kokybės inžinierių grupės, kurių dydis yra daugmaž vienodas (Lietuvos padalinyje prie produkto dirba 6 analitikai, 10 programuotojų ir 8 kokybės inžinieriai). Taip pat suformuotas pardavimų padalinys (Lietuvos padalinyje dirba 4 pardavimų vadybininkai), marketingo padalinys (3 žmonės), paskirti mokymų, vartotojų palaikymo, produkto dokumentacijos koordinatoriai, kurie iš esmės paskirsto darbus specialistams iš kitų grupių. Produkto kūrimo komandos grupių darbai gerai suderinti tarpusavyje, pavyzdžiui, kol programuotojai kuria naujos versijos funkcionalumą, kokybės inžinieriai ruošia testavimo atvejus, o analitikai konsultuoja programuotojus ir testuotojus bei pradeda rengti reikalavimus dar kitai produkto versijai. Mūsų praktika parodė, kad toks darbų specializavimas, juos tinkamai koordinuojant, leidžia pasiekti labai gerų rezultatų. 


 

Vartotojų palaikymas – vertinkite galimybe tiesiogiai bendrauti su klientais ir neatiduokite klientams skirtų paslaugų vykdyti partneriams

Pradėjus kurti MagicDraw UML neturėjome pakankamai resursų, todėl įrankio mokymus ir su įrankio taikymo konsultacijas vykdėme per partnerius. Deja, bet pastebėjome, kad tai nėra efektyvu, nes partneriai dažniausiai nepakankamai gerai žinojo įrankio funkcionalumą bei konfigūravimo ir praplėtimo galimybes, nedėdavo pastangų raportuoti pastebėtas problemas ar nuosekliai perduoti mokymų dalyvių pasiūlymus kaip patobulinti produktą. Be to atsiradus papildomų paslaugų poreikiui jie stengdavosi jas perimti savo įmonei. Kai perėmėme vykdyti įrankio mokymus ir konsultacijas patys, pastebėjome, kad mokymų dalyvių atsiliepimai daug geresni, o grįžtamasis ryšys buvo labai svarbus produkto vystymui. Taip pat stengėmės į mokymus ir vartotojų palaikymą įtraukti kuo daugiau MagicDraw kūrimo komandos narių. Tai padėjo pakeisti darbuotojų požiūrį ir geriau suprasti įrankio vartotojų poreikius. Vėliau išaugo ir mokymų kiekis, kuris leido iš mokymų ne tik suteikti pridėtinę vertę produkto vartotojams, bet ir gauti pelną bei paskatinti efektyvesnį MagicDraw UML naudojimą ir parduoti papildomų įrankio licenzijų.


 

Produkto vystymo strategija – turėkite aiškią viziją, kur būsite po kelių metų

Parduodant įrankį didelėms kompanijoms, labai svarbu žinoti ir tinkamai pristatyti viziją – kas planuojama kitoms 2 ar 3 versijoms, kuria ar kuriomis keliomis iš daugybės galimų krypčių planuojama vystyti produktą. Gartner Research tyrimų duomeninis, didelių organizacijų įrankių pasirinkimą tik 24% lemia funkcionalumas, apie 20% kuriančios organizacijos (tiekėjo) gyvybingumas, apie 8% paslaugos ir palaikymas, tik 8% kaina ir netgi 40% – įrankio vystymo vizija. Neverta pamiršti ir vidinio vizijos poveikio. Produkto kūrimo komanda taip pat daug labiau motyvuota, jeigu žinos viziją, kaip įrankis turėtų atrodyti po 3-5 metų ir kokios jų kaip darbuotojų perspektyvos dalyvaujant įrankio kūrime. Žmonėms patinka būti dalimi svarbių ir įtakingų dalykų, net jei tai tik šviesi vizija :) O vizijos pildosi, jeigu jomis tikima.


 

Baigiamasis žodis

Pateikėme keletą patarimų iš praktinės patirties, kuriant MagicDraw produktą. Visus, ką šis straipsnis bent kiek sudomino, kreipkitės į mus bei sekite mūsų organizuojamus renginius.