POC, Prototype et Pilote, quelles différences ?

proof-of-concept

Voici quelques définitions:

  • Une preuve de concept ou POC (Proof  Of Concept) est une réalisation expérimentale concrète et préliminaire, très courte, illustrant une certaine méthode ou idée afin d’en démontrer la faisabilité.
  • un prototype est selon la définition de l’OCDE « un modèle original qui possède toutes les qualités techniques et toutes les caractéristiques de fonctionnement d’un nouveau produit ». , mais il s’agit aussi parfois d’un exemplaire incomplet (et non définitif) de ce que pourra être un produit ou service.
  • Le pilote ou prototypage consiste à concevoir des versions intermédiaires et donc incomplètes d’un produit, conçues pour tester l’utilisation auprès des utilisateurs, et/ou les performances, avant la phase proprement de conception proprement dite.  On parle également de pilote terrain lorsqu’on ait sur des conditions proches de ceux du déploiement sur le « terrain » mais à une échelle plus réduite.

Les définition sont très proche mais quelles sont les différences?

La démarche

Le choix d’une solution informatique est souvent dépendant d’un existant technique et d’un schéma directeur. Les outils sont alors choisis avant même que les besoins n’aient été détaillés avec les métiers. Dans tous les cas, le POC, prototype, pilote consiste à tester les fonctionnalités, l’ergonomie et/ou les performances techniques d’un produit ou d’un service auprès de ses futurs utilisateurs avant d’envisager un déploiement plus large. Ce test se fait sur une durée limitée et, autant que possible, dans des conditions très proches de la réalité : on teste généralement une version incomplète de la solution avec un échantillon représentatif de la population utilisatrice…

La démarche dépend du type de solution à tester. Les tests peuvent se dérouler sur une journée ou plusieurs semaines, impliquer un petit nombre d’utilisateurs ou une population vaste, vérifier un ou plusieurs concepts.

Dans tous les cas, le POC, prototype, pilote doit répondre à des objectifs mesurables définis en amont du lancement. La démarche comporte 4 étapes clés :

  • la définition de la situation cible à laquelle doit aboutir le produit ou le service,
  • la définition des objectifs du test et de ses modalités,
  • la mise en œuvre de la phase de tests,
  • la phase de bilan qui validera les enseignements du test et permettra de statuer sur l’opportunité du déploiement.

Une valeur ajoutée

En confrontant le produit ou du service à la réalité du terrain et de ses utilisateurs sur une plus petite échelle, le POC, prototype, pilote permet de le rectifier ou de l’améliorer, et de lever le doute sur la pertinence du produit ou du service. Les parties prenantes du projet peuvent valider l’adéquation du produit ou du service à leurs besoins, ce qui modère les risques de rejet. Observer le comportement avec un test réel permet d’anticiper l’accompagnement des utilisateurs à prévoir lors du déploiement. Ainsi on le voit au travers la démarche, la valeur ajoutée de ce test se fait sur 3 angles:

  • aider à développer un engouement: Quand il s’agit d’implémenter une nouvelle solution technologique dans une organisation,  il est important de s’assurer que l’équipe ne rejette pas le projet. Concevoir un POC, prototype, pilote avec des fonctionnalités limitées permet de s’assurer que la plupart des personnes y adhère ce qui contribuera au succès du projet.
  • limiter les risques : pour rallier les parties prenantes du projet, le POC, prototype, pilote peut soulever les problèmes et les risques à un stade précoce du cycle de vie du projet. Cela est particulièrement vrai lorsque les exigences restent un peu floues. Rien ne vaut un test proche du terrain pour aider à minimiser les risques avant le déploiement.
  • obtenir le maximum de commentaires des utilisateur: Les Tests d’Acceptation Utilisateurs (UAT) permettent de vérifier le potentiel d’acceptation de la solution par les utilisateurs finaux avant le déploiement final de la solution. Les commentaires des utilisateurs finaux sont essentiels au succès du produit ou du service et permet d’anticiper les problèmes reliés à l’expérience utilisateur beaucoup plus tôt dans le projet.

La différence

Dans une article sur son blog,  fait la différence entre les  trois concepts.  Selon lui pour intégrer la solution avec succès dans votre entreprise, il faut réaliser tous les trois. Voila la démarche:

poc-prototype-pilote

  1. La preuve de Concept: un POC est un système conçu purement pour illustrer la fonctionnalité d’un ou plusieurs principes à intégrer dans un système. La convivialité avec le monde réel n’est pas envisagée car l’intégration avec d’autres technologies pourrait diluer la capacité à déterminer si le principe (idée, vision) est viable. Les résultats doivent être mesurables, afin qu’ils puissent permettre de prendre une décision (go/no go). La décision doit reposer sur des seuils comme un niveau de performance acceptable. Les résultats du test doivent permettre de valider que ça fonctionne et comment ça fonctionne.
  1. Le prototype: Le Prototype est un système plus étoffé qui tente de simuler le système complet (avec une intégration système) ou au moins la plus grande partie de celui-ci. Les prototypes sont utilisés pour tester la viabilité ou l’utilité d’un système. Le prototype permet de valider et corriger certaines hypothèses. Il faudra plusieurs itérations pour valider plusieurs hypothèses (cycles essais/erreurs). Un prototype aura  les fonctionnalités principales du produit fini, mais il ne sera généralement pas aussi efficace, esthétique ou durable. Il ne faut pas confondre prototype et Wireframe qui consiste à  déterminer les composants nécessaires dans une interface utilisateur. Le prototype est ici à un stade plus avancé et permet de valider que l’utilisation de ces composants est viable pour l’utilisateur.
  1. Le pilote: Un pilote quant à lui utilise le système de production complet et il teste par rapport à un sous-ensemble d’utilisateurs finaux. Le but d’un projet pilote est d’obtenir une meilleure compréhension de la façon dont la solution sera déployé et utilisé dans l’entreprise et à corriger la solution. Le groupe utilisateurs doit être soigneusement choisi pour recueillir les bonnes données. Les données et les outils pour les mesurer doivent être déterminés à l’avance. Enfin il ne faut pas le confondre avec la « pré-série » qui consiste à tester l’ensemble d’un processus de fabrication.

