Hva et byrå bør forberede før overlevering av utvikling.

En god utviklingsavlevering krever ikke at byrået blir en programvarekonsulent. Det krever en klar forklaring på klientresultatet, arbeidet som blir utnevnt og avgjørelsene som forblir hos byrået.

Målet er å gjøre ansvaret synlig. En utvikler bør ikke måtte gjette om en manglende skjerm, en integrasjon eller en sen klientforespørsel er en del av det avtalte engasjementet.

Beskriv kunderesultatet før teknologien

Forklar hva klienten prøver å levere og hvem som vil bruke det. \"Implementer disse designene\" kan være en del av oppgaven, men det forklarer ikke hva programmet må oppnå.

Et illustrativt kort kan for eksempel være: \"Opprett en partnerportal der godkjente partnere sender inn forespørsler og kundens ansatte gjennomgår dem. Agenturet leverer grensesnittets design og konsoliderer klientens tilbakemelding.\" Dette gir prosjektet en brukerreise og en ansvarsfordeling.

Det er et eksempel, ikke en referanse til en eksisterende klient engasjement.

Definer utviklerens grense

Oppgi om kommisjonen dekker en fullstendig søknad, en frontend implementering, en backend-komponent eller en integrasjon. Oppgi deler som vil bli levert av byrået eller en annen part.

En delvis bygg trenger klare integrasjonspunkter. Hvem tilbyr API? Hvem eier den endelige distribusjonen? Hvem tester det kombinerte resultatet? Uten disse svarene kan en liten komponent skaffe seg et mye større underforstått ansvar.

Gi designbeslutningene, inkludert stater

Leveres design bør identifisere tiltenkt skrivebords- og mobiladferd og viktige tilstander på skjermen. Tomt innhold, valideringsfeil, lastings- og fullføringstilstander alle trenger et svar.

Når byrået ikke har designet en stat, merke det som en beslutning å løse. Det er bedre enn å forlate utvikleren for å oppfinne atferd og oppdage senere at klienten forventet noe annet.

Identifiser hvilke eiendeler og tekst som er godkjent, og som er foreløpig. Utviklingsmiljøet bør ikke gjøre en plassholder til å ligne godkjent kundevendt kopi.

Opprette gjennomgangs- og kommunikasjonsveien

Navngjev en person som konsoliderer tilbakemeldinger for byrået. Forklar om utvikleren vil delta på kundemøter, svare på spørsmål gjennom byrået eller delta bare i avtalte tekniske diskusjoner.

Sett ut hvem som kan godkjenne en endring. En klientidé, et byråpreferanser og et kontraktskrav er ikke automatisk det samme. Å holde en beslutningsliste hjelper alle å forstå hva som faktisk har gått inn i omfanget.

En hvitmerket ordning trenger også praktiske regler: møte introduksjoner, tilgang, merkevare på leveranser og tillatelse til å nevne prosjektet offentlig. Disse punktene tilhører i avtalen i stedet for i antagelser.

Del avhengigheter uten å dele hemmeligheter uforsiktig

Liste over relevante systemer, dokumentasjon, hosting ordninger, arkiver og tredjepartskontoer. Forklar hvem som eier dem og hvor relevant tilgang vil bli gitt.

Ikke plasser passord eller API-hemmeligheter i et generelt prosjekt kort eller vanlig spørreskjema. Bruk en avtalt sikker kanal og begrense tilgang til hva oppgaven trenger.

For integrasjoner, inkludert tilgjengelige testkontoer, prøve nyttelaster uten private data og en kontakt for forretningsregler spørsmål. En API-lenke alene forklarer ikke hva klienten forventer tilkoblingen å oppnå.

Gjør aksept betong

Beskriv hva byrået vil gjennomgå på hver milepæl. Et nyttig aksepteksempel angir en handling og et resultat: en partner sender en forespørsel, personalet kan gjennomgå den og partneren ser den avtalte statusen.

Enighet om hvordan problemer vil bli registrert, hvordan tilbakemeldinger er konsolidert og hvordan endringer utenfor omfang håndteres. Formålet er ikke å gjøre revisjoner vanskelig. Det er å skille ut å fullføre den lovede funksjonen fra idriftsettelse av en ny.

Definer leveringspakken

Den avtalte overleveringen kan inneholde kode, utplasseringsnotater, konfigurasjonsinformasjon, administrasjonsveiledning og en liste over avhengigheter. Eierskaps- og lisensvilkår avgjør hva som kan overføres eller gjenbrukes; ikke oppgir dem fra tilgang til et arkiv alene.

Separat aksept, en avtalt feilrettelsesperiode og enhver fremtidig utvikling. Et fullført prosjekt bør ikke stille gjøres til ubegrenset teknisk tilgjengelighet for byrået eller dets klient.

En nyttig første melding

Gi det tiltenkte resultatet, den delen du vil utvikle, designstatus, de kjente integrasjonene, ønsket leveringsvindu og alle budsjettparametre. Deretter navngi beslutningstakeren og foretrukne kommunikasjonsarrangement.

Det er nok til å starte en fokusert samtale. Det detaljerte omfanget kan bli avtalt når de viktige grensene er forstått.

Utforsk byråutviklingspartnerskap eller Send et byrå kort.