Quelle est la meilleure façon de permettre à un client de contribuer à un projet?

Nous construisons un CRM pour un client. Maintenant que la première phase majeure est terminée et qu'une seconde a été convenue, le client souhaite reprendre une partie du travail, en apportant des modifications mineures au schéma de la base de données et aux processus métier la première phase pendant que nous construisons la seconde .

Je ne sais pas si cela est vraiment pratique, mais en supposant que ce soit le cas, j'aimerais avoir des indications sur les mesures à prendre pour que cela soit réalisable. Voici ce que j'ai jusqu'à présent:

• Jusqu'à présent, le client a surtout vu le projet du point de vue d'un utilisateur; clairement, un séminaire en deux parties devrait avoir lieu où nous lui présenterons le fonctionnement interne:

  • tout d'abord, en montrant le schéma de base de données existant et, à titre d'exemple, en l'étendant,
  • puis, en montrant un exemple de code et en écrivant un nouveau processus métier pour l'amélioration du schéma.
• Le code réside actuellement dans un référentiel Subversion interne. Bien que nous puissions en créer un ou un public sur son réseau (auquel nous pouvons VPN), je pense qu'un système distribué fonctionnerait mieux. Cependant, il me semble que je suis le seul à ressentir cela, alors je pourrais utiliser de bons arguments convaincants.

• Je ne sais pas comment mandater / s'assurer que le code qui s'exécute en production est validé. On dirait que "x a fait un changement critique et non documenté juste avant de partir en vacances; maintenant y essaie de comprendre ce bug qui se produit depuis" les catastrophes sont inévitables. Idéalement, toutes les modifications, avant le déploiement, devraient:

  • être documenté dans un système de suivi des problèmes,
  • se produire d'abord sur un environnement de test séparé, et
  • doivent passer des tests automatisés.

  Hélas, je doute la discipline pour tout ceux qui prévaudra.

Supposons qu'une architecture de plug-in ou un projet séparé ne sont pas des options viables, car 1) le premier n'existe pas et 2) le second interdirait au client de consulter et éventuellement de modifier le code existant, une capacité que je crois qu'il le ferait insister sur.

Ce sera la réponse la moins préférée - mais néanmoins la voici!

C'est risqué (autant que de permettre à un débutant de conduire une voiture neuve) - mais ce n'est pas une mauvaise idée.

Comprenez pourquoi ils veulent faire cela: ce n'est pas qu'ils ont des ressources disponibles, c'est seulement pour se sentir sous contrôle.

Ce que vous devez faire est le suivant:

1. Éduquez votre client - le logiciel est plus qu'un code. S'ils veulent participer, laissez-les d'abord examiner les aspects architecturaux, les conceptions, etc. Leur poser des questions et leur montrer les implications des choix qu'ils font a priori.

2. Vous devriez toujours revenir en arrière avec des options sur les avantages / inconvénients des approches (et bien documenter ces réunions), mais vous devriez leur permettre de prendre des décisions. Au moins, ils commenceront à comprendre qu'ils ne savent pas grand-chose - ou s'approprieront eux-mêmes.

3. Vous pouvez créer un espace séparé - comme des branches pour qu'elles puissent coder ce qu'elles veulent - les choses doivent être dûment testées avant les validations ou les fusions.

Bien que je sache que des complications pourraient survenir, chaque problème est une opportunité. Si tout se passe bien, votre client appréciera davantage les problèmes internes et développera une meilleure confiance car il sait (comment) vous avez fait du bon travail!

PS: Pour vous donner un aperçu - je viens d'Inde; et je connais beaucoup de boutiques informatiques où la direction n'a pas vraiment la moindre idée. Ils ne se soucient généralement pas (voire se sentent heureux) que le client mette des ressources supplémentaires pour s'assurer que le projet ne va pas dans la poubelle! Cela fonctionne très bien pour eux; ils vont tous avec un état d'esprit "Quoi que vous disiez monsieur!". Il ne s'agit pas de rabaisser mon propre compatriote - mais de montrer que le développement conjoint n'est pas une si mauvaise idée. C'est après tout ce que de nombreux gourous de la gestion dépeignent comme étant «l' approche Prosumer » des problèmes commerciaux.

Aïe ... Vous avez la bonne idée mais j'ai vu à quel point cela peut être compliqué et les deux parties souffrent considérablement. Je maintiens actuellement une telle application.