Différence avec le Lean Startup

Comme le monte un article de François sur son blog, on est alors très proche de démarche Lean décrite dans un autre article, avec le MVP. Le “Minimum Viable Product” est un concept introduit par Eric Ries et Steve Blank,  créateurs respectivement de la démarche Lean Startup et du Customer Development. Comme son nom l’indique, un MVP consiste à concevoir une “solution de vérification” aussi minimaliste que possible afin de savoir s’il a une viabilité,  mais qui doit répondre à une seule question : « Y-a-t-il un marché (des clients) pour ce produit ?« 

L’objectif d’un MVP est donc d’apprendre du marché, des retours des clients potentiels (la cible) afin de valider et d’invalider des hypothèses que vous aurez formulées avant de lancer votre produit. Un MVP s’attachera à valider la valeur fondamentale du produit avec la seule question: « S’il ne devait y avoir qu’une seule chose qui ferait acheter mon produit, qu’est-ce que ça serait ? »

Ainsi vous l’aurez compris, MVP et prototype sont complémentaires. Le MVP permet valider la viabilité commerciale du concept alors que le POC, prototype ou pilote permet d’en valider la faisabilité technique.

Aussi, toute approche produit doit comporter une phase de création d’un MVP puis d’un prototype avant de lancer la fabrication et le développement du produit.

Conclusion

MVP, POC, prototypes et pilotes sont donc tous d’importantes tactiques à mettre à exécution dans l’implantation de nouvelles technologies. Ce sont des moyens rationnels d’orienter le choix, en mettant dans la balance l’expérience utilisateur. Pour réussir dans cette démarche il faut procéder de façon méthodique pour qu’ils aient une valeur. Et vous ne réaliserez jamais cette valeur à moins que consciemment vous notez les résultats et transformez ces données en informations utilisables et exploitables.

Référence:

Publicités

Un peu d’humour

 

Quelques dictons qui datent un peu (plus de 20 ans déjà) mais qui sont toujours d’actualité 😉

bege_humour

Les vrais programmeurs

  • Les vrais programmeurs ne commentent jamais leurs programmes : comme un programme est difficile à écrire, il doit être difficile à modifier
  • Les vrais programmeurs ne lisent jamais les manuels d’utilisation : faire confiance à ce genre de documentation est un signe de lâcheté et d’absence de confiance en soi
  • Les vrais programmes des vrais programmeurs ne marchent jamais du premier coups : mais ces programmes peuvent être modifiés pour fonctionner normalement après seulement une trentaine d’heure de débogage.
  • Les vrais programmeurs ont horreur de la programmation structurée : la programmation structurés est faite pour les névrosés contrariés qui nettoient leur bureau, taillent leurs crayons, rangent leurs affaires et rentrent à l’heure pour manger.
  • Les vrais programmeurs ne travaillent jamais de 9 heures à 18 heures : si un quelconque vrai programmeur est devant sa machine vers 9 heures du matin, cela signifie qu’il y a passé la nuit.
  • Les vrais programmeurs n’aiment pas la programmation en équipe : … à moins qu’ils soient le chef.
  • Les vrais programmeurs n’utilisent pas de générateurs d’applications ou de programmes : les outils de ce genre sont faits pour les assistés ou les fainéants.
  • Les vrais programmeurs n’écrivent pas en Basic : en réalité, aucune personne normalement constituée ne programme plus en Basic après avoir atteint la puberté.
  • Les vrais programmeurs n’écrivent pas en Fortran : le Fortran est fait pour les ingénieurs en cravate et en chaussettes blanches qui prennent leur pied en faisant de l’analyse statistique ou des simulations de réacteurs nucléaires.
  • Les vrais programmeurs n’écrivent pas en Cobol : le Cobol est fait pour les octogénaires qui continuent à programmer sur du papyrus.
  • Les vrais programmeurs n’écrivent pas en Lisp : car seuls les programmes en Lisp contiennent plus de parenthèses que de code.
  • Les vrais programmeurs n’écrivent pas en  Pascal, C, Bliss, Ada ou autre clone qui demande plus à taper le programme qu’à réfléchir.
  • Les vrais programmeurs détestent encore plus HTML : ce langage que même les Macintosh comprennent et qui est destiné à des non-programmeurs afin de leur donner l’impression qu’ils sont de vrais programmeurs.
  • Les vrais programmeurs n’aiment pas Microsoft : pour eux, Windows est un jeu d’aventures au scénario bien faible dans lequel on est toujours perdant, inconvénient qui était inexistant, même sur les Commodore 64, alors qu’ils n’étaient pas entre de vrais programmeurs.

