Kodėl nuolat apsišauname vertindami projektus? HOT.LT: Lithuanian

Įsivaizduokite žvilgančią, šiuolaikinę gamybos liniją, kurioje kažkas rimtai sutriko. Iš pirmo žvilgsnio ji atrodo kaip gerai suteptas mechanizmas, tačiau tikrovė liūdina Darbininkai dirba su naujausia ir pažangiausia įranga, tačiau, kaip bebūtų keista, daugiausia laiko gaišta pasikartojantiems, rankų darbams, kurie iš tikro turėtų būti automatizuoti. Gamybos procesui lėtėjant, pervargę darbininkai dažniau klysta. Produktai vėluoja, pasirodantys dažnai su defektais, kuriuos reikės taisyti. Ir nors dirbama viršvalandžiai ir savaitgaliais, vis tiek atsiliekama nuo grafiko.
Čia aprašytas tipinis programinės įrangos kūrimas.

Galite kiek norite planuoti, strateguoti, rengti aptarimus ir susirinkimus, skaidyti dalimis, adžiliuoti (vykdyti agile stiliumi), skruminti, maigyti, spausti, atidėlioti, supaprastinti, visaip sukinėti ir galiausiai visai sugadinti projektą ir vis tiek nežinosite, kokie sunkumai tyko rašant realų kodą.

Bet kodėl taip nuolat nutinka? Tai ir pasakysiu jums tiesiai šviesiai – tiesiog neįmanoma teisingai įvertinti bet kokios svarbos programinio projekto!

Dabar daugelis pasakys, kad aš jau kuoktelėjau!? Greičiausiai taip ir yra, dėl to nesiginčysiu – ale programinės įrangos developinime jau prabuvęs per 40 m. - o nuo to tikrai ne tik vabalai, bet ir drambliai galėjo į smegenis sulįsti… (klausimas ant kabliuko – ar nujaučiat, kiek dramblių gali tilpti kaukolės ertmėje?!). Tačiau vis tik turi atsirasti kažkas bent vienas, kuris pasakytų, kad tai tiesa, tik nenorime jos pripažinti! Why we suck estimating software projects?

Why we suck estimating software projects?

Taigi buvo prirašyta kalnai knygų, surengta daugybė konferencijų, prapirkta daugybė konsultacijų valandų ir parašyta begalės tinklaraščio įrašų apie tai, kaip geriau įvertinti softo projektus – tai ko tu dar nori?! Supratau. Mes visi nuoširdžiai triūsiame stengdamiesi nuraminti alkanus ir piktus viršininkus, kurie nori žinoti, kada bus paruoštas naujas funkcionalumas. Visi nustatome terminus pagal iš anksto numatytą išleidimo datą, o ne pagal tai, kada PĮ gali būti iš tikrųjų parengta.

Tik visas šposas yra tame, kad mes tiesiog negalime to padaryti! Na,… galime tai padaryti – tai darome nuolat – tačiau negalime to padaryti gerai. Kitaip sakant, mes visada prašaunam!

Čia aš apie tai – mes tebešvaistome pinigus ir laiką, vaikštom į seminarus ir susirinkimus, rengiam aptarimus, gūgliname, skaitome blogus, knygas ir net … instrukcijas. Kviečiamės brangiai apmokamus konsultantus, kurie elgiasi taip, tarsi žino, apie ką, nutaisę protingą veidą, kalba. Tačiau niekas nepagerėja, tačiau niekaip nenorime pripažinti labai paprastos tiesos – mes tiesiog nepajėgūs įvertinti PĮ projektus!

Yra priežastys, kodėl yra būtent taip. Svarbiausia (ir žinomiausia), kad kiekvienas projektas unikalus ir turi didelį kiekį „nežinomų nežinomųjų“. Kai rašomas kodas, kai kurie dalykai, apie kuriuos manėte, kad bus sunkūs, pasirodo realizuojami lengvai, o ties kai kuriais, kuriuose „nėra ką čia ir daryti“, galima užstrigti savaičių savaitėmis… Vis tik dažniau nepakankamai įvertinamas vienas ar kitas projekto aspektas…

