Kui kaua kestab Drupal-projekt – realistlikud tähtajad

🎧 Kuula kõiki artikleid järjest

Üks esimesi küsimusi iga Drupal-projekti alguses on „Kui kaua see aega võtab?”. Vastus sõltub rohkem projektist kui tehnoloogiast. Siin on realistlikud tähtajad ja peamised tegurid, mis ajakava mõjutavad.

Kui kaua Drupal-projekt tegelikult kestab?

Peaaegu iga Drupal-projekti alguses küsitakse sama küsimust:

> "Millal veeb valmis saab?"

Lühike vastus on, et see sõltub projektist.

Pikem vastus on, et projekti kestust mõjutavad sageli rohkem organisatsioonilised tegurid kui tehnoloogia ise. Arendus võib olla hästi planeeritud, kuid kui sisu viibib või otsused venivad, liigub ka tähtaeg edasi.

Seetõttu tasub tähtajaid hinnata realistlikult, mitte lähtuda optimistlikust soovist veeb võimalikult kiiresti avalikuks teha.

Miks projektid tähtajast üle lähevad?

Enamik hilinemisi ei teki koodi kirjutamise tõttu.

Tüüpilised põhjused on hoopis järgmised.

Sisu ei ole valmis

See on üks levinumaid viivituste põhjuseid.

Sageli eeldatakse, et:

• tekstid kirjutatakse projekti käigus;
• pildid leitakse hiljem;
• tõlked jõuavad õigeks ajaks.

Praktikas venib sisuloome sageli nädalate või kuude võrra.

Ilma reaalse sisuta on keeruline:

• kujundust lõplikult hinnata;
• testimist teha;
• kasutajakogemust valideerida.

Otsused venivad

Kui otsuseid teeb üks inimene, liigub projekt tavaliselt kiiresti.

Kui otsuseid teeb:

• juhtgrupp;
• komitee;
• mitu osakonda;

võib iga muudatus võtta päevi või nädalaid.

Isegi väikesed küsimused võivad mõjutada kogu ajakava.

Projekti maht kasvab

Peaaegu igas projektis tekib mingil hetkel mõte:

> "Lisame veel ühe väikese funktsiooni."

Üks muudatus ei pruugi olla suur probleem.

Kümned väikesed muudatused võivad aga lisada projekti mitu nädalat või kuud.

Seda nähtust nimetatakse sageli scope creep'iks.

Testimist alahinnatakse

Arendus ei lõpe siis, kui funktsioon valmis saab.

Pärast seda tuleb:

• funktsionaalne testimine;
• kasutajate testimine;
• brauseritestid;
• mobiilitestid;
• integratsioonide kontroll.

Mida keerukam süsteem, seda rohkem aega testimine nõuab.

Miks erinevad arendajate tähtajad nii palju?

Sama lähteülesande kohta võib üks partner pakkuda kolme kuud ja teine kuus kuud.

See ei tähenda tingimata, et keegi eksib.

Erinevus tuleb sageli sellest, mida hinnang sisaldab:

• kas kujundus on hinnas;
• kas sisu migratsioon on arvestatud;
• kas WCAG testimine on planeeritud;
• kas koolitus on kaasatud;
• kas testkeskkond on ette nähtud;
• kui palju aega on jäetud parandustele ja tagasisideringidele.

Odavaim või kiireim pakkumine ei pruugi sisaldada sama töömahtu, mida põhjalikum pakkumine.

Realistlikud tähtajad erinevate projektide puhul

Lihtne ettevõtte veeb

Tüüpiline projekt:

• 5–15 sisulehte;
• kontaktivorm;
• uudised;
• standardne sisuhaldus.

Kui kujundus on valmis ja sisu olemas, võib selline Drupal-projekt valmida ka 6–12 nädalaga.

Täisteenusprojektis, kus sisaldub analüüs, disain, arendus, sisestus ja testimine, on realistlik ajakava järgmine:

Kokku: 10–17 nädalat ehk umbes 3–4 kuud.

Mitmekeelne ettevõtte veeb

Kui lisanduvad:

• mitu keelt;
• keerukam sisustruktuur;
• rohkem osapooli;
• tõlkeprotsessid;

pikeneb projekt märgatavalt.

Tüüpiline kestus: 4–6 kuud.

Mitmekeelsuse puhul ei lisandu ainult tõlked.

Lisanduvad ka:

• URL-struktuurid;
• hreflang seadistused;
• SEO kontroll;
• kvaliteedikontroll;
• tõlgete haldamise protsessid.

Drupal migratsioon

Migratsioonide puhul sõltub maht eelkõige olemasolevast süsteemist.

#### Lihtsam Drupal 7 → Drupal 11 migratsioon

Näiteks:

• kuni 500 sisuobjekti;
• vähe kohandusi;
• standardmoodulid.

Tüüpiline kestus: 2–4 kuud.

#### Keerukam migratsioon

Näiteks:

• tuhandeid sisuobjekte;
• keerukas andmemudel;
• palju kohandatud koodi;
• integratsioonid.

Tüüpiline kestus: 4–8 kuud.

