Când un proiect software dezamăgește, analiza de după se uită de obicei la livrare. Estimări, ritm, scope creep, echipă. Ocazional, asta chiar e povestea.
Mai des, proiectul a fost decis cu luni în urmă, în câteva conversații pe care nimeni nu le-a considerat tehnice.
Scop scris ca listă de funcționalități, nu ca rezultat
O specificație care enumeră ce va conține sistemul nu poate fi folosită ca să decizi ce tai. Iar orice proiect ajunge la un moment dat să taie ceva.
O specificație scrisă ca rezultat poate. „Reducem timpul de la cerere la ofertă" îi spune echipei ce să protejeze când se strânge programul. „Un configurator de oferte cu șabloane și export PDF" nu.
Cea mai riscantă presupunere, programată ultima
Orice proiect stă pe ceva ce nimeni nu a verificat. Datele sunt mai curate decât a verificat cineva. API-ul extern face ce zice documentația. Utilizatorii vor accepta fluxul nou. Migrarea durează o săptămână.
Instinctul natural e să construiești întâi părțile familiare, pentru că produc progres vizibil. Consecința e că presupunerea care poate scufunda proiectul e testată exact când nu mai există buget de reacție.
Găsește presupunerea care ar durea cel mai tare dacă ar fi greșită și testeaz-o în prima săptămână — fie și grosier.
Arhitectură aleasă din familiaritate
Unele decizii sunt ieftin de schimbat, altele nu. Ce bază de date, ce model de randare, unde stau granițele dintre servicii, cum funcționează multi-tenancy, cum funcționează identitatea: astea sunt cele scumpe.
Merită o oră de argumentat deliberat și un paragraf de raționament scris. De obicei nu primesc niciuna, pentru că răspunsul i s-a părut evident celui care era în cameră.
Nicio definiție agreată a succesului
Dacă nimeni nu a scris ce trebuie să realizeze versiunea unu, atunci versiunea unu nu poate reuși. Poate doar să fie livrată și apoi judecată față de ce a așteptat fiecare, în gând.
O propoziție, agreată înainte să înceapă construcția, previne o cantitate enormă de dezamăgire ulterioară. E și cel mai ieftin artefact din tot proiectul.
Tiparul
Niciuna dintre ele nu e o eroare de inginerie. Sunt decizii luate rapid, de oameni rezonabili, într-un moment în care nu păreau să conteze.
Exact de asta o fază scurtă și deliberată înainte de dezvoltare se plătește singură — nu ca livrabil, ci ca momentul în care cele patru întrebări sunt puse cu voce tare.
