Par qui faire réaliser un développement informatique ?
En ce moment je rencontre régulièrement des porteurs de projet, principalement dans le domaine de l’internet ou de la technologie. Un question fréquente est “par qui faire réaliser ce développement informatique ?”.
Voici mes idées sur le sujet. Attention ce qui suit ne s’applique qu’à des projets raisonnables, impliquant moins de 50 personnes.
Globalement il y a 3 solutions, l’embauche d’un ou plusieurs développeurs, la sous-traitance en régie ou la sous-traitance au forfait (éventuellement off-shore).
En terme d’organisation, l’embauche ou la régie sont comparables, puisque les développeurs travailleront dans l’entreprise. Par contre le coût d’un même profil en souvent plus élevé en régie, mais souvent on obtient quelqu’un plus rapidement que par embauche, et à la fin du projet les prestataires quittent l’entreprise.
J’ai travaillé des développeurs en régie durant une période où recruter était très difficile, alors même que j’avais les moyens de recruter. Franchement c’était une erreur, car l’investissement en formation, encadrement, etc, toujours nécessaire lorsqu’une personne intègre une équipe est en pure perte lorsqu’il est fait pour un prestataire qui partira au bout de quelques mois. Alors à moins d’avoir besoin d’une compétence très pointu, la régie coûte beaucoup trop cher.
J’ai aussi fait réalisé un projet au forfait. Ce fut catastrophique. D’une part il faut dédier une ressource pour assurer l’interface qui devra régulièrement s’occuper du projet à 100 % (définition du cahier des charges, test, recette…). Et pour peu que l’on oublie quelque chose dans le cahier des charges (comme par exemple des performances à tenir), le résultat peut être catastrophique. Quand à l’offshore, même si les coûts horaires sont attractifs, l’exigence en terme de qualité du cahier des charge monte d’un cran donc il faut un projet d’une certaine taille pour rentabiliser les surcoûts de gestion (le gain serait au mieux de 40 % avec de l’offshore par rapport à un prestataire national).
Disposer une équipe de développeurs salariés est de loin la solution la plus productive. La proximité limite les risques d’obtenir un logiciel inadapté, à condition d’utiliser une méthode agile. Les investissements fait en formation sont rentabilités.
Reste la question du coût et des fameux “coup de bourre”. Mon sentiment est qu’il faut passer d’un fonctionnement en mode projet (combien ça coûte, combien ça rapporte) à un mode de gestion des priorités en fonction des ressources (nous avons 3 développeurs, faisons les demandes les plus urgentes, puis réévaluons nos priorité en fonction de nos moyens, ou éventuellement augmentons nos moyens…). J’ai expérimenté qu’une équipe de 6 personnes bien géré pouvaient être plus productive qu’une équipe de 30 personnes désorganisée.
Attention il ne faudrait pas croire qu’une bonne gestion suffit à augmenter la productivité d’une équipe formée de bric et de broc. C’est donner trop d’importance au management ou au processus. Or le développement est une activité intellectuelle, elle n’est pas optimisable comme une activité manuelle. Un bon management consiste à former et valoriser ses équipes, mais aussi savoir ce que chaque personne dans l’équipe peut et ne peut pas faire. On ne transforme pas un développeur débutant en expert simplement parce que CMMi ou RUP est en place dans l’entreprise. A l’inverse ne chercher qu’à embaucher des “génies” est difficile et on risque d’obtenir une équipe déséquilibrée (regardez les résultats des équipes de foot n’ayant que des vedettes…).
Donc mon tiercé est :
- Développement en interne.
- Régie.
- Forfait.
Ce qui pourrait changer la donne en faveur du forfait (surtout offshore), c’est l’utilisation des outils collaboratifs (IM, wiki, blog, bts…), mais cela impliquerait un changement de la nature de la relation commerciale entre le client et le prestataire pour s’affranchir du sacro-saint cahier des charges. Sans doute un paradigme à inventer !
avril 16th, 2005 à 13:36
J’ai fondé en 1998 une boîte au Canada qui a maintenant pigon sur rue en France également. Notre mission: amélioration de processus. J’ai été très impressionné par la convergence émergente des approches Agile et process (par exemple basées sur le CMMI). Voilà que Microsoft s’y lance! et avec la complicité du SEI http://www.weblmi.com/sections/a...
avril 16th, 2005 à 14:47
Bonjour Richard. Effectivement j’ai aussi constaté ce fait, d’une part dans les discours de certains consultants adepte de méthodes formelles, et d’autre part chez Microsoft notamment, avec l’intégration de pratiques agiles dans MSF qui avant s’inspirait plutôt de méthodes formelles comme RUP.
Je crois qu’au dela des pratiques centré sur l’humain plutôt que sur les process qui caractérisent les méthodes agiles, XP a introduit plusieurs pratiques ou concepts dont l’efficacité est indéniable, comme les développement piloté par les tests, le remaniement, l’intégration continue, les livraisons fréquentes et la planification itérative.
Il n’est pas étonnant qu’après une phase de rejet d’XP par les défenseurs du CMMI, le pragmatisme fassent que certaines pratique agiles sont intégrés dans les process plus formels.
Quand à l’implication de Microsoft sur le sujet, l’embauche de Ward Cunningham (l’un des “complices” de Kent Beck) n’y sans doute pas pour rien. De plus la plateforme .Net a beaucoup été utilisé dans des projets XP. J’en parle moi-même souvent en ce moment.
avril 16th, 2005 à 20:33
Je sens qu’on aura de bons échanges.
J’ai été assez amusé de lire que dans ta perspective, ce sont les "Formalistes" qui, fascinés par la souplesse de l’XP, se dirigent vers les "Agilistes"; certains verront plutôt dans cette convergence les "Agilistes" qui s’assagissent et se dirigent vers les "Formalistes". Et, comme ne bien des choses en ce monde, c’est probablement les deux n’est-ce pas?
avril 16th, 2005 à 23:30
Tant mieux, j’ai commencé ce blog pour échanger (et aussi parce qu’en ce moment j’ai du temps libre).
Tu as sûrement raison sur une convergence entre les deux populations, mais à la différence des autres approches, les méthodes agiles et surtout eXtreme programming, comme son nom l’indique, ont été créées et promus par des développeurs. Alors que les autres méthodes viennent de spécialistes de la qualité, de l’organisation ou du management. Ce qui fait que fondamentalement il y a peu d’affinité entre les agilistes et les formalistes. Les méthodes agiles sont quand même fondé en réaction avec les méthodes formelles (tout en étant finalement assez rigoureuses).
En fait je me demande si ma perception ne vient pas du fait qu’en France les méthodes agiles n’ont pas vraiment percés. A ma connaissance il n’y a que quelques consultants spécialistes sur le sujet, et peu de sociétés l’utilisent.
Quand je présentais l’utilisation d’XP dans mon ancienne entreprise, je faisais face à un mélange de scepticisme et d’ironie de la part des français, et à bien plus d’intérêt de la part des anglo-saxons (on m’a même demandé un fois à combien de % j’étais XP et à quel niveau de maturité CMMI je me situais).
Je qui me fais penser que cette convergence (d’où qu’elle viennent) pourra faciliter l’adoption de principes d’agilité en France, et c’est finalement le plus important, car finalement le but de tout ça est d’améliorer la qualité des logiciels produit.