Targo tarkvara

Jätkuks eelmisele samateemalisele sissekandele.

Tootearenduse ajagraafikutest

Tootearenduse puhul on meil tüüpiliselt võimalik oma ajagraafikutes paindlikumad olla ja rohkem ise kuupäevi seada. See aga loob suure kiusatuse võtta endale suhtumine, et asi on valmis siis, kui ta on valmis.

Siin tekib meil kaks probleemi:

Esiteks projektikolmnurga põhimõte, mille kohaselt erinevad uued võimalused võtavad meilt ka ekstra aega ja raha (või kui me katsume aja ja raha fikseerituna hoida, siis kahandavad kvaliteeti).

Teiseks ei kasva aja ja rahakulu võimaluste hulga kasvades mitte lineaarselt, vaid kiiremini, kuna projekti keerukus suureneb ja projekti otseselt mitte edasiviivatele tegevustele kulub rohkem aega.

Konkreetselt Microsofti hiljutisest ajaloost leiame kaks näidet, mis selle sündroomi erinevaid aspekte illustreerivad:

Negatiivne näide: Windows Vista (arendus kestis mai 2001-november 2006). Longhorn/Vista projekt oli algul mõeldud suhteliselt väikese sammuna pärast Windows XP-d. Siis aga hakkas toimuma “projektiosmoos”, igasugused lisaideed ja võimalused “imendusid” järjest projektile juurde. Vt näiteid selle tagajärjel kokku pandud fantasmagooriast Paul Thurrotti väga illustratiivsest ülevaatest. WinFS, Avalon/WinPF, Indigo/WinCF ja Monad/PowerShell on vaid üksikud markantsemad näited, mis oleksid pidanud Vistasse naha ja karvadega integreeritud olema.

Pauli tsiteerides:

In late August 2005, Microsoft was still developing Windows Vista as it did previous Windows versions: New features were being added on the fly, and would continue to be added right up through the release candidate stages.

Uh-oh. Lõppkokkuvõte on meile kõigile teada. Vista sai valmis oluliselt hiljem ja oluliselt väiksemate võimalustega, kui oli alguses planeeritud (ja mitu aastat enne valmimist ka inimestele demotud!), rääkimata ulgumisest ja hammaste kiristamisest, mida mõned muudatused kasutajates indutseerisid.

Positiivne näide: Microsoft Office. Office 2010 RTM versiooninumber on 14.0.4760.1000. Kuigi Office’i versiooninumbritega on mõningast trikitamist sooritatud, pole maailmas just palju tarkvarapakette, mis sellise arvuni oleks jõudnud, ning Office’i väljalasked on juba üle kahe dekaadi küllaltki kellavärgina toiminud.

Office’i puhul fikseeritakse esimese asjana valmissaamise kuupäev. Näiteks Office XP puhul öeldi üle kahe aasta ette ära, et ship date on 3/2/1 (2.märts 2001 USA kuupäevastiili järgi) ja nii ka juhtus (Wikipedia artikkel näitab poodidesse jõudmise ehk launchi kuupäeva). Sarnaselt on fikseeritud ka beetade jt oluliste sündmuste ajad. Alati muidugi päris õigeks ajaks ei saa, aga üldiselt on hilinemised mõõdetavad mõnede kuudega. Kui mõni feature pole vastavaks ajaks piisavalt valmis, jäetakse ta lihtsalt sellest release’ist välja ja järgmine kord proovitakse uuesti.

Kui ma SharePointi Portal Serveri tiimiga ühinesin, oli just alanud kõige esimese SharePointi versiooni loomine (isegi see polnud veel teada, et seda just SharePointiks hakatakse hüüdma). Mitmesugused inimesed (mina sealhulgas) fantaseerisid kokku kõikvõimalikke võimalusi, mis tootes peaks kindlasti olemas olema. Meie õnneks lõikas toote juhtkond enamiku sellest värgist halastamatult plaanist välja, keskendudes vaid võimalustele, mille osas olid olemas kõige kindlamad ja konkreetsemad potentsiaalsete klientide soovid.  Tol hetkel paljud (mina sealhulgas) seda küll ei adunud ning vandusid tulist kurja, et keegi ei hakka sihukest toodet iialgi ostma. Lohutuseks oli vähemalt asjaolu, et tuleb ka teine versioon, kuhu need featured kindlasti sisse saavad.

SPS 2001 sai siiski valmis ning mõned inimesed isegi ostsid seda.

SPS ver 2 puhul sooritati sama harjutus, suur hulk asju jäid plaanist välja, aga inimesed ostsid ka SharePoint Portal Server 2003 litsentse ja isegi oluliselt suuremal hulgal kui 2001 omi. Sama asi kordus ka 2007 ja 2010 puhul.

Huvitav on siin aga asjaolu, et mõned featured, mis juba esimesest versioonist välja jäid, on sealt endiselt väljas! Ja mitte midagi hirmsat pole sellest juhtunud, vastupidi, SharePoint on Microsofti ajaloos kõige kiiremini kasvanud käibega (kuude arv nullist miljardini) toode.

Ehk siis jutu moraal: kui me arvame, et me teame täpselt, mis meie tootes peab olemas olema, siis me suure tõenäosusega eksime – ajagraafikute õhkulaskmisest ja feature creep‘ist oluliselt parem variant on põhiasjad korda saada ning seejärel klientide tagasisidet kuulata, mis neile järgmiseks kõige-kõige olulisem on.

Järgneb…

PS Minu Wordpressi ReCaptcha plugin muutus hiljuti üleagressiivseks ning liigitas kõik viimase paari kuu kommentaarid spämmikasti, mida ma pahaaimamatult tühjendanud olen. Mõned kommentaarid läksid nüüd ilmselt kaduma – vabandan.

Comments RSS