Comment vendre le développement Agile à des clients (en cascade)
Notre boutique de développement aimerait vraiment faire des projets plus agiles, mais nous avons un problème pour obtenir des clients à bord. De nombreux clients veulent un budget et un délai. Il est difficile de vendre un client sur un projet agile lorsque nos concurrents proposent des délais fixes et des prix fixes basés sur la cascade. Nous savons que leurs numéros fixes sont mauvais, mais le client ne le sait pas. Donc, nous finissons par avoir mauvaise mine pour le client car nous ne pouvons pas fixer le prix ou un délai mais nos concurrents le peuvent.
Alors, comment pouvez-vous convaincre votre force de vente de vendre avec succès un projet utilisant des méthodes de développement agile ou un produit développé à l'aide de ces méthodes? Toutes les informations que j'ai trouvées semblent se concentrer sur la gestion de projet et les développeurs.
La clé pour bien faire cela est d'utiliser un contrat de support.
Fondamentalement, lorsque vous vendez le client pour la première fois, vous le vendez en fonction de votre expertise et vous le faites en cascade. Cela signifie un contrat qui fixe la portée et un délai ferme. C'est ce que veut le client. Le client connaît plus ou moins la portée. La cascade fonctionne très bien, dans un environnement à portée fixe et définie, je dirais que cela fonctionne mieux que l'agile dans de tels environnements. Et dans ce cas, cela donne au client un niveau de confort lorsque la tendance est à la nervosité car il n'a jamais travaillé avec vous auparavant. Ça va, Agile n'est pas toujours mieux que la cascade.
Vous avez donc un contrat à prix fixe pour la portée X. Ensuite, vous dites au client " Écoutez, vous allez vouloir faire des changements, et vous allez avoir besoin de nous pour vous soutenir dans la post-production, mettons de côté 20% de votre budget pour ces choses à utiliser selon les besoins au moyen d'un contrat d'assistance . "
Si un changement survient au cours du projet, reportez-le simplement pour qu'il soit traité par le contact de support. (En supposant que ce changement entraînerait une grave perturbation du projet)
Les termes du contact de support sont les suivants " Le travail à effectuer sur une base horaire, à la demande du client, peut être utilisé pour des demandes de changement ou un support et une maintenance générale du système . " BAM! Vous êtes en Agile.
Vous pouvez ensuite continuer à étendre le contact de support et simplement utiliser le contact de support comme moyen d'exécuter de nouveaux projets. De plus, si ces heures sont achetées et payées d'avance , nous accordons généralement au client une remise de 15%. C'est gagnant-gagnant.
Agile n'empêche pas les délais et les budgets. Si j'étais un client et que j'allais chez un développeur et qu'ils me disaient qu'ils ne pouvaient pas me donner de date limite ou de coût estimé, je remettrais en question leur raison. Et leur dire qu'ils ne comprennent tout simplement pas ne fonctionnera pas: ils doivent être en mesure de budgéter et de planifier.
Ils n'ont pas besoin de connaître votre processus de développement. Ils doivent savoir combien de temps il faudra pour développer des fonctionnalités et combien cela va coûter. Donnez-leur un nombre basé sur l'hypothèse (fallacieuse) que leurs besoins sont exacts à 100%, et lorsque leurs besoins changent, modifiez ensuite vos estimations.
Cela leur donne les postes budgétaires et les dates de déploiement qu'ils souhaitent, et lorsque les choses changent, votre processus vous permet d'avoir l'air flexible et accommodant.
Il semble que vos vendeurs créent une couche de mauvaise communication entre vos équipes de développement et vos clients. S'ils ne vendent pas sur le marché informatique depuis longtemps, ils peuvent considérer leur rôle comme "déplacer le produit", ce qui signifie obtenir une signature sur un contrat "tout ce qu'il faut". En bref, ils sont motivés à fermer, peu importe ce qu'ils promettent. Dans de telles circonstances, ils vont suivre la langue du client aussi étroitement que possible.
Je suis un record brisé citant cela, mais voici: vous êtes sur la table d'opération et comme vous le voyez, le chirurgien dit "nous vous ferons sortir d'ici à temps et dans les limites du budget". Génial. Vais-je être vivant?
Si vous travaillez sur les organes internes d'une entreprise, vous arrêtez-vous à un moment arbitraire? En règle générale, une application n'est affectée par les forces ni de vous ni de vos contrôles clients - réglementations, climat des affaires, comportement des concurrents, émergence d'un nouveau paradigme, etc. Si vous dites simplement "nous ferons" chose x "pour" prix y " le client reviendra trois mois plus tard et dira - "bien ...". Cela signifie généralement qu'ils savent quelque chose qu'ils ne savaient pas lorsque vous avez accepté un projet de cascade.
Ce qui pourrait fonctionner dans une telle situation, c'est de montrer à votre propre personnel de vente à quoi ressemble une promenade dans un canyon. A chaque tournant il y a des surprises. Il n'est pas possible de voir plus de trois mois environ, donc si un client demande un projet de 18 mois, il ne sera pas reconnaissable au moment où vous êtes presque terminé. Par conséquent, votre représentant commercial doit commencer par trouver le gain financier du projet. Est-ce que cela augmentera les ventes de 10 millions de dollars? Si oui, vaut-il la peine d'investir 2 000 000 $ pour faire ces 10 millions de dollars supplémentaires? Si le client et le représentant commercial convergent vers un engagement de 500 000 $, il se peut que quelque chose cloche et que personne ne puisse dire de quoi il s'agit - cela ne semble tout simplement pas correct. Ce qui "ne se sent pas bien", c'est un engagement à faire quelque chose qui risque d'être inutile.
Les deux derniers modèles d'avions de ligne à réaction ont eu une histoire de snafus. Healthcare.gov n'a même pas besoin de discussion. Si vous pouvez trouver des livres ou des articles de presse spécialisée sur les avions de ligne, vous pouvez indiquer comment certaines hypothèses ont été avancées qui se sont avérées optimistes et que les projets ont manqué leurs délais à plusieurs reprises. Cela était souvent dû à une sous-estimation de la complexité. Si vous ne pouvez pas vraiment comprendre à quel point il est complexe jusqu'à ce que vous commenciez à le coder, vous aurez besoin d'un `` tour initial '' pour avoir une meilleure idée des vrais problèmes. La coupure budgétaire devrait représenter une fraction du total des bénéfices supplémentaires (ou des revenus dans certains cas), et ce nombre doit être supérieur à ce que quiconque pense que le projet actuel coûtera. Si vous pouvez montrer comment le dernier jalon peut être franchi sans dépasser la "limite de gain", il devrait être possible de vendre le projet comme un effort agile.
Le principal obstacle à l'obtention des avantages du développement logiciel extérieur Agile-Scrum est de l'intégrer aux mécanismes de contrôle existants. Ces mécanismes de contrôle sont stipulés en raison de diverses conditions préalables organisationnelles et sont normalement actualisés en utilisant l'approche et la méthodologie Linear Waterfall.
Quatre de ces conditions préalables organisationnelles typiques sont décrites ci-dessous:
Grandes entreprises mondiales - dans ces organisations matricielles hiérarchiques, le contrôle descendant du portefeuille est la règle du jour. L'approche agile de l'esprit libre a du mal à s'adapter aux contrôles rigoureux. Plus précisément, les concepts inhérents sans plan Agile rendent Agile-Scrum difficile à avaler pour l'organisation.
Industries hautement réglementées - certaines industries sont tenues par les organismes de conformité et de gouvernance d'avoir un mécanisme de contrôle contraignant strict. Il peut s'agir, par exemple, d'équipements médicaux, d'avions et d'unités commerciales de recherche et de développement de produits pharmaceutiques. Alors que des équipes individuelles peuvent utiliser Agile-Scrum, le processus de développement doit suivre une méthode d'approche linéaire linéaire en cascade pour la traçabilité et la gouvernance.
Produits complexes prédéfinis - certains produits intégrés qui incluent à la fois du matériel, des logiciels, des logiciels intégrés et plus sont développés en tant que contrat avec un client final selon un ensemble d'exigences prédéfinies. Dans ces cas, le degré de flexibilité des exigences est faible, mais supérieur à ce qui était prévu initialement. Le concept d'un backlog entièrement flexible d'Agile-Scrum souffre considérablement dans ces cas.
Services informatiques génériques - une grande partie des activités quotidiennes et hebdomadaires dans les services informatiques axés sur la maintenance est ponctuelle. Les changements d'horaires quotidiens sont nombreux et immédiats. Les interférences constantes dans le travail des équipes sont la norme. Le concept de boxe temporelle et aucune interférence est difficile à maintenir dans ces situations.
Naturellement - plusieurs fois, les quatre catégories distinctes détaillées ci-dessus se mélangent; il est donc courant de trouver un produit complexe dans une grande entreprise mondiale qui doit se conformer à une réglementation ferme.
Sur la base de l'expérience pratique, la méthode recommandée pour s'attaquer à ces scénarios et à d'autres consiste à habiliter le PMO Agile à agir en tant que facilitateur, pilote et traducteur entre les équipes Agile-Scrum émergentes et les éléments Linear Waterfall.
Reportez-vous au tableau ci-dessous pour des directives spécifiques
Source - Interfaçage entre cascade linéaire et approches agiles par Michael Nir
Nous mettons en place 2 ou 3 séances d'estimation avec le client potentiel et nos développeurs où nous discutons du travail à réaliser et fixons les critères d'acceptation. Les développeurs estiment le travail en points d'histoire au cours de la réunion.
Ensuite, nous vendons au client un certain nombre de points d'histoire. Cela est possible car il a une bonne idée de la valeur des points d'histoire. Nous lui disons qu'il a la possibilité d'affiner son backlog/scope pendant le projet et que ce sera facile grâce à l'utilisation des story stories. Nous lui disons également qu'il y aura une livraison fréquente de logiciels de travail afin qu'il puisse suivre les progrès et obtenir de nouvelles informations.
En s'accordant sur un certain nombre de points d'histoire, le client est assuré d'obtenir un bon rapport qualité-prix. S'il ne modifie pas son carnet de commandes, il a son projet à prix fixe/portée fixe, mais mon expérience est qu'il apportera des changements. En faisant des estimations en présence du client potentiel, nous essayons de construire une relation basée sur l'ouverture et la confiance.
Nous avons réussi à convaincre des clients comme vous le décrivez, qui "veulent un budget et un délai", et ils étaient heureux que nous voulions vraiment comprendre ce dont ils avaient besoin, au lieu de travailler à partir d'un document. Nous avons montré que nous voulions investir dans ces projets.
Au cours des séances d'estimation, nous avons estimé l'intégralité de leur carnet de commandes. Cela a donné x points d'histoire. Nous avons suggéré d'ajouter 25% pour les fonctionnalités qui n'étaient pas encore claires ou connues à l'époque. Avec l'arriéré estimé attaché au contrat, ils ont été rassurés qu'ils obtiendraient tout pour le budget fixe.
À l'origine, l'offre était du temps et du matériel. Comme ils voulaient avoir une offre à prix fixe, nous avons suggéré de travailler pour le prix que nous leur avons donné et d'utiliser les 25% de points d'histoire supplémentaires pour la contingence. Si les choses se passaient bien, la partie des 25% qui n'a pas été utilisée pour couvrir les retards que nous avons rencontrés serait utilisée pour offrir plus de fonctionnalités au client.
Cela les a stimulés de plusieurs manières: premièrement, ils ont fait tout ce qu'ils pouvaient pour permettre à nos développeurs de travailler le plus rapidement possible, car c'était clairement dans leur propre intérêt. Nous n'avons jamais eu à attendre les réponses aux questions. Deuxièmement, ils ont vraiment compris le concept des points d'histoire. Avant le début du projet, ils avaient déjà supprimé certaines histoires et nous avaient demandé d'estimer d'autres histoires. Aucune négociation de contrat compliquée n'était nécessaire pour cela.
Nous les avons tenus informés des progrès et avons maintenu une communication très ouverte. Ils ont reçu un rapport d'étape toutes les 2 semaines: x% des points d'histoire réalisés en y% du temps estimé laisse z% des points d'histoire supplémentaires disponibles. Nous avons eu un début un peu difficile mais nous avons réussi à rattraper les estimations à la fin du projet, ce qui a laissé 100% des points d'histoire supplémentaires disponibles pour un développement supplémentaire. Le client était content parce qu'il avait tout ce dont il avait vraiment besoin (et c'était un peu différent de ses fonctionnalités initialement demandées, il en a retiré certaines et en a ajouté d'autres).
Le client était également satisfait parce que tout a été livré dans les délais prévus (où il a également fait tout son possible pour nous aider à chasser les tickets, répondre immédiatement aux questions, impliquer les utilisateurs dans les réunions d'analyse hebdomadaires et les impliquer également dans les tests fonctionnels).
Mon entreprise était heureuse car nous avons livré dans les délais et dans les limites du budget. Mon entreprise était également heureuse car le succès de ce projet a ouvert la porte à plus de projets. Nous avons même été mentionnés dans le magazine mensuel du client qui a été envoyé aux gens du monde entier.
Faire de bonnes estimations a été la partie la plus difficile du projet, mais avoir des séances d'estimation à l'avance nous a permis de comprendre la difficulté et les risques. Cela nous a permis de donner une estimation basée sur des faits et a supprimé beaucoup d'inconnues.
Essayer d'utiliser des méthodes Agiles dans un environnement de conseil/appel d'offres est très difficile lorsque le client n'est pas à bord.
S'ils sont habitués au style Waterfall "voici nos exigences, combien et combien de temps cela prendra-t-il?" tapez des projets et lancez-les, il n'y a pas vraiment de temps pour les convaincre qu'Agile ou tout autre moyen est meilleur.
Agile a ses avantages (et ses inconvénients bien sûr), mais très franchement, le client ne connaît pas ou ne se soucie pas des détails en coulisses.
Ils veulent 2 choses - le coût et l'échelle de temps. Et une fois que vous leur avez dit cela, ils le veulent alors moins cher et plus tôt. Et vous savez quoi, nous voulons tout. Toutes les exigences. Personne ne peut attendre ou être haché.
Et autant que je n'aime pas les vendeurs dans la plupart des milieux, ne soyez pas trop dur avec les vendeurs. C'est un travail difficile.
Ils ne construisent pas de logiciels, ils ne savent généralement pas comment tout cela fonctionne après les mots à la mode.
Pourtant, ils doivent trouver des échelles de temps et des coûts basés sur certaines exigences laineuses. Peut-être qu'ils ont certains des gars de la technologie avec eux pour les régner, mais ils doivent faire une vente pour faire avancer les choses.
Alors, comment pouvez-vous convaincre votre force de vente de vendre avec succès un projet utilisant des méthodes de développement agile ou un produit développé à l'aide de ces méthodes?
En faisant venir votre client au bureau par votre force de vente. L'intérêt de l'agilité est d'obtenir un feedback immédiat du client afin que vous puissiez produire ce qu'il veut (et pas plus). Amenez-les, demandez ce qu'ils veulent. Deux semaines plus tard, amenez-les et montrez-leur une démo/prototype. Vendez-les sur cette interaction. Montrez-leur les progrès et expliquez que ce type d'itération est ce que vous aimeriez faire pour qu'ils obtiennent exactement ce qu'ils veulent.
Donnez des estimations de la quantité de travail nécessaire (c'est ce qu'est un budget après tout), mais laissez-leur le pouvoir (lire: responsabilité) d'inclure ce qu'ils veulent intégrer dans leur budget.
Je pense que la réponse est que, dans la plupart des cas, vous n'en aurez probablement pas. J'essaierais de voir cela initialement comme une petite partie de votre entreprise - peut-être 20%, le reste selon un modèle traditionnel. Au fil du temps, j'essayerais de me concentrer davantage sur les produits et les clients Agiles et d'essayer de faire grandir cette partie.
Une autre partie de ce problème consiste peut-être à essayer d'utiliser les deux approches. Utilisez l'approche en cascade avec les cadres supérieurs et les négociateurs de contrats. Par exemple, "un système permettant aux clients de gérer des portefeuilles et de prendre des décisions d'investissement en utilisant à la fois des navigateurs et des téléphones mobiles (Apple et Android)". ou quelque chose comme ça. Ensuite, utilisez Agile pour le développement de l'équipe de développement sur les fonctionnalités plus détaillées, par exemple, Créer une page d'accueil, Créer une page de connexion, Créer un historique de gestion du portefeuille, Créer une connexion mobile, etc.
Une autre idée est donc de faire d'Agile votre différenciateur. Je sais que beaucoup sinon la plupart des grandes organisations ne font pas d'Agile. Cependant, la plupart (la grande majorité selon mon expérience) des petites entreprises le sont. Je pense que Agile se développe rapidement et cela va continuer. L'avantage de cet itinéraire est que vous présentez ce que vous voulez le plus aux clients qui le reconnaissent déjà. Cette approche nécessitera un certain travail au fil du temps sans aucune garantie de succès.
Vous pourriez également trouver une certaine traction si vos clients aiment les tests. Avoir des produits bien testés peut être plus facile à vendre pour certains clients. Un livre que je trouve utile dans ce domaine est "Agile Testing" par Adison Wesley Press.
Vous pouvez également utiliser les événements actuels pour soutenir votre cas. Par exemple, le site de soins de santé actuel (écrit en octobre 2012) est un bon exemple de la façon de NE PAS gérer les changements qui étaient nécessaires 2 semaines avant la mise en service. De plus, la sur-ingénierie apparente aurait probablement été mieux abordée avec des méthodes plus agiles.
Contactez les clients précédents qui sont satisfaits de votre travail. Surtout s'ils sont des convertis de Waterfall to Agile. À tout le moins, des convertis qui n'étaient pas vos clients.
Leurs témoignages (en tant que client) l'emporteront sur tout et tout ce que vous pourriez dire. Ils peuvent répondre aux préoccupations et aux craintes de votre nouveau client plus que jamais.
Du point de vue de la gestion, un budget et un délai est un besoin commercial pour le projet. Vous devez vous assurer que vous répondez à ces besoins, et si vous regardez les témoignages d'une entreprise sur le changement, vous remarquerez que cela arrive directement. Si vous regardez les témoignages des développeurs sur le changement, vous remarquerez que ce n'est souvent pas le cas.