Wat een agentschap moet voorbereiden voordat ze de ontwikkeling overdragen.

Een goede ontwikkeling handoff vereist niet dat het agentschap een software consultancy. Het vereist een duidelijke uitleg van de klant resultaat, het werk wordt in opdracht en de beslissingen die blijven bij het agentschap.

Het doel is om verantwoordelijkheid zichtbaar te maken. Een ontwikkelaar mag niet hoeven te raden of een ontbrekend scherm, een integratie of een verzoek van een late klant deel uitmaakt van de overeengekomen opdracht.

Beschrijf het resultaat van de klant vóór de technologie

Leg uit wat de klant probeert te leveren en wie zal het gebruiken. .Implementeren deze ontwerpen kan deel uitmaken van de taak, maar het niet uitleggen wat de toepassing moet bereiken.

Bijvoorbeeld, een illustratieve opdracht zou kunnen zijn: Een partnerportaal maken waar goedgekeurde partners verzoeken indienen en de medewerkers van de klant beoordelen. Het agentschap levert de interface ontwerpt en consolideert de feedback van de klant.

Het is een voorbeeld, geen verwijzing naar een bestaande klant engagement.

Grens van de ontwikkelaar definiëren

Geef aan of de opdracht betrekking heeft op een volledige aanvraag, een frontend implementatie, een backend component of een integratie. Noem de onderdelen die door het agentschap of een andere partij worden geleverd.

Een gedeeltelijke opbouw heeft duidelijke integratiepunten nodig. Wie levert de API? Wie bezit de uiteindelijke implementatie? Wie test het gecombineerde resultaat? Zonder die antwoorden kan een klein onderdeel een veel grotere impliciete verantwoordelijkheid verwerven.

De ontwerpbesluiten verstrekken, met inbegrip van de staten

Toegepaste ontwerpen moeten het beoogde desktop- en mobiele gedrag en de belangrijke toestanden van een scherm identificeren. Lege inhoud, validatiefouten, laden en voltooiingstoestanden hebben allemaal een antwoord nodig.

Wanneer het agentschap geen staat heeft ontworpen, markeer het als een beslissing om op te lossen. Dat is beter dan de ontwikkelaar om gedrag uit te vinden en later te ontdekken dat de klant iets anders verwachtte.

Identificeer welke activa en tekst zijn goedgekeurd en welke voorlopig zijn. De ontwikkelingsomgeving mag een plaatshouder niet laten lijken op een goedgekeurde klantgerichte kopie.

Vaststelling van het evaluatie- en communicatietraject

Noem één persoon die de feedback voor het agentschap consolideert. Leg uit of de ontwikkelaar klantvergaderingen zal bijwonen, vragen via het agentschap zal beantwoorden of alleen zal deelnemen aan overeengekomen technische discussies.

Stel uit wie een wijziging kan goedkeuren. Een klant idee, een agentschap voorkeur en een contractuele eis zijn niet automatisch hetzelfde ding. Het bijhouden van een beslissing record helpt iedereen te begrijpen wat daadwerkelijk is ingevoerd de scope.

Een white-label regeling heeft ook praktische regels nodig: meeting introducties, toegang, branding op deliverables en toestemming om het project publiekelijk te vermelden.

Deel afhankelijkheden zonder geheimen onzorgvuldig te delen

Vermeld de relevante systemen, documentatie, hostingregelingen, repositories en derdenaccounts. Leg uit wie de accounts bezit en hoe de juiste toegang wordt geboden.

Plaats geen wachtwoorden of API-geheimen in een algemeen project kort of gewoon aanvraagformulier. Gebruik een overeengekomen beveiligd kanaal en beperkt de toegang tot wat de taak nodig heeft.

Voor integraties, omvatten beschikbare testaccounts, monsterladingen zonder privégegevens en een contact voor zakelijke-regelvragen. Een API link alleen niet uitleggen wat de klant verwacht dat de verbinding te bereiken.

Acceptatie concreet maken

Beschrijf wat het agentschap zal beoordelen bij elke mijlpaal. Een nuttig acceptatievoorbeeld geeft een actie en een resultaat: een partner dient een verzoek in, personeel kan het beoordelen en de partner ziet de overeengekomen status.

Mee eens hoe problemen worden opgenomen, hoe feedback wordt geconsolideerd en hoe veranderingen buiten het toepassingsgebied worden behandeld. Het doel is niet om herzieningen moeilijk te maken. Het is om te onderscheiden het voltooien van de beloofde functie van het ingebruik nemen van een nieuwe.

Definieer het leveringspakket

De overeengekomen overdracht kan code, implementatie notes, configuratie-informatie, administratieve begeleiding en een lijst van afhankelijkheden bevatten. Eigendoms- en licentievoorwaarden bepalen wat kan worden overgedragen of hergebruikt; leiden ze niet af van toegang tot een repository alleen.

Aparte acceptatie, een overeengekomen foutcorrectieperiode en eventuele toekomstige ontwikkeling. Een voltooid project mag niet stilletjes veranderen in onbeperkte technische beschikbaarheid voor het agentschap of zijn opdrachtgever.

Een nuttig eerste bericht

Geef het beoogde resultaat, het deel dat u wilt ontwikkelen, de ontwerpstatus, de bekende integraties, het gewenste leveringsvenster en eventuele budgetparameters. Noem dan de besluitvormer en de voorkeurs communicatie regeling.

Dat is genoeg om een gericht gesprek te beginnen. De gedetailleerde reikwijdte kan worden overeengekomen zodra de belangrijke grenzen worden begrepen.

Ontdek ontwikkelingspartnerschappen van agentschappen of stuur een brief van het agentschap.