Kodėl programavimo projektai stringa ir kaip to išvengti?

Problemos prasideda gerokai anksčiau: kai tikslas suprantamas skirtingai, projekto apimtis plečiasi be kontrolės, o esminiai sprendimai atidedami „vėlesniam laikui“.

Kuo projektas didesnis, tuo pavojingiau manyti, kad visi dalyviai projekte galvoja vienodai.

Dažniausiai pasitaikančios priežastys, dėl kurių projektai pradeda vėluoti, brangti arba praranda kryptį.

1. Skirtingi žmonės įsivaizduoja skirtingą rezultatą

Projekto pradžioje gali atrodyti, kad visi kalba apie tą patį.

• Vadovas tikisi greitesnio proceso.

• Pardavimų komanda – patogesnio darbo su klientais.

• IT komanda – tvarkingos architektūros.

• Naudotojai – kuo mažiau papildomų veiksmų.

• Programuotojai – aiškių taisyklių ir sprendimų.

Projekto planavimo metu, pradžioje atrodo, kad visos pusės vienodai supranta būsimą sprendimą. Problema išryškėja tada, kai pradedamas demonstruoti konkretus rezultatas.

Vienam „paprasta savitarna“ reiškia prisijungimą ir dokumentų peržiūrą. Kitam – visą užsakymų, kainodaros, mokėjimų ir komunikacijos aplinką.

Kaip tai išspręsti

Prieš programavimą reikia susitarti ne tik dėl funkcijų sąrašo, bet ir dėl to, kaip atrodys galutinis sprendimas.

Tam padeda:

• aiškiai aprašytas pagrindinių naudotojų kelionės scenarijus

• kokybiškas sistemos prototipas

• iš anksto numatytas rizikų sąrašas

• išsamus sprendimo aprašymas

• etapų ir darbų planas

• projekto dalyvių patvirtinimas ir atsakomybės prisiėmimas

Jeigu sprendimai priimami remiantis tik prielaidomis ar skubotais susitarimais, skirtingas supratimas išryškėja per vėlai ir tampa viena pagrindinių projekto problemų priežasčių.

2. Neaišku, kas būtina, o kas tiesiog „būtų gerai“

Daugelyje projektų funkcijos surašomos į vieną bendrą sąrašą.

Prisijungimas, užsakymų istorija, ataskaitos, pranešimai, eksportai, sudėtingos rolės, papildomi filtrai, personalizacija – viskas atrodo svarbu.

Tačiau ne viskas yra vienodai svarbu paleidimui.

Kai nėra aiškios ribos tarp būtino funkcionalumo ir pageidavimų, projektas pradeda augti dar neprasidėjęs. Programavimo komanda negali planuoti, nes kiekviena nauja idėja tampa „dar vienu mažu dalyku“.

Kaip tai išspręsti

Kiekvieną funkciją reikia priskirti vienai iš trijų grupių:

• Būtina paleidimui
  Be šios funkcijos sprendimas negali atlikti pagrindinės savo paskirties.

• Svarbu, bet galima vėliau
  Funkcija naudinga, tačiau netrukdo paleisti pirmos veikiančios versijos.

• Būtų gerai
  Idėja turi vertę, bet kol kas nėra pakankamai svarbi, kad patektų į pirmą etapą.

Tai nėra formalumas. Šis atskyrimas tiesiogiai lemia projekto kainą, terminą ir tikimybę, kad jis bus užbaigtas ir pasieks numatytus tikslus.

3. Sprendimai priimami per vėlai

Programuotojai gali judėti greitai tik tada, kai yra aišku, ką reikia kurti.

Projektas pradeda strigti, kai lieka neatsakytų klausimų:

• kas gali matyti konkrečius duomenis;

• kuri sistema yra pagrindinis informacijos šaltinis;

• kaip skaičiuojama kaina;

• kas nutinka išimtiniais atvejais;

• kas patvirtina vieną ar kitą veiksmą;

• kokie duomenys turi būti migruojami.

Kol sprendimas nepriimtas, komanda arba laukia, arba kuria pagal prielaidą. Abu variantai kainuoja.

Kaip tai išspręsti

Projektui reikia aiškaus sprendimų priėmimo modelio.

Turi būti žinoma:

• kas atsakingas už verslo sprendimus;

• kas tvirtina dizainą;

• kas atsako už integracijoms reikalingą informaciją;

• kas priima galutinį sprendimą, kai nuomonės išsiskiria;

• per kiek laiko turi būti pateiktas atsakymas.

Vienas iš dažniausių projekto stabdžių – ne projekto sudėtingumas, o netinkamas atsakomybių paskirstymas.

4. Procesas bandomas pritaikyti sistemai, o ne sistema procesui

Kartais projektas pradedamas nuo funkcijų, neįsigilinus, kaip iš tikrųjų dirba žmonės.

Dokumente procesas atrodo aiškus. Realybėje darbuotojai turi išimtis, apėjimus, papildomus patikrinimus ir informaciją, kurios niekas nebuvo aprašęs.

Jeigu sistema kuriama pagal idealizuotą proceso versiją, paleidus paaiškėja, kad ji netinka kasdieniam darbui.

Tada atsiranda papildomi laukai, išimtys, naujos būsenos ir „laikini“ sprendimai, kurie pamažu tampa nuolatiniais.

Kaip tai išspręsti

Prieš projektuojant sistemą reikia suprasti ne tik oficialų procesą, bet ir realų darbą.

Verta išsiaiškinti:

• kaip procesas vyksta šiandien;

• kur darbuotojai nukrypsta nuo oficialios tvarkos;

