Låt projektbeskrivningen vara facit, även när verktyget har en minnesfunktion. Vad som följer med till nästa samtal beror på verktyg, inställningar och vilket projekt eller samtal du öppnar. Om underlaget blandar stabila beslut med dagens läge får du svar som låter hjälpsamma men som redan motsäger gårdagens överenskommelse. Den enklaste lösningen är att hålla isär det som sällan ändras och det som ändras varje gång.
Minne är hjälp, inte facit
OpenAI beskriver att ChatGPT-projekt kan hämta sammanhang från chattar och filer i projektet. Google beskriver på motsvarande sätt både samtal med sparat tillstånd och samtal utan sparat tillstånd. Funktionerna skiljer sig åt och kan bero på inställningar. Prov: öppna ett nytt samtal där du tänker fortsätta arbetet och be verktyget återge appens mål, avgränsning och senaste säkra läge. Det som saknas eller blir fel ska stå tydligare i projektbeskrivningen eller nuläget.
Vad som hör hemma i projektbeskrivningen
Projektbeskrivningen är den fasta ramen. Den ska vara kort nog att du faktiskt använder den, men tydlig nog att nästa samtal förstår vad projektet är och inte är.
Det som ska stå kvar
- Vad appen gör. Prov: kan du läsa raden högt utan att nämna en teknik eller en fil?
- Vem den är till. Prov: går det att se om användaren är medlem, styrelse eller bara du själv?
- Vilka ytor som finns. Prov: kan du peka ut de få sidor eller steg som faktiskt ingår?
- Vad som uttryckligen inte ingår. Prov: om du stryker den raden blir projektet genast otydligare.
- Beslut som redan är tagna. Prov: behöver du inte ta ställning till dem igen när du läser texten i morgon?
- Språk, datumformat och andra fasta regler. Prov: går det att märka om modellen försöker byta dem utan att du bad om det?
Det viktiga provet är enkelt: om du kan läsa texten i dag och känna att den fortfarande stämmer i nästa samtal, då gör den sitt jobb. Om du redan vid läsningen känner att halva texten egentligen beskriver en ändring som håller på att hända, då är den för rörig.
Vad som inte hör hemma där
- Dagens buggar och halvfärdiga försök. Prov: om du måste skriva om raden ofta är den inte en del av projektets identitet.
- Vilken knapp som just nu är trasig. Prov: ett trasigt moment ska kunna försvinna ur nuläget utan att projektbeskrivningen blir fel.
- Nya idéer som inte är beslutade. Prov: om du fortfarande testar dem hör de inte hemma i den fasta texten.
- Namn på filer, komponenter eller andra interna detaljer. Prov: läsaren ska förstå målet utan att kunna ett enda teknikord.
Det här är den vanligaste sammanblandningen i ett långt projekt: projektbeskrivningen blir en blandning av löfte, statusrapport och önskelista. Då slutar den vara en stabil punkt och börjar i stället åldras redan medan du skriver den.
Två texter, två jobb
Den andra texten är nuläget. Den hör ihop med projektbeskrivningen, men gör ett annat jobb: den säger vad som är sant just nu och byts ut när du går vidare. Om du vill att nästa samtal ska börja rätt behöver du båda.
Skriv om den här projektbeskrivningen så att den blir kort, sann och stabil.
Behåll bara sådant som ska gälla i flera sessioner: vad appen gör, vem den är till, vilka ytor som finns, vad som inte ingår, redan fattade beslut och fasta regler för språk och form.
Ta bort allt som låter som nuläge, felrapport eller gissning om nästa steg. Ändra inte sådant som redan är fast.
Prov: läs resultatet och fråga dig om du kan klistra in samma text om en vecka utan att skämmas över att den redan blivit gammal. Om svaret är nej, har du skrivit status i stället för ram.
Här är projektbeskrivningen och nuläget. Läs båda och svara med tre saker innan du ändrar något: vad appen gör i dag, vilket beslut som fortfarande gäller, och vad som är oklart eller motsägelsefullt.
Ändra ingenting förrän jag har godkänt. Om något i underlaget krockar, peka ut det tydligt.
Prov: om modellen börjar med att rätta texten eller ställa frågor om sådant som redan står där, har den inte läst underlaget ordentligt. Då är det bättre att fixa texten än att fortsätta bygga på en oklar grund.
Ett enkelt minutprov
Det här testet tar mindre tid än att skriva en dålig omgång till. Om det inte går att göra snabbt betyder det oftast att texten försöker vara både ram och status samtidigt.
När metoden inte räcker
En stabil projektbeskrivning löser inte ett för stort projekt. Om du måste lägga till undantag och förklaringar för varje ny session är det ofta uppgiften som behöver delas upp, inte bara texten som behöver putsas.
Därför hör den här vanan ihop med två andra texter i sajten: guide 1 för den fasta projektbeskrivningen och När modellen tappar tråden för nuläget mellan samtal. Om problemet i stället är att du beställer för mycket på en gång är En sak i taget den bättre ingången.
Projektbeskrivningen säger vad projektet är. Nuläget säger vad som är sant i dag. Om båda behöver skrivas om hela tiden är projektet fortfarande för otydligt.