Découvrez les vraies raisons pour lesquelles le client juge nécessaire de contribuer directement au projet. Est-ce qu'ils veulent maintenant que le projet se fasse plus rapidement que vous ne pouvez le faire de manière réaliste? Souhaitent-ils déjà des changements mais ont-ils peur d'engager des frais supplémentaires de votre part pour apporter des modifications aux spécifications ou demander des fonctionnalités supplémentaires? Y a-t-il une lutte politique dans leur organisation où les ressources de développement internes veulent plus de contrôle et d'entrée dans le projet ou où ils recherchent un travail occupé pour les développeurs internes? (ce dernier frappe près de chez moi)

Trouvez quelles sont leurs véritables motivations et abordez-les si possible. Le fait qu'ils suggèrent même que c'est un énorme signe avant-coureur que des problèmes sont sur la route. Essayez d'atténuer leurs véritables préoccupations avant d'accepter une telle chose, car ce qui va probablement se passer, c'est qu'ils auront le contrôle fort du projet et vous élimineront, ou ils causeront un chaos massif et un projet échoué.

EDIT: Malheureusement, ce navire a navigué pour vous, mais ne désespérez pas pour l'instant. Il y a encore des choses que vous pouvez faire pour minimiser considérablement la douleur. Quoi qu'il en soit, assurez-vous qu'ils sont UN ET UN SEUL GESTIONNAIRE DE PROJET et PROPRIÉTAIRE DE PRODUITS et que cette personne est associée à votre organisation / entreprise. Cette personne doit avoir la capacité de planifier des sprints, d'inclure ou de supprimer des user stories et d'affecter des tâches aux ressources de votre entreprise ainsi qu'à celle de votre client. Quoi qu'il arrive, assurez-vous que les ressources de développement de votre entreprise ne fonctionnent pas séparément des ressources de vos clients et, surtout, NE PASpermettre aux développeurs de votre entreprise de faire rapport à leurs chefs de projet ou propriétaires de produits! Ils pourront soit profiter pleinement du travail gratuit non couvert par le contrat, soit vous soustraire à votre propre projet. C'est une certitude.

D'un point de vue juridique, vous demandez essentiellement "Quelle est la meilleure façon de monter un âne les yeux bandés à travers un champ de mines?"

Du point de vue de la programmation, je demanderais plus d'informations - ce que le client demande peut-il être mis en œuvre en utilisant une sorte de système EAV défini par l'utilisateur ou avec des crochets qui peuvent être ajoutés au système? Idéalement, je voudrais garder le code du client aussi séparé du vôtre que possible pour diverses raisons.

Quelqu'un qui est généralement dans le rôle du client intervient. Honnêtement, je n'aurais pas ce problème parce que si cela allait si loin, vous seriez sous mon contrôle de source, en utilisant ma configuration CI et ma configuration QA pour tester les choses. Cet arrangement peut être assez difficile à mettre en place - je reçois beaucoup de réponses des consultants, surtout pour faire avancer les choses. Il semble que le processus interfère avec les heures facturables.

Je pense que votre point de vue est honnêtement un peu biaisé. Tout d'abord, gardez à l'esprit que ce n'est pas votre base de code mais plutôt notre base de code. Deuxièmement, dans la plupart des cas, la boutique informatique côté client est beaucoup plus motivée pour s'assurer que ce produit fonctionne comme prévu et qu'il est facile à entretenir, à gérer et à prendre en charge à l'avenir. Plonger pour corriger des bugs n'est pas plus facturable pour nous contrairement à la plupart des consultants. De plus, construire des choses pour être facilement configurables et échouer de manière prévisible est beaucoup plus important lorsque vous possédez également le côté opérations de la pièce. Vous pourriez vous retrouver avec un projet de meilleure qualité car une partie du personnel de développement n'est pas limitée par les heures facturables.

En ce qui concerne la façon de le faire fonctionner, DCVS est certainement la voie à suivre si cela peut se produire. Choisir quelque chose de neutre (bitbucket, github) peut aider. Avoir CI en place est également une aubaine ici - plus difficile pour les choses de sortir de Whack quand tout le monde sait qu'il est sorti de Whack lors du dernier commit. Si vous pouvez forcer les choses à se déployer via CI - quelque chose que nous devons généralement imposer aux fournisseurs - vous pouvez vraiment vous assurer que toutes les modifications sont validées. En ce qui concerne la formation, avez-vous envisagé de vous associer au client pendant quelques jours? Cela pourrait être un bon moyen d'établir les liens latéraux dont vous aurez besoin. Dans l'ensemble, le meilleur pari est de convaincre tout le monde qu'ils font partie de la même équipe. Parce qu'ils font partie de la même équipe.

