AI može izraditi uvjerljiv nacrt proizvoda u nekoliko minuta: popis značajki, shemu baze podataka, API rute, zaslone, pa čak i okvirni plan implementacije. Ta je brzina korisna. Ona nije odgovornost.

Teški dio izgradnje trajnog digitalnog proizvoda jest odlučiti što treba postojati, što mora ostati fleksibilno, koji rizici zaslužuju pozornost sada i tko će snositi posljedice kada prvi uredno izgledajući plan naiđe na stvarne kupce. Tehničko vodstvo počinje ondje gdje završava generirana izvjesnost.

Nacrt može ubrzati razmišljanje. Ne može zamijeniti prosudbu potrebnu da se poslovna potreba pretvori u proizvod koji i šest mjeseci kasnije ostaje razumljiv, operativan i vrijedan.

Koristite AI kao nacrt, a ne kao donositelja odluka

Arhitektura koju generira AI često izgleda cjelovito jer navodi poznate komponente: frontend, API, autentikaciju, relacijsku bazu podataka, pozadinske zadatke, nadzor i implementaciju u oblaku. Sve te komponente mogu biti prikladne. Neodgovorena pitanja važnija su.

Koji problem korisnika opravdava asinkronu obradu? Za koje je radnje potreban revizijski trag? Što se događa kada pružatelj platnih usluga istekne nakon terećenja kartice? Tko smije brisati podatke i može li se to brisanje poništiti? Kako će osoblje podrške razumjeti neuspjeli tijek rada bez traženja od inženjera da pregleda produkcijske zapisnike?

To su produktna i operativna pitanja prerušena u tehničke detalje. Tim koji prihvati nacrt bez njihova preispitivanja može brzo isporučiti proizvod, a zatim otkriti da je izgradio skup niz pretpostavki.

Bolje je polazište zatražiti od AI-ja alternative i kompromise. Zatražite da utvrdi načine kvara, navede pretpostavke i objasni što bi se promijenilo kada bi upotreba porasla, propisi postali stroži ili ovisnost o trećoj strani postala nepouzdana. Njegov odgovor tretirajte kao materijal za pregled dizajna, a ne kao sam pregled dizajna.

Arhitektura je niz obveza

Svaki tehnički izbor obvezuje proizvod na budući oblik. Neke je obveze jeftino promijeniti: oznaku gumba, internu pomoćnu funkciju, upit za izvještavanje. Druge brzo postaju skupe: modeli identiteta, vlasništvo nad podacima, javni API-ji, granice zakupaca, tijekovi plaćanja i ugovori o događajima između usluga.

Iskusni tehnički voditelji razlikuju odluke koje sada zahtijevaju preciznost od onih koje mogu ostati otvorene. Cilj nije predvidjeti svaki budući zahtjev. Cilj je izbjeći slučajno donošenje nepovratnih odluka.

Odvojite reverzibilne izbore od temeljnih

• Neka rana sučelja budu uska. Mali API oblikovan oko stvarnog tijeka rada lakše je razvijati od širokog API-ja zamišljenog prema popisu željenih značajki.
• Učinite vlasništvo eksplicitnim. Za svaki važan podatak utvrdite njegov izvor istine, tko ga smije mijenjati i na što se korisnici podataka mogu osloniti.
• Dizajnirajte za uočljiv neuspjeh. Sustav ne postaje pouzdan zato što su pogreške rijetke. Njime se može upravljati kada se neuspjesi mogu otkriti, objasniti i sigurno ponoviti.
• Dajte prednost jednostavnim granicama pred pomodnom dekompozicijom. Dobro strukturirana modularna aplikacija može ranom proizvodu služiti bolje od nekoliko usluga s distribuiranom operativnom složenošću.

Razmotrite proizvod koji voditeljima omogućuje odobravanje troškova zaposlenika. Generirani plan može predložiti zasebne usluge za račune, odobrenja, obavijesti, izvještavanje i korisnike. Prije njihova stvaranja utvrdite temeljno pravilo: kada je trošak odobren, tko ga odobrava i koji to zapis dokazuje? Ako isporuka obavijesti ne uspije, status odobrenja i dalje treba biti ispravan. Ako voditelj odobri dvaput, sustav ne bi smio dvaput izvršiti povrat troška. Ta pravila oblikuju koherentan dizajn učinkovitije od dijagrama punog okvira.

