- Et produkt kan betjene kundene hver dag og likevel ha begynt å holde virksomheten tilbake.
- Fem spørsmål får tegnene fram: tempoet i endringene, støtten for plattformen, hvem som sitter på kunnskapen, hvordan lanseringer føles, og hva produktet ikke kan gjøre.
- Det finnes ingen poengsum. Svarene dine er starten på en beslutning som forblir din.
Et produkt sier ikke fra når det har blitt en bremse. Kundene logger fortsatt inn, og bestillingene går fortsatt gjennom. Det som endrer seg, er stillere: veikartet sklir, det samme navnet dukker opp hver gang noe vanskelig skal gjøres, og ønsker fra salg og juridisk havner i en kolonne merket «senere».
Denne sjekklisten spør ikke om du bør bygge på nytt. Den spør om tegnene er der som sier at du bør stille spørsmålet. Ta ett spørsmål om gangen og skriv ned svaret som en setning, ikke en hake. En setning tar vare på detaljene en hake kaster bort.
Tar endringer lengre tid for hvert kvartal?
Det første tegnet viser seg i kalenderen, ikke i koden.
Velg noen endringer fra det siste året av omtrent samme størrelse: et nytt felt i et skjema, en ny prisregel, en ny rapport. Tok den samme typen endring lengre tid utover i året? Spør dem som gjorde endringene, hvor tiden gikk. «Å skrive den» er et sunt svar. «Å finne ut hva annet den ville ødelegge» er et tegn. Én treg endring beviser ingenting. En trend over flere kvartaler gjør det.
Er plattformen forbi sluttdatoen for støtte?
Dette spørsmålet har en dato som svar, publisert av dem som lager plattformen: dagen de slutter å gi ut rettelser for en versjon, sikkerhetsrettelser inkludert. Utgivelsesplanen for Node.js setter for eksempel Node.js 22 i vedlikehold og oppgir 30. april 2027 som datoen da støtten tar slutt. Vår kalender over når rammeverk når slutten av sin levetid (på engelsk) samler flere slike datoer, hver lenket til kilden.
List opp hva produktet ditt kjører på, finn hver dato på den offisielle siden, og marker dem som har passert eller faller innenfor det veikartet du har nå.
Har én person kunnskap ingen andre har?
Still et enkelt spørsmål i neste planleggingsmøte: hvis denne personen var borte i en måned, hvilke endringer ville stoppe opp?
Noe kunnskap finnes bare i hodet til én person: hvorfor fakturajobben kjører to ganger, hvilken kunde som har den spesielle eksporten, hva som ikke må røres før en lansering. Så lenge den personen svarer på alle spørsmålene, lærer ingen andre svaret. Skriv ned områdene der bare ett navn dukker opp.
Gruer teamet seg til lanseringsdagen?
Lytt til hvordan teamet snakker om å sette endringer i drift.
Et team som stoler på produktet sitt, lanserer når arbeidet er klart. Et team som har brent seg på det, samler endringer i store, sjeldne lanseringer, setter dem i drift sent på kvelden og har noen i beredskap «for sikkerhets skyld». Det er ikke en svakhet ved teamet. Det er teamet som beskytter kundene mot et produkt det ikke lenger stoler på. Spør dem hva de er redde for, og skriv ned hva de sier.
Finnes det et krav produktet ikke kan oppfylle?
Det siste tegnet kommer utenfra: noe en kunde, virksomheten eller loven ber om som produktet ikke kan gi.
Det kan være en stor kunde som vil ha enkel pålogging, et marked som forventer et andre språk, eller en lov med en dato. Vi tar for oss to slike lover i essayene våre om European Accessibility Act (på engelsk) og Cyber Resilience Act (på engelsk), hver med den juridiske kilden lenket. Noter for hvert krav om produktet kan oppfylle det med arbeid på noen få steder, eller om ingen kan si hvor arbeidet ville begynne.
Hva du gjør med svarene
Les de fem setningene sammen. De er ingen poengsum, og ikke noe antall ja-svar betyr «bygg på nytt». Ett sterkt tegn kan bety mer enn tre svake.
Hvis svarene er rolige, har du en liste å holde øye med. Hvis flere peker samme vei, still neste spørsmål: endre produktet der det står, eller bygge det på nytt. Det spørsmålet har sin egen veiledning, Bygge på nytt eller refaktorere? En beslutningsguide (på engelsk), og vi gjentar den ikke her. Ingen av veiene får tegnene til å forsvinne av seg selv.
Der vi kommer inn
Hvis svarene dine leder deg mot en ny start, beskriver Bygg en eldre nettapplikasjon på nytt uten å miste det som fungerer (på engelsk) hva vi kan ta på oss. Hvis problemet mest ligger i en aldrende plattform, beskriver Kom bort fra et aldrende rammeverk uten å stoppe produktet (på engelsk) den veien.
Produktet ditt fortsetter å bevege seg framover, uke etter uke. Arbeidet havner i ditt eget kodelager. Du bestemmer hva som lanseres. Ingenting når brukerne dine uten din godkjenning.
Det starter med en samtale, helt uforpliktende.