On dirait que c'est beaucoup un problème de gestion car c'est un problème technique. J'ai fait face à des situations comme celle-ci dans les cabinets de conseil et les éditeurs de logiciels. D'un "Quelle valeur globale le client retirera-t-il du logiciel?" et "De combien d'efforts aurai-je besoin pour le maintenir en post-production?" c'est en fait une bonne situation pour vous. De nombreux clients insistent pour que leur personnel soit impliqué. Cela prendra cependant beaucoup de travail.

En commençant par la fin, vous aurez besoin d'un bon énoncé de travail . Cela indiquera ce pour quoi vous êtes accroché et ce pour quoi ils sont accrochés. Une matrice des rôles et responsabilités est un document moins légaliste qui décrit à qui appartient chaque élément, qui est impliqué et qui doit simplement être informé. Ces deux supposent que vous avez une structure de répartition du travail bien définie qui répertorie à un faible niveau (suffisamment bas pour estimer) ce que chaque tâche est.

En termes de création, c'est généralement l'ordre inverse: Portée (que vous avez clairement déjà) -> WBS (que vous pouvez avoir) -> Matrice des rôles et responsabilités -> SOW.

Une fois que la propriété est clairement définie, il est temps de gérer le code et les environnements. Je suis assez agnostique sur les outils de gestion de code. Ce que je dirai, c'est qu'il est vital de faire une revue de code pour tout ce qui est fait par quelqu'un en dehors de l'équipe de base. Si l'outil que vous utilisez marque cela, tant mieux. Vous voulez éviter que quelqu'un serre quelque chose qui va à l'encontre des décisions architecturales clés précédemment prises. Le concept des 4 yeux (2 yeux supplémentaires examinant tout) est la décision tactique la plus importante que vous puissiez prendre.

Les environnements sont également pénibles à gérer. Habituellement, j'ai vécu des situations où «nous faisons notre travail sur notre environnement, quand nous avons terminé, il revient au vôtre» et le vendeur et le client se débattent. Votre situation semble plus complexe. Je vous conseille d'essayer de trouver un moyen pour eux de travailler dans votre environnement jusqu'à la fin du projet. Si vous pouvez trouver un moyen de former le client à la gestion de son environnement (ne présumez pas qu'il est bon dans ce domaine), tant mieux.

Quelques autres mises en garde ...

1. Ne présumez pas que le client a la même productivité que votre équipe. (Vous obtiendrez des surprises à la hausse sur la connaissance du domaine, des surprises à la baisse sur la vitesse spécifique à votre logiciel.)

2. Ne présumez pas que le client connaît votre méthodologie.

3. Ne présumez pas que le client partage l'éthique de travail de votre équipe. (J'ai vu des surprises à la fois vers le haut et vers le bas.)

4. Passez beaucoup de temps à vous entraîner et à co-localiser.

5. Chaque heure passée à enseigner au client à résoudre les problèmes permettra d'économiser de nombreux jours à l'avenir.

6. Utilisez le client pour travailler à travers son organisation interne pour vous et trouvez des experts en contenu et en questions de domaine.

7. Utilisez le client pour vendre former son organisation.

8. Par défaut, impliquer des clients dans votre processus de développement vous obligera à penser comme un cabinet de services professionnels. David Maister a écrit le meilleur livre sur le sujet. Même si seulement 20% vous concernent, cela vaut la peine d'être lu.

Malgré toutes ces mises en garde, inclure des clients dans vos équipes peut faire des merveilles pour vous rapprocher de vos acheteurs. Ces clients sont les plus susceptibles d'être de futures références. Bonne chance pour tirer le meilleur parti de cette situation!

Votre client devrait certainement avoir une explication de la façon dont tout est mis en place, cela aurait dû être une exigence de signature lors de la première phase. Vous devez reculer pour permettre à votre client de modifier quoi que ce soit directement, il doit remplir une demande de changement qui est entrée dans votre système de suivi des problèmes et priorisée avec le reste du travail. Ce sera à vous et à votre client de décider quelles demandes sortent du champ d'application du contrat. La façon dont cela se produit devrait être conçue dans une sorte de flux de travail / document de gestion du changement, s'il n'y en a pas, je vous suggère fortement d'en créer un et de faire en sorte que votre client accepte que c'est le processus par lequel il peut changer les choses, et obtenir ceci dans l'écriture. Sinon, vous ne pouvez pas faire grand-chose d'autre que de prier.