Les sept lois de la programmation

  • Première loi : tout programme, quel qu’il soit, est obsolète dés qu’il est commercialisé.
  • Deuxième loi : tout nouveau programme coûte plus et est plus lent que l’ancien.
  • Troisième loi : si un programme est utile, il devra être rapidement remplacer par un autre.
  • Quatrième loi : si un programme est inutile, il faudra lui faire une documentation et le généraliser à tous les utilisateurs.
  • Cinquième loi : la complexité d’un programme s’accroît jusqu’à ce qu’elle dépasse les capacités du programmeur qui en assure le développement.
  • Sixième loi : tout programme, lors de son lancement, aura tendance à remplir toute la mémoire disponible.
  • Septième loi : la valeur d’un programme est inversement proportionnelle à la taille des documents qu’il génère.

Dictons

  • Si l’on ajoute un homme à un projet en retard, cela ne fera qu’ajouter du retard au projet
  • Ce n’est qu’après avoir essayé tout le reste qu’on lit la documentation. Et c’est à ce moment-là qu‘on se rende compte qu’on l’a jetée avec l’emballage.
  • La fonction  » Annuler  » n’est jamais disponible quand vous en auriez besoin.
  • Un programme informatique fait ce que vous lui dites de faire, pas ce que vous voudriez qu’il fasse.
  • Un projet préparé sans soin prendra trois fois plus de temps que prévu pour son achèvement. Un projet préparé soigneusement prendra seulement deux fois plus de temps.
  • La complexité d’un programme croîtra jusqu’à ce que le programmeur lui-même n’y comprenne rien.
  • C’est généralement lorsque le disque dur plante qu’on se rend compte qu’on a oublié de sauvegarder son fichier. Sinon, c’est en sauvegardant qu’on l’a fait planter.
  • Les ordinateurs accomplissent plus de travail que les humains. L’une des raisons est qu’ils n’ont pas, eux, à s’arrêter pour répondre au téléphone (ou à répondre aux mails).
  • Ce n’est que lorsqu’un programme est commercialisé que les plus graves erreurs sont détectées.
  • Les ordinateurs sont très bêtes, mais très rapide. Les hommes sont très futés, mais très lents. A eux deux, ils forment un couple idéal.
  • Pour savoir combien de temps sera nécessaire à l’écriture et au débogage d’un programme, faites votre estimation la plus fiable, ajoutez un, multipliez par deux et arrondissez à la dizaine supérieure.
  • Sur une installation de test fonctionne parfaitement, tous les systèmes qui en dépendent vont planter.
  • A la source de chaque erreur imputée à l’ordinateur, on découvrira au moins deux erreurs humaines (on compte ici l’erreur qui consiste à imputer la faute à l’ordinateur).

DO 178, le développement de logiciels critiques

Les normes ED-12 et DO-178 (Software considerations in airborne systems and equipment certification) développées en commun et éditées respectivement par EUROCAE l’Organisation européenne pour l’équipement de l’aviation civile, et RTCA, Radio Technical Commission for Aeronautics en relation avec FFA (Federal Aviation Administation), fixent les conditions de sécurité applicables aux systèmes critiques, c’est à dire dont la panne peut avoir des conséquences dramatiques, pour l’ensemble des équipements informatiques qui aident au pilotage des aéronefs et des astronefs dans l’espace aérien. Elles régissent les activités de développement et de test des logiciels embarqués à bord des avions et aéronefs commerciaux

do178-aviation

Historique

La rédaction de la norme débuta en 1982. Une première version, baptisée DO-178A, fut établie en 1985. Elle fixa entre autres l’obligation de procéder à des tests unitaires sur tous les composants logiciels. Elle fut ensuite remise à jour en 1992 pour devenir la DO-178B. Parmi les améliorations de cette version, on peut citer la prise en compte des systèmes d’exploitation avec des noyaux “préemptifs” qui permet à une  application prioritaire peut prendre la main lorsque survient un certain type d’évènement. En 2004, elle a été mise à jour avec une version DO-178C pour clarifier certains points de la norme et permettre l’intégration de nouvelles techniques de génie logiciel jugées suffisamment matures pour être utilisées dans les systèmes aéronautiques et leur certification. C’est le cas du développement orienté objet, de l’utilisation de modèles pour la génération automatique de code ou de tests, ou encore des méthodes de vérification basées sur des équations mathématiques appelées “méthodes formelles”.

Niveau de criticité

La norme définit 5 catégories de conditions de panne comme suit:

  • Niveau A, catastrophique : Conditions de panne susceptibles de provoquer un problème catastrophique (Sécurité du vol ou atterrissage compromis, Crash de l’avion … )
  • Niveau B, dangereuse : Conditions de panne susceptibles de provoquer un problème dangereux entraînant des dégâts sérieux voire la mort de quelques occupants
  • Niveau C, majeure : Conditions de panne susceptibles de provoquer un problème majeur entraînant un dysfonctionnement des équipements vitaux de l’appareil
  • Niveau D, mineure: Conditions de panne susceptibles de provoquer de provoquer un problème mineur sans effet sur la sécurité du vol
  • Niveau E, sans effet : Conditions de panne susceptibles de provoquer un problème sans effet sur la sécurité du vol

La corrélation entre la fréquence et les niveaux est la suivante avec une probabilité en nombre d’accident par heure de vol :

DO 178 1.jpg

La norme définit ainsi 5 niveaux de logiciel pour chaque catégorie. Ainsi un logiciel est dit de niveau D lorsque son dysfonctionnement mis en évidence par l’analyse de sécurité du système, provoquerait ou contribuerait à une panne d’une fonction du système entraînant une condition de panne de niveau D pour l’aéronef.

Ces 5 niveaux sont aussi appelés niveaux DAL (Development Assurance Level).

Cycle de vie et processus

La norme n’impose pas de cycle de vie mais des processus séparés qui seront combinées pour décrire son cycle de vie:

  • Processus de planification : organisation et plans
  • Processus de développement : spécification, conception, codage et intégration
  • Processus intégraux : vérification, gestion de configuration, assurance qualité, coordination pour la certification.

