Rares sont ceux qui trouvent une issue, certains ne la voient pas même s'ils la trouvent, et beaucoup ne la recherchent même pas.
D'Alice au pays des merveilles
L'article soulève les questions suivantes.
- Sur l'incohérence des composants de la formule d'externalisation «Scrum + Fixed Price».
- Une erreur possible (cause principale) précédant le mauvais choix de l'outil Scrum.
- À propos d'une situation où il est vraiment question de combiner Scrum et Fixed Price, nécessitant une analyse approfondie et de trouver des compromis pour la résoudre.
L'article aborde un point très controversé qui n'a pas de point de vue sans ambiguïté et fait l'objet de discussions interminables. Par conséquent, en lisant, gardez à l'esprit que votre opinion ne coïncide peut-être pas avec celle qui vous a été présentée, mais cela ne signifie pas du tout que l'un de nous a absolument raison et que quelqu'un a absolument tort.
Comme mentionné dans l'article «Comment démarrer le pseudo-Scrum en sous-traitance» , dans un grand nombre de projets d'externalisation, dont les équipes combinent (ou peut-être un vœu pieux) Scrum et Fixed Price, le cycle de vie du projet (LC) n'est pas correctement identifié. Ceux. une erreur a été commise en choisissant entre un cycle de vie itératif incrémental ou flexible. Et, en conséquence, le mauvais outil de gestion a été choisi - le framework Scrum. Et déjà une conséquence de ce choix est l'émergence d'un certain nombre de problèmes, de fausses conclusions sur Agile, Scrum et des tentatives (du mot «torture»?) De combiner ces deux concepts mutuellement exclusifs.
Mutuellement exclusif?!
Maintenant je discute.
On suppose que le lecteur est davantage familiarisé avec les matériaux de l'article ci-dessus.
Scrum + Fixed Price – , ?
, , .Lors de la conclusion d'un contrat pour la fourniture de services d'externalisation, le client insiste presque toujours sur un prix fixe (système clé en main). Son souhait est de fixer la portée du produit (ou la quantité de travail), voir le budget, les délais. Il veut voir ce qu'il «achète». Les clients acceptent rarement le temps et le matériel.
“ ”
Ainsi, le point clé: le besoin du client doit être fixé dans le contrat, et le besoin du prestataire de services de remplir les obligations du contrat et de s'assurer que les paramètres resteront inchangés avec une erreur prévisible (due à un certain degré d'incertitude et de risques aux étapes de la vente et de la conclusion du contrat) après le début du développement. La question de la réduction du degré d'incertitude et des risques est la question de la faisabilité et de la qualité de la phase Découverte (Pré-vente, diagnostic) par rapport au Périmètre Produit.
Il est bien évident que si nous réparons quelque chose (nous garantissons au client dans le cadre du contrat), nous devons le planifier et le gérer de manière à assurer le respect de nos obligations. Ceux. gérer le plan (ou les caractéristiques fixes du triangle du projet).
Le prix fixe nous oblige simplement à prioriser la gestion du plan. Sinon, pourquoi devrions-nous réparer quelque chose, sachant à l'avance que cela va changer, et nous n'avons pas vraiment l'intention de le gérer? Pour simplement signer un contrat? Une erreur critique dans les processus de vente établis: nous la réparons, sachant à l'avance que nous allons changer, uniquement pour signer un contrat!
Pourquoi allons-nous changer? Parce que Scrum est toujours une question d'incertitude et de son résultat - le changement. Il s'agit de la priorité de la gestion du changement. Et il est possible qu'ils apparaissent après le premier sprint. Pourquoi?
Une digression sur les raisons possibles du changement
Quelle pourrait être la raison du changement? Par exemple, il peut s'agir d'une phase de découverte (pré-vente, diagnostic) mal menée dans une situation où la portée du produit peut être définie dans une certaine mesure (pour un exemple, voir le paragraphe 3 de l'étude de cas dans l'article ), mais pour quoi pour une raison quelconque, cela n'a pas été fait. Dans ce cas, il s'agit d'un problème de phase et de processus internes, et non de la raison du choix de Scrum pour un contrat à prix fixe, un cycle de vie flexible au lieu d'un cycle itératif afin de compenser l'erreur commise.
Bien que, en toute honnêteté, je note que dans la vente (activités de pré-vente des analystes d'affaires) en sous-traitance (l'une des phases les plus problématiques du point de vue de la portée du produit!), Tout n'est pas aussi simple que dans un magasin lorsqu'un produit fini avec des propriétés spécifiques est acheté (Fonctionnalité). Et la phase de découverte est une activité difficile à vendre des analystes commerciaux et des équipes. Mais minimiser l'incertitude à un degré ou à un autre et évaluer les risques est l'une des tâches principales d'un processus de vente bien construit. Ainsi que la formation d'une compréhension chez le client sur la nécessité et l'importance de ces activités (cela peut être très difficile!). Mais pour cela, il existe un nombre suffisant de techniques et d'outils. Et cela revient à la question de la qualité des services fournis, et non de la vente d'un "cochon dans un poke".
Une autre raison peut être l'incapacité de déterminer la portée et la vision du produit pour le moment (pour un exemple, voir p. 2 de l'étude de cas dans l'article ). Et c'est en effet une situation très difficile et défavorable pour les deux parties, lorsqu'une sérieuse contradiction surgit et que la question de combiner Scrum et Fixed Price dans la fourniture de services d'externalisation se pose. Cela nécessite une analyse minutieuse, des actions supplémentaires pour former une compréhension globale du client (souvent techniquement et idéologiquement loin des réalités des processus de développement) des difficultés et des risques possibles, et la recherche de solutions de compromis.
Alors pourquoi Scrum est-il choisi? Pour gérer les changements qui, par exemple, surviennent à la suite d'une phase de découverte mal conduite (prévente, diagnostic) ou lorsque l'étendue du produit ne peut pas être déterminée à cette phase? Dans le premier cas, à mon avis, c'est faux. Dans le second cas, il est difficile à mettre en œuvre avec un prix fixe.
La troisième option possible pour choisir Scrum comme outil Agile, un cycle de vie flexible au lieu d'un cycle de vie itératif incrémental dans une situation où la portée du produit est élaborée et fixée à la phase de découverte (Pré-vente, diagnostic), et dans le contrat - Prix fixe, n'est pas non plus rationnelle à mon avis: pourquoi choisir un outil de gestion des changements (le flou est clairement une chose plus prioritaire - un plan), quand leur probabilité est-elle minimisée?
Revenez à l'idée principale de l'article.
Mais disons que Scrum est choisi. Encore une fois, Scrum est un outil de gestion du changement, lorsque le degré d'incertitude ne peut être réduit que dans le processus et uniquement en utilisant des approches appropriées. Et ce déclin est le résultat de ce processus.
Mais le contrat à prix fixe donne la priorité à la gestion du plan!
Ainsi, la «formule» «Scrum + Prix fixe» se transforme en «gestion du changement + gestion du plan simultanément». La tâche du gestionnaire est de gérer, à des degrés divers, à la fois le plan et les changements, mais il ne peut y avoir qu'une seule priorité: soit le plan, soit les changements.
La gestion de plan ou la gestion du changement est une sorte d'axiome ancré dans les fondements de la gestion et de l'analyse commerciale. Il se reflète dans les manuels de base (et pas seulement) pour les gestionnaires (PMBOK) et les analystes d'affaires (BABOK). Et la classification du cycle de vie (et leur identification par rapport à des projets spécifiques) se base dessus: il existe des cycles de vie conçus pour gérer le plan (par exemple, Waterfall, itératif incrémental (IID)) et flexible, Agile pour la gestion du changement. Le choix du cycle de vie (et par la suite des outils) est basé sur ce qui est prioritaire dans la gestion.
Le cycle de vie flexible est une sorte de cycle de vie incrémental itératif pour les projets avec certaines caractéristiques / caractéristiques dominantes (une liste de questions de contrôle est donnée dans l' article ci-dessus), vous permettant de l'identifier comme un cycle de vie distinct et de «diriger tous les efforts» vers la gestion du changement. Ces caractéristiques peuvent être attribuées: l'impossibilité de «ici et maintenant» d'atteindre un certain degré de certitude du Product Scope (le plus important!), La recherche d'une solution métier (ou sa livraison rapide à l'entreprise pour générer du feedback) qui va «tirer», la formation d'une liste de fonctions clés produit (caractéristiques clés), itérations courtes, variabilité, expérience, développement progressif des fonctionnalités, rétrospectives, amélioration non seulement du produit, mais aussi des processus afin d'obtenir la meilleure version du produit. Est-il possible dans de telles conditions d'obtenir des estimations adéquates du budget et des termes?
Le diable est dans un seul détail, ou ... tout dépend de la portée du produit
Tout a sa propre moralité, il suffit de pouvoir le trouver!
D'Alice au pays des merveilles
Que pouvez-vous dire sur la certitude (la capacité de l'établir) par rapport à la portée et à la vision du produit au stade de la vente, la phase de découverte, au début du projet d'externalisation?
Si le Périmètre Produit ne peut être défini, évalué, fixé en raison des raisons de l'unicité du produit, de l'idée d'une start-up, de l'incertitude sur l'efficacité des décisions commerciales prises (nécessité de les trouver) et de la difficulté à déterminer les fonctions clés du produit, la présence d'hypothèses à vérifier, etc. ... (voir à nouveau le point 2 de l'étude de cas ici ), alors, bien sûr, le framework Scrum est l'outil le plus adapté.
Cependant, pour l'externalisation, cette situation est considérablement compliquée par la volonté du client d'utiliser le système de prix fixe lors de la conclusion d'un contrat et apparaît sous un jour défavorable pour les deux parties. Dans une certaine mesure, avec certaines hypothèses, un compromis peut être atteint dans la passation de marchés et la gestion d'un tel projet. Il est important de former la bonne compréhension et les attentes correctes du client (investisseur), d'évaluer les risques, d'envisager, si possible, d'autres schémas d'interaction financière, et dans le processus de mise en œuvre du projet, de travailler en permanence avec la fidélisation du client, etc. Je n'entrerai pas dans la question, car elle dépasse le cadre de l'article.
En sous-traitance, la question se situe le plus souvent avant tout dans la conduite compétente de la phase de Découverte (Pré-vente, diagnostic) par rapport au Périmètre Produit et au choix du bon cycle de vie. Et si Agile et Scrum sont choisis dans une situation où la portée du produit peut être fixée (et encore plus lorsque cela n'a pas été fait pour une raison quelconque à temps, avec l'attente / l'hypothèse de son développement dans le futur), et en même temps dans le contrat - Prix fixe, à mon avis, une erreur est commise qui jette un doute sur l'issue positive du projet.
Merci de votre attention!