Raksta lasīšanai nepieciešamais tehnisko zināšanu līmenis: ⭐⭐⭐⭐⭐ (zems)
Programmēšana ir ne tikai mūsu bizness, bet arī mūsu radošās izpausmes veids. Tā mēs pievienojam vērtību šai pasaulei, tāpēc mums, arī emocionāli, ir svarīgi lai projekti būtu veiksmīgi! Mēs lepojamies ar to, ka pilnīgi visus projektus, ko esam uzņēmušies un uzsākuši, mēs esam noveduši līdz galam. Tas varētu izklausīties neambiciozi, bet patiesībā, pēc statistikas datiem, tikai 2,5%* IT uzņēmumu visā pasaulē var lepoties ar ko tādu. Vienlaicīgi, pabeigts projekts ne vienmēr uzskatāms kā veiksmīgs, jo var tikt būtiski pārtērēts budžets, termiņi vai netikt realizēta iecerētā funkcionalitāte. Šī iemesla dēļ mēs nolēmām rakt dziļāk un rast risinājumu.
Katru projektu, var klasificēt kā veiksmīgu, apstrīdami veiksmīgu vai neveiksmīgu!
Jāatzīst, ka globālā statistika nav glaimojoša. Apjomīga pētījuma (CHAOS Report: Beyond Infinity) rezultāti liecina, ka no 10 projektiem - 2 nepiedzīvos “dienas gaismu”, vēl 4-5 projekti būs apšaubāmi veiksmīgi un atlikušie 3-4 būs veiksmīgi. Kas ir zīmīgi, pēdējo 20 gadu laikā, tendences šajā statistikā nav būtiski mainījušās.
Izvērtējot savus projektus un rezultātus, mēs redzam, ka uz kopējās statistikas fona mēs izskatāmies labi, taču mēs zinām, ka varam vēl labāk, tāpēc rakām tālāk.
Kāpēc vispār ir neveiksmīgie un apšaubāmi veiksmīgie projekti? Vienkāršā atbilde ietver 4 punktus:
- Katram projektam vienmēr ir sākums un beigas. Neatkarīgi no posmu, iterāciju vai nodevumu skaita. Līgums kaut kur sākas un kaut kur beidzas.
- Katram projektam ir vairākas fāzes.Tās var būt atšķirīgas, taču viens piemērs būtu: Noslēdzam līgumu, izplānojam, uzzīmējam dizainu, uzprogrammējam un ieviešam.
- Katrā no šiem posmiem ir vesela virkne ar lietām, kas var noiet greizi. Mēs tos saucam par riskiem. Ja risks neiestājas, tad viss labi. Ja iestājas, tad tā kļūst par problēmu.
- Jo vairāk riski iestājas, jo lielāka iespēja, ka projekts būs apšaubāmi veiksmīgs. Ja nepaveicas un iestājas akūtie riski, tad projekts tiek apturēts.
Visbiežāk sastopamās risku kategorijas, nozares spēlētājiem, sen jau ir zināmas. Tās būtībā jau ir klasiskas:
- neprecīzi novērtējām
- prasības pamainījās
- projekta statusa atskaites neatspoguļoja patieso statusu
- trešo pušu integrācijas nebija pieejamas utt.
Tām ik gadu pievienojas jaunas tēmas, kuras ietekmē projektu iznākumu:
- jēgpilns darbs
- darba un privātās dzīves balanss
- ilgtspējīga vide un attiecības
- attālināts darbs
- tehnoloģiju straujā attīstība u.c.
Šīs tēmas pārsvarā virza jaunākās paaudzes speciālisti un šīs tēmas ir svarīgas, jo arī ar šīm projekta laikā ir jāstrādā.
Tik pat svarīgs jautājums ir “Kāpēc projekti izdodas?” Pēc mūsu izpētes atkal dodam vienkāršu atbildi:
- Ir labs projekta sponsors - tie ir klienti.
- Ir laba komanda - tie ir programmētāji.
- Ir laba vide, kur tie visi kopā darbojas. Vide iekļauj arī procesus un atbalsta mehānismus.
- un...
- Tam visam caurvijas - disciplīna.
Mitigate Modeļa galvenais izvirzītais apgalvojums ir “Disciplīnas trūkums ir problēmu sakne”. Mēs identificējām to, ka mūsdienās cilvēkam pietrūkst kapacitātes un motivācijas patiesai disciplīnai. Apkārtējo faktoru gluži vienkārši ir par daudz, lai tos paturētu prātā. Un rutīnas darbi, kas ir disciplīnas stūrakmens, ir demotivējoši. Lai būtu disciplinēti un caurspīdīgi, mums ir visa nepieciešamā informācija un rīki, jo IT nozarē regulējumu, metodoloģiju un standartu netrūkst. Pastāv simtiem aktīvu standartu un tas ir nozares speciālistu labākās pieredzes apkopojums.
Lai mūsu pieeju padarītu caurspīdīgāku un disciplinētāku, mēs izveidojām Mitigate modeli, kurā iekļāvām darbības metodes (kuras priekš mums der un strādā) no klasiskām metodoloģijām, vadlīnijām, standartiem, utt. Tās metodes, kuras mums neder un nestrādā mēs sintizējām.
Mitigate modelis sastāv no:
- 8 posmiem.
- 78 tēmām, kur katra ir pakārtota kādam no posmiem
- un 624 darbībām (skaits ir mainīgs ik kvartālu pēc modeļa refaktorēšanas), kur katra ir pakārtota kādai no tēmām
Katrai tēmai un tai pakārtotajām aktivitātēm jābūt skaidri nomērāmām. Ar to saprotot, vai projektā šī aktivitāte ir izdarīta? Kā tā ir izdarīta. Ja tā jāveic regulāri, tad kad nākošreiz tā ir jāveic!?
Darbībām ir definēti atbilstošie potenciālie riski, sagataves, norādīti vēlamie izmantojamie rīki un metrikas, kā nomērīt darbības rezultātu. Mitigate Modelī uz šo brīdi ir 624 darbības un skaits laika gaitā visdrīzāk augs, tāpec šis ir mirklis, kad man ir jāatkārtojas: “cilvēkam pietrūkst kapacitātes un motivācijas patiesai disciplīnai. Faktoru un darāmo darbu gluži vienkārši ir par daudz.” Tāpēc Mitigate Modelis ir digitāli dzīva struktūra. Tas pats sevi monitorē, tas ziņo par nepilnībām projekta gaitā, un tas lūdz pēc cilvēka iesaistes, kur tas nepieciešams.
Liela daļa metriku ir veidotas ar salīdzinoši vienkāršiem algoritmiem, balstoties uz pieejamiem datiem, taču ir metrikas, kuras tiek mērītas ar komplicētiem un gudriem algoritmiem, un tādā veidā pretendē uz vēl nepieredzētu automatizāciju projektu un risku pārvaldībā. Šie algoritmi modeli padara dzīvu.
Piemēram, būtisku ieguvumu mums nodrošina nu jau iedzīvinātais algoritms, kurš analizē projekta darba uzdevumu saturu un darbiem norādīto laikietilpību. Balstoties uz vēsturisko pieredzi, tas klasificē katru uzdevumu kā reālu vai riskantu. Protams, ja uzdevumi ir 10, tad to var veikt cilvēks, bet ja uzdevumi ir 200?
Apkopojot līdz šim izstāstīto, piedāvāju 2 projektu scenārijus:
- Projekta scenārijs, kur Mitigate Modelis NETIEK izmantots un paļaujās uz veiksmi. Ja veiksme nav projekta pusē, tad iestājoties riskiem rezultāts būs apšaubāmi veiksmīgs vai pat neveiksmīgs.
- Projekta scenārijs, kur Mitigate Modelis TIEK izmantots - tādā veidā jau preventīvi apstrādājot iespējamos riskus. Projekts būs veiksmīgs.
Projekts būs veiksmīgs. Šis ir mūsu solījums Mitigate esošajiem un topošajiem klientiem. Ja vēlies, lai arī Tavs projekts ir veiksmīgs, droši sūti mums ziņu vai zvani.
* “PricewaterhouseCoopers veiktajā pētījumā, apskatot 10,640 projektus 200 dažādu nozaru uzņēmumos 30 valstīs, tika atklāts, ka tikai 2.5% uzņēmumu veiksmīgi noslēdz 100% savu projektu.” - (https://hbr.org/2021/10/does-your-project-have-a-purpose)