La norme définit des objectifs pour chacun de ces processus, et décrit un ensemble d’activités pour atteindre les objectifs.

Processus de planification

Les processus liés à la phase de planification s’accompagnent de l’édition de plusieurs documents  :

  • Le plan pour les aspects logiciels de la certification (PALC) : support initial utilisé par l’autorité de certification pour déterminer si un postulant propose un cycle de vie du logiciel en accord avec le niveau du logiciel à développer, il précise le niveau de criticité retenu
  • Le plan de développement du logiciel (PDL): comprend les objectifs, les règles et les cycles de vie du logiciel à utiliser dans les processus de développement
  • Le plan de validation du logiciel (PVL): description des procédures de vérification pour satisfaire les objectifs du processus de vérification
  • Le plan de gestion de configuration (PGCL): détermine les méthodes à utiliser pour atteindre les objectifs de gestion de configuration du logiciel pendant tout le cycle de vie
  • Le plan d’assurance qualité du logiciel (PAQL): définit les méthodes à utiliser pour atteindre les objectifs du processus d’assurance qualité du logiciel
  • Règles de spécifications du logiciel
  • Règles de conception du logiciel
  • Règles de codage du logiciel

Les processus de développement logiciel

Les processus liés à la phase de développement :

  • Les spécifications du logiciel (DSL) : utilise les produits du cycle de vie du système pour développer les exigences de haut niveau du logiciel. Cela comprend, les exigences fonctionnelles, de performance, d’interface et celle liées à la sécurité.
  • La conception du logiciel (DCL) : développe l’architecture du logiciel et les exigences de bas niveau qui peuvent être utilisés pour réaliser l’application.
  • Le codage du logiciel
  • L’intégration du logiciel

Les processus intégraux

Concernant le processus de vérification des spécifications:

  • Conformité avec les spécifications du système :
  • Précision et cohérence
  • Traçabilité
  • Revues et analyses d’architecture du logiciel

Concernant le processus de vérification du logiciel:

  • Cas et procédures de vérification du logiciel
  • Résultats de la vérification du logiciel :
    • Résultats de tests unitaires
    • Résultats de tests d’intégration
    • Résultats de tests
    • Analyse de la couverture de code (MC/DC)
    • Revue de chaque document du logiciel

Concernant le processus de gestion de configuration :

  • Index de la configuration du logiciel
  • Index de l’environnement du cycle de vie du logiciel

Concernant le processus d’assurance qualité :

  • Enregistrements relatifs à la qualité
  • Compte-rendu de revue de conformité
  • Résumé des travaux réalisés

Objectifs à atteindre selon le niveau requis

Plus le niveau de criticité est proche du niveau A, plus le nombre d’objectifs à tenir est élevé. Ainsi :

  • Niveau E :
    • aucune contrainte particulière.
  • Niveau D :
    • Le logiciel doit être documenté, les plans doivent être établis. Tout ce qui est spécifié doit être formellement vérifié. Tous les documents doivent être formellement vérifiés.
    • Le logiciel doit être géré en configuration
    • Un service Qualité indépendant doit assurer le respect de la norme
  • Niveau C : en plus des contraintes du niveau D :
    • Des règles de développement doivent être fixées au préalable
    • Les contraintes de traçabilité et de vérification s’appliquent également aux phases de conception et de codage du logiciel.
    • Les exigences de bas niveau (ou exigences de conception) doivent être formellement vérifiées.
    • Couverture des instructions (Statement Structural Coverage); Ces contraintes amènent souvent à devoir passer des tests unitaires.
  • Niveau B : en plus des contraintes du niveau C :
    • Couverture de décision / Couverture de condition (Decision/Condition Structural Coverage)
    • Les activités de développement et de vérification doivent être confiées à des équipes indépendantes.
  • Niveau A : en plus des contraintes du niveau B :
    • Couverture de condition / Décision modifiée (Modified Condition Decision Structural Coverage, MC/DC)

Références:

Lean Startup

Dans une article précédent consacré à la transformation numérique, il est rappelé que les entreprises du numérique se sont  inspirées de l’approche du Lean pour construire leur produit. C’est sur cette intuition que l’approche Lean Startup s’est appuyée pour formaliser la méthodologie des entreprises du numérique. Elle tend à réduire les cycles de conception des produits en mesurant régulièrement les progrès réalisés, pour apprendre et corriger leur mise au point afin de concevoir des produits et services qui satisfont au mieux la demande de leurs consommateurs, avec un investissement initial minimal.

The lean startup.png

Le concept est initialement développé en 2008 par Eric Ries. Il a connu un grand succès à travers le monde, grâce à son livre, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Pour Ries, l’erreur de la plupart des « jeunes pousses » est qu’elles partent d’une technologie, au lieu de la développer à partir des besoins à satisfaire. Ainsi elles conçoivent des produits qui ne seront jamais utilisés. explique dans sa présentation que 70% des entrepreneurs en startup se retrouvent vite bloqués à cause du temps (qui manque), de l’idée de départ (qui n’a pas évaluée) ou des clients (qui ne sont pas là!). Mais heureusement Lean Startup est la pour y remédier.

Le concept peut aujourd’hui s’appliquer à toute organisation, équipe ou entreprise qui introduit un produit, un projet ou un service.

Le MVP ou Minimum Viable Product