Uključite produktno razmišljanje u inženjerstvo

Razvojni inženjeri najbolje rade kada razumiju posljedicu značajke, a ne samo opis zadatka. „Dodajte gumb za izvoz” zahtjev je. „Omogućite financijama usklađivanje odobrenih troškova bez ručnog kopiranja podataka” opis je problema. Potonje potiče bolja pitanja o formatima, dozvolama, potpunosti podataka, performansama i podršci.

Produktno razmišljanje ne znači da svaki inženjer mora postati produktni menadžer. Znači da tehnički rad treba ostati povezan sa zadatkom korisnika i poslovnim ishodom. Ta povezanost pomaže timovima da bolje uoče lažne prečace.

Na primjer, zahtjev za ažuriranjima u stvarnom vremenu zapravo može značiti da korisnici nisu sigurni je li njihova radnja uspjela. Veza uživo mogla bi riješiti taj problem, ali mogu ga riješiti i jasno stanje potvrde, vremenska crta aktivnosti i predvidljivo ponašanje osvježavanja. Jednostavnije rješenje može biti otpornije i lakše za podržavanje.

Udaljenim timovima potrebna je pisana inženjerska prosudba

U radu na daljinu pretpostavke putuju dalje od razgovora. Odluka donesena na sastanku može nestati za ljude u drugoj vremenskoj zoni, kolegu usmjerenog na isporuku ili osobu koja se projektu pridruži kasnije. Dokumentacija nije birokracija kada čuva kontekst koji bi se inače izgubio.

Korisni pisani artefakti mali su i konkretni: kratki zapis odluke, definicija dovršenosti, API ugovor, operativni priručnik za poznati operativni zadatak ili bilješka koja objašnjava zašto je prečac bio prihvatljiv. Najbolji dokumenti odgovaraju na praktična pitanja bez potrebe da čitatelji rekonstruiraju argument iz povijesti razgovora.

Jednostavan zapis odluke može sadržavati:

• problem koji se rješava;
• odluku i razmotrene alternative;
• pretpostavke koje stoje iza nje;
• posljedice, uključujući ono čemu će se tim kasnije morati ponovno posvetiti.

Ta navika također poboljšava upotrebu AI-ja. Kada tim ima jasna ograničenja i odluke, može sigurnije koristiti generirani rezultat. Upit se temelji na stvarnom kontekstu proizvoda, a ne na općem tehničkom rječniku.

Izgradite sustave isporuke koji mogu održati pažnju

Održiva isporuka nije spora isporuka. To je isporuka koja ne zahtijeva herojstvo da bi se ponovila. Timovima je potrebno dovoljno automatizacije i discipline da s pouzdanjem objavljuju izdanja, uče iz produkcije i oporave se kada se nešto pokvari.

To obično znači male promjene, pull zahtjeve koji se mogu pregledati, automatizirane provjere razmjerne riziku i postupak implementacije koji omogućuje vraćanje prethodne verzije ili ublažavanje problema. To također znači zaštititi vrijeme za održavanje. Ignoriranje ažuriranja ovisnosti, nejasnog vlasništva, krhkih testova i bučnih upozorenja ne uklanja posao; samo prenosi trošak u hitniji trenutak.

Tehnički voditelji trebaju to učiniti vidljivim u planiranju. Rad na pouzdanosti nije odvojen od rada na proizvodu kada nepouzdan proizvod ometa korisnike. Ni refaktoriranje nije automatski vrijedno; prioritet zaslužuje kada smanjuje konkretan rizik za isporuku, ispravnost ili rad sustava.

Vlasništvo je trajna prednost

Najvrjedniji razvojni inženjeri neće biti oni koji mogu generirati najviše koda. Bit će to ljudi koji mogu oblikovati problem, osporiti privlačnu, ali slabu pretpostavku, odabrati prikladnu razinu složenosti i pomoći timu da uči iz rezultata.

AI može proširiti mogućnosti tima. Vlasništvo tim mogućnostima daje smjer. Ono pretvara generirani nacrt u proizvod kojem korisnici mogu vjerovati, koji kolege mogu mijenjati i na kojem poslovanje može nastaviti graditi.

To je budućnost vrijedna arhitektonskog oblikovanja: ne sustav koji se prvog dana čini dovršenim, nego onaj čije odluke ostaju razumljive, čiji su neuspjesi preživljivi i čiji ljudi ostaju sposobni unapređivati ga.