Image d'entête

Image d'entête

Sunday 9 March 2014

Énoncé budgétaire Agile, comment faire ?

Avant-propos

Je fus très occupé ces derniers temps, ce qui ne m'a pas permis d'entrenir mon blogue. Et tant qu'à publier juste pour publier, des articles sans contenu valable, j'ai préféré attendre de pouvoir prendre le temps et rédiger quelque chose avec plus de substance.

Ce nouvel article m'est venu suite à une soumission que j'ai faite à un nouveau client.

Le client, après m'avoir exposé le sommaire des fonctionnalités qu'il avait besoin dans un nouveau système, m'a demandé de lui produire une soumission dans un délais plutôt court lui indiquant combien de temps de réalisation pensais-je que son projet nécessitait. C'est un piège ! Car en corrélation avec le taux horaire de mon entreprise, il pouvait s'attendre à un prix X, ce qui n'est pas forcément un estimé réel.

Le développement logiciel n'a rien de simple. Dans la négociation d'un contrat, il y a toujours un compromis à faire.

Malheureusment, et j'en ignore la raison, on dirait que les clients, une fois qu'ils ont défini leur besoins généraux, pensent que nous, les entreprises de développement logiciel, allons pouvoir arriver avec un prix bien précis, et trouver toutes les fonctionnalités dont ils ont besoin pour ensuite fixer tout cela dans le béton avec un contrat - pèse fort, trois copies ! - Mais non !

Dans cette publication, je vais tenter d'expliquer en quoi le développement ne peut fonctionner comme cela. Les clients perdent trop ! C'est désavantageux pour vous, mesdames et messieurs les clients ! 

Les trois incontournables

Il existe trois variables incontournables dans la gestion de projets. Et ce, peut importe le type de projet. Que ce soit en construction, en développement logiciel, en entretien ménager, bref, tous les domaines à ma connaissances ont ces trois variables.
  1. Qualité
  2. Portée
  3. Prix
Le meilleur des mondes voudrait qu'on ait un logiciel de la plus grande qualité, avec toutes les fonctionnalités souhaitées, et au meilleur prix. 

La façon de ce faire, est d'établir une relation de confiance avec une firme de développement logiciel qui adhère scrupuleusement aux méthodologies Agiles.

La qualité

Qu'arrive-t-il quand vous ne voulez pas payer trop cher pour un article ? 

On sacrifie souvent sur la qualité du produit.

Le rénovateur professionnel

Dans le but d'éviter qu'une perceuse ne le lâche dès la première journée, il est concevable que l'entrepreneur en rénovation aille vers des marques plus reconnues pour leur qualité et leur caractéristiques techniques.
  • La dimension du mandrin,
  • S'il a'git d'une perceuse à percussion
  • Les rotations par minutes
  • Le torque de celle-ci
  • Fonctionnalité de débrayage, pour le gypse, par exemple.
Ces "fonctionnalités" se trouveront, pour des outils de qualité professionnelle, chez des marques comme DeWalt, Bosh, Ridgid, Milwaukee et plusieurs autres du même calibre.

Le rénovateur ne veut pas de compromis sur la qualité de ses outils, car il peut perdre un temps précieux si un outil brise en plein milieu d'un chantier.

La qualité de son outil est non-négociable !

Le développement logiciel

Le développement logiciel cible les petites, moyennes et grandes entreprises (PMGE). Or, il s'agit alors de la création d'un outil de qualité professionnel. La qualité n'est donc pas un compromis intéressant à faire, d'autant plus que la firme de développement logiciel joue sa réputation à chaque produit qu'elle crée, alors je doute qu'elle soit intéressée à compromettre la qualité d'un système.

En clair, la qualité, ça se paie !

La portée

La portée peut être vue comme la quantité de travaux à effectuer par rapport à un temps donné. Plus il y a de fonctionnalités à développer, plus de temps cela prendra, et plus cher le système coûtera.

S'il y a une constante dans le développement logiciel dont je suis sûr, c'est bien que la portée change toujours au cours d'un projet de développement. C'est en raison de cela qu'il est si difficile de fixer les prix dans un contrat, car il faut aussi fixer la portée.