le MVP désigne un produit ou un service très simple, comprenant le minimum de fonctionnalités pour être utilisé. D’une conception minimaliste, il se met en place très rapidement pour pouvoir être testé auprès d’une clientèle cible, sans prendre de grands risques financiers ou perdre énormément de temps à développer un produit que personne ne veut. Cela permet de savoir rapidement si vous trouvez des utilisateurs enthousiastes, ou à l’inverse, si ils ne mordent pas à l’hameçon, il faut l’améliorer afin qu’il réponde davantage aux attentes des clients.

Le Lean Startup fournit des outils puissants et faciles à mettre en place afin d’éviter des mois de réunions et de rédaction de l’expression de besoin du produit ou du service. Le Lean Canvas est une excellente première étape d’une démarche Lean Startup avant de lancer le MVP et afin de formaliser les hypothéses. A noter que le Lean Canvas est un peu différent de la Matrice d’affaire (Business Model Canvas) dont la finalité est de décrire clairement son modèle d’affaires pour convaincre un investisseur, alors que le Lean Canvas est plus accès sur le recherche de solutions et de sa validation. Ainsi il permet rapidement savoir à chaque étape si cela vaut la peine de continuer.

Le Lean Canevas

Le Lean Canvas est un outil mis au point par Ash Maurya et qui permet de valider un business model du projet en une seule page. Il va prioriser les efforts à porter, les enseignements à chercher, les hypothèses à valider et les métriques à suivre.

La création d’un Lean Canvas ne doit pas prendre plus de 15 minutes. Il s’agit d’un état des lieux à date des hypothèses et du business model. Une fois établi, le Lean Canvas servira de support pour des réflexions bien plus longues.

Si vous ne pouvez ou savez pas remplir certaines parties , c’est qu’elles sont révélatrices d’un risque à lever et de réflexions à mener.

Il permet également d’en mesurer les progrès et est utilisé comme support pour communiquer sur le projet, notamment auprès des parties prenantes.

On part généralement d’une vision, c’est le « pourquoi » de Simon Sinek: pourquoi s’impliquer? dans quel but? pour quelle raison ? quelle en est la cause? Le « pourquoi » est lié à la cause ou la raison du projet. Le but est généralement celui de l’organisation. La vison du projet ne s’intéresse pas aux détails, le Lean Canvas permet alors d’en décortiquer la stratégie et les hypothèses.

Pour cela il doit répondre à une liste de 9 éléments dans l’ordre suivant :

  1. Segments de clients: potentiels clients et utilisateurs (vente ou application interne); pour des clients très différents, il faudra faire plusieurs canvas différents. Précisez également les Early Adopters : les tout premiers clients les plus faciles à convaincre.
  2. Problèmes: les 3 principaux problèmes rencontrés pour atteindre la cible; Identifiez également les problèmes des alternatives actuelles (concurrents ou  contournements)
  3. Proposition de Valeur Unique (UVP) : caractéristique du produit ou du service qui le rend différent et/ou meilleur du marché
  4. Solution:  les 3 fonctionnalités qui font que le produit a de la valeur et se différencie;  cet élément n’est pas figé et sera modifié par le suite.
  5. Canaux: canaux de communication pour entrer en contact avec les clients ou se faire connaitre, mais recevoir des feedbacks
  6. Revenus/Gains : modèle de revenu (abonnement, commission, freemium…) ainsi la marge brute, seuil de rentabilité, etc…; pour un projet interne cela peut être les économises et bénéfices.
  7. Coûts: liste des coûts fixes et variables. Il faut compter les coûts de communication, le développement du MVP, les coûts exploitation et le burn rate. De là on pourra déduire combien de clients sont nécessaires pour couvrir les coûts au démarrage.
  8. Indicateurs clés :  actions clés permettant de mesurer les étapes clés du parcours utilisateurs: taux d’acquisition, activation, rétention, revenue, référencement.
  9. Avantage concurrentiel : protection  et avantages compétitifs du produit/service: « quelque chose qui ne peut pas être copié facilement ou acheté ».

Voici un excellent exemple fournit par le blog Octo pour un réseau social d’entreprise:

lean-canvas-octo-raiseau-social

Le Lean Canvas doit être partager et valider par l’ensemble des parties prenantes du projet : responsables marketing, métier, SI, experts fonctionnels et techniques.

Le pivot, ou l’apprentissage par itérations

Il faut se rendre à l’évidence, on découvre par des retours terrain avec de vrais clients que le produit n’est pas adapté, qu’il ne répond pas aux besoins et qu’il faut l’adapter, le changer, … bref il faut le faire évoluer. On parle de faire un « pivot », c’est-à-dire qu’on change une des hypothèses du modèle économique pour repartir sur un nouveau cycle de tests auprès des utilisateurs. Ainsi à la différence des autres méthodes de gestion de projet plus classique (cycle en V ou agile), les besoins des utilisateurs ne sont pas connus et sont formalisés par hypothèques, les hypothèses sont validés par étapes avec la réalisation de MVP itérés par des cycle de test.

build-measure-learn-loop

Le cycle de test , semblable à une itération de sprint en agilité, se fait en 3 étapes : « build », « measure », « learn » . Les qualiticiens auront reconnu l’inspiration de la roue de Deming décrit dans un  article présent. Le cycle doit être rapide comme dans les modèles agiles de manière à s’adapter et optimiser le produit. Les mesures se font avec les indicateurs clés definis dans le Lean Canvas.

