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.


4 comments:

  1. Je suis tout à fait d'accord, très bon billet.
    Excellente idée pour lancer des débats, de recouper le concept de gestion de projet (qui rime malheureusement trop souvent avec waterfall) et la métho Agile.

    ReplyDelete
    Replies
    1. Merci de votre appréciation ! Auriez-vous des idées quant à comment négocier avec un nouveau client qui a besoin de certaines bases de comparaison, qui ne vous connait pas, et qu'il ne peut baser son choix sur la confiance, nécessairement ?

      Delete