En général, on s'entend pour établir trois niveaux de foncitonnalité.
  • Obligatoire
  • Linéaire
  • Facultative

Les fonctionnalités obligatoires

Les fonctionnalités obligatoires sont celles qui définissent votre système. Sans elles, votre système n'a aucune raison d'être. Celles-ci représentent ce qui donne le plus de valeur à votre système. Elles constituent les fonctionnalités qui vous procureront le meilleur retour sur investissement.

On leur donne une valeur d'affaires de dix (10).

Les fonctionnalités linéaires

Les fonctionnalités linéaires représentent des foncitonnalités très près de votre coeur, elles ont une importance certaine, et elle figurent au deuxième rang, après les fonctionnalités obligatoires. Ce sont des foncitonnalités dites "nice to have", et elles sauraient ajouter une valeur à votre système à coup sûr, et leur valeur sont tout de même moindre que les fonctionnalités obligatoires.

On leur donne une valeur d'affaires de vingt (20).

Les fonctionnalités factulatives

Les fonctionnalités facultatives sont, tel que suggéré par leur nom, optionnelles. Elles devraient être les premières à être sacrifiées dans le cas où des coupures au niveau des foncitonnalités doivent être faites.

On leur donne une valeur d'affaires de trente (30).

La portée en développement logiciel

La portée est à la fois la seule variable négociable, et la plus difficile à évaluer. C'est elle qui rend l'estimation d'un développement logiciel aussi complexe.

Je dis souvent qu'il est possible de tout faire avec les technologies de l'information. Mais à quel prix ?

La portée viendra nécessairement influencer le coût d'un développement logiciel. 

Prenons par exemple notre rénovateur professionnel énoncé plus haut. Il vous fera un estimé pour la rénovation de votre salle de bain. Si vous êtes bricoleur le moindrement, vous saurez qu'il est parfois impossible de savoir à l'avance quels seront les travaux nécessaires à effectuer, car c'Est souvent en commençant les travaux qu'on s'aperçoit qu'une partie du plancher est pourrite, ou qu'il y avait une fuite minime d'eau, pas assez importante pour que vous l'ayez constaté avant, mais suffisamment pour avoir fait pourrire le contreplaqué du plancher. Vous ne pourrez ignorer cela ! Vous devrez alors augmenter la portée des travaux, et résoudre votre problème de plomberie, en même temps que de changer votre contreplaqué, et refaire votre plancher, même si ce n'était pas prescrit dans vos intentions initiales.

C'est la même chose en développement logiciel, mais en plus complexe, car il n'est pas possible d'établir de métriques précises sur un projet, car le même logiciel développé pour deux clients différents ne résultera pas au même système.

D'ailleurs, la seule constante dont tous les fournisseurs en développement sont certains, c'est que la portée changera tout au long du projet. Alors, comment anticiper les changements ?

Une foncitonnalité qui peut sembler simple à première vue, peut s'avérer très complexe une fois qu'on l'explore plus en détail. Malheureusement, on n'explore pas tout en détail lors de l'évaluation, autrement on devrait charger, et ça, faut éviter, pour une estimation !

Il est donc très important pour vous et pour nous que vous sachiez catégoriser vos fonctionnalités selon leur niveau.

En clair, seule la portée peut être négociable.

Le prix

Le prix dépend de la portée et de la qualité du développement. Comme la qualité n'est pas négociable, on parle donc ici d'une variation en fonction de la portée.

Pour s'assurer de créer de la valeur pour vous, monsieur le client, l'industrie du développement logiciel a adopté depuis plusieurs années maintenant des nouvelles méthodologies dites Agiles.

En développement logiciel

Étant certaine d'une seule chose, l'augmentation de la portée dans le temps, l'entreprise en développement logiciel qui sera forcée d'établir un prix forfaitaire devra soumissionner deux et trois fois plus cher que le système en coûterait développé selon les méthodologies adaptées à son industrie.

Autrement, elle devra absorber les débordements de coûts, et fera faillite dans les prochaines années, ayant dû absorber trop de fois la perte liée à l'augmentation de portée.

Les deux seules issues sont alors la faillite de l'entreprise en développement logiciel, ce qui vous laisse sans support, pour un système que vous avez fait développé. 