Et quand est ce cela s’arrête ? Deux cas:

  1. le lean canvas a été tourné dans tous les sens, le MVP a été testé dans différentes variantes, mais le produit n’accroche pas. Il faut être lucide et ne pas s’obstiner, abandonner le projet et passer à un autre. Cette situation n’est certes pas heureuse mais vous n’avez pas de regret et vous avez limité vos pertes.
  2. le produit est apprécié par les premiers fans, les retours terrains montrent que les clients sont réellement prêts à l’utiliser et à le valoriser ? Alors il faut passer la vitesse supérieure et le proposer à plus grande échelle. Pour une start-up c’est l’étape ou il faut trouver des investisseurs.

Le modèle dans l’ensemble devient donc le suivant:

modele-lean-startup

Les limites du modèle

dans son article sur son blog montrent les inconvénients de la méthode, en voici les grandes lignes:

  • Lean Startup « casse » un peu trop vite la vision d’origine, à trop vouloir mettre l’accent sur des itérations rapides autour de « petit » produit  et le retour trop concret des utilisateurs potentiels, alors qu’une vision (le « pourquoi ») demande une approche à plus long-terme. Ainsi Lean Startup a tendance à tuer certaines idées qui auraient nécessiter un peu plus de temps. Guilhem prend l’exemple de covoiturage (devenu BlaBlaCar) : il a fallu près de 8 ans avant que ça décolle vraiment – s’ils avaient suivi les principes de la lean startup, ils se seraient arrêté avant ! On aurait pu prendre le même exemple pour « AlloResto » qui a demandé 10 ans!
  • Lean startup oublie le côté humain dans les métriques: on ne peut pas réduire les envies et les rejets des hommes à de simples métriques, ce qui peut fausser les mesures et vite invalider des hypothèses qui  auraient pu marcher
  • Lean Startup tue l’innovation de rupture et la passion, au profit de l’innovation incrémentale et le perfectionnement de petites fonctionnalités. On part d’une vision « passion » ou en rupture avec ce qui se fait déjà, on se rend compte que ça ne prend pas au vu des critères de Lean Startup (avec les métriques pas très humain) , on met alors la barre vers des projets de « raison », et on obtient un projet qui pourrait marcher mais qu’on n’a pas envie de faire tourner…
  • Lean startup amène à faire des tests sur ses premiers utilisateurs, quitte à les perdre ensuite… alors que qu’ils auraient dû être des supporters du projet  jusqu’au bout.
  • Lean Startup est difficile à bien faire tourner en France, du fait de la faiblesse des utilisateurs « early adopters ». C’est pourquoi beaucoup de startups « à la française » préfèrent démarrer aux États-Unis qui ont plus l’esprit « pionnier ».

Conclusion

Lean Startup est une démarche très orienté produit. Il permet de développer rapidement un produit correspond aux attentes de utilisateurs et évite la création d’un produit « parfait » que personne ne veut. C’est le principale avantage de la méthode. La notion de « vision » pousse en effet beaucoup d’entrepreneurs à créer des produits en inadéquation avec le marché. Cependant comme beaucoup de démarche projet, il ne faut pas prendre la méthode comme un approche système pour avoir un produit qui cartonne. Il faut prendre le bon, laisser le mauvais de côté, pour pouvoir avancer au rythme et l’humeur de l’organisation qui a été mis en place.

Références:

CMMI, le modèle de maturité

cmmi-logoL’utilisation d’un modèle de maturité permet à une organisation d’évaluer ses processus et méthodes selon les meilleures pratiques de gestion et par rapport à un ensemble clair de références externes.  CMMI est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d’ingénierie informatique.

CMMI a été développé par le Software Engineering Institute (SEI) de l’université Carnegie-Mellon, initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du département de la Défense des États-Unis (DoD). Il est maintenant largement employé par les entreprises d’ingénierie informatique, les directeurs des systèmes informatiques et les industriels pour évaluer et améliorer leurs propres développements de produits. CMMI reste une marque déposée par le SEI.

CMMI a pour finalité essentielle de mesurer la capacité des projets à s’achever correctement en terme de délais, de fonctionnalités et de budget.

Historique

Après une lente maturation dans les années 1980, le SEI financé par le DoD a présenté en 1991 le Capability Maturity Model (CMM). Ce modèle de référence ne concerne que les bonnes pratiques du génie logiciel. Après un fort engouement pour ce modèle, d’autres domaines distincts de l’ingénierie informatique ont vu le jour, tels que intégration système (SE) , le développement logiciel (SW),  la gestion de fournisseur (SS), le développement intégré des produits et processus (IPPD) et dernièrement la gestion des ressources humaines. En 2001, le SEI a proposé une nouvelle version de son modèle, le CMMI (Capability Maturity Model Integration) qui englobe les bonnes pratiques des autres modèles. La version du modèle a été réactualisée en 2006 (version 1.2). La dernière version du modèle date de 2011 (version 1.3). La dernière version regroupe 25 processus.

Définitions

Un Modèle définit précisément le chemin et les étapes vers l’objectif souhaité (niveau de maturité). Il a un langage commun et une vision partagée. Il permet de savoir où on en est, par comparaison. Il possède une méthode d’évaluation objective et fiable.

Un Processus (Process Area) est élément qui répond aux questions qui, quoi, quand, comment. C’est avant tout une aide aux développeurs. Ils sont sont regroupés en 4 catégories:

  • Process Management
  • Project Management
  • Engineering
  • Support

Un Objectif est un résultat à atteindre; leur atteinte ou pas, donne une mesure du niveau de maturité de l’organisation. C’est donc une notion très importante dans le modèle. Les résultats sont  observés sur l’ensemble des caractéristiques observables de organisation qui aurait mis en place les pratiques

Deux approches

