Aš jums čia papasakosiu šį bei tą labai paprasto, bet sunkiai suvokiamo apie kai kokius projektų valdymo niuansus, nes visi žino, kad stebuklų nebūna. Ypač projektų valdyme, kur būna tik katastrofos. Bet gal pirmiausiai apie realybę. Žodžiu, yra toksai vadybinis dviejų trečiųjų dėsnis, plačiausiai žinomas iš vieno puikaus ir seno žydiško anekdoto.
Ateina klientas pas geriausią miesto siuvėją:
– Norėčiau pas jus užsisakyti kostiumą, nes visi sako, kad jūs ir greitai mokate siūti, ir pigiai, ir kokybiškai…
– Žinoma, kad taip. Galiu ir greitai, ir pigiai, ir kokybiškai. Kuriuos du iš šitų trijų norų renkatės?
Išties tai yra tiesiog projektų valdymo reikalavimai – „on time, on budget, on scope“ arba OTOBOS, tik kitaip išreikštas: ar laiku, ar už priimtiną (sutartą) kainą ir ar viskas bus suteikta taip, kaip klientas nori. Protingi ir sąmoningi kriterijai, tiesa?
Deja, labai jau dažnai, o tiksliau, praktiškai visada būna taip, kad bedarant bet kokį projektą, tenka rinktis, kurį reikalavimą paaukoti vardan kitų. T.y., kurį trečdalį atmesti. Priežasčių labai daug, pradedant kliento durnumu (kai tikimasi pirkti mersedesą už zapuko kainą, nes tipo esą zapukas juk mašina, o mersas irgi mašina, tai kainuoti turi vienodai) ir baigiant labai paplitusiu įvairių pardavėjų įpročiu klientams žadėti aukso kalnus, kad tik jie pirktų, o ar vykdytojai sugebės tai padaryti – visiškai nesvarbu.
Su patirtimi projektų vadovai įsisamonina vieną dalyką: nėra tokio projekto, kuris negalėtų baigtis bloguoju. Ir skirtingai nei kokiam balete, išsitėškusiam projektų vadovui publika neplos.
Aišku, neretai įmanoma suvaldyti šitus reikalus, nes dažniausiai pardavėjui galima įkalti į galvą, o klientui išaiškinti, kad tas dviejų trečiųjų dėsnis yra visai ne anekdotinis. Galima suvaldyti tai ir kitaip, užtikrinant visokius reikalavimus, įvedant kainos paskaičiavimo metodikas ir panašiai. Daugelis projektų vadovų bando visaip gudriai balansuoti ir kažkaip įvykdyti viską, dėl to prikuria ir visokių metodologijų. Bet tai veikia ne visada.
Su programine įranga, deja, suvaldyti projektų dažniausiai nepavyksta (juk ne veltui IT laikoma bene sunkiausiai suvaldoma veiklos rūšimi). Kur tik atsiranda projektai, susiję su tikslingai klientui kuriamais programinės įrangos sprendimais, kažkodėl labai jau dažnai vietoje dviejų trečiųjų ima veikti vienos trečiosios dėsnis*. Nelaimingam klientui lieka tik tokie variantai:
- Gauti programinę įrangą, kuri daro daugmaž tai, ką reikia, bet projektas užtrunka krūvą metų ir ne tik nepavyksta jo sutrumpinti, bet terminai persikeldinėja krūvą kartų, o viskas ima veikti tik nuo trečios versijos**, o negana to, dar ir atsieina krūvą tiesioginių ar netiesioginių išlaidų, kurios paaiškėja besančios dešimtis kartų didesnėmis, nei tikėtasi.
- Gauti programinę įrangą laiku, bet ji būna visiškai neadekvati, daro tai ko nereikia, nedaro to, ko reikia ir negana to, kainuoja baisius pinigus. Kitaip tariant, beperkant klientui atrodo, kad jis gaus kažką naudingo, o nusipirkus paaiškėja, kad arba tas daiktas daro visai ką kitą, arba išvis neaišku, ką jis išvis daro.
- Gauti programinę įrangą pigiai, bet ji visvien atsiranda pavėluotai ir būna neadekvati: tiekimo terminai vėluoja neįsivaizduojamai, tiekėjas kažkodėl tempia gumą, per kelias dienas turėję įvykti dalykai tęsiasi kažkiek savaičių, paskui ir mėnesių, o galų gale netgi metų, o galutinis rezultatas – artimas nuliui, nes galų gale tasai daiktas pasirodo besąs niekam netinkamu.
Būdinga, kad visi tokie vienos trečiosios atvejai labai paplitę. Dargi tiek smarkiai, kad apie dviejų trečiųjų atvejus išgirsti pasitaiko pakankamai retai, kad jie atrodytų lyg neįtikėtina sėkmė, l visi šitie tragiški vienos trečiosios atvejai atrodo kaip kažkas visai normalaus. Bet jei pasižiūri į tai, kaip viskas vyksta realybėje, pasidaro aišku, kad kažko kito tikėtis dažniausiai net ir nevertėtų. Nebent išmoksite daryti stebuklus.
Kaip ir kodėl feilina programinės įrangos projektai
Čia panagrinėkim tiesiog vieną ryškesnį, bet labai tokį visai vidutinišką scenarijų, kai programinės įrangos projektuose klientas paprastai pats nelabai žino, ko nori, o projekto kūrėjas paprastai turi plaktuką, todėl visur aplinkui mato vinis, bet į kliento realybę nesigilina. Štai jums pavyzdys (sakykim, kad hipotetinis, nes tos įmonės jau seniai nėra):
Kažkokia firma, platinanti kokį nors tipišką telefonstotės apskaitos softą, sugalvoja jį išplėsti ir pardavinėti, kaip programą, skirtą skambučių centro valdymui. Gaunasi kažkoks vištgaidis, bet dar iš bėdos veikiantis. Tada firma savo kūryboje pamato panašumų su CRM, todėl pradeda brukti visiems tai kaip esą CRM, o paskui dar pamato, kad kažkokie CRM pardavėjai bando savo daiktus įbrukti kaip esą ERP, tai ir baigiasi tuo, kad klientui parduodamas kažkoks ERP pusfabrikatis, kuris esą išspręs visas verslo valdymo problemas ir darys viską, ko tik reikia, įskaitant net ir visą sandėlio apskaitą, buhalteriją ir sąskaitų išrašymą.
Klientas kažkodėl patiki tokiu neadekvatu, viskas jam pasiūloma už stebuklingai mažą kainą, susitariant, kad už visokius pritaikymus bus mokama atskirai ir prikabinama makaronų, kad jau čia viską tasai softas darys ir taip, nes jis viską gali ir yra stebuklingas. O tada jau softas privedinėjamas prie kažko, kas bent miglotai primintų kliento norus.
Aišku, reikalas užtrunka keletą metų, galutinė projekto savikaina, o tuo pačiu ir kaina klientui išauga iki nenormalių sumų, o softas visvien nesugeba daryti to, ką jis turėtų daryti. Galų gale viskas baigiasi sutarčių nutraukimu, tarpusavio kaltinimais ir taip toliau.
Panašių scenarijų yra labai daug: tai ne tik bandymai pardavinėti klientui visai ne tai, ko reikia, bet ir softą kuriančių įmonių negebėjimas suvaldyti savo vidinės veiklos, paties kliento negebėjimas įsivaizduoti, ko jis nori, projektą kuriančios organizacijos negebėjimas gilintis į kliento procesus ir begalės kitų, labai objektyvių ir žlugdančių faktorių. Galų gale, suveikia net ir tas visiems gerai žinomas reiškinys, kai lyg ir ta pačia lietuvių kalba šnekantys programuotojai kažkokiais keistais būdais suvokia viską visai priešingai, negu klientas ar netgi projekto vadovas ir padaro kažką, kas nieko bendro su kliento reikalavimais neturi. Ir negana to, sudėtingėjant projektui, visas šitas briedas auga eksponentiškai.
Kartais užkietėję programavimo projektų vadovai tarp savęs kalba, jog per keliasdešimt savo veiklos metų taip ir neįstengė nei vieno projekto įgyvendinti sėkmingai, sutelpant į visus tris kriterijus. O visai atvirai prisipažinti paprastai išdrįsta tik visiškai tobuli asai, kaip kad Frederick Brooks, kuris tapo pačiu kiečiausiu ir sėkmingiausiu programinės įrangos projektų vadovu ever, o taip pat ir bendrai vienu iš šiuolaikinio projektų valdymo pradininkų. Taip, ponai ir ponios. Problemos čia rimtos.
Kai kurios firmos, nukentėjusios dėl tokių projektinių feilų, ilgainiui ima ieškoti tik gatavų, jau paruoštų programinės įrangos variantų – tegul ir ne viską darančių, bet bent jau nevėluojančių ir bent jau kažkiek darbingų. Kitos įmonės ima leisti šimtus tūkstančių ir netgi milijonus rimtoms sistemoms, dėl kurių bent jau gali būti tikras, kad jos bent jau kažkaip veiks, o diegimo terminai bus viršyti ne daugiau, kaip pusantro-du kartus. Dar kiti ima patys samdytis programuotojus, nes pasiskaičiuoja, kad taip bent kažkoks valdomumas atsiranda, o ir tikimybė, kad programuotojai teisingai supras įmonės poreikius, irgi padidėja.
Atvirai kalbant, gražaus sprendimo čia nėra, todėl susitaikykite. Tiesiog nėra sprendimo ir viskas. Ir netgi aš jums jo nepateiksiu, nors jūs mane ir garbintumėt. Nes jei jums reikia kažkokio softo, kuris būtų sukurtas jums, jums reikia susitaikyti su tuo, kad jums veiks vienos trečiosios dėsnis. Arba net ir jis neveiks. O jei jums pavyks gauti dvi trečiąsias – tai bus kaip tikras stebuklas, neįmanomybė.
Ką daryti, kad projektai įvyktų ir gautumėte bent jau tą vieną trečiąją
Visgi aš jums duosiu vieną stebuklingą patarimą, kuris jus bent kartais išgelbės. Aišku, jeigu jį labai tvirtai įsisąmoninsite. Tiesiog darykite viską mažais mažais ir bukais bukais žingsneliais ir visada norėkite mažiau. Niekada nebandykite realizuoti visko ir niekada nedarykite taip, kad būtų išsyk tobulai ir teisingai, nes vos tik projektas pasidarys sudėtingesnis už vieną kubelį, jūs jo jau nesuvaldysite. Jei reikia kažkokios programinės įrangos, kuri būtų tinkama tik jums, apsibrėžkite viską taip, kad gautųsi tiek supaprastintas ir suprimityvintas minimumas, kad bukiau jau būtų neįmanoma.
Ir beje, ne tik kad minimumas, o geriau jau net ne visai teisingas, bet užtat visiškai pagal TB ir neišvengiamai veikiantis. Ir prašykite programuotojų, kad jie padarytų lygiai tiek ir niekaip ne daugiau. Dargi ne prašykite, o reikalaukite ir bauskite už bet kokius papildomus navarotus, netgi jei jums jų reiks paskui. Nes tai, ko papildomai reikia, jie gali padaryti kitame etape.
Taip, jūs teisingai supratote: reikalaukite iš programuotojų, kad jie neviršytų absoliutaus minimumo ir kategoriškai prieštaraukite viskam, ką jie siūlytų papildomai, net jei tie papildymai atrodytų labai geri ir už dyką.
Bėda ta, kad jei tik paprašysite daugiau, tai jie visvien viską supras iškrypėliškai neteisingai, būtent taip neteisingai padarys visus tuos papildymus, o tuos dalykus kurių reikia – išvis užmirš, nes nuspręs, kad jų nereikia. Ir nepasikliaukite čia savo laiminga žvaigžde, nes aš jums iš savo praktikos pasakysiu: kiek bekartotum programuotojui, kas yra svarbu, jis visvien suras tai, kas jam įdomu, o tada, jei tik bus proga, būtent tai, kas įdomu, tai ir darys. O tai, kas reikalinga, jam niekad nebus įdomu, todėl vos tik jūs duosite kad ir menkiausią galimybę, programuotojas jums prikurs visokio briedo, kuriam sugaiš krūvą laiko, o to ko reikia – taip ir nepadarys.
Kad nebūčiau galaslovnas, aš jums papasakosiu dar vieną istoriją. Įsivaizduokite firmą, kuriai reikia buko sandėlio apskaitos softo. Ir ta firma dėl kažkokių jai vienai težinomų motyvų užsisako tą softą nuo nulio pas kažkokį pakankamai kietą programuotoją, kurį pasisamdo šitam reikalui kaip darbuotoją. O pasisamdo nuosavą programuotoją todėl, kad jau nudegė su visokiom lievom kontorom, kurios vis prikurdavo niekam netinkamo briedo.
Taigi, pasisamdo firma programuotoją, išaiškina jam viską, o po pusės metų darbo… Jūs įkvėpkite, įkvėpkite, nes aš jums tai pasakysiu: po pusės metų darbo tas programuotojas firmai duoda kažkokį savo nuoširdžiai suprogramuotą 3D sandėlio emuliatorių su žmogiukais, kurie vaikšto ir nešioja kažkokias dėžutes po sandėlį***. Ir be anei jokių priemonių, kur apskaitininkai kokias nors prekes ar jų kiekius galėtų įvesti – viskas kažkokiais trimačiais dragendropais, o vieninteliai keičiami tų dėžių parametrai (irgi, beje, tik su pele, vizualiai) – tai tų dėžių didumas ir spalva. Ir visa šitai – nepaisant to, kad jam belenkiek laiko kniso protą ir aiškino, kas ir kaip turi būti ir kas kelias dienas vis klausinėjo, kaip jam sekasi.
Žinot, kas tam programeriui galvoje susisuko? Ogi jis pagalvojo, kad padarys tą 3D emuliatorių ir prie jo prikabins tuos neįdomius apskaitos skaičiukus kažkada paskui, kad jie emuliatoriuje vaizduojamas trimates dėžes skaičiuotų, o toksai vizualus trimatis sandėlio valdymas bus visiems suprantamesnis, o ir šiaip šitaip gražiau ir įdomiau. Taip, jie šitaip supranta pasaulį. Ufonautai tie.
Tarp kitko, aš jums garantuoju, kad čia pas mane skaito dar ir daug programuotojų, tai kokia pusė iš jų net ir iš šito pavyzdžio nesupras, kas gi ten su tuo programuotoju ir visu šituo pavyzdžiu ne taip. Nes jie yra visiškame kosmose. Jiems atrodo, kad viskas su tuo pavyzdžiu tvarkoje.
Štai todėl ir reikia viską minimizuoti iki visiško absurdo. Geriau jau net neteisingai, bet bent jau kad veiktų. Tiktai taip jūs užsitikrinsite, kad bus padaryta pakankamai greitai, už priimtinus pinigus ir kažkaip veiks. Nes kitaip jūs gausite tokių čiūdų, kad maža nepasirodys.
Paradoksas, bet būtent priešingas požiūris, kai norima tik minimalaus daikto, viską leidžia gerokai pataisyti. O vos tik gaunamas kažkoks veikiantis daiktas, galima vėl pakartoti tą patį – vėl vienam žingsniukui, kurį ir vėl įmanoma sukontroliuoti, padaryti laiku ir prasmingai.
Nors tais mažais žingsniukais ir nesigaus planuoti kažkiek toliau į priekį, bet jūs bent jau gausite kažkokį priimtiną rezultatą per priimtiną laiką ir už priimtinus pinigus. Ir gal netgi paaiškės, kad kartais gausite net ir tas mistines tris trečiąsias. Nes sako, kad stebuklų būna ir netgi stebuklinėse pasakose yra tiesos.
Žinote, kaip tai vadinasi? Agile.
———
* Aš čia nekalbu apie kažkokius klaikius korupcinius atvejus, kurių pilna valdiškose įstaigose – ten tai jau veikia išvis kiti principai: kuo projektas daugiau kainuoja, tuo jį ilgiau reikia vykdyti, nes vertė suprantama kaip darbų trukmė, o ne atvirkščiai: valdininkiškai sąmonei atrodo nesuvokiama, kad galima mokėti daugiau už tai, kad būtų greičiau. Negana to, vietoje prasmingų projekto sėkmės kriterijų įvedami kažkokie kliedesiai, dėl kurių sukurta/parduota programinė įranga lyg ir atitinka, bet realiai taip ir lieka niekam nereikalinga, nes niekam realiai ir netinkama. Bet mes čia juk ne valdiškus atvejus nagrinėjame.
* Trečiosios versijos efektai buvo pastebėti dar inžinierių, berods dar XXa. pačioje pradžioje: pirma daikto versija būna tiesiog šiaip kažkoks daiktas. Antra – tas pats daiktas, tačiau prikaišiotas visokių papildomų, dažnai niekam nereikalingų fyčerių. Tačiau trečia versija jau skiriasi savo konceptualiomis idėjomis, todėl būna kardinaliai geresnė. Taip yra dėl paprastos priežasties: pirmą versiją kuriant, sukuriama taip, kaip įsivaizduojama, kad reiks. Antrą versiją kuriant, bandoma tą pačią pirmąją versiją pagerinti ir pataisyti. Tačiąu kuriant trečią versiją, susiduriama su tuo, kad daugiau nėra per kur gerinti, todėl reikia viską pergalvoti kardinaliai. Apie 1960-1970 metus tarp programinės įrangos kūrėjų šitie efektai buvo stebimi tiek ryškiai, kad tapo tiesiog visiems žinoma tiesa.
*** Kad jūs žinotumėte, kiek aš tame sakinyje buvau prirašęs negražių keiksmažodžių, kuriuos ištryniau, o tada sakinys sutrumpėjo maždaug 5 kartus…
Rokiškis Rabinovičius rašo jūsų džiaugsmui
Aš esu jūsų numylėtas ir garbinamas žiurkėnas. Mano pagrindinis blogas - Rokiškis Rabinovičius. Galite mane susirasti ir ant kokio Google Plus, kur aš irgi esu Rokiškis Rabinovičius+.
- Web |
- Google+ |
- More Posts (1489)
Tas reikalas išrastas jau seniai, tik vadinasi jis daug kam nesuprantamu žodžiu: iteratyvus (programinės įrangos kūrimo procesas). Ir čia jokio Agile (kuris originaliai akcentuoja visai kitus dalykus šiaip, čia tik mes dabar taip apibendrintai tas metodikų grupes vadinam) nereik.
Šiaip ta visa problema yra labai paprasta -- tai yra viso labo nesusišnekėjimo problema. Ją lengva identifikuoti (nes ji VISADA egzistuoja), bet neįmanoma visiškai išspręsti.
Dauguma softo projektų nufeilina dėl atgyvenusių waterfall metodikų, kur viskas prasideda reikalavimų išsiaiškinimu ir baigiasi (teoriškai) veikiančia programine įranga. Čia ir išlenda visos bėdos: vartotojai patys nežino ko jie nori, o jeigu ir žino, tai detalūs reikalavimai vistiek bus nustatyti tik vėliau, o jei ir reikalavimai žinomi, tai neįmanoma nustatyti sudėtingumo (atitinkamai ir projekto kainos), o jei ir tą sudėtingumą sugebam nustatyti, tai išorinės jėgos, kaip perėjimas į naują platformą (pvz.debesis) gali paveikti projektą. Rezultatas: tik 28% taip valdomų projektų būna sėkmingi. Agile, propaguojantis iteratyvius (iterative-incremental) procesus (ir netik) gelbėja labai smarkiai, bet vėlgi, tai nėra kažikas stebuklingo. Pavyzdžiui, kaip nustatyti galutinę projekto kainą ir trukmę dar jam neprasidėjus jokia Agile metodika nepasakys. Ką dažnai daro kompanijos -- išranda savo procesą paremtą visokiausiom metodikom, ir Agile, ir tuo pačiu waterfall. Deja universalaus, visiem projektam tinkamo valdymo nėra. Tuo savotiškai išsiskiria IT projektai nuo kitų.
Tiesą sakant, be kliento poreikių išaiškinimo ir veikiančios programinės įrangos galutiniame etape jokie Agile metodai nepadės.
Čia visas klausimas tame, ką daryti, kai klientas negali pakankamai adekvačiai perduoti programuotojams visų reikalavimų, o programuotojai irgi negeba jų adekvačiai išsiaiškinti, o visas aiškinimasis vyksta bedarant projektą, įskaitant ir galutinius etapus. O taip būna kokiais 9 atvejais iš 10.
Dėl Agile ribotumo -- taip, jis sunkiai suderinamas su planavimu.
O dėl projektų valdymo -- čia reikia turėti omeny, kad projekto atveju darbų sekos apsibrėžiamos projekto ribose, skirtingai nuo proceso. T.y., būtent šitai iš esmės natūralu ir būtent šitai nėra IT specifika.
Reali IT specifika IT projektų valdyme yra tame, kad pats IT projektas keičia kliento procesą, kuriam pagerinti tas IT projektas skirtas, taip pakeisdamas kliento keliamus reikalavimus, t.y., holistiškai žiūrint, projektas ilgainiui modifikuoja pats save, tačiau nei projekto vykdytojas, nei projekto užsakovas dažnai šito nepastebi, o vietoje to ima švaistytis tarpusavio kaltinimais, dėl reikalavimų pokyčio ir negebėjimo to padaryti. Ir vat čia trumpi žingsniukai padeda labai smarkiai.
Ponas Vidmantai, taip, iteracijos ir skaidymas mažais gabaliukais yra senas dalykas, kuris žinomas daug seniau, nei bet koks Agile. Maždaug nuo tada, kai žmonės išmoko plytas mūryt ir ropes sodint.
O dėl Agile -- jei ten nebus remiamasi makslimaliu skaidymu į minimalius gabaliukus, neveiks niekas. Nebus nei galimybės ką nors pamatuoti, nei galimybės orientuotis į klientą, nei efektyvios komunikacijos, nei saviorganizacijos, nei dar kažko.
Čia žiūrėkit paprastai: yra sąlygų logika. Vat ten įsivardinkit kriterijus ir jiems būtinas sąlygas. Ir atrasit, kad skaidymas mažais gabaliukais -- pati ta sąlyga Agile idėjoms.
Ir problema ne tik nesusišnekėjime. IT vadyboje yra visas kompleksas kraupių problemų, kurių nei viena neišsprendžiama pilnai. Ir globaliau žiūrint, netgi pati IT savaime yra problema, kuri neišsprendžiama pilnai 🙂
Kita vertus, aš šitą straipsnį rašiau ne tiek programuotojams, kiek programuotojų klientams, kurie paprastai nori visko iškart ir galvoja, kad kuo daugiau, tuo geriau, o tada gauna tai, ką gauna 🙂
Aš dabar suprantu kokį mes stebuklą turime už belekiek melejonų.
Nors pamąsčius atidžiau -- tai tik toks multitaskeris rūšiuotojas.
Dabar turime 6.3 versiją. Pirkom 4.5 -- tada ji buvo visa InternetExploreryje, turėjo netgi gražų spalvotą GUI ir didžiulį universalumą dirbant bet kokiu kompiuteriu.
6.3 versijoje turime excel-alike client’ą, kuris veikia keliolika kartų greičiau ir penkiolisdešimt kartų patogiau ir universaliau.
Upgreidas irgi kainavo.
Antai kita sistema irgi yra, katra melejonus kainavo, nes su dideliais kiekiais duomenų dirba, tai ten GUI su java suprogramintas. Visokios ikonėlės ir paveiksliukai -- niekam nereikalingas šlamštas.
Ir viskas kas iš tiesų veikia -- tai pagrindinė funkcija. Pagrindinis protingas dalykas, tai universalus tūpai paprastas būdas skaidyti problemas į smulkesnes. Vėliau kiekvieną sprendžiant atskirai, o paskui duomenis agreguojant pagal tūpus algoritmus.
Kiek suprantu, jūs turite maždaug dvi trečiąsias. Taip, tai yra stebuklas.
aš dabar pradedu suprasti, kaip atsiranda tokie stebuklai, kai iš dviejų skirtingų „vietų“ bandant išsiaiškint to paties pirkėjo skolą gaunami visiškai skirtingi skaičiai 😀
Yra tokia istorija, kaip amerikonai suprate, jog neturi atsvaros rusų balistinėms raketoms, puolė statyti povandeninius raketnešius. Patikėjo reikalą kokiai tai be proto krūtai navy projektų valdymo agentūrai (sako ji tokia krūta yra ir iki šiol). Laiko konstravimui turėjo nulį, nes laivų reikėjo jau vakar, kai kilo rusų balistinės testavimui. Žodžiu gavo (berods) du metus paleisti pirmą (istorijoje) raketinį povandeninį eksploatacijon. Šioje vietoje visi normalūs šių laikų IT project manager’iai pradėtų klykt kaip už vienos vietos pagauti ir suspausti, kad tai jokiais būdais neįmanoma, ar ne? Bet tie iš agentūros buvo tikrai kieti. Programos vadovas nusprendė… vienu metu statyti tris povandeninio laivo versijas. Pirma versija buvo visiškas tiap liap bile kokių esančių technologijų, bet reikalingų, kad laivas plauktų ir galėtų leisti raketas. Šitas ir turėjo plaukti po dviejų metų. Kitas, statomas lygiagrečiai, buvo panašus į pirmąjį, tik turėjo gauti kai kurias naujesnes, kurios jau buvo kuriamos ir turėjo būti po testavimų įdiegtos. Natūraliai jis išplaukė šiek tiek vėliau už pirmąjį. Ir tuo pat metu buvo statoma trečioji su visomis super puper technologijomis ir įvertinta statymo patirtimi iš pirmųjų dviejų. Šita plaukė vėliausiai ir buvo totali sekmė. Ir kas mane toje istorijoje užmušė, tai faktas, kad jie release’ndavo visas sistemas… kas dvi savaites -- ten gi visiškas technologijų monstras buvo kuriamas.
Tai dabar aš šią istoriją pasakoju visiems developer’iams, kurie man bando paaiškinti, kad jų darbas yra kažkoks stebuklingai sudėtingas ir jie negali release’inti savo tūkstančio eilučių kas dvi savaites 🙂
Čia vat ką užkabinote, tai yra dar toksai vienas niuansas -- šitokie paralelinio kūrimo metodai veikia tik tuo atveju, jei grupės negauna duomenų apie tai, kaip sekasi kitoms. Tai būtina sąlyga, nes kitaip prasideda konkurenciniai tarpusavio kopijavimo ciklai, kurie labai blogai baigiasi.
Na ciklams išvengti, gal užtenka to, jog paralelinės versijos persislenka laike ir vėlesnė versija ties tuo pačiu komponentu dirba, kai ankstesnė jau uždarė developmentą? Tiesą sakant, niekad apie tai daug nemąsčiau, nes tokią prabangą -- gamint kelias versijas lygiagrečiai -- kaip toj istorijoje gali sau leisti tik turintys pakankamai pinigų. IT srityje man asmeniškai neteko tokių sutikti 🙂
O mano asmeninis akcentas stipriau krito ant tempo, kaip release’indavo tą daiktą. Kuo daugiau apie tai galvoju, tuo labiau jis (tempas) atrodo neįtikėtinas, ir tuo pačiu suprantu, kad jeigu taip nebūtų buve, jie nebūtų taip (kaip reikia) greitai gave rezultato.
Kas čia nuostabaus? Jeigu resursai ne problema, tai gali ir šešias versijas gaminti vienu metu 🙂
Man įdomu, ką jūs tam vienam savo developeriui pasakojat, kuris sako, jog jūsų užprašytos „fyškės“ iki penktadienio niekaip neina padaryt gerai. Siūlot sukodint 3 versijas? 😀
Klausimas ne taip būna pastatytas. Aš paprastai klausiu, ką po dviejų savaičių naujo ir naudingo klientui galėsiu pamatyt. Kai pradeda stenėt apie daromus super puper endžainus, kuriuos pabaigus po dviejų mėnesių, užteks sušvilpt ir viskas atsiras savaime -- va tada ir pasakoju šią istoriją. Apie tikrus super puper endžainus 🙂
Mėsą pjaunu su tokiu aštriu dideliu peiliu, kurį dažnai galandu. Pomidorus su tokiu dantytu peiliu. Duonai irgi dantytas, bet labai ilgas toks, nes duona gi didelė.
Mažus projektus darau tik voterfolu, o dideli iteruoju ir deliverinu kas savaite. Klienta isklausius, viena tenka paprotinti, kitas mane paprotina.
Nėra panacėjos, tam ir komplektuojam peilius.
Taip, kiekvienam atvejui skirtingi įrankiai. Tik vat reikia turėt omeny, kad daug kur daug kas ir sutampa.
Kaip beskaidytum projektus, visvien dažniausiai (išskyrus labai specifines išimti) geriau, jei išskaidoma į pakankamai nedidelius prasmingus gabaliukus, o ne klaikūs monolitai kuriami.
Zvengeu koke valanda.
Ne nu aš programuotojas, bet tas 3D sandėlio simuliatorius mane užmušė. Čia mes aprašyti kaip… kaip… nesu tikras, kažkas tarp beždžionių su kūrybinio mąstymo užuomazgom ir šiaip paauglių, kurių paprašė savanoriškai padaryti ką nors itin nuobodaus. Ir dabar prie šito pridedam draivą kurti 3D sandėlių simuliatorius, ir, voila, programuotojas.
Nu bet čia pavyzdžiai iš lietuviško enterpraiso, jis toks specifinis, ir klientais (ėėė tai kas čia yyra, a ko taip brangiai), ir viskuo kitu. Gal su kokiais UNIXiniais programuotojais lengviau biškį dėl scope (_tik_ dėl scope, visa kita tas pats), ten kultūra „do one thing, and do it well“.
Negaliu atsidžiaugti, kad mano darbe klientai kaip ir kiti programuotojai, ufonautai ufonautus daugmaž supranta.
Ponas Laurynai, visur tie enterpraisai panašūs ir visur tos pačios bėdos. Tie pasakymai apie specifikas -- tai, atleiskit, stradankės. Visur tos specifikos tos pačios: klientai nori trijų trečiųjų ir viskas.
Mano projektuose yra deimantas su keturiais kampais, kurie vadinasi time, quality, budget ir scope. Esmė ta pati. Klientas valdo tris kampus, o pv ketvirtą.
Nu tai va
Jei įvedate kokybę, tai žiūrėkite, kad netyčiukais neatsirastų tolerancija nekokybei (laiko irba reikalavimų irba kaštų pažeidimams -- likę trys parametrai patys savaime apibrėžia kokybę), nes ten labai slidi riba gausis. Vos tik atsiranda tolerancija nekokybei, prasideda bėdos.
Tolerancija nekokybei -- tai kai atseit kas nors sakys -- a, ma jį velniai tą jūsų kokibišką architektūrą, svarbu greitai/pigiai ir kad statybos leidimas būtų?
Ne, čia kai atsiranda neatitiktis kliento reikalavimams ir sakoma, kad „ai, čia maži bugai ir tik diena užvėlinsim, per kokią kitą iteraciją pataisysim, o ir taip mažai mokama“.
Reikalas tas, kad kokybę pilnai nusako trys parametrai. Kai tie trys dar kartą atkartojami ketvirtame, pradedama manipuliuoti ir tuo ketvirtuoju, nes juk kitais trimis irgi galima, tiesa?
O jau kai tuo ketvirtuoju pradedama manipuliuoti, prasideda nenumatyti tų pirmų trijų slankiojimai.
Vat todėl čia ir atsiranda toji slidi riba, kur reikia saugotis. Nebūtinai ten kažkas blogai bus, bet reikia turėt omeny.
*Bet mes čia juk ne valdiškus atvejus nagrinėjame.
O savotiškai gaila.
Ten juk neišsemiami nesamonių aruodai. Projektų sėkmingo įgyvendinimo kriterijai ypač. Ypač tada kada juos copy-pastina konsultantai kurie neturės nieko bendro su jų įgyvendinimu (kompanija A) (gairės or whatever) o vargšai kurie turi juos realizuoti („techninė užduotis“, kompanija B) turi viską daryti taip kaip pirmieji parašė nieko nekeisdami kad ir kokius fantasmagoriškus dalykus tektų lipdyti. O užsakovas is viso nesupranta nei ko jam reikia (tam jam ir konsultantai, nes taip dažniausiai apllyinama pinigams kad mes neturim pajegumu-ziniu-etc), nei ar tai kas jam buvo padaryta jam tinka. Ratas uzsidaro.
Su valdiškais IT projektais nėra ką nagrinėti. Kai lemia korupciniai kriterijai, visa kita tėra priedanga. BTW, kai tik IT projekto kaina viršija keliasdešimt tūkstančių, išsyk jau galima kai ką įtarti. Ir kuo kaina didesnė, tuo įtartiniau.
Ne visada lemia korupciniai kriterijai. Pradinius projekto griaučius rengiančių žmonių bukumas gali sekmingai suveikti taip, kad rezultatas bus bet kuriuo atveju identiškas korupciniam variantui. Tik ten jau vykdytojai išnaudoja situaciją užsakovas-durnas-profit. Matytas ne kartą atvejis.
O keliasdešimt tūkstančių manau pasikuklinote. Sumos skyrocketina biurokrato mintyse ir projektai pervertinami dešimtimis kartų jau pačioje pradžioje kada nesuvokiant kiek kas kainuoja prašoma finansavimo. Mąstymas čia deja toks -- kuo daugiau pinigų, tuo geresnis bus rezultatas. Paskui susiduriama su problema kaip juos išleisti kad negauti per galvą.
Korupciniai atvejai -- čia viskas savaime aišku, tik ten veikiama su išankstiniu nusistatymu.
Aišku, kad ne visada lemia korupciniai. Bet dėl kainos -- aš tamstai garantuoju. Kai sumos pasiekia porą šimtų tūkstančių, tai jau švarius projektus rasti sudėtinga, o kai pareina milijonai, tai klausimas paprastai būna dar sunkesnis.
Korupciją reikia suprasti truputį bendriau, nei vien kyšius su atkatais -- ten daug tų faktorių. Ir kai biurokratas pirma prikliedi nerealias sumas, o tada jau aiškinasi, ką daryt -- tai irgi korupcijos forma. Korupcija -- tai tiesiog sugedimas.
Ir neužmirškim to, kad yra dar ir biurslas. Korumpuoti valdininkai puikiai sinergizuojasi su korumpuotais verslininkais.
Čia yra dar vienas įdomus dalykas su valstybiniais užsakymais.
Jie ne tik, kad dažniausiai yra atvirai korupciniai, nereikalingi, o kartais – velniškai žalingi, bet ir labai darko IT rinką.
Turbūt žinote, kad Lietuvoje iš visų IT kompanijų kokie 15-20% dirba tiktai su viešuoju sektoriumi. Kai prasidėjo krizė ir blogasis Kubilius pradėjo karpyti finansavimus, o po to drįso reikalauti, kad vieši pirkimai eitų per vieningą, skaidrią sistemą, daugeliui tokių firmelių katino dienos pasibaigė.
Dėl to pradėta mėginti savo jėgas privačiame sektoriuje. Tas baigėsi epiniais failais. Žinau vieną įmonę, kuri kūrė milijonines duombazes valstybei, bet nesugebėjo sukompiliuoti flashinio korporatyvinio websaito, ką sėkmingai padarė iš jų užsakymą nugvelbę du KTU studentai.
Tos kompanijos puikiai prisitaikė prie biurokratinių-korupcinių procesų ir pačios nejučiomis virto visokių ministerijų ir komitetų departamentais. Todėl jos paprasčiausi neturi įgūdžių dirbti privačiame sektoriuje ir toliau murkdosi viešų pirkimų liūne ir tampa visiškai parazituojančiom struktūrom.
Vieši pirkimai negatyviai paveikę ir kitus sektorius, bet IT – labiausiai. Teko matyti įmonių, kurių akcininkai iš direktorių reikalauja rašytinių pasižadėjimų nedalyvauti viešuose pirkimuose, nes yra n+1 pavyzdžių, kai kompanija pradeda vykdyti valstybinius užsakymus, kurie palaipsniui suryja kitų užsakymų resursus ir tada bendrovė persimeta į darbą tik su jais. Nuo tada įmonėje prasideda vėžys – ji niekada reikšmingai neaugs, nekurs inovacijų ir per kiekvieną rimtesnę finansinę krizę turės labai daug tikimybių subankrutuoti.
Tamsta labai gerai čia to segmento reikalus nupasakojote. Ir tam reiškiniui dar yra ir toksai pavadinimas -- biurslas 🙂
Pripranta daryti daiktus, kurie realiai niekam nereikalingi, o paskui kai prireikia kažkokio prasmingo darbo, būna bėdos.
Beje, dėl tos priežasties geriausias būdas kovot su šitu kliedesiu -- tai valdiškoms įmonėms samdytis programuotojus pačioms.
Pasižiūrėjus, kaip ir kodėl pas save gerai tvarkosi Registrų Centras, klausimų daugiau nekyla.
RC sėkmė sietina labiau ne su programerių buvimu, o vadovybės suvokimu kas tai yra IT.
Prie Šimonytę finminas savo vidinę apskaitą vedė kažkokia prieštvanine programa, kuri veikia tik DOS‘e. Aitišnikai plaukus rovėsi, nes dažnas jų apie dosą girdėjęs iš kokio pasenusio dėstytojo, studentavimo laikais ir kai reikėdavo sistemą tvarkyt, nežinojo nuo ko net pradėt. Ta tema internetuose net tutorialų beveik nėra. Dar buvo bėda, kad duomenų negalima buvo operatyviai eksportuoti. Viską reikėjo adatiniu printeriu atspausdinti, nenešti specialiai pasamdytai darbuotojai, kuri viską suveda į ekselį. Ir ilgus metus niekas nesikeitė, nes viskam vadovavo sena tarka, kuriai ir taip gerai buvo.
Dažnai valstybinio IT problema yra ne tik korupcinė, bet elementarus suvokimo stokos. Yra nemažai susifermentaviusių biurokratų Chroniaus Bradausko veidais, kurie nesupranta kas tie internetai, kam jų išvis reikia ir kuo blogai ranka supildyti popieriniai blankai?
Viena organizacija, tik prasidėjus krizei pradėjo smarkiai reklamuoti open sourc‘ą. Buvo aiškinama kiek tas pinigų sutaupo, kokie tai lengvi ir greiti sprendimai ir t.t. Pačiame akcijos gale buvo padarytos apklausos, kurios parodė, kad dauguma respondentų suprato, kad jiems mėgina parduoti kažkokias šifravimo sistemas.
Biurokratija yra labai sena. Jaunesnių nei 30 – geriausiu atveju penktadalis, todėl vis dar egzistuoja bajeriukai, kai kokią nors paraišką turi nusiųsti faksu, nes vyr specialistė (pastebėjot, kad ten visi vyr specialistai?) Stefutė nemoka atidaryti jpeg‘o.
Tamsta pradedat ginčytis čia dėl RC apie visai kitus dalykus, kurie bendru atveju yra ne tokie jau ir svarbūs.
Esmė yra outsorcingo problemos: jei pagrindinį procesą per IT ima realizuoti pašalinės firmos, gaunasi feilai, nes išorinė organizacija iš principo negali realizuoti įmonei pagrindinio proceso gerai. Bet kai realizuotojai yra pašonėje, savi, žinantys vidinius įmonės reikalus tiesiog iš kasdienio gyvenimo, viskas juda kardinaliai geriau.
Kita vertus, dėl suvokimo -- tai yra dar blogiau, nei tamsta sakot: jie supranta išvis tūpai: kadangi jiems IT ir kompiuteriai yra nesuprantamas briedas, per kurį galima nebent nuleisti valdiškus pinigus, tai reiškia, kad ir tikrintojai nieko nesupras, o todėl tai geriausias būdas nuleisti valdiškus pinigus.
Atitinkamai ir randasi krūvos absurdiškų kelių metų trukmės projektų po keletą milijonų, kuriuos galėtų realizuoti koks nors studentas per kelias savaites dirbdamas vakarais ir už tai paimti keletą tūkstančių.
Man taip kartais kyla mintis, kad reiktų imti ir pasisiūlyti kokiems STT paskaitų paskaityt apie tai, kaip identfikuoti korupcinių IT projektų požymius ir efektyviau pričiupti tų lievų projektų pirkėjus.
Manote suveiktų? Aš manau ne. Čia dėl STT. Suprasčiau kad čia tik mintis.
Kai stovinčių on top kontrolierių-organizacijų ideologija vertinant projekto sekmes/nesekmes ir tikslus yra pagrįsta principu kad jei užsakovas (čia tas kuris suko pinigus) patenkintas, viskas kaip ir ok, ir visi grandinėlėje pasirašo kad ok. O ką ten daugiau veikti papildomiems tikrintojams kai požymių nebėra po tiek antspaudų ir parašų.
Bandyti pradinėje stadijoje identifikuoti problemas? Nerealu, neužteks žmonių visas potencialius probleminius atvejus kontroliuoti
O kam kontroliuoti visus potencialius? Reikia tik kokį pusšimtį didesnių per metus lengvai patikrinti, ar jie gali būti korupciniai, ar visgi yra tikrumo požymių. Ir taai dažniausiai pakankamai lengva.
Ten gi tų kriterijų nėra tiek jau daug, ir pusė tų kriterijų net IT žinių tereikalauja maždaug tiek, kiek reikia žmogui, mokančiam naudotis elektroniniu paštu.
Kita vertus, pastebėkim, kad tamsta truputį painiojatės STT ir VPT funkcijose. Nors, kita vertus, VPT irgi kai kas padėtų 🙂
Parašysiu kaip programeris.
Jei pasisamdai durną programerį ir dar kosmonautą -- gausi durną kosminį produktą. Lygiai taip pat jei pasisamdysi tų pačių savybių vadybininką, šlavėją ar gen. direktorių. Tad programeriai nėra išskirtiniai.
Problema, mano akimis yra dvilypė (Agile yra gerai, bet nereik iš jo daryt šventos karvės):
Didesniuose projektuose reikia žmonių, sistemų analitikų ar projektų vadovų, kurie labai gerai įsikirstų į įmonės procesus, sudengtų juos su kaip galima mažesniu softo scope’u, kad neprirprogramuot naujų dangoraižių. T.y. jie turi žinot ką patys turi iš funkcionalumo, kiek jų funkcionalumas dengia įmonės procesus ir kiek tai atitinka pvz. įstatymus ar elementarią good practice. Nes dažnai įmonėse kai kur įsibėgėjusi bloga praktika, bet „mes visada taip darome, nes taip priimta“
Bėda ta, kad tų protingųjų, galinčių kokybiškai padengti visas tris šakas, yra minimaliai. O jei jų laikas dar skaidomas esamų sprendimų supportui ir naujų projektų suvaldymui, galų gale nė vienas iš projektų nebegauna pakankamai kokybiško dėmesio ir laiko.
Antra, tas pats Agile reikalauja nuolatinio ir nuoširdaus įmonės žmonių įsitraukimo į developinimo procesą. Didelėse įmonėse tas padaroma, bet problematiška.
Savų programerių samdymas gali būti geras sprendimas jei suprantama, kad samdant IT skyrių nereikia taupyt. Nes prisirenka visokių „pigių“ programerių ir vėl gale turi kosmosą.
Neblogas sprendimas, imho, gali būti, kai kūrėjas-diegėjas atsineša pusfabrikatį, kuris remiasi gerom praktikom apskaitoje, sandėliavime etc. etc. ir diegimo metu apmoko vietinį IT skyrių, kuris darys kažkurią dalį būsimo kasdieninio supporto.
Nepainiokit koldūnų su arabais. Geri programuotojai amžinai visokie kosmonautai. O tie, kurie realybėje gerai susivokia -- paprastai nemėgsta programuoti ir tuo neužsiima. Taip yra dėl elementarios priežasties: jei nori būti geru programuotoju, turi būti nuprotėjusiu ant tų visų reikalų.
Dėl pigių ir nepatyrusių programuotojų -- ten ne kosmosai gaunasi, o atvirkščiai -- klaikūs, bugovi ir nedarbingi fufeliai.
O dėl to, kad daugiausiai nulemti sugeba geri projektų vadovai ir kad visą tą kūrimą reikia integruoti su užsakančios įmonės IT procesais -- tai taip, tikrai taip.
„Geri programuotojai amžinai visokie kosmonautai. O tie, kurie realybėje gerai susivokia — paprastai nemėgsta programuoti ir tuo neužsiima.“
Kosminio lygio nusikalbėjimas…. siūlau susipažinti su platesniu ratu programuotojų. Normalių.
Taigi, vadinasi, tamsta esate programuotojas ir labai nenorite būti kosmonautu. Deja, realybės nepripažinimas -- tai jau požymis 🙂
Taip, esu programuotojas.
Dauguma programuotojų, kuriuos pažįstu, anaiptol ne kosmonautai. Netgi atvirkščiai -- aplinkos suvokimu lenkia visokius vadybibininkus, marketingą ir kitus blahblah. Dažniausiai pastariesiems tenka sprendimų teisė.
O visas IT kolektyvas prilyginamas valytojų lygio padaliniui -- pinigus suėda, o iškrypusių kažkieno fantazijų nepaverčia pelnu.
O kosmonautais išvadint tokius žmones kaip Linus Torvalds, Paul Allen, Larry Ellison ar kokį tais Dennis Ritchie…
Štai visa esmė: tamstai atrodo, kad tie kiti nenormalūs, kurie su IT nesusišneka, daro sprendimus ir nežino, ką su tais programuotojais bei adminais daryt 🙂
Kitaip tariant, programuotojai programuotojus supranta ir jiems atrodo, kad pasaulį suvokia adekvačiai. O visokiems marketingistams irgi atrodo, kad jie pasaulį supranta adekvačiai. Bet vieni kitus laiko durniais.
Taigi, pagalvokit gerai apie tai, kur slepiasi paslaptis 🙂
Jo! O dar pasakykit, kad Čiubaka neturi jausmų 🙂
būdamas programuotojas galiu pridurti, kad nemačiau dar didesnio Kostmonauto negu Linus Torvalds. Kostmosas ir jis ir jo GIT’as ir jo požūris 😀
Kosmonautas tamsta. Paaiškinsiu kodėl: nes vertini programuotoją ir įrankį ne pagal nuveiktus darbus ir teikiamą naudą, o pagal savo galvos kosminėje tuštumoje esančias figūras. Tai neturi nieko bendro su žemės paviršiumi ir yra klasikinis kosmonautizmo pavyzdys.
Žemės paviršiuje reikia to apie ką rašo Rokiškis: iš programuotojų – veikiančių programų ir skubiai, o iš įrankių – kad būtų naudingi.
Linuxo kernelis (kurį pusė šio posto komentatorių nešiojasi kišenėj) – vienas sudėtingiausių programavimo projektų evar. Ir jis ne tik, kad veikia. Jis veikia ant krūvos skirtinigiausių platformų, jis nukonkuruoja visas kitas OS ant tų platformų, dėl savo tolesnio plėtojimo (o dažnai ir veikimo) greičio. Kas pradėjo tą kernelį ir kas vairuoja jo kūrimą visi žinome.
Git buvo parašytas efektyvinti šio sudėtingiausio projekto programuotojų darbui. Tai, kad jis dar yra ir universalus bei tinka net kurti dropbox alternatyvoms yra šalutinis efektas, bet jis daug pasako apie to pačio Torvalds sugebėjimus. Taip, Git nėra skirtas programuotojams su pampersais , jų žaislų dėžėms valdyti. Užtat tiems, kas juo naudojasi, jis yra nepakeičiamas, nes joks plastmasinis kukutis niekad nepakeis pneumatinio kūjo.
Kosmonautizmas ir rezultatyvumas -- skirtingi dalykai. Kosmonautai gali būti ir rezultatyvūs, ir ne. Tiesa, superrezultatyviais paprastai tampa visgi kosmonautai. Nes jie skraido kosmose.
Programuotojų išskridimo į kosmosus nereiktų vertinti kaip neigiamo dalyko -- tai tiesiog gebėjimas persijungti iš realybės į kažkokią didžiulę, klaikiai sudėtingą abstrakciją.
Nelabai pageidautina, bet sunkiai išvengiama tokio persijungimo pasekmė -- tai negebėjimas (ir beje, kartais tiesiog stulbinantis) orientuotis kitose srityse, nes joms tiesiog pritrūksta ir laiko, ir procesoriaus pajėgumų.
Visoje aprašytoje problematikoje bei komentaruose pasigedau žvilgsnio per finansinę prizmę.
Gal kiek grubiai.. bet apmokėjimo būdas įtakoja darbo organizavimą:
„fixed price“ apmokėjimas -- waterfall’as. Atsiranda noras kuo detaliau aprašyti specifikaciją, detaliai įvertinti „scoupą“, užmesti buferį nenumatytiems darbams, fiksuoti projekto pradžios ir pabaigos datas. Griežtai laikytis plano, kontoliuoti „milestones“. Bet kokie pakeitimai t.b. įtraukti kaip papildomas poreikis įvertinant laiką (pinigus :)) bei bendrą projekto trukmę. Žinoma, projekto eigoje galima peržiūrėti ir atsisakyti tam tikro funkcionalumo tačiau dažniausiai tai būna problematiška nes yra sutartys, įsipareigojimai trečioms šalims ir pan. (pvz projektai už „europinius“ pinigus kur ką apsirašei tą ir turi gauti nesvarbu kad biznio logika jau pasikeitusi, kitaip už projektą susimokėsi iš savų pinigų :))
IT bendrovėms irgi naudingas šis metodas nes yra aišku kiek laiko bus užimta komanda (kitų projektų planavimas) ir kiek pajamų bus gauta.
„times and materials“ -- darbas iteracijomis „agile“ -- specifikuojamės „scoupą“, detalizuojames svarbiausias funkcijas darbus nuo kurių pradėsime, visas kitas poreikis įvertinamas „maždaug“, lyginamuoju budu. Gaunamas projekto biudžetas. Darome gabaliukais, pristatome kas nuveikta, jei reikia darome pakeitimus, tobuliname. Dirbame kol baigiasi biūdžetas nes „tobulumui“ ribų nėra. Metodas labiau tinkamas vidiniams įmonių IT padaliniams, komandoms suburtoms tam tikram uždaviniui spręsti.
Na gal kiek tendencingai surašiau, bet iš esmės ne metodai kūria produktus, bet žmonės, komanda (užsakovas irgi komandos dalis) ir visada svarbiausia yra bendravimas.
Tiesa sakant, daugelis IT kompanijų lietuvoje dirba miksuojant kelias metodikas. Tai labai priklauso nuo kliento, užsakovo kiek jis linkęs pasitikėti IT kompanija ir pats įsitraukti į kuriamą produktą.
IT sritis nėra kažkokia išimtis. Planuojat įsigyti namą. Po detalaus pokalbio su architektu sumušat rankom ir po kurio laiko pasiimat naujai pastatyto namo raktus.. ar viskuo būsite patenkintas?
Tų įtakojančių veiksnių labai daug, čia tamsta išties bent tris įvardinote, kurie susiję tarpusavy: finansinį, reguliacinį, planavimo.
Dėl finansinio -- Agile turi vieną labai gerą privalumą: mokėjimo sumos adekvačiai eina irgi mažais gabaliukais, todėl mažinamos rizikos ir pinigų įšaldymas, o kartu paankstinama atsiperkamumo pradžia.
Dėl reguliacinio -- kur įsikiša valdiškos kontoros su visokiais fondais, Agile panaudojimas tampa sunkiau taikomu būtent dėl to išankstinio apibrėžimo.
Su ilgalaikiu planavimu Agile irgi sunkiau siejasi, nes dėl nuolatinio perplanavimo prognozuoti darosi keblu, nukrypstama nuo planų, o neretai ir nuo galutinių kriterijų. Kita vertus, čia yra ir toksai paradoksas, kad dėl padidinto valdomumo Agile atveju projekto sėkmės tikimybė paprastia išauga.
O šiaip jau, nagrinėjant visus tuos veiksnius, o ir jų tarpusavio sąveikas, gautųsi ištisa knyga 🙂
Pachiam tenka dalyvauti IT projektuose ish HW puses. Tai pasakychiau, kad bent jau IT projektai (manau namo statyba irgi) turi savybe multiplikuoti nesamones ir problemas esanchias tiek tiekianchioje, tiek gaunanchioje imoneje. Ypach grazhiai ish shono zhiurint matosi ivairios nekompetencijos, nemotyvuoti darbuotojai, bukumas, konfliktai tarp padaliniu, itakos sferu ir pan. Pvz. vienas skyrius reikalauja, kad produktas darytu kazka vienaip, kitas -- kad kitaip. Ir peshasi, tampo antklode tiekejo akivaizdoje… Kai buvau jaunesnis, karshtesne galva, esu savo iniciatyva ishtraukes pora projektu ish fail’o, nors mano atsakomybe tik HW. Bet juk nesamones bet kuriam sveiko proto zhmogui matosi. T.y. atsistoji tokiose razborkese ir pasiulai normalu, imones realybes atitinkanti varianta „o tai gal tiesiog padarykit taip ir anaip?“. Shito reikalo tamsioji puse, kaip paaishkejo, yra ir automatine atsakomybes uzh projekta (ir su visais jo fail’ais) delegacija paprastam technariui :D. Todel valdzhia griezhtai uzhdraude savo mintis reikshti outside the scope. Dabar stebi projekto eiga ir matai, kad pvz. chebra sekmingai vazhiuoja i pievas ir tuoj su trenksmu reshis i siena, ar bent jau uzhrish projekta del eksponentishkai ishsiputusiu kashtu (kuriu visai nereikejo, jei butu suvaldyti poreikiai). Nu ka darysi, toks tas IT.
Beje tinklistu ir hardwaristu paprastai nesupranta ne tik projmanai, bet ir tie patys kosminiai programeriai, nors jie tipo irgi IT. O vat mums kazkaip isheina juos suprast (tikiuosi), nes kai kalbiesi su architektais, visviena reikia ishsiaishkinti, kas kaip, kur, ka daro.
Del IT totalaus nesuvaldymo ish vadybos puses. Belieka tik pritarti. Jei norima nesigilinti i specifika, ir ivertint viska skaichiais. Pas mus linksma buna, kai valdzhia 12451’a karta megina nesekmingai ivertinti kazkokiais rodikliais (hardcore?) adminu grupes darba (tinklas, OS, HW) ir pagal tai daryti kazkokius sprendimus. Nes verslui reikia, kad paslaugos veiktu sparchiai ir patikimai. Jei adminai (galima ir visa IT paimt, arba net plachiau, pvz. pramones irengimu aptarnavima) kazka ten savo magijom buria ir tos paslaugos kazkaip veikia, niekas nesuvokia kaip, tai klausimas -- kaip ivertinti ar ju per daug, per mazhai, jie geri ar blogi, kaip juos motyvuoti, kelt algas ar mazhint. Galu gale ar biudzhetas naudojamas pagristai. T.y. ar ishties imonei reikia kazkokios dezhes uzh belenkiek pinigu, ar ne :). Verslas gi paprastai totaliai nerisha, kuo uzhsiima ta kruva pavojingai protingu ir ishsilavinusiu zhmoniu. Kurie beje gali taip pat sekmingai ir parazituoti imoneje.
Rokishki, gal koki straipsneli ta tema galetum brukshtelt a? Tema gi idomi turetu but, kaip gamybos priezhiura kontroliuot ish aukschiau. Nes koks departamento/skyriaus vadovas, kuris stumdo biudzhetus nelabai supranta ar pneumatikos/IT sistema veikia taip kaip veikia del zhmoniu/skyriu nuopelnu/kaltes/pastangu/bbdejimo, ar del to, kad ji tokia kokia yra.
Šiaip tai tinklistai ir šiaip įvairūs hardwarininkai toliau nuo visų tų projektų vidinės logikos, tai dėl to gal šiek tiek holistinio požiūrio daugiau gaunasi, o ir šiaip mažiau į kosmosus tokie žmonės lenda 🙂
Dėl IT valdymo -- yra atsikros metodologijos tam, pvz., ITIL, tik ten irgi amžini šlubavimai ir paskutiniu metu, su 3 versija -- dar ir nusivažiavimai į visokius vidinius optimumus, klaikų IT padalinių valdymą bei pinigų kalimą iš sertifikacijų. Labai aiškūs požymiai, kad apsirgo klasikine standartizacijos komitetų liga.
Bendrai imant, yra tiesiog vienas dalykas, kurio amžinai trūksta visur, kur tik IT -- tai ir IT vadovų, ir IT darbuotojų supratimo apie bendrus kliento/įmonės tikslus.
Dažniausiai gi gaunasi taip, kad IT darbuotojai įsivaizduoja, kad jų tikslas yra gerai veikiantis IT, o apie tai, kad IT yra reikalingas tik tiek, kiek leidžia pagerinti kliento/įmonės veiklą -- užmiršta taip sėkmingai, lyg klientas/įmonė būtų dirbti trukdantis išorinis veiksnys.
Kita vertus, patys klientai ar IT besinaudojančios įmonės irgi neretai nuleidžia rankas ir ima galvoti, kad ką ten tie kompiuterastai -- visvien nieko nesupranta, tai ko ten jiems aiškinti apie tai, dėl ko įmonė dirba.
Neretai į kompiuterastus žiūrima kaip į visiškai neįtakojančius darbuotojus, be kurių kažkodėl nesigauna apsieiti -- panašiai, kaip į valytojus ar santechnikus.
Vat paskui ir matom, kokie rezultatai 🙂
Jei rokishkis nepraleis mano didzhiojo komentaro, tai gal nors praleis shita ;). Reali citata ish gyvenimo. Tiesiog projektuotojo zhodzhiai vienam IT projekte: „Mes sugalvojam normalią paslaugą, jūs apkabinėjat ją nesamoningais, niekam nereikalingais reikalavimais ir funkcionalumu, dėl ko po to gaunasi neveikiantis gremėzdas, kuris niekam po to nereikalingas. Ir po to kaltinat paslaugos autoriu!“. Zhodzhiai pranashishki. Jau tam asmeniui nebedirbant (ishmete, mol konfliktinis), bet neuzhilgo, startavo megaprojektas, tiekejas kardinaliai perrashe produkta, sugaisho pora metu, tas kainavo daug pinigu ir dabar produktas sekmingai naudojamas be viso to funkcionalumo, del kurio ta produkta perrashinejo… Tie darbuotojai, del kuriu asmeniniu ambiciju fukncionalumas buvo pritemptas prie required -- jokiu pasekmiu nepajuto, nes kaltas juk tiekejas.
Tokia projektų eiga, kai viskas apkabinėjama belenkuo, yra labai tipinė. Nuolat visi prisigalvoja, kad būtų gerai turėti tą, aną, dar kažką, nes būtų gerai, o be to, ką gali žinoti -- gal ims ir prireiks, todėl geriau neužmiršti. Tada vienos fantazijos persikloja su kitomis, kūryba įsivažiuoja, projektas išauga 5-10 kartų, pagrindinis funkcionalumas pamirštamas ir gaunasi kažkoks niekam nereikalingas gargaras, kuris kuriamas krūvą metų, o naudos taip ir neatneša 🙂
Isties geras straipsnis reikia tik dabaigti skaityt 😉
Kaip programuotojui, norėtųsi ką nors čia labai protingo pasakyt. Bet kad ne, neįmanoma. Bet kokiu atveju, trečia versija geriausia, jeigu iki jos klientas su rangovu „dagyvena“. Dažniausiai nedagyvena, nes nu kur jau šitaip.
O šiaip tai čia problema elementari, nes žmogus yra toks primityvokas gyvulys, kuris gyvena realiame pasaulyje, o ne kažkokiame „softe“. Nupaišyti namą iš plytų ir jį pastatyti ir tai nelengva. O jūs pabandykite aprašyti ir „pastatyti“ kažkokį „nieką“. Gerai, jei tas programinis įsivaizduojamas menamas daiktas dar turi kokį tai „interfeisą“, lietuviškai tariant, vartotojo sąsają. O jeigu neturi, tik šiaip bitukus iš vienos pusės į kitą pilsto? Ir dar, tarkim, yra kaip nors labai sudėtingas? Nu koks normalus žmogus gali kažkokį įsivaizduojamą, menamą bitukų kratalą susikišti į galvą ir suvokti?
Geriau 3D simuliatorius.
Kad nieką pastatyti -- tai dar nieko. Bet kai jį pradėti statyti reikia nuo šviestuvų, o pabaigti sienomis, o negana to, visas tas daiktas, bestatant, nuolat kinta -- vat čia tai jau yra išties problemos.