Ou encore, vous payez beaucoup trop cher, car l'entreprise de développement logiciel n'envisage pas la faillite pour votre projet. Dans les deux scénarios, vous êtes perdant.

La méthodologie Scrum

Scrum est un cadre de gestion de projet agile qui vous permet de choisir le niveau de risque que vous êtes prêt à prendre pour le développement de votre système. 

La durée de l'itération est ni trop longue, ni trop courte selon le niveau de risque que vous êtes prêt à supporter. L'itération peut avoir une durée d'une deux ou quatre semaines.

Lorsque le temps de l'itération est écoulé, l'équipe de développement vous démontre les travaux effectuer. C'est alors que le lein de confiance s'établira avec votre fournisseur, en voyant une partie de votre système fonctionner devant vous en un si court lapse de temps.

Vous êtes responsable de l'entretien du carnet de produit. Celui-ci contient toutes les fonctionnalités souhaitées dans votre futur système. Elles sont priorisées de la plus importante en haut, à la moins importantes en bas.

L'équipe de développement s'engage alors à vous livrer une partie de ces foncitonnalité à la fin de l'itération, dans le but de vérifier avec vous si le développement correspond à votre besoin.

Comme cette méthodologie s'adapte très bien au changement, vous pourrez modifier la portée à votre guise, tout en étant conscient que cela a un impact sur le prix.

Ce qui est magnifique dans cette méthodologie, c'est que vous êtes en tout temps au courant de ce qui se trime, et des difficultés rencontrées, ce qui vous aide à mieux saisir l'impact de certains éléments sur la complexité du projet.

En étant mieux informé, vous êtes en mesure de prendre de meilleure décision quant à la portée du projet et à l'augmentation des coûts inhérants.

Comme cela, tout le monde gagne !

Conclusion

En somme, tentez d'éviter les contrats à prix fixes. Plutôt, fixez la portée qui elle viendra définir le prix. Et comme la portée change toujours en développement logiciel, le prix changera toujours aussi. Et vous serez avisé en quoi le prix a changé, et il n'en tient qu'à vous après cela d'accepter l'augmentation du prix, ou de le maintenir en retirant une fonctionnalité du niveau de votre choix.


Saturday 4 January 2014

L'expérience-utilisateur, un gage de qualité !

Dans une récente publication, j'ai parlé des dépassements de coûts et des échéanciers du développement logiciel. J'ai tenté en vain d'expliquer quelques unes des causes probables selon mes observations et mon expérience du terrain au sein d'entreprises d'envergure et de ministères et organismes gouvernementaux du Québec.

Les dépassements de coûts et des échéanciers peuvent aussi venir jouer sur la qualité d'un logiciel développé à la hâte dans des délais trop serrés. Le client doit être conscient de cela, car ce logiciel a pour objectif de l'aider dans son processus d'affaires et lui faire épargner temps et argent. Pourtant, encore aujourd'hui des logiciels font perdre d'importantes sommes aux entreprises et aux gouvernements.

Dans un premier cas, je vous citerai certains cas d'exemple tiré du Spetrum IEEE et du Québec, pour enchainer sur la façon dont tout cela peut être éviter, pour finir avec l'approche agile du développement logiciel piloté.

Exemples de projets qui ont mal virés

Spectrum IEEE

Plusieurs cas de logiciels défaillants sont rapportés par le Spectrum IEEE. Certains logiciels ont causé la faillite de certaines entreprises, tandis que d'autres ont coûté des millions, voir même des milliards de dollars.

Avez-vous déjà vu disparaître un entrepôt ? En 2005, le système de gestion d'inventaire de la compagnie Hudson Bay Co. (Canada) fait disparaître un entrepôt. L'entrepôt était toujours là physiquement, et des travailleurs y travaillaient chaque jour. Néanmoins, les produits destinés à cet entrepôt étaient redirigés vers d'autres entrepôts par le système informatique. Pendant trois ans, rien n'a été réceptionné ni n'a quitté cet entrepôt. Le système de paie étant administré par un autre système, les employés de l'entrepôt disparue étaient payés. En bout de ligne, le système informatique a contribué à 33,3 M$ en perte à l'entreprise.

