Kort beskrivelse af agenturets udvikling
Hvad et agentur skal forberede, før du afleverer udvikling.
Et agentur guide til at forberede en udvikling overdragelse: kunderesultat, design, omfang, godkendelser, afhængigheder, kommercielle ansvar og accept.
En god udvikling overdragelse kræver ikke, at agenturet bliver en software rådgivning. Det kræver en klar forklaring af kundens resultat, det arbejde, der er bestilt, og de beslutninger, der forbliver i agenturet.
Målet er at gøre ansvaret synligt. En udvikler bør ikke være nødt til at gætte, om en manglende skærm, en integration eller en forsinket klient anmodning er en del af den aftalte engagement.
Beskriv klientresultatet før teknologien
Forklar, hvad klienten forsøger at levere, og hvem der vil bruge det. "Implementere disse designs" kan være en del af opgaven, men det forklarer ikke, hvad programmet skal udføre.
For eksempel kan en illustrativ briefing være: "Opret en partnerportal, hvor godkendte partnere indgiver anmodninger, og kundens personale gennemgår dem. Agenturet leverer grænsefladen designs og konsoliderer kundens feedback". Dette giver projektet en brugerrejse og en ansvarsfordeling.
Det er et eksempel, ikke en henvisning til et eksisterende kundeengagement.
Definer udviklerens grænse
Angiv, om Kommissionen dækker en fuldstændig ansøgning, en frontend implementering, en backend komponent eller en integration. Navn de dele, der vil blive leveret af agenturet eller en anden part.
En delvis build har brug for klare integrationspunkter. Hvem leverer API? Hvem ejer den endelige implementering? Hvem tester det kombinerede resultat? Uden disse svar, kan en lille komponent erhverve et langt større implicit ansvar.
Angiv designbeslutninger, herunder stater
Medfølgende design bør identificere den tilsigtede desktop og mobil adfærd og de vigtige tilstande på en skærm. Tomt indhold, valideringsfejl, lastning og afslutning stater alle har brug for et svar.
Hvor agenturet ikke har designet en stat, markere det som en beslutning om at løse. Det er bedre end at overlade udvikleren til at opfinde adfærd og opdage senere, at kunden forventede noget andet.
Identificer hvilke aktiver og tekst der er godkendt, og hvilke der er foreløbige. Udviklingsmiljøet bør ikke få en pladsholder til at ligne godkendt customer-vender kopi.
Etablere revisions- og kommunikationsvejen
Nævn en person, der konsoliderer feedback til agenturet. Forklar, om udvikleren vil deltage i klientmøder, besvare spørgsmål gennem agenturet eller kun deltage i aftalte tekniske diskussioner.
Sæt ud hvem kan godkende en ændring. En klient idé, et agentur præference og et kontraktkrav er ikke automatisk det samme. Holde en beslutning rekord hjælper alle forstå, hvad der faktisk er kommet ind i anvendelsesområdet.
En white- label ordning har også brug for praktiske regler: møde introduktioner, adgang, branding på leverancer og tilladelse til at nævne projektet offentligt. Disse punkter hører til i aftalen snarere end i antagelser.
Del afhængigheder uden at dele hemmeligheder skødesløst
Angiv de relevante systemer, dokumentation, værtsordninger, datalagre og tredjepartskonti. Forklar, hvem der ejer dem, og hvordan passende adgang vil blive givet.
Må ikke placere adgangskoder eller API hemmeligheder i et generelt projekt kort eller almindelig forespørgsel formular. Brug en aftalt sikker kanal og begrænse adgangen til, hvad opgaven har brug for.
For Integrationer, omfatte tilgængelige testkonti, prøve nyttelast uden private data og en kontakt for business-regel spørgsmål. En API-link alene forklarer ikke, hvad kunden forventer forbindelsen til at opnå.
Gør accept konkret
Beskriv, hvad agenturet vil gennemgå ved hver milepæl. Et nyttigt accepteksempel angiver en handling og et resultat: en partner indgiver en anmodning, personale kan gennemgå det, og partneren ser den aftalte status.
Enig hvordan spørgsmål vil blive registreret, hvordan feedback er konsolideret, og hvordan ændringer uden for anvendelsesområdet håndteres. Formålet er ikke at gøre revisioner vanskelige. Det er at skelne udfylde den lovede funktion fra idriftsættelse af en ny.
Definer leveringspakken
Den aftalte overdragelse kan indeholde kode, implementeringsnoter, konfigurationsoplysninger, administrationsvejledning og en liste over afhængigheder. Ejerskab og licensvilkår afgør, hvad der kan overføres eller genbruges; afleder dem ikke fra adgang til et arkiv alene.
Separat accept, en aftalt aftrækker- korrektion periode og enhver fremtidig udvikling. Et afsluttet projekt bør ikke stille og roligt blive til ubegrænset teknisk tilgængelighed for agenturet eller dets klient.
En nyttig første meddelelse
Giv det ønskede resultat, den del, du ønsker udviklet, designstatus, de kendte integreringer, det ønskede leveringsvindue og eventuelle budgetparametre. Derefter navngiv beslutningstageren og foretrukne kommunikation arrangement.
Det er nok til at starte en fokuseret samtale. Det detaljerede omfang kan aftales, når de vigtige grænser er forstået.
Udforske agenturudviklingspartnerskaber eller sende et agentur brief.