Miks migratsioonid võtavad oodatust kauem?

Drupal 7 või mõne muu vana CMS-i migratsiooni puhul ei ole suurim töö sageli tehniline üleviimine.

Rohkem aega kulub küsimustele nagu:

• milline sisu viiakse üle;
• milline sisu kustutatakse;
• kas URL-id säilivad;
• kuidas käsitleda katkiseid pilte;
• millised vanad moodulid asendatakse;
• kuidas säilitada SEO väärtus.

Mida kauem sait on eksisteerinud, seda rohkem leidub ajaloolisi erandeid, mis mõjutavad migratsiooni mahtu.

Suurem organisatsiooniplatvorm

Kui projekt sisaldab:

• keerukaid kasutajarolle;
• töövooge;
• API integratsioone;
• mitut toimetajate gruppi;
• erilahendusi;

võib projekt kesta märkimisväärselt kauem.

Tüüpiline kestus: 6–12 kuud.

Mõne suure avaliku sektori või haridusasutuse projekti puhul võib ajakava ulatuda isegi üle aasta.

Mis mõjutab tähtaega kõige rohkem?

Lähteülesande kvaliteet

Mida täpsem on lähteülesanne, seda täpsem on hinnang.

Kui lähteülesanne sisaldab:

• eesmärke;
• kasutajarolle;
• sisutüüpe;
• integratsioone;
• SEO nõudeid;

on võimalik koostada realistlik ajakava.

Ebamäärane lähteülesanne tähendab alati ebamäärast tähtaega.

Sisu valmidus

Kui tekstid, pildid ja tõlked on valmis enne arenduse algust, võib projekt liikuda oluliselt kiiremini.

See on üks suurima mõjuga tegureid kogu ajakavas.

Integratsioonid

Välised süsteemid lisavad alati riski.

Näiteks:

• CRM-id;
• ERP-d;
• makselahendused;
• autentimissüsteemid;
• registrid ja andmevahetusliidesed.

Selliste süsteemide puhul sõltub projekt osaliselt ka kolmandatest osapooltest.

Otsustusprotsess

Mida rohkem inimesi peab muudatusi kinnitama, seda aeglasemaks projekt muutub.

Kiire otsustamine on sageli olulisem kui kiire arendus.

Kuidas projekti kiirendada enne arenduse algust?

Suur osa ajakavast sõltub ettevalmistusest.

Enne partneri valimist tasub kokku koguda:

• olemasolevad sisud;
• vajalikud integratsioonid;
• kasutajarollid;
• SEO nõuded;
• brändijuhised;
• näited veebidest, mis meeldivad.

Mida täpsem on sisend, seda kiiremini saab alustada arendusega ja seda täpsemaks muutub hinnang.

Kuidas tähtajast paremini kinni pidada?

Alusta sisuloomega kohe

Sisu kogumine ei tohiks alata projekti lõpus.

Ideaalis algab see samal ajal analüüsi või disainiga.

Lepi kokku minimaalne teostatav versioon

MVP ehk Minimum Viable Product võimaldab:

• veeb kiiremini avalikustada;
• koguda kasutajate tagasisidet;
• lisada täiendavaid funktsioone hiljem.

See on sageli tõhusam kui proovida kõike korraga valmis teha.

Fikseeri projekti maht

Tähtaeg ja maht on omavahel seotud.

Kui maht kasvab, peab kasvama ka ajakava või eelarve.

Edukamad projektid hoiavad selle seose algusest peale selgena.

Dokumenteeri otsused

Otsuste register aitab vältida olukordi, kus:

• sama küsimust arutatakse mitu korda;
• otsuseid muudetakse teadmata põhjustel;
• projekt liigub edasi-tagasi.

Kas kiirem tähendab alati parem?

Mitte tingimata.

Väga agressiivne tähtaeg võib tähendada:

• vähem testimist;
• rohkem tehnilist võlga;
• suuremat vigade hulka;
• keerulisemat hooldust tulevikus.

Pikaajalise platvormi puhul on kvaliteet tavaliselt olulisem kui mõne nädala võit.

Kokkuvõte

Drupal-projekti kestust ei määra ainult arendus.

Sageli mõjutavad ajakava kõige rohkem:

• sisu valmidus;
• otsustusprotsess;
• projekti ulatus;
• integratsioonid;
• migratsiooni keerukus;
• testimise maht.

Rusikareeglina võib arvestada:

• lihtne ettevõtte veeb: 6–12 nädalat kuni 4 kuud;
• mitmekeelne veeb: 4–6 kuud;
• Drupal migratsioon: 2–8 kuud;
• keerukas organisatsiooniplatvorm: 6–12 kuud või rohkem.

Realistlik ajakava ei tee projekti aeglasemaks. Vastupidi – see aitab vältida ebarealistlikke ootusi ja suurendab tõenäosust, et veeb jõuab õigel ajal kvaliteetselt tootmisesse.

Kui soovid hinnata oma projekti mahtu, aitab esimese orientiiri anda Drupal audit või projekti kirjelduse saatmine kontaktivormi kaudu.

WebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.

Võta ühendust