Nuo neaiškios problemos iki veikiančio sprendimo.
Nebūtina ateiti su paruošta technine užduotimi ar žinoti, kokios technologijos reikia.
Man svarbiau suprasti, kaip procesas vyksta dabar, kur jis stringa ir kokio rezultato reikia. Techninis sprendimas atsiranda tik tada, kai aiški pati problema.
Prieš pradedant
Techninės užduoties paruošti nereikia.
Dažniausiai pakanka papasakoti, kas vyksta dabar ir ką norėtumėte pakeisti.
Tai gali būti procesas, kurį komanda nuolat kartoja rankiniu būdu, kelios nesusikalbančios sistemos, sudėtinga metodika, Excel skaičiavimas ar idėja individualiam AI įrankiui.
Pirmiausia išsiaiškiname problemą. Tik tada sprendžiame, ar jai reikia individualaus programavimo, integracijos, nedidelės automatizacijos, ar galbūt gerokai paprastesnio sprendimo.
Darbo eiga
Penki projekto etapai
Situacijos analizė
Pirmiausia išsiaiškiname, kaip procesas veikia dabar ir ką iš tikrųjų reikia pakeisti.
Aptariame dabartinę darbo eigą, naudojamas sistemas, duomenis, pasikartojančius veiksmus ir išimtis. Jei turite realių failų, dokumentų ar proceso pavyzdžių, šiame etape jie ypač naudingi.
- Kaip procesas vyksta šiandien?
- Kur daugiausia rankinio darbo, klaidų ar laukimo?
- Kokios sistemos ir duomenys jau naudojami?
- Koks rezultatas reikštų, kad problema išspręsta?
Aiškiai apibrėžta problema, poreikis ir ribos, kuriose verta ieškoti sprendimo.
Sprendimo projektavimas
Kai aišku, ką reikia išspręsti, ieškau paprasčiausio prasmingo techninio kelio.
Įvertinu jau naudojamų sistemų galimybes, integracijas, API, duomenų struktūrą ir verslo taisykles. Jei esamą aplinką galima išlaikyti, nereikia jos keisti vien todėl, kad kitą sprendimą būtų patogiau programuoti.
- Apibrėžiama būsimo sprendimo logika.
- Pasirenkamas tinkamas techninis įgyvendinimas.
- Nustatoma, kokių integracijų ir prieigų reikės.
- Sutariama projekto apimtis ir pagrindinės funkcijos.
Aišku, ką kuriame, kaip sprendimas veiks ir kokia projekto apimtis.
Kūrimas ir testavimas
Sprendimą kuriu etapais ir tikrinu ne tik tai, ar kodas veikia, bet ir ar teisingai atkartojamas realus procesas.
Testavimui naudoju realistiškus duomenis ir situacijas. Ypač svarbios išimtys: kas vyksta, jei duomenų trūksta, jie pateikti kitaip nei įprasta arba viena iš sistemų grąžina netikėtą rezultatą.
- Kuriamos pagrindinės funkcijos ir integracijos.
- Tikrinama verslo logika ir skaičiavimai.
- Testuojami realūs ir nestandartiniai scenarijai.
- Pagal testų rezultatus koreguojamas sprendimas.
Veikianti ir ištestuota sprendimo versija, paruošta naudoti realiame procese.
Paleidimas
Sprendimas pereina iš testinės aplinkos į realų procesą.
Sukonfigūruojamos reikalingos prieigos ir integracijos, patikrinamas veikimas realioje aplinkoje ir, jei sprendimu naudosis komanda, paaiškinama, kaip jis veikia.
- Sprendimas prijungiamas prie realių sistemų.
- Patikrinamas veikimas su realiais duomenimis.
- Perduodama naudojimui reikalinga informacija.
- Stebimas pirmasis realus proceso vykdymas.
Sprendimas naudojamas ten, kur anksčiau vyko rankinis ar kitaip neefektyvus procesas.
Priežiūra ir tobulinimas
Tik pradėjus sprendimą naudoti kasdien paaiškėja, kaip jis elgiasi visose realiose situacijose.
Po paleidimo skiriamas laikas realiam naudojimui, grįžtamajam ryšiui ir reikalingoms korekcijoms. Ištaisomos su sutartu funkcionalumu susijusios klaidos, o atsiradus naujiems poreikiams galima planuoti tolesnį sprendimo vystymą.
- Surenkamas realių naudotojų grįžtamasis ryšys.
- Atliekamos reikalingos korekcijos.
- Jei procesas keičiasi, sprendimą galima pritaikyti.
- Naujos funkcijos vertinamos kaip tolimesnis projekto etapas.
Ne tik perduotas kodas, o realiame darbe naudojamas ir prireikus toliau vystomas sprendimas.
Ko reikės iš jūsų
Geras sprendimas priklauso ir nuo gero konteksto.
Parodyti, kaip dirbate dabar
Nebūtina graži proceso schema. Dažnai realus pavyzdys daug naudingesnis už formalų aprašymą.
Pateikti realistiškų pavyzdžių
Failai, įrašai, skaičiavimo pavyzdžiai ar tipinės situacijos padeda patikrinti, ar logika atitinka realų darbą.
Paaiškinti išimtis
Automatizuojant svarbu žinoti ne tik įprastą scenarijų, bet ir tai, kas nutinka nestandartinėse situacijose.
Išbandyti sprendimą
Jūs geriausiai pažįstate savo procesą, todėl testavimo metu svarbus grįžtamasis ryšys apie tai, kaip sprendimas veikia praktiškai.
Svarbus principas
Jei problemą galima išspręsti paprasčiau, nereikia kurti didesnės sistemos.
Individualus programavimas nėra savaiminis tikslas.
Kartais projekto analizės metu paaiškėja, kad užtenka nedidelės automatizacijos, jau naudojamos sistemos funkcijos arba paprastesnės integracijos.
Lygiai taip pat AI naudoju tik ten, kur jis iš tiesų reikalingas. Jei procesą patikimiau galima aprašyti aiškiomis taisyklėmis, nėra priežasties jo komplikuoti generatyviniu AI.
Nuo ko pradėti?
Pradėkime nuo problemos, ne nuo techninės užduoties.
Papasakokite, kaip procesas vyksta dabar, kas jame užima daugiausia laiko arba ko trūksta jūsų naudojamose sistemose. Įvertinsiu situaciją ir pasiūlysiu, koks sprendimas būtų prasmingas.