Ir žinoma tai įvyksta ir todėl, kad statistiškai vidutinis projekto vadovas visada laikys, kad kelias iki paskirties punkto yra lygus ir ne duobėtas, kad oras visad nuostabus ir niekad nelyja ir nesninga. Taip niekada nebūna! Reikalavimai keičiasi, tačiau projekto atidavimo data ne. Darbuotojai suserga (neduokdie, numiršta!), pasiima neplanuotus laisvadienius ir t.t. Trukdo kiti projektai ar prioritetai ir t.t., ir pan. Ir svarbiausia, PĮ projektas – tai ne inžinerinis sprendimas; tai kūrybinis, o ne mokslinis procesas (ech, buvo laikai, kai programavimas iš tikro laikytas menu! Ale kas tai dar prisimena!?)

Taip, taip, suprantu, kad tai skaudu (sunku) girdėti. Verslas (t. y. klientai ir vadovai) nenori girdėti: „Na, nežinom, kada tai turėsim jums“. Jiems patinka tie, kurie sako tai, ką jie nori girdėti, nors tai būtų ir visiški blėniai. Produktas privalo pasirodyti tiksliai tą dieną, kada buvo žadėta!

Tai ką daryti? Nežinau, bet reikia tai pripažinti ir gyventi su tuo (kaip pripažįstame, kad sutuoktinis girtuoklis ir taikomės su tuo; arba, kad namą užplūdo tarakonai – kažką daryti bandai, nors žinai, kad juos išnaikinti beviltiška). Yra, kas tam reikalui ieško Šventojo Gralio, ir ieškos toliau. Bet aš (ir daugelis skaitančiųjų, o gal ir visi) jau nesužinosiu. Greičiausia vaisto niekad nebus. Jei tai pripažinsime, tai bus pirmas žingsnis prie problemos, kuri niekad neišnyks, sprendimo.

Viena didžiausių kloakų laikui programinės įrangos kūrime yra kodo peržiūros ir tada pataisymų pagal pastabas patvirtinimai (aprobavimai). Tad nenuostabu, Klaidos paieška

kad verta tai atidžiau išnagrinėti, nes būtent aprobavimai yra pagrindiniu stabdžiu tame procese. Todėl ir „Microsoft“ ištyrė savo komandas ir rado du akis stulpu statančius aspektus. Pirma, klaidų aptikimas sudarė apie tik 15% pastabų kodo peržiūros, nepaisant to, kad tai buvo pagrindinė peržiūrų motyvacija. Antra, socialiniai kodo peržiūros aspektai, įskaitant komandos hierarchiją ir recenzento patirtį, gali labai paveikti peržiūros rezultatus.

Taigi, kodo peržiūra ieškant klaidų nėra tokia veiksminga, kaip to norėtume. Bet tai nereiškia, kad reikėtų jų atsisakyti (iš savo patirties galiu pasakyti, kad tikrai buvo atvejų, ir ne tek mažai, kai jie buvo tiesiog būtini; nors dauguma buvo tipo „man tai kažko nepatinka“ arba „gal, pagal mane, reiktų realizuoti kitaip“). Tiesiog vertėtų jas atsieti nuo aprobavimo atliekamo atsižvelgiant į galimas rizikas. Tai leistų pakeitimams su maža rizika (kurių būna daugiausia) nelaukti LGBT (looks good to me) aprobavimo, dėmesį skiriant didelės rizikos pakeitimams. Taip programuotojai būtų mažiau apkrauti atsisakant nesvarbių pakeitimų peržiūros ir rečiau perjunginėdami savo dėmesį. O menedžeriai galėtų vertinti rizikas ir spręsti kompromisus. Ir projektai galėtų judėti sparčiau...

