Vad en byrå bör förbereda innan du lämnar över utvecklingen.

En bra utvecklingshandoff kräver inte att byrån blir en mjukvarukonsult. Det kräver en tydlig förklaring av kundresultatet, det arbete som beställs och de beslut som finns kvar hos byrån.

Målet är att synliggöra ansvaret. En utvecklare ska inte behöva gissa om en saknad skärm, en integration eller en sen kundförfrågan är en del av det överenskomna engagemanget.

Beskriv kundresultatet innan tekniken

Förklara vad klienten försöker leverera och vem som kommer att använda den. "Avsluta dessa mönster" kan vara en del av uppgiften, men det förklarar inte vad programmet måste åstadkomma.

Till exempel kan en illustrativ kort vara: "Skapa en partnerportal där godkända partners skickar in förfrågningar och klientens personal granskar dem. Byrån levererar gränssnittet designar och konsoliderar klientåterkoppling." Detta ger projektet en användarresa och en ansvarsfördelning.

Det är ett exempel, inte en hänvisning till ett befintligt kundengagemang.

definiera utvecklarens gräns

Ange om kommissionen omfattar en komplett ansökan, en frontend-implementering, en backend-komponent eller en integration. Namnge de delar som kommer att levereras av byrån eller en annan part.

En partiell byggnad behöver tydliga integrationspunkter. Vem ger API? Vem äger den slutliga utplaceringen? Vem testar det kombinerade resultatet? Utan dessa svar kan en liten komponent få ett mycket större underförstått ansvar.

Ge designbesluten, inklusive stater

Tillhandahållna mönster bör identifiera det avsedda skrivbordet och det mobila beteendet och de viktiga tillstånden på en skärm. Tomma innehåll, valideringsfel, laddning och slutförande stater alla behöver ett svar.

Om byrån inte har utformat ett tillstånd, markera det som ett beslut att lösa. Det är bättre än att låta utvecklaren uppfinna beteende och upptäcka senare att kunden förväntade sig något annorlunda.

Identifiera vilka tillgångar och texter som är godkända och som är provisoriska. Utvecklingsmiljön bör inte göra en platshållare ser ut som godkänd kundanpassad kopia.

Etablera gransknings- och kommunikationsvägen

Namnge en person som konsoliderar feedback för byrån. Förklara om utvecklaren kommer att delta i kundmöten, svara på frågor via byrån eller delta endast i överenskomna tekniska diskussioner.

Ange vem som kan godkänna en förändring. En kundidé, en byråpreferens och ett avtalskrav är inte automatiskt samma sak. Att hålla ett beslutsrekord hjälper alla att förstå vad som faktiskt har gått in i omfattningen.

Ett vitmärkesarrangemang behöver också praktiska regler: mötesintroduktioner, tillgång, branding på leveranser och tillstånd att nämna projektet offentligt. Dessa punkter hör hemma i avtalet snarare än i antaganden.

Dela beroenden utan att dela hemligheter slarvigt

Lista relevanta system, dokumentation, hosting arrangemang, repositorier och tredjepartskonton. Förklara vem som äger dem och hur lämplig åtkomst kommer att tillhandahållas.

Placera inte lösenord eller API-hemligheter i ett allmänt projekt kort eller vanligt förfrågningsformulär. Använd en överenskommen säker kanal och begränsa tillgången till vad uppgiften behöver.

För integrationer, inkludera tillgängliga testkonton, provbelastningar utan privata data och en kontakt för affärsregelfrågor. En API-länk ensam förklarar inte vad kunden förväntar sig att anslutningen ska uppnå.

Gör acceptans konkret

Beskriv vad byrån kommer att granska på varje milstolpe. Ett användbart godkännande exempel anger en åtgärd och ett resultat: en partner lämnar in en begäran, personal kan granska den och partnern ser den överenskomna statusen.

Håller med om hur frågor kommer att spelas in, hur återkopplingen konsolideras och hur förändringar utanför räckvidden hanteras. Syftet är inte att göra revideringar svårt. Det är att skilja att slutföra den utlovade funktionen från att beställa en ny.

Definiera leveranspaketet

Den överenskomna överlämningen kan innehålla kod, utplaceringsanteckningar, konfigurationsinformation, administrationsvägledning och en förteckning över beroenden. Ägar- och licensvillkor avgör vad som kan överföras eller återanvändas; dra inte av dem från tillgång till ett förvar ensam.

Separat acceptans, en överenskommen felkorrigeringsperiod och eventuell framtida utveckling. Ett slutfört projekt bör inte tyst förvandlas till obegränsad teknisk tillgänglighet för byrån eller dess klient.

Ett användbart första meddelande

Ge det avsedda resultatet, den del du vill ha utvecklat, designstatusen, de kända integrationerna, det önskade leveransfönstret och eventuella budgetparametrar. Sedan namnge beslutsfattaren och föredragna kommunikationsarrangemang.

Det räcker med att inleda en fokuserad konversation. Den detaljerade omfattningen kan överenskommas när de viktiga gränserna förstås.

Utforska partnerskap för byråutveckling eller Skicka en byrå kort.