Arendus- ja ärimudelid

Kui mõelda konkreetsete tarkvaraarenduse mudelite peale, siis kaks kõige popimat tunduvat olevat ikkagi agiilne ja waterfall, kus esimene esindab seda kuidas tänapäeval oleks mõistlik teha ning teine kuidas tehakse iganenud ja piirangutega ettevõtetes. Eeldusel, et väle mudel on rohkem leierdatud keskenduksin siinkohal pigem kosemudeli peale ning mitte liigselt soovides reeta enda tööandjat või kliente, siis tooksin välja mitte ühe konkreetse projekti, vaid süsteemi, kus sellelaadselt toimetatakse, miks ja mis see endaga kaasa toob.

Waterfall võib tänases agiilses maailmas olla kasutusel kui sõimusõna, kuid kindlasti on ka projekte ja kliente, kus see on jätkuvalt ainuõige lähenemiseviis - nõuded on selged ja muutumatud, ülesanded ei ole liiga suured, kogu protsess on suhteliselt lihtne. Küll on suurem osa neid, kus see tegelikult sedasi ei ole, ent erinevate taakade ja piirangute tõttu praktiseeritakse ikka kosemudelit - üheks selliseks segmendiks on riigisektori projektid, kes saavad enda rahastuse Euroopa Liidu struktuurifondidest (SF) ja peavad RIA-le detailselt aru andma kõigist enda plaanidest ja tulemustest ning nende kahe vahele jääb üldjuhul üsna mitu head aastat reaalset elu ja arendamist. Et töölõiku oleks võimalik paremini ette kirjeldada ja planeerida, siis tõmmatakse arendus erinevatesse etappidesse ja tehakse igale etapile eraldi hange: analüüs, disain, arendus, testimine ja hooldus. See omakorda toob kaasa tohutu ajakulu ja segasummasuvila, sest igat tööjuppi võivad teostada erinevad partnerid ning ükski ei ole kunagi täielikult rahul teise poolt eelnevalt tehtud tööga, samuti muutuvad ka avalikus sektoris elu, seadused ja vajadused ning bürokraatia kägistab neid kosena jätkuvalt tegema asju, mille vajadused on muutunud või kadunud.

Teine näide on see, kui SF-ist saadavate rahade eest tehtavasse projekti on fixed skoobi, aja ja raha eest (need kolm ei tohiks kunagi korraga fixed olla!) kokku keevitatud kõik need etapid ning siis tahetakse teha nägu, et teeme nüüd seda projekti agiilselt, kuid tegelikult ei ole süsteem, klient ega projekti olemus selleks valmis, oma olemuselt tehakse ikka waterfalli ning paindlikkus praktiliselt puudub.

Ärimudeleid on tarkvaraarenduse maailmas palju. On teatud hulk IT inimesi turul, kellele meeldib nokitseda innovaatilise oma toote kallal, mida siis müüakse, renditakse või mingit muud moodi seotakse miski ärimudeliga. Ise töötan IT konsultatsiooniettevõttes, mis tegeleb projektipõhise custom made teenuse osutamisega. St, et arendatav tarkvara on alati unikaalne ja omandiõigus kuulub kliendile, ettevõttel on küll valdkonnad ja tehnoloogiad, milles ollakse eriti head, kuid neid ei tootestata. Ühest küljest tähendab see alati justkui nullist alustamist, kuid teisest küljest võimaldab olla paindlik ja innovaatiline, sest ei üritata suruda klienti enda toote raamidesse. Ärimudelina sa müüd inimeste oskust ja tööaega, mitte konkreetset toodet.