2024 m. „Wakefield Research“ atlikta programuotojų apklausa parodė, kad 8 ir daugiau valandų per savaitę dėl įvairių priežasčių sugaišta apie 70% programuotojų. Didžiausia priežastimi yra „techninė skola“, kai neoptimalus kodas lieka neištaisytas dėl būtinybės diegti naujas funkcijas. Toliau – kodo dokumentacijos trūkumas, lėti „buildai“ ir pertraukos. Ir vis tik 25% nurodė „aiškios krypties nebuvimą“. Tuo tarpu vadovų požiūris kitoks: darbuotojų stoka, programuotojų vaidmens išsiplėtimai, naujos technologijos, bendradarbiavimo stoka tarp komandų. Kad dirbtinis intelektas nepadeda, įsitikinę net 52%, o apie jo įrankių tobulėjimą nuomonės prieštaringos. Pripažįstama, kad labai svarbi patirtis, tačiau per 85% laiko, kad tam skiriamos pastangos dažniausiai yra bevaisės.

Taip pat naujas tyrimas rodo, kad dauguma programuotojų (net 80%) nepatenkinti savo darbu (pusė jų – „išgyvenimo“, t. y. kentėjimo ribose, padėtyje) – už juos laimingesni netgi santechnikai ir ūkininkai. Tai kur problema, jei jie santykinai neblogai apmokami ir dažnai gali dirbti nuotoliniu būdu?
Vis tik jų pajamos mažėja; darbo pakeitimas neretai jas padidina, tačiau trumpam, nes naujoje darbovietėje vėl susiduriama su tomis pačiomis problemomis. O didžiausia priežastimi yra techninė skola (spaudimas viską padaryti kuo greičiau), vedanti į nerealistinius planus ir „perdegimą“. Netobulos sistemos demoralizuoja programuotojus, neleidžia kokybiškai atlikti darbo. Begaliniai susirinkimai ir menedžerių reikalavimai (pvz., vertimas grįžti į ofisus, ko darbuotojai nenori) sukelia beprasmiškumo jausmą. Galiausiai sėdimasis darbas atsiliepia ir sveikatai. Tuo tarpu pats programavimas nėra problema, nes arti 70% jų programuoja ir ne darbovietei.

Per pora paskutinių dešimtmečių matome, kad programavimo inžinerija išėjo iš mados. Programuotojai privalo „deliverinti, deliverinti, deliverinti - ir, ei, tu ten, netrukdyk, leisk jiems kepti kodą!“ Ir nors yra daug argumentų už tai, kad „programavimas per sudėtingas: tai ne mokslas, o menas – tad džiaukimės juo!“, ir tame yra dalis tiesos, pažvelkime ir kitaip.

Iš kur tai kyla?! Iki 2000-ųjų kompiuterijos mokslą valdė akademinė visuomenė, bandžiusi suprasti, ką programavimui reiškia „inžinerija“. Ji ėmė pavyzdžius iš kitų sričių – taip radosi architektų atskyrimas nuo praktikų ir kruopštaus suplanavimo („krioklio“ – waterfall) projektai. Tai buvo blogai, netgi labai blogai – projektai nuolat vėlavo, buvo painūs ir sudėtingi, o „inžinieriai“ nemotyvuoti.

Ir tai leido leido paskelbti „paslankų manifestą“ (agile). Tai sutrikdė tvarką ne tik to, kaip programuojame, bet ir kaip vyksta verstas It technologijose. Jis spaudė daryti sparčiai, etapiukais, nesirūpinant planavimu (ir to „neimant į plaučius“). O kas dar blogiau, buvo paimta Donaldo Knuto citata „Ankstyvas optimizavimas yra viso blogio šaknis“ ir patogiai interpretuota kaip „tiesiog duok bet ką ir taisyk tai vėliau… arba ne[taisyk]“.
Knyga pradedančiajam

Tuo tarpu yra labai naudingų inžinerinių praktikų, tarkim servetėles matematika ar Fermi problema (čia ne toji, kodėl mes nerandame nežemiečių, jei pagal „teoriją“, jų turėtų tiesiog knibždėti; žr. ) – abi susijusios su tikėtinu įvertinimu (angl. estimation). Būtent matematika gali išspręsti daugumą žmonių tiesinių problemų

Taip tai taip, tačiau jei turime sudėtingą sistemą (tarkim, ląstelinį automatą), mums nėra trumpo kelio ir čia nėra jokios matematikos (ir greičiausiai niekada nebus) – mums telieka paleisti programą ir laukti, kuo viskas baigsis. Dauguma programų yra sudėtingos – ir iš čia opozicija inžinerijai: tiesiog įvykdykime ir žiūrėkime, kas bus.