En octobre 2004, au Royaume Uni, le géant de la distribution alimentaire J Sainsbury PLC a dû laisser sur la tablette son investissement de près de 527 M$ pour un système de gestion de la chaîne logistique automatisée. Il semble que la marchandise était coincée dans les dépôts et les entrepôts de la société. Sainsbury a été contraint d'embaucher environ 3 000 employés supplémentaires pour stocker ses étagères manuellement.

Pour d'autres anecdotes tirés du Spectrum IEEE : Why Software Fails.

Au Québec

La CARRA a fait les manchettes avec sa solution RISE évalué initialement à 30M$, et qui a coûté plus de 100M$ au final (Rien ne va plus à la CARRA). De plus, comme si ce n'était pas suffisant, des problèmes persistent !

Le CSPQ engloutit près de 450M$ dans le projet le plus important du gouvernement, SAGIR (450M$ engloutis dans le projet SAGIR)

Des moyens de contraception

Ces problèmes bien qu'informatiques, ne sont pas liés directement à la technologie de l'information proprement dit. Il s'agit d'abord et avant tout d'un système de valeur inaproprié et d'une incompréhension de la complexité du développement logiciel et de tout ce qui y ait relié.

Au gouvernement, les projets informatiques ne regardent pas seulement le développement logiciel, bien qu'il s'agisse du point généralement le plus important. On parle aussi de d'infrastructures réseaux, de plusieurs centaines de serveurs, avec des stations de stockage réseau et toute l'expertise pour mettre tout cela en place. 

Quoiqu'il en soit, les demandes de service sont toujours rédigés de sorte que la soumission du consultant doit comprendre un montant forfaitaire qui englobe tout, tout, tout ! Si on se fie aux mésaventures illustrées ci-haut, ce n'est pas possible.

Les ministères gouvernementaux et organismes paragouvernementaux devraient, à mon avis, être administrés comme des entreprises privés, d'une part, pour s'assurer de maximiser le retour sur investissement. D'autre part, l'utilisation des méthodologies agiles pourraient contribuer à une plus grande valeur et une plus grande qualité des produits développés, alors que celles-ci visent à créer la plus grande valeur d'affaires suivant la meilleure qualité possible. Autrement, on crée un système qui n'a aucune valeur aux yeux des utilisateurs et ce même système finira sur les tablettes. Or, à mon avis, il faut d'abord se soucier des utilisateurs et créer un système avec une excellente expérience utilisateur. C'est ce qui fait maintenant la qualité d'un système informatique.

Un gage de qualité

Aujourd'hui, on n'impose plus aux utilisateurs d'utiliser notre système. Les règles du jeu ont changées, et heureusement pour le mieux !

Plusieurs systèmes qui étaient développés en fonction de ce que les administrateurs d'une entreprise veulent, sans tenir compte des volonté ou de la réalité du terrain. Cela finissait pas des résistances aux changements de la part des employés qui finissaient par faire des épuisements professionnels ou rendaient simplement leur démission. Ces mêmes systèmes venaient compliquer la tâche de l'utilisateur final au nom d'une meilleure gestion des administrateurs, soit disant. Par ailleurs, il existe une expression populaire en informatique qui dit "garbage in, garbage out". Cette expression anglaise veut qu'un système ne produise seulement ce qui est saisi. Alors si on saisit n'importe quoi dans le système, on récoltera n'importe quoi à la sortie !

Apple a misé sur l'expérience utilisateur dans le passé, créant des outils conviviaux à la hauteur du génie de Steve Jobs. Voyez ce que cela donne aujourd'hui ! C'est en produisant des systèmes qui créent de la valeur aux utilisateurs que le système sera apprécié. Autrement, ce même logiciel sera considéré comme de la merde, et ce, même si la meilleure architecture est en place.



Des notions comme le design, l'ergonomie et la simplicité d'utilisation sont maintenant des prérequis nonobstant le système à créer. Et plus important encore : ne pas programmer un produit dont l'utilisateur n'en a rien à faire. Tout cela se résume par l'expérience-utilisateur, un gage de qualité !

Car en créant la plus grande valeur d'affaires en répondant aux besoins précis du client, en conjonction avec une excellente expérience-utilisateur qu'un système informatique gagnera des points vis-à-vis les clients.