Ce qu'une agence devrait préparer avant de livrer le développement.

Un bon transfert de développement n'exige pas de l'agence qu'elle devienne un consultant logiciel, mais qu'elle explique clairement le résultat du client, le travail commandé et les décisions qui restent à l'agence.

Le but est de rendre la responsabilité visible. Un développeur ne devrait pas avoir à deviner si un écran manquant, une intégration ou une demande tardive de client fait partie de l'engagement convenu.

Décrivez le résultat du client avant la technologie

Expliquez ce que le client essaie de livrer et qui l'utilisera. L'application de ces modèles peut faire partie de la tâche, mais elle n'explique pas ce que l'application doit accomplir.

Par exemple, un mémoire illustratif pourrait être : -Créer un portail de partenaires où les partenaires approuvés soumettent des demandes et le personnel du client les examine. L'agence fournit l'interface conçoit et consolide la rétroaction du client.

Il s'agit d'un exemple, et non d'une référence à un engagement client existant.

Définir la limite du développeur

Indiquer si la commission couvre une demande complète, une mise en œuvre frontale, un élément moteur ou une intégration. Nommer les pièces qui seront fournies par l'agence ou une autre partie.

Une construction partielle nécessite des points d'intégration clairs. Qui fournit l'API? Qui possède le déploiement final? Qui teste le résultat combiné? Sans ces réponses, un petit composant peut acquérir une responsabilité implicite beaucoup plus grande.

Fournir les décisions de conception, y compris les États

Les modèles fournis devraient identifier le comportement prévu du bureau et du mobile et les états importants d'un écran. Le contenu vide, les erreurs de validation, les états de chargement et d'achèvement ont tous besoin d'une réponse.

Lorsque l'agence n'a pas conçu d'État, marquez-le comme une décision à résoudre. C'est mieux que de laisser le développeur inventer un comportement et découvrir plus tard que le client attendait quelque chose de différent.

Identifiez les actifs et le texte qui sont approuvés et qui sont provisoires. L'environnement de développement ne devrait pas faire en sorte qu'un détenteur de place ressemble à une copie de client approuvée.

Établir la voie d'examen et de communication

Nommez une personne qui consolide les commentaires pour l'organisme. Expliquez si le promoteur assistera aux réunions des clients, répondra aux questions de l'organisme ou ne participera qu'aux discussions techniques convenues.

Définir qui peut approuver un changement. Une idée de client, une préférence d'agence et une exigence contractuelle ne sont pas automatiquement la même chose.

Un accord sur l'étiquette blanche nécessite également des règles pratiques : l'introduction, l'accès, l'image de marque des produits livrables et l'autorisation de mentionner le projet publiquement.

Partager les dépendances sans partager les secrets sans souci

Énumérez les systèmes, la documentation, les arrangements d'hébergement, les dépôts et les comptes de tiers pertinents. Expliquez qui en est propriétaire et comment un accès approprié sera fourni.

Ne placez pas les mots de passe ou les secrets d'API dans un résumé général de projet ou un formulaire de demande ordinaire. Utilisez un canal sécurisé convenu et limitez l'accès à ce dont la tâche a besoin.

Pour les intégrations, inclure les comptes de test disponibles, des exemples de charges utiles sans données privées et un contact pour les questions de règles d'affaires.

Faire en sorte que l'acceptation soit concrète

Décrivez ce que l'organisme examinera à chaque étape. Un exemple d'acceptation utile indique une action et un résultat : un partenaire soumet une demande, le personnel peut l'examiner et le partenaire voit le statut convenu.

Convenir de la façon dont les questions seront enregistrées, de la façon dont la rétroaction est consolidée et de la façon dont les changements en dehors de la portée sont traités. L'objectif n'est pas de rendre les révisions difficiles.

Définir le paquet de livraison

Le transfert convenu pourrait contenir du code, des notes de déploiement, des informations sur la configuration, des directives administratives et une liste de dépendances.Les termes de propriété et de licence déterminent ce qui peut être transféré ou réutilisé; ne pas les déduire de l'accès à un dépôt seul.

Acceptation séparée, période convenue de correction des défauts et tout développement futur. Un projet achevé ne devrait pas se transformer en disponibilité technique illimitée pour l'agence ou son client.

Un premier message utile

Précisez le résultat attendu, la partie à développer, l’état de la conception, les intégrations connues, la période de livraison souhaitée et les éventuelles contraintes budgétaires. Indiquez ensuite la personne décisionnaire et le mode de communication préféré.

Cela suffit pour commencer une conversation ciblée. La portée détaillée peut être convenue une fois que les limites importantes sont comprises.

Explorer les partenariats de développement des agences ou envoyer un mémoire d'agence.