Tačiau visose jų yra ir paprastų tiesinių problemų, paprastai viena iš tokių (kurios, aišku, dar ir tarpusavyje susiję): a) laikas (tai truks 10 ms ar 10 d.? Tai algoritminio sudėtingumo, šviesos greičio ar vėlavimo sritis); b) erdvė (kiek atminties, operatyviosios ar diskinės reiks. Tai užkodavimo, kompresijos, duomenų struktūrų sritis); c) pinigai (ar tai pasiekiama/įgyvendinama? Sveiki atvykę į optimizacijų, piktnaudžiavimo debesija ir kodėl, po velnių, baigiau gyvenimą po tiltu pelkę).

Taigi grįžkime prie servetėlės matematikos [tai greitasis paskaičiavimas tarsi tai būtų atlikta ant servetėlės arba tiesiog galvoje] ir Fermi problemų. Vienas dalykų, kuris trikdo žmones yra „aš nepažįstu skaičių“ (t. y., išvertus kitaip, esu glušas matematikoje). Viena Ferma užduotimi, dažnai užduodama per įsidarbinimo interviu, yra įvertinimas, kiek mieste (tarkim, Vilniuje) yra pianinų derintojų. Aišku, tikslaus skaičiaus nežinosite, bet tikrai galite spėti, kad jų yra kažkur tarp 1 ir 500 (pagal gyventojų skaičių, galimą procentą gyventojų turinčių pianinus, derintojo pajėgumą aptarnauti). Ir nors spėjami parametrų įvertinimai gali skirtis keliomis eilėmis, - tai gali įtikinti, kad neverta kurti 1 Eur kainuojančios programėlės tai nišai…

Taigi pradedate nuo labai pesimistinių įverčių (pvz., kiek atminties reikės duomenų bazei apie visus pianinus šalyje ir nusprendžiate, kad pianinų bus 1 mln.; jei jų bus mažiau – viskas gerai). Skaičiavimai susiveda į paprastą matematiką – jūsų prielaidų sumavimą ir dauginimą. Čia nieko ypatinga, tačiau kitiems paskaičiavimams prireiks vykdymo apdorojimo spartos, algoritmų ar duomenų struktūros žinojimų. Pvz., jei norite žinoti, kiek prireiks lėšų apmokyti LLM modelį, turite suprasti, kaip visa tai veikia – tai padės paskaičiuoti reikiamos atminties kiekį. Kartais pakanka paskaičiavimų blogiausiam atvejui.

Paskutiniu laiku stipriau pasijuto programinės įrangos (PĮ) nestabilumas. Tai ne tik „Crowdstrike“, bet ir daugybė kitų, tik mažiau plačiai pastebėtų, PĮ sutrikimų atvejų. Visų jų priežastys įvairios, tačiau tai parodo, kad PĮ nepakankamai gerai palaikoma. Tai keista, nes iš tikro vidutiniškai 42% programuotojų darbo laiko skiriama techniniam aptarnavimui, o dar apie 1/3 - techninei skolai. (apie gaišimą dėl jos ir iš to kylantį nepasitenkinimą skaitykite skirsnelyje ‘Kodo peržiūros ne tokios jau ir veiksmingos!’). Taigi, tiek daug laiko gaištama taisymams, o ne naujiems dalykams. Kai Dievas sumaišė kalbas, niekas nežinojo, kaip tas Babelio bokštas pastatytas – ir nė vienas nenorėjo būti atsakingu už jo sugriuvimą. Ir vis tik iš apačios dar atsklido įsiaudrinusio vyriausiojo menedžerio balsas: „O dar į jį pridėkite DI!..“ Plytų erozija