CMMI propose deux représentations :

  • Une approche Continue qui conduira à l’évaluation de chaque processus indépendamment des autres. On parlera de niveau d’aptitude
  • Une approche Étagée avec une évaluation de façon globale de la maturité de l’entreprise en 5 niveaux. On parlera de niveau de maturité

Les deux représentations s’appuient sur les mêmes processus mais ceux-ci sont utilisés différemment.

La représentation étagée

Dans l’approche étagée , les bonnes pratiques préconisées par le modèle sont regroupés en 5 niveaux de maturité. Les domaines de processus rattachés à un niveau de maturité M ne peuvent être stabilisés et efficaces que si les domaines de processus des niveaux inférieurs  sont déjà stabilisés et efficaces (principe d’empilement).

Les 5 niveaux sont :

  • Initial (initial, niveau de maturité 1): La réussite des projets dépend du savoir-faire de quelques personnes clés dans l’organisation, pas de formalisation des processus et pas de partage. Ce niveau est caractérisé par un ensemble de mauvaises pratiques et d’un seul non-processus, le mode « pompier » avec une gestion par crise:
    • Indiscipline généralisé
    • Pas de processus fiables, on s’en remet à l’expérience de la personne
    • Projets pilotés par les délais
    • Population de héros
    • Pas d’enseignement tiré des difficultés ou erreurs
    • Pas de contrôle
    • Mode essentiellement réactif
    • Incapacité à reproduire les éventuels succès passés
  • Managed (géré, niveau de maturité 2): une gestion de projet élémentaire est définie pour assurer le suivi des coûts, des délais et de la fonctionnalité du projet. La discipline nécessaire au processus est en place. Le chef de projet a une forte responsabilité  : il doit définir, documenter, appliquer et maintenir à jour ses plans. D’un projet à l’autre, il capitalise et améliore ses pratiques de gestion de projet et d’ingénierie. Mais il ne s’interroge pas sur la pertinence de l’expression de besoin et il se limite à sa réalisation. Les 7 processus élémentaire doivent être maitrisés:
    • Gestion des exigences
    • Planification du projet
    • Conduite et maîtrise du projet
    • Gestion des achats
    • Production et analyses des indicateurs
    • Assurance qualité des processus et des produits
    • Gestion de la configuration
  • Defined  (défini, niveau de maturité 3): Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système de Management de la Qualité). L’organisation a défini des méthodes, outils et document. L’organisation est garante de la pérennité de l’ensemble, le chef de projet n’est plus tout seul. Il existe des lignes directrices, un plan stratégique et une planification de l’amélioration de processus pour le futur, en ligne avec les objectifs de l’organisation. Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.
  • Quantitatively managed (quantifié, niveau de maturité 4): Les projets sont pilotés sur la base d’objectifs quantitatifs. On travaille sur la notion de productivité, de performance des projets, en récupérant et comparant les statistiques de chaque projet. Des mesures détaillées sont prises en ce qui concerne le déroulement du processus logiciel et la qualité des produits.
    • Métriques / Indicateurs mis en place et exploités
    • Retours d’expérience possibles car processus cohérents (les comparaisons ont un sens)
    • Programme qualité
    • Évaluation des impacts liés aux évolutions de processus
  • Optimizing (optimisé, niveau de maturité 5): Les processus qui sont gérés quantitativement pour le pilotage de projet sont en optimisation constante par l’organisation afin d’anticiper les évolutions prévues (besoins clients, nouvelles technologies…). Les statistiques sont utilisées pour les processus standards. Le référentiel sert à construire et améliorer les processus standards

Chaque niveau intègre un certain nombre de processus qui doivent être maitrisés  par l’organisation ou par le projet:

sei-cmmi-level-3-718

Chacun des Processus doit répondre à des objectifs qui peuvent être spécifiques, intrinsèquement reliés à la nature de l’activité couverte par le processus, ou génériques, transversaux et identiques d’un processus à l’autre.

Ces objectifs se déclinent en pratiques qui décrivent le comportement attendu de la part de l’organisation ou d’un projet .

Afin de prouver la bonne implémentation de chacune des pratiques, des preuves (PII: Practice Implementation Indicator) doivent être collectées.

La représentation continue

Contrairement à la représentation étagée qui regroupe sous des niveaux de maturité les différents processus, la représentation continue exprime la capacité de chaque processus au sein de l’organisation suivant une échelle de 6 niveaux. Cette représentation permet à l’entreprise d’entreprendre un programme d’amélioration sur un bouquet de processus qu’elle a sélectionnés. Une décomposition proposée par le SEI regroupe les processus en 4 catégories définissant le CMMI Framework :

continous-representation

SCAMPI

Le Standard CMMI Appraisal Method for Process Improvement (SCAMPI) est la méthode officielle d’évaluation du SEI  utilisées pour identifier les forces et les faiblesses des processus, mettre en évidence les risques sur le développement ou les achats, et déterminer les niveaux de maturité et de capabilité. Ils sont principalement utilisés comme partie d’un programme d’amélioration continue ou pour évaluer des fournisseurs. La méthode définit le processus d’évaluation allant de la préparation, les activités sur site, les observations préliminaires, les constats et notations, le rapport final et les activités de suivi.

Il existe trois types de SCAMPI : SCAMPI Class C, Class B et Class A. La distinction principale entre ces trois évaluations est leur centre d’application :

  • SCAMPI C est une évaluation d’ « Approche » ;
  • SCAMPI B est une évaluation de « Déploiement » ;
  • SCAMPI A est une évaluation d’ « Institutionnalisation ».