• kokios išimtys pasitaiko dažniausiai;

• kuri informacija gaunama per vėlai;

• kurie veiksmai dubliuojami;

• ką žmonės sprendžia ne sistemoje.

Tik tada galima nuspręsti, ką verta automatizuoti, ką supaprastinti, o ko išvis nereikia perkelti į naują sistemą.

5. Nustatomas terminas, kuris neatitinka projekto apimties

Ambicingas terminas savaime nėra problema. Problema atsiranda tada, kai data nustatoma dar neįvertinus darbų apimties, priklausomybių ir sprendimų, kuriuos reikės priimti projekto metu.

Kartais terminas pasirenkamas pagal vidinį renginį, rinkodaros kampaniją, vadovybės lūkestį ar norą projektą užbaigti iki konkrečios datos. Tačiau vien data nesumažina reikalingų darbų kiekio.

Kai spaudžiama tilpti į terminą, bet nemažinama projekto apimtis, dažniausiai nutinka keli dalykai:

• planavimui ir prototipui skiriama per mažai laiko

• programavimas pradedamas dar nepriėmus svarbių sprendimų

• testavimas paliekamas projekto pabaigai

• klaidos taisomos skubotai

• pasirenkami trumpalaikiai techniniai sprendimai

• komanda vienu metu bando užbaigti per daug funkcijų

Iš pirmo žvilgsnio atrodo, kad toks spaudimas projektą pagreitina. Praktikoje jis dažnai sukuria priešingą rezultatą: daugiau taisymų, prastesnę kokybę, neprognozuojamą paleidimą ir papildomus darbus jau po jo.

Blogiausiu atveju sistema paleidžiama numatytą dieną, tačiau dar nėra pasirengusi patikimai atlikti savo paskirties.

Kaip tai išspręsti

Terminas turi būti derinamas su projekto apimtimi, o ne tiesiog perduodamas komandai kaip nekintanti sąlyga.

Jeigu data iš tiesų svarbi, reikia pasirinkti vieną iš kelių kelių:

• sumažinti pirmojo etapo funkcionalumą

• projektą suskaidyti į kelis paleidimus

• pirmiausia įgyvendinti vieną pilnai veikiantį procesą

• atidėti mažiau svarbias integracijas ir papildomas funkcijas

• numatyti pakankamai laiko testavimui ir korekcijoms

• aiškiai įvardyti, kokia rizika priimama dėl sutrumpinto termino

Kai vienu metu fiksuojama ir data, ir biudžetas, ir visas funkcionalumas, projektas dažniausiai nebeturi erdvės racionaliems sprendimams.

Realus terminas nėra komandos atsargumas. Tai įvertinimas, kiek laiko reikia ne tik parašyti kodą, bet ir priimti sprendimus, išbandyti sistemą bei paruošti ją naudojimui.

6. Projektas vertinamas kaip vienas didelis paleidimas

Kuo ilgiau komanda kuria projektą nedemonstruodama veikiančio rezultato, tuo didesnė rizika, kad einama ne ta kryptimi.

Dideli projektai dažnai stringa todėl, kad mėnesiais kuriama „visa sistema“, o realus naudojimas pradedamas tik pabaigoje.

Tada vienu metu paaiškėja:

• dalis funkcijų naudotojams neaiškios;

• kai kurie procesai suprojektuoti neteisingai;

• trūksta svarbių išimčių;

• integracijos veikia kitaip nei tikėtasi;

• dalies funkcijų išvis nereikėjo.

Kaip tai išspręsti

Projektą reikia skaidyti į mažesnius veikiančius etapus.

Kiekvienas etapas turi turėti aiškų rezultatą, kurį galima parodyti, išbandyti ir įvertinti.

Pavyzdžiui:

1. Prisijungimas ir naudotojų teisės

2. Pagrindinis procesas

3. Integracijos

4. Dokumentai ir pranešimai

5. Ataskaitos

6. Papildomos funkcijos

Tai leidžia anksčiau pastebėti neteisingas prielaidas ir neinvestuoti per daug į sprendimą, kuris dar nebuvo patikrintas realiame darbe.

Kaip sumažinti projekto strigimo riziką

Programavimo projektui nereikia tobulo plano, kuriame viskas numatyta iš anksto.

Tačiau būtini keli dalykai:

• bendras supratimas, kokį rezultatą kuriame;

• aiški riba tarp būtino ir papildomo funkcionalumo;

• vienas sprendimų priėmimo modelis;

• valdoma pakeitimų tvarka;

• realaus proceso analizė;

• kūrimas etapais ir reguliarus pasiektų tikslų vertinimas.

Geras projektas nėra tas, kuriame niekas nepasikeičia.

Geras projektas yra tas, kuriame pokyčiai pastebimi anksti, įvertinami sąmoningai ir neleidžia prarasti pagrindinės krypties.

Prieš kodą turi atsirasti aiškumas

Daugiausia problemų projektams sukelia ne pats programavimas, o nepriimti sprendimai prieš jį.

Todėl prieš pradedant svarbu susitarti:

• ką iš tikrųjų sprendžiame;

• kam sistema kuriama;

• kas turi patekti į pirmą etapą;

• kas priima sprendimus;

• kaip vertinsime, ar rezultatas pavyko.

Kai šie klausimai atsakyti, programavimas tampa prognozuojamas, sumažėja netikėtumų, lengviau planuoti laiką ir biudžetą, o komanda gali susitelkti į kokybišką sprendimo įgyvendinimą, o ne nuolatinį krypties keitimą.