Uolas paveikia erozija. Ir kalnus… Ir, o taip, dabar erozija ardo PĮ!? Tik šįkart nė vėjas ir vanduo, o vidinis PĮ sudėtingumas. Jis kyla dėl naujų priklausomybių tarp įvairių PĮ dalių. Tai ir nereikalingo (nenaudingo) naujo kodo sudėtingumas, verčiančio PĮ kažkokiu monstru, kurio nei normaliai neperskaitysi (nesuprasi), nei palaikysi, kitur panaudosi (reuse) ar sėkmingai vystysi. Ir tai gali sukelti grėsmę funkcionaliam sistemos saugumui.

Programuotojai vis tiek žino, kaip orientuotis (tvarkytis) tuose išpūstuose kodo raizgalynuose. Jie dažnai panaudoja „užtrumpinimus“ (shortcuts) ar „pahakina“ kodą (workaround) – kad pagreitintų procesą. Kartais jie tiesiog priversti tai daryti!? Tik gaila, kad tai turi savo kainą, kuri su laiku tik auga.

PĮ industrija reikalauja tiesti naujus kelius, tuo tarpu seni yra ardomi. Vis pridedamos naujos funkcijos, tik pučiančios kodą. Skubėdami programuotojai prideda vis naujų šortkatų… O tada vadovai paprašo vėl atnaujinti kažkurią PĮ dalį, bet …. ei, palaukite, … atnaujinimas lūžta nuo priklausomybės nuo kažkurio šortkato… Programuotojai persijungia palaikymui, fiksina, kas ryja nepaprastai daug laiko ir priverčia juos … pridėti dar vieną šortkatą (workaround).

Tai PĮ eroziją paverčia, kai tik peržengiama tam tikra riba, kažkuo panašiu į savaime besivystančią sniego griūtį. Tada bet koks PĮ produkto perdirbinys tarsi grandininė reakcija rizikuoja pažeisti kitų funkcinių dalių veikimą. Tampa sunku papildyti net santykinai paprasta funkcija – ir tai jau tikrai prasta padėtis.

Tai verčia dar daugiau laiko skirti kodo palaikymui. Kažkiek padėti gali statinė kodo analizė, funkciniai testai ir … kodo peržiūros (nors ir teigiama, kad jos ne tokios jau ir veiksmingos; žr. atitinkamai pavadintą skirsnį). Ne visad tai padeda – tada jau turi kilti mintys apie sistemos restruktūrizaciją, bet kai kodas kaupėsi dešimtmetį ar ilgiau, tai gali būti praktiškai neįmanoma. Bet jei projektas gana šviežias, tokiu atveju galimas trumpalaikis skausmas leistinas.

Man agile reiškia „pripažintą, bet nesprendžiančią problemų“ praktiką. Tačiau sąvoka turi ir labai specifinę reikšmę, o kartu ir plačią aibę dalykų, apie kuriuos vadovai nori, kad jis tai reikštų. Tačiau vadinti tai procesu ar metodologija yra per bendra, nes tai procesas tik labai nutolusia jo (proceso) prasme. Tai vertybių ir principų rinkinys, iš kurio kažkaip susikūrėme teiginį, kad jis naudingas ir kažkuria prasme yra tokiu, ką ir reiškia.

„Mes dirbame agile“ reiškia „Darome greitai, skaidydami dalimis taip, kad naujas funkcijas pateiktume šį ketvirtį, kad mūsų vadovai būtų patenkinti“ arba „Mums nereikia plano, - mes reaguojame į tai, kas nutinka dabar“, o gal ir „Mūsų programavimo komanda nuolat užimta, nes prastovos kainuoja pinigus, nes programuotojai brangūs“…

Paimkime, pvz., tokį agile principą: „Geriausios architektūros, reikalavimai ir projektai yra savi-organizuojančių komandų“. Kokie kliedesiai! Geriausios architektūros, reikalavimai ir projektai negali atsirasti savi-organizuojančiose komandose, nes jos turi apribojimus, kurių nekontroliuoja. Žmonės ne supermenai, jie neturi supergalių, kurios panaikintų resursų ir finansų poreikį ir leistų nepriklausyti nuo kompanijos biurokratizmo. Net tikėti savi-organizuojančių komanda yra pavojinga – ar galima būti jai izoliuotai nuo verslo, ar ji žino, ko reikia klientui ir t.t.