Seule l’évaluation SCAMPI Class A pourra déterminer officiellement le niveau de maturité de l’entreprise. Elle est généralement précédée d’une ou plusieurs évaluation SCAMPI Class B et/ou C qui évalue respectivement la profondeur du déploiement des pratiques du référentiel et  la cohérence du référentiel de l’organisation avec les exigences du modèle CMMI.

Conclusion

CMMI est avant tout un modèle de maturité qui permet à une organisation de se situer en évaluant l’organisation de ses activités d’ingénierie informatique.

Mais comme le rappelle Anis Ferchichi dans le blog octo.com, CMMI peut être défini comme un modèle d’amélioration continue. En effet, CMMI est basé sur des pratiques spécifiques qui peuvent assimilées à des buts à atteindre en terme d’organisation et qui se définissent effectivement par des résultats observables. Le challenge pour les entreprises souhaitant respecter CMMI est le choix de l’implémentation des pratiques. Le danger résulte en général d’un mauvais choix d’implémentation; car si sur le terrain chaque entreprise est libre d’implémenter les pratiques comme elle le souhaite, elle risque, par manque de créativité ou de conseils avisés, de mettre en place des solutions très lourdes, contraignantes et sans réelle valeur ajoutée avec un grands volumes de documentation et un circuits de communication à rallonge, comme cela été été déjà le cas lors de la mise en place du SMQ et de la nome ISO 9001.

Donc l’enjeu principal de la mise en place d’une démarche CMMI, comme cela a été déjà fait pour la plupart des entreprises avec l’ISO 9001,  est le bon choix d’implémentation des pratiques afin de ne pas alourdir inutilement le quotidien des participants aux projets.

Comme le disait George Box : « tous les modèles sont faux, mais certains sont utiles ».

Références:

 

 

Définir la pertinence d’un projet avec une analyse SWOT

L’analyse SWOT  est un outil de stratégie permettant de déterminer les options envisageables au niveau d’un projet: pertinence et cohérence en prenant en compte tous les facteurs (interne et externe).

C’est  un acronyme issu de l’anglais : Strengths (forces), Weaknesses (faiblesses), Opportunities (opportunités), Threats (menaces).

L’analyse SWOT consiste à effectuer deux diagnostic:

  • un diagnostic interne, qui identifie les forces et les faiblesses internes au projet, d’origine organisationnelle.
  • un diagnostic externe, qui identifie les opportunités et les menaces présentes dans l’environnement.

La matrice SWOT est un modèle élaboré vers 1960 et elle est traitée lors de la 1ère réunion pour faire l’inventaire des différents éléments du projet pour décider de son démarrage ou pas. Il y a lieu de la remettre à jour régulièrement.

Elle se présente sous la forme d’un tableau comportant une grille composée de 4 grandes cases  :

swot_graphefl

  • Verticalement : 2 colonnes.
    • Celle de gauche recueille la liste des éléments ayant une incidence positive ou favorable sur le projet étudié
    • Celle de droite recueille la liste des éléments ayant une incidence négative ou défavorable sur le projet étudié.
  •  Horizontalement : 2 lignes.
    • Celle du haut recueille la liste des éléments dont l’existence est due à des causes internes, spécifiques au domaine d’activité du projet étudié. Ces éléments sont censés être maitrisables par les directeurs de l’organisation.
    •  Celle du bas recueille la liste des éléments dont l’existence est due à des causes externes. Ces éléments s’imposent aux directeurs de l’organisation qui ne peuvent avoir prise sur eu

Il est conseillé de faire apparaître les faits qui ont un impact sur les décisions à prendre et à signaler les tendances émergentes qui peuvent avoir une influence. Parfois il est intéressant de prioriser en numérotant les faits, des plus significatifs aux moins significatifs.

Une analyse SWOT tient sur une page, un slide ou un écran. L’intérêt est d’en avoir une lecture globale afin d’entrevoir l’ensemble de la situation. L’analyse doit permettre d’avoir une vision claire de l’ensemble de la situation. La liste figurant dans chaque case ne doit pas compter trop d’éléments (en général la liste comprend 3 à 5 éléments)

L’analyse SWOT est d’autant plus pertinente que les faits sont analysés de façon à servir les objectifs généraux de l’organisation.

Commencer par l’analyse des faits externes et les répertorier en menaces ou opportunités en vue d’atteindre l’objectif du projet, puis analyser les faits internes en forces ou en faiblesses, toujours par rapport à l’objectif du projet. Il arrive parfois qu’un fait soit à la fois une menace et une opportunité ou une force et une faiblesse, il convient de préciser pourquoi dans l’un et l’autre cas.

Voici un très bon exemple d’analyse SWOT effectuée en 2012 par le blog de la stratégie marketing sur la stratégie marketing qui a poussé Apple à lancer son iPad mini :

swot-ipad-mini1-gif

Références:

How Projects Really Work

Régulièrement vous  voyez apparaitre la fameuse bande dessinée « How projects really work » sur les blogs de gestion de projet, les présentations, les cours ou encore sur les murs des bureaux des sociétés de conseils. 
how-the-projet-works
Il y a quelques années est né un site appelé Project Cartoon qui permet de personnaliser la bande dessinée pour votre propre organisation ou votre projet. Vous pouvez même l’obtenir sous forme d’affiche ou de T-shirt. Mais le propriétaire du site ne sait pas d’où provient l’original (la version 1.0 sur le site). Il affirme qu’il existe des versions remontant aux années 1960. Néanmoins il l’améliore régulièrement avec de nouvelles cases. Cette illustration intemporelle de la gestion de projet informatique entre en raisonnante et fait débat, à chaque fois que quelqu’un voit pour la première fois, il reconnait ces simples vérités .