Forum du club des développeurs et IT Pro - Blogs - Dessine-moi un CTO par fluctus https://www.developpez.net/forums/blogs/654313-fluctus/ Developpez.com, le Club des Développeurs et IT Pro fr Thu, 09 Apr 2026 11:55:49 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.jpg Forum du club des développeurs et IT Pro - Blogs - Dessine-moi un CTO par fluctus https://www.developpez.net/forums/blogs/654313-fluctus/ 10 problèmes et leurs solutions possibles pour remettre un projet sur les rails https://www.developpez.net/forums/blogs/654313-fluctus/b10674/10-problemes-leurs-solutions-possibles-remettre-projet-rails/ Fri, 28 Feb 2025 07:18:00 GMT 1. Clarifier les niveaux de... 1. Clarifier les niveaux de délégation et de responsabilité
Contexte
Une équipe ou un manager ne sait pas exactement jusqu’où vont leurs responsabilités (et leur autonomie).

Outils possibles
  • Matrice des rôles et responsabilités : Visualiser les rôles de chacun sur les tâches clés
  • RACI et ses variantes (RASCI, DACI, RAPID, ARPA) : Définir clairement qui fait quoi dans un projet
  • Kanban : Tableau des politiques explicites (formaliser les responsabilités)

NB : le Delegation Poker du Management 3.0 est utile pour clarifier les niveaux de délégation en 1 to 1.

2. Après un incident : apprendre sans blâmer
Contexte
Un échec ou incident majeur a eu lieu, et l’équipe doit en tirer des enseignements.

Outils possibles
  • Blameless Post-Mortem : Identifier les causes profondes sans chercher de coupables
  • Liberating Structures : What, So What, Now What? (structurer l’analyse de l’incident)
  • Management 3.0 : Celebration Grid (transformer l’échec en apprentissage)
  • Kanban : Analyse des incidents sur le flux de travail (identifier les zones de fragilité)
  • PRINCE2 : Rapport de leçons apprises (documenter et améliorer les processus)

3. Gérer les conflits interpersonnels dans l'équipe
Contexte
Des tensions apparaissent entre membres de l’équipe.

Outils possibles
  • Communication Non Violente : OSBD (Observation, Sentiment, Besoin, Demande)
  • Triangle de Karpman & Triangle The Empowerment Dynamic : Identifier les rôles toxiques et les transformer en dynamique positive
  • Liberating Structures : Heard, Seen, Respected (favoriser l’écoute mutuelle)
  • Feedback Wrap (Management 3.0) : Encourager un feedback constructif et bienveillant

NB : expliquer et anticiper les phases de la dynamique d'équipe (modèle de Tuckman) aide à dépasser l'étape Storming.

4. Faciliter un atelier ou une rétrospective
Contexte
Le Scrum Master ou le manager veut rendre ses réunions plus interactives.

Outils possibles
  • Core Protocols : Check-in pour commencer avec un bon état d’esprit
  • Management 3.0 : Kudo Cards (valoriser les contributions)
  • Liberating Structures : 25/10 Crowd Sourcing (brainstorming collectif), What, So What, Now What? (rétrospective efficace)
  • Kanban : Réunion d'amélioration continue basée sur les indicateurs de flux

5. Faciliter une prise de décision collective
Contexte
Une équipe a du mal à converger vers une décision.

Outils possibles
  • Liberating Structures : 1-2-4-All (faciliter la co-construction)
  • Management 3.0 : Delegation Poker (définir qui décide quoi)
  • Core Protocols : Decider (technique de vote rapide)
  • Matrice des rôles et responsabilités, RACI ou équivalents : Définir qui est responsable de la décision
  • Kanban : Priorisation explicite des tâches (visualisation claire des décisions prises)

6. Améliorer la communication dans l’équipe
Contexte
Manque de transparence ou difficultés à s’exprimer.

Outils possibles
  • CNV : OSBD pour structurer la communication
  • Liberating Structures : Conversation Café (donner la parole à chacun)
  • Core Protocols : Perfection Game (donner du feedback constructif)
  • Feedback Wrap (Management 3.0) : Structurer les retours

7. Améliorer la motivation et l'engagement de l'équipe
Contexte
Une équipe semble désengagée ou démotivée.

Outils possibles
  • Management 3.0 : Moving Motivators (comprendre les motivations individuelles)
  • Leadership adaptatif / leadership tribal : Identifier le niveau de maturité de l’équipe et ses membres, pour adapter son style de leadership
  • Liberating Structures : Appreciative Interviews (mettre en avant les réussites)
  • Les 5 dysfonctionnements d'une équipe : Vérifier si le manque d’engagement est lié à un manque de confiance ou de clarté


NB : l'approche Kanban est utile pour éviter la surcharge de travail qui démotive, en mettant en place des limites WIP.

8. Mieux gérer l’incertitude et l’adaptation au changement
Contexte
L’équipe ou l’organisation traverse une période d’incertitude.

Outils possibles
  • Liberating Structures : Ecocycle Planning (analyser le cycle de vie des initiatives)
  • Leadership adaptatif : Encourager l’expérimentation et l’adaptation continue
  • Management 3.0 : Celebration Grid (apprendre de ses erreurs)
  • PRINCE2 : Plan de contingence et gestion des risques
  • Kanban : Révision continue des flux de travail (ajustement rapide aux changements)

9. Renforcer la cohésion d’équipe et l’esprit de collaboration
Contexte
Une équipe nouvellement formée ou en difficulté dans sa dynamique.

Outils possibles
  • PRINCE2 : Réunion par exception (éviter la saturation des agendas en ne tenant des réunions que si un écart majeur est détecté)
  • Modèle de Tuckman : Identifier où en est l’équipe (Forming, Storming, Norming, Performing)
  • Liberating Structures : Troika Consulting (entraide entre collègues)
  • Management 3.0 : Personal Maps (mieux se connaître)
  • Kanban : Tableau des tâches partagées (favoriser la transparence et la collaboration)

10. Gérer la performance et la responsabilisation de l’équipe
Contexte
L’équipe manque d’ownership ou ne respecte pas ses engagements.

Outils possibles
  • Matrice de rôles et responsabilités, RACI : Clarifier la responsabilité de chaque acteur
  • Management 3.0 : Metrics Ecosystem (choisir les bons indicateurs)
  • Liberating Structures : Min Specs (définir les règles minimales à respecter)
  • Leadership tribal : Amener l’équipe à un niveau de maturité supérieur
  • Kanban : Réunion de revue des indicateurs de flux (évaluation continue de la performance)
]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10674/10-problemes-leurs-solutions-possibles-remettre-projet-rails/ Le blitz planning : estimer rapidement un backlog https://www.developpez.net/forums/blogs/654313-fluctus/b10673/blitz-planning-estimer-rapidement-backlog/ Wed, 26 Feb 2025 07:30:00 GMT Le Blitz Planning avec... Le Blitz Planning avec estimation par paliers est une méthode rapide et pragmatique pour structurer efficacement un projet en difficulté.

Il permet de clarifier les tâches, gérer les dépendances et ordonnancer intelligemment le travail, sans s’enliser dans des estimations complexes et peu fiables.

Cette approche est particulièrement utile lorsqu’un projet accumule des retards, un manque de clarté sur les priorités, et des équipes désalignées.
Utile pour relancer un projet en crise, en fournissant une vision claire des priorités et en alignant toute l’équipe vers un plan d’action réaliste et exécutable immédiatement.

Les problèmes courants des projets en difficulté :
  • Un manque de visibilité sur les tâches restantes.
  • Des retards non maîtrisés et des engagements non tenus.
  • Une gestion défaillante des dépendances, causant des blocages.
  • Un stress et une confusion croissants au sein de l’équipe.

Le Blitz Planning permet de reprendre le contrôle rapidement en structurant les actions à réaliser et en les ordonnançant de manière efficace.
Il évite aussi les pertes de temps liées aux estimations trop détaillées, en utilisant la technique d’estimation par paliers.

Préparer et mener l’atelier de Blitz Planning
Préparation de l’atelier
Participants à impliquer :
  • L’équipe de développement.
  • Le Product Owner ou Chef de projet.
  • Les parties prenantes clés (si nécessaire).


Matériel nécessaire
  • Un tableau physique ou un outil numérique (Miro, Mural, Jira, Trello).
  • Post-it pour noter les tâches.

Durée estimée
Entre 2h et 4h, selon la taille du projet et le nombre de tâches à structurer.
4h peuvent suffire pour estimer les travaux d'une équipe de 4 développeurs sur 6 mois.

Déroulement de l’atelier
Étape 1 : Identification des tâches
L’équipe liste toutes les tâches restantes à accomplir.
Chaque tâche est notée sur un post-it ou une carte numérique.

Étape 2 : Regroupement et clarification
Suppression des doublons et regroupement des tâches similaires.
Reformulation des tâches pour garantir une compréhension partagée.

Étape 3 : Estimation qualitative avec la technique d’estimation par paliers
Plutôt que de donner des estimations précises, les tâches sont classées selon quatre paliers d’effort.
Posez-vous ces questions simples. "La tâche durera probablement ?"
  • Moins de 2 heures
  • Moins de 2 jours
  • Moins de 2 semaines
  • Au-delà de 2 semaines

Cette approche permet de réduire le temps passé en discussions, tout en conservant une vision claire de l’effort global.

Étape 4 : Identification et gestion des dépendances et adhérences
L’équipe analyse les tâches pour repérer :
  • Les dépendances : une tâche A doit être terminée avant qu’une tâche B puisse commencer.
  • Les adhérences : des tâches qui ne sont pas strictement dépendantes, mais qui doivent idéalement être réalisées ensemble pour éviter des incohérences ou des doublons de travail.

Exemple :
  • Une dépendance serait "Déployer le serveur avant de configurer la base de données".
  • Une adhérence serait "Créer le design UX et intégrer les retours utilisateurs", car ces tâches peuvent avancer en parallèle mais doivent rester cohérentes.

Un code couleur peut être utilisé sur le tableau pour identifier visuellement ces relations entre tâches.

Étape 5 : Ordonnancement des tâches
Une fois les dépendances et adhérences identifiées, les tâches sont ordonnancées de manière logique :
  • Les tâches critiques et bloquantes sont traitées en priorité.
  • Les tâches avec des adhérences sont regroupées pour éviter des retouches ultérieures.
  • Les tâches indépendantes peuvent être parallélisées entre plusieurs membres de l’équipe.

L’objectif est d’optimiser le flux de travail et de minimiser les temps d’attente.

Après l’atelier : Mise en action et suivi
  1. Transférer les tâches dans votre outil de gestion de projet.
  2. Visualiser l’avancement pour adapter en temps réel.
]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10673/blitz-planning-estimer-rapidement-backlog/ Initiation à No Estimates (partie 1) https://www.developpez.net/forums/blogs/654313-fluctus/b10672/initiation-no-estimates-partie-1/ Mon, 24 Feb 2025 07:24:00 GMT No Estimates est une approche... No Estimates est une approche qui propose de supprimer ou réduire l'importance des estimations dans la gestion de projet, en particulier dans le développement logiciel. Plutôt que de se focaliser sur des prévisions souvent imprécises, No Estimates encourage l'exécution immédiate des tâches, avec un suivi basé sur des mesures empiriques.

No Estimates met l'accent sur :
  • l’amélioration du flux de travail pour livrer plus vite ;
  • l’utilisation des données passées (Lead Time, Cycle Time) pour prévoir les livraisons ;
  • la livraison continue et l’adaptation progressive aux besoins.

L'objectif est donc de remplacer les estimations par des métriques réelles et mesurables, et ainsi réduire le gaspillage de temps lié aux estimations longues et souvent erronées.

Duarte et d'autres partisans du mouvement ont observé que les estimations étaient souvent source d'erreurs, de frustration et de retard, et que les équipes pouvaient mieux travailler en se concentrant sur des cycles courts et des métriques de flux réels plutôt que sur des prévisions arbitraires.

No Estimates trouve aussi ses racines dans les principes du Lean et du Kanban, qui mettent l'accent sur l'amélioration continue et la réduction du gaspillage.

No Estimates = Not Only Estimates
Le terme No Estimates ne signifie pas que les équipes ne font jamais d’estimations, mais plutôt qu’elles s’appuient sur des données empiriques et des mesures de productivité pour améliorer la planification et la prédictibilité.

Plutôt que d’essayer de deviner combien de temps prendra une tâche :
  • les équipes analysent combien de tâches similaires ont été réalisées dans le passé ;
  • elles utilisent le flux de travail pour évaluer combien de tâches peuvent être complétées en une période donnée ;
  • elles se concentrent sur la réduction de la taille et de la complexité des tâches pour mieux avancer.

C'est pourquoi certains parlent de "Not Only Estimates", mettant en avant une approche où les décisions sont basées sur des faits et non des suppositions.

Elle est particulièrement populaire car :
  • elle élimine les biais et erreurs des estimations classiques ;
  • elle permet une focalisation sur l’amélioration continue ;
  • elle réduit la charge mentale et la perte de temps liée aux réunions d'estimation.

Le mouvement #NoEstimates a émergé sur Twitter, notamment grâce à l'initiative de Woody Zuill.
Il a utilisé ce hashtag pour lancer des discussions sur des alternatives aux estimations traditionnelles en développement logiciel.
Par exemple, en décembre 2012, il a tweeté :
"#NoEstimates - I've added a little more fuel to the fire"

Quelques ressources du mouvement #NoEstimates :

No Estimates dans le cadre du redressement de projets
Lorsqu’un projet est en difficulté (dépassement de budget, retard, mauvaise gestion des priorités), No Estimates peut être un levier puissant pour remettre le projet sur les rails.

Pourquoi ?
  1. Éliminer les prévisions fausses : Beaucoup de projets échouent parce que les estimations initiales étaient trop optimistes ou inexactes. No Estimates permet de baser la planification sur des données réelles plutôt que des suppositions.
  2. Accélérer la livraison : En se concentrant sur l'exécution plutôt que sur les estimations, les équipes livrent plus vite et s’adaptent plus facilement aux besoins réels du projet.
  3. Améliorer la visibilité : En suivant des métriques comme le Lead Time et le Cycle Time, on obtient une vision plus fiable des délais de livraison.
  4. Réduire la complexité : No Estimates encourage le découpage des tâches en petits lots, ce qui simplifie le travail et facilite l’alignement avec les objectifs stratégiques.

Comment l’appliquer dans un projet en difficulté ?
  1. Stopper les longues réunions d’estimation et passer directement à l’exécution.
  2. Utiliser un tableau Kanban pour visualiser le flux et réduire le temps de cycle.
  3. Mesurer la cadence réelle des livraisons pour mieux prévoir la suite du projet.
  4. Prioriser les tâches critiques et éliminer les dépendances inutiles.
  5. Réduire la taille des tâches pour accélérer la mise en production.


No Estimates est une approche pragmatique qui remet en question les pratiques traditionnelles d’estimation.

En supprimant les prévisions peu fiables et en se basant sur des données concrètes et un flux de travail efficace, cette méthode favorise la rapidité, la flexibilité et la transparence.

Idéale pour les équipes agiles et les projets en difficulté, No Estimates n’est pas une solution miracle, mais une alternative aux estimations traditionnelles
qui permet de se concentrer sur ce qui compte vraiment : livrer rapidement et efficacement. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10672/initiation-no-estimates-partie-1/ <![CDATA[Quelles techniques d'estimation utiliser ?]]> https://www.developpez.net/forums/blogs/654313-fluctus/b10671/techniques-d-estimation-utiliser/ Fri, 21 Feb 2025 15:32:00 GMT La plupart d'entre nous ne maîtrisent qu'une ou deux techniques d'estimations.
Parfois, aucune.

Je vous ai préparé un tableau comparatif pour choisir la technique la plus adaptée à votre contexte.

Nom : Capture d’écran 2025-02-22 à 18.02.00.png Affichages : 2753 Taille : 241,2 Ko
Nom : Capture d’écran 2025-02-20 à 11.26.06.png Affichages : 3317 Taille : 363,4 Ko
Nom : Capture d’écran 2025-02-20 à 11.26.19.png Affichages : 3324 Taille : 373,4 Ko
Nom : Capture d’écran 2025-02-20 à 11.26.38.png Affichages : 3318 Taille : 111,7 Ko

#NoEstimate semble un peu à part, voir étonnante dans cette liste.
Mais abordée sous l'angle Not Only Estimates,
elle prend tout son sens en complément des autres méthodes,
pour attendre de sortir du cône d'incertitude avant de pouvoir estimer efficacement (avec une technique adaptée au contexte).
Images attachées
]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10671/techniques-d-estimation-utiliser/ Estimations : arrêtons l’hypocrisie ! https://www.developpez.net/forums/blogs/654313-fluctus/b10670/estimations-arretons-l-hypocrisie/ Thu, 20 Feb 2025 09:42:03 GMT Stress, pression et... Stress, pression et frustration.
Les estimations traditionnelles sont un piège !

  • Fausses par nature.
    Mike Beedle : "Estimates are the best lie we can give you."
    Elles reposent sur des hypothèses floues et biaisées.
  • Souvent faites trop tôt.
    Le cône d’incertitude de Steve McConnell montre que toute estimation réalisée trop en amont est, de facto, imprécise.
  • Détournées pour les besoins budgétaires.
    L’argent ne pousse pas sur les arbres. Quand on finance la R&D via un emprunt, la banque veut connaître le budget global. C’est notre responsabilité d’apporter de la visibilité, mais sur des bases réelles, pas sur des paris.
  • Forcent les équipes à entrer dans un cycle de justification absurde.
    Au lieu de se concentrer sur l’avancement réel.
    Un projet qui dépasse une estimation initiale n’est pas nécessairement en échec, mais il sera perçu comme tel.


Les estimations sont une illusion !

Faut-il jeter toutes les techniques d’estimations à la poubelle ?
Pas forcément. Mais il faut les repenser.

Une alternative : les estimations par paliers

Plutôt que de jouer à deviner l’avenir, poser une question simple :
"Est-ce que cette tâche demande (hors gros imprévus) :"
  • Moins de 2 heures
  • Moins de 2 jours
  • Moins de 2 semaines
  • Au-delà.



Ainsi, on parle directement un langage commun à tous.
Exit les estimations en points (de quoi ?), traduites en jours/homme à coup de règles de 3.
En prime, cette méthode permet d’identifier rapidement les tâches mal définies ou trop risquées.

Les estimations traditionnelles sont une fausse sécurité

"No Estimates" ne signifie pas abandonner toute planification, mais plutôt baser les décisions sur des mesures empiriques et un bon découpage des tâches.
Arrêtons de nous mentir, et apprenons à travailler avec des repères réalistes. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10670/estimations-arretons-l-hypocrisie/ Remettre une équipe sur pieds avec Kanban https://www.developpez.net/forums/blogs/654313-fluctus/b10276/remettre-equipe-pieds-kanban/ Fri, 04 Feb 2022 17:02:51 GMT Les défections se succèdent... Les défections se succèdent dans l'équipe, chaque jour votre crainte augmente : que le dernier développeur qui connaît l'application vous quitte.

Le dernier des mohicans
Certes, vous avez entamé un plan de Knowledge Management qui pourrait aider à limiter la casse.
Vous avez demandé de consigner soigneusement dans le wiki toutes les connaissances sur cette application critique pour votre entreprise :
  • Architecture de l'application,
  • maintenance à effectuer régulièrement,
  • mots de passe et autres accréditations nécessaires,
  • principales pannes courantes,
  • modes opératoires complets pour des pannes graves,
  • contacts à solliciter,
  • inventaire complet des risques priorisés avec MoSCOW.


Mais tout-le-monde sait que la montée en compétence d'un éventuel successeur serait rude, surtout si vous ne parveniez pas à réaliser un transfert efficace avant son départ.
Le best case scenario serait quand même de parvenir à le garder.

Un nouvel espoir
L'enjeu étant cerné, reste à bâtir un plan de reconquête.

Dans un contexte où les départs se multiplient, ceux qui restent sentent le poids des responsabilités peser de plus en plus sur leurs épaules.
Au fil du temps leur stress augmente, et avec lui les risque de burn out ou départ, même pour une offre moins attractive que leur position actuelle.
Ce n'est pas juste une question de rémunération, c'est d'abord une question de pression.

Il ne suffira pas seulement d'embaucher pour combler les pertes. Il va falloir sécuriser et re-motiver toute cette équipe.

Renégocier pour restaurer la confiance
La première tâche nécessaire est la sécurisation du backlog. Avec une todo list longue comme un jour sans pain, pas étonnant que les développeurs se démotivent.
Il va falloir prendre votre bâton de pélerin et aller négocier avec chaque partie prenante :
  • mettre les stakeholders face aux enjeux (capacité à faire, risque de défaillance des systèmes, risque de départs dans l'équipe, etc.) ;
  • re-prioriser avec eux les demandes, en alignant les priorités sur la stratégie d'entreprise ;
  • rendre visible de tous la nouvelle roadmap négociée (donner 2-3 mois de visibilité, pas plus) ;
  • annoncer clairement les demandes qui devront être abandonnées.


Repartir sur de meilleures bases
Ce type de crise est une excellente opportunité de changer les façons d'aborder les problèmes :
  • obtenir plus d'implication au quotidien des parties prenantes, pour une meilleure définition des besoins, avec une spécification juste à temps (plutôt qu'une longue phase de spécification) ;
  • simplifier les cahiers des charges pour raccourcir les délais de livraison grâce à une approche frugale du logiciel ;
  • refactoriser souvent plutôt que de chercher à concevoir du code générique/évolutif ;
  • abandonner les demandes de correction pour des défauts mineurs, adopter une approche "qualité suffisante" ;
  • proposer de transformer en paramètres applicatifs, des demandes qui étaient jusque-là satisfaites par du développement et donnaient lieu à des modifications fréquentes du code ;
  • déporter des fonctionnalités vers des petits logiciels dédiés, plutôt que d'augmenter la complexité du logiciel principal ;
  • troquer des logiciels trop lourds à maintenir en interne, pour des logiciels SAAS ;
  • troquer des logiciels sur mesure trop lourds à configurer et/ou maintenir, pour des logiciels génériques (open source ou propriétaires).


Changer de vocabulaire pour rendre le changement visible
Beaucoup d'équipes ont souffert d'une implémentation incomplète de Scrum (culte du cargo, "scrum but"...).
Cela conduit au rejet de l'agilité. Pour que les nouveaux process soient mieux acceptés par l'équipe, changez de méthode (au moins en apparence).
Il ne s'agit pas de duper les développeurs, mais au contraire de rétablir la vérité. Ce qui fait l'efficacité de Scrum, ce n'est pas les sprints, les daily, et les planning pokers. C'est la mise en œuvre constante des 3 piliers de l'empirisme (transparence, inspection, adaptation). Un reboot de Scrum s'impose.

En annonçant que vous allez vers une autre méthode (Kanban, eXtreme Programming, AgileUP, Heart of Agile...), vous déplacez l'angle de la caméra pour permettre aux parties prenantes de repartir sur de meilleures bases, en mettant cette fois-ci en œuvre les bases qui rendent l'agilité vivante.

Si vous pratiquez le cycle en V, mais qu'aucun projet n'est autorisé à revenir dans une phase précédente pour corriger les défauts logiciels, vous êtes également victime d'une erreur méthodologique grave. Pour remettre les choses d'équerre, il peut aussi être utile de changer de vocabulaire. Adoptez RUP, Prince2, ou le PMbok, pour aider l'entreprise à respecter les règles de base de la gestion de projet.

Rétablir un delivery fluide
Paradoxalement, si vous n'arrivez pas à livrer, c'est en livrant plus souvent que vous améliorerez la situation !

Les sprints d'un jour sont d'une efficacité redoutable pour obtenir ce changement :
chaque matin au daily meeting, demandez au développeur ce qu'il pense qu'il peut raisonnablement livrer pour le lendemain. Ne négociez pas son estimation. Le but est d'amener l'équipe à s'engager uniquement sur des choses tenables. En constatant jour après jour, qu'elle arrive à tenir ses engagements et surtout qu'elle voit ses progrès vers le but annoncé, l'équipe va reprendre confiance en elle.

Du côté des parties prenantes, en communicant chaque semaine ou toutes les 2 semaines sur les objectifs concrets atteints par l'équipe, les stakeholders vont également reprendre confiance dans la capacité de l'équipe à atteindre ses engagements. Les estimations de l'équipe seront moins challengées, ses refus seront mieux acceptés. Le respect mutuel sera restauré.

Kanban comme méthode universelle ?
L'intérêt de Kanban, est que cette méthode s'adapte aussi bien à des contextes agiles comme waterfall, pour visualiser le flux de travail et réduire le WIP (Work In Progress). En temps de crise, cesser de paralléliser et ne plus faire qu'une seule seule chose à la fois, permet de rendre visible les progrès et de rétablir la confiance.

Une fois qu'on a goûté à ce confort de travail, il est impossible de revenir en arrière.
Pour démarrez, un guide Kanban illustré est disponible gratuitement en ligne et en français. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10276/remettre-equipe-pieds-kanban/ CTO : Comment conjurer la malédiction de la V2 ? https://www.developpez.net/forums/blogs/654313-fluctus/b10278/cto-conjurer-malediction-v2/ Fri, 14 Jan 2022 06:17:00 GMT Dans le dernier billet... Dans le dernier billet, nous avons parlé de la malédiction de la V2.
Un mal profond qui met en péril la plupart des éditeurs de logiciels.
Cette semaine, place aux remèdes possibles.

Résumé des épisodes précédents
Après une version 1 à succès, cet éditeur de logiciel se retrouve comme beaucoup d'autres incapable de sortir la V2 qui devait lui apporter un relais de croissance. L'entreprise n'est pas loin de déposer le bilan.

sevyc64 ajoute avec beaucoup de justesse :
Et ce que tu oublies de dire, c'est que, en réponse au succès de la V1, les concurrents, eux, ont fait la "V2" et sont même sur le point de sortir la beta de ce qui aurait pu être la "V3"

C'est bien de se retrouver leader à moment donné, et de prendre tout le marché aux concurrents, mais il faut pas perdre de vue, que la place, quand on la veut, il faut dore et déjà prévoir qu'il faudra tout faire, ensuite, pour la garder. Et que la concurrence ne restera pas les bras croisées.

J'ai comme la sensation de vivre cette histoire, en ce moment dans ma boite.
Un nouvel espoir
Si votre entreprise est dans cette situation, que faire pour redresser la barre ?
Les mesures de redressement financier ne suffiront pas. Diminuer les effectifs, c'est aussi hypothéquer l'avenir. Avec quelles ressources trouverez-vous des relais de croissance ?

Trouver un pivot marché
J'ai travaillé chez un éditeur qui ne trouvait plus de relais de croissance.
Face à un client lourd vendu à des grands comptes, un concurrent SAAS prospérait en vendant à des clients plus petits des abonnements pour une application web. Nous étions sur un marché en consolidation, tandis qu'eux avaient découvert une océan bleu.
Dans le même temps, un marché proche était également en croissance, celui des logiciels vétérinaires.
Il y avait donc 2 possibilités de pivot qui pouvaient être testées :
  1. déployer des logiciels web open source concurrents ou louer des accès à notre logiciel à travers une prise en main à distance, pour vérifier si nous pouvions nous positionner face à ce concurrent SAAS
  2. ajouter à un logiciel open source ou à notre base de données la notion de "propriétaire du patient" (propriétaire de l'animal) pour vérifier si nous pouvions nous positionner sur ce marché proche, celui des logiciels vétérinaires.


En guise de MVP, une page web décrivant l'offre, quelques coups de téléphone pour démarcher en complément, et nous aurions pu vérifier si nous étions en capacité d'attirer des prospects.
Dans les 2 cas, une fois la demande validée par ce MVP, pour satisfaire pleinement ces nouvelles demandes, nous pouvions déployer des logiciels open source concurrents de notre offre, en les remodelant juste ce qu'il faut.

Pendant ce temps, faute de croissance sur son marché principal, le CEO positionnait l'entreprise sur d'autres marchés connexes (prise de rdv, prise en charge d'autres spécialités médicales). Cela nous amena à financer le développement de plusieurs autres logiciels. Ces pivots n'amenèrent pas la croissance espérée. Aucun ne trouva de débouchés, sauf un développement rapide et bon marché, celui du rappel de rdv (envoyer un sms pour éviter les rdv non honorés par les patients).

Le CEO était proche de la retraite. Bien que le marché soit en consolidation, nous avons remporté un appel d'offre. Notre situation financière saine permit de trouver un repreneur.

Avant la catastrophe

Le repreneur ne réalisa pas de chiffre d'affaires significatif l'année suivante. Les abonnements de support logiciel finançaient les frais fixes, mais il ne trouva pas de nouveau client.
Face à cette situation, il pouvait décider de tester les deux pivots SAAS/vétérinaire à peu de frais, mais il ne vit probablement pas ces opportunités.
Face à une situation bouchée, il reste cependant toujours une dernière possibilité :
  • faire l'inventaire des compétences disponibles en interne, et les proposer en prestation.


En effet, nos équipes étaient particulièrement aguerries sur les technologies Oracle. Et d'autre part, l'entreprise entretenait un service support, qui aurait pu être proposé pour compléter celui d'autres entreprises ou apporter du support sur des solutions open source concurrentes. Ainsi, les compétences seraient restées en interne et nous aurions eu du temps pour conduire d'autres tests marché.

Réussir sa V2
Dans le billet précédent nous avons vu que dédier une équipe distincte pour développer la V2 ne produisait pas les résultats escomptés. Pourquoi ?

Nouveau produit = nouveau MVP
Parfois, remanier l'architecture ou recopier la V1 dans une nouvelle technologie peut marcher. Je l'ai déjà réussi, dans un contexte où un client pensait tirer un avantage concurrentiel à travers notre solution. Et c'est d'ailleurs ce client qui s'est engagé à financer intégralement 1 an de développement pour cela.

Comme l'a souligné sevyc64, le marché a probablement changé depuis l'introduction de notre logiciel : les concurrents se sont mis à niveau, et il peut maintenant être difficile de convaincre face à eux.
Il est donc vital de réduire les risques en testant à nouveau notre proposition de valeur via un MVP.
Ce nouveau test marché sera peut-être l'occasion de découvrir des besoins actuellement non satisfaits par les offres disponibles. Ces besoins pourraient constituer des relais de croissance intéressants (cf le logiciel de rappel de rdv vu précédemment).

Structurer les équipes pour scaler
Les entreprises se structurent souvent d'une façon un peu naïve, en copiant un modèle hiérarchique répandu.
Or, dans le cas d'un éditeur l'activité de production logicielle est critique, et s'accommode mal de ces structures classiques : une organisation centrée sur les produits est nécessaire.


Lutter contre l'entropie logicielle
Nous avons vu dans le billet précédent que, au fil du temps, le logiciel devient de plus compliqué à maintenir. Cela se reflète dans des métriques Sonar telles que la complexité cyclomatique.
Repartir à zéro sur un nouveau développement semble la seule solution du point de vue des développeurs.
Mais si l'on se place du point de vue financier il n'y a pas là une réelle création de valeur. Après tout, l'ancienne version fait déjà le job.
Alors, comment procéder pour remettre le code d'équerre ?

Réduire la complexité
Pour rendre le code plus facile à maintenir et évoluer, il sera probablement nécessaire de :
  • se séparer des clients qui refusent de monter sur la dernière version et préfèrent rester sur des versions plus anciennes (pour lutter contre la complexité engendrée par la fragmentation des versions)
  • se séparer des clients qui veulent des garder des fonctionnalités sur mesure spécifiques, que nous ne pouvons pas intégrer dans notre offre globale (pour lutter contre la complexité cyclomatique).


- Nous verrons dans un prochain billet que la valeur ajoutée d'un logiciel "sur étagères" repose justement dans cet alignement sur les meilleurs process. -

Découper verticalement
Pour faciliter l'évolution du code et de l'architecture, nous pouvons profiter des demandes d'évolution de fonctionnalités existantes.
En s'appuyant sur la démarche eXtreme Programming, l'équipe de développement va refactoriser le code.

Il sera important que le Product Owner découpe verticalement les évolutions ou fonctionnalités. En applicant la technique du hamburger, l'équipe découvrira des opportunités de refactoring sur certaines couches logicielles. La roadmap devra intégrer ces changements : on répartira le coût de refactorisation d'un composant sur les sprints à venir. Ainsi, tout en livrant de la valeur, l'équipe pourra procéder à la refonte complète d'une couche logicielle.

Nom : hamburger_step_1-282x300.png Affichages : 219 Taille : 87,5 Ko

Refactoriser la couche de stockage
La généralisation des ORM amène souvent à un usage assez pauvre des SGBD.
Il serait pourtant dommage de se priver des possibilités que les vues SQL nous amènent pour favoriser le refactoring.
Une première étape dans le refactoring peut donc être de ne plus requêter directement sur les tables, mais de s'astreindre à passer systématiquement par une vue. On peut ainsi ajouter ou modifier des champs dans la base de données, sans mettre en danger le code existant.

Pour les insertions et mises à jour de données, passer par des procédures stockées va également aider à découpler le SGBD du code qui y accède (couche modèle dans le pattern MVC). C'est le concept de bases de données épaisses.

Amener du découplage dans un client lourd
La généralisation des environnements RAD comme Visual Studio a amené à fusionner les couches présentation et métier.
Pour découpler ces couches, il peut être intéressant de transformer l'application pour obtenir une interface graphique qui exécute des applications en ligne de commande. C'est d'ailleurs un standard dans le logiciel médical, notamment pour les applications qui utilisent le toolkit DICOM DCMTK.

Micro services, maxi complexité
Les patterns des grands du web inspirent souvent les refontes logicielles. Mais ils ont un coût, notamment en termes de complexité.
Combien d'équipes s'aperçoivent après coup qu'elles ont succombé au hype-driven development ?

Les logiciels sur étagère héritent souvent d'une architecture monolithique. C'est loin d'être un anti-pattern.
Il est tout-à-fait possible de rendre un monolithe adaptatif, et c'est souvent le meilleur choix pour un client lourd.

Amener du découplage dans une application web
Le web est devenu une sorte d'enfer des dépendances, particulièrement dans l'éco-système javascript.
La dette technique et les coûts de maintenance explosent, tirés par les fréquentes et indispensables mises à jour de composants.

Une application web peut bénéficier d'une ré-écriture qui va diminuer la taille du graphe de dépendances, en rationalisant l'usage qui est fait des frameworks.
Les frameworks comme Angular proposent maintenant des fonctionnalités qui permettent de ne charger que les composants correspondant aux fonctionnalités réellement utilisées.
Il peut également être intéressant de s'intéresser sur l'usage qui est fait de ces frameworks dans notre application. Beaucoup de sites ecommerce ou institutionnels utilisent des frameworks conçus pour des applications web. Si votre application n'est pas un tableur, il y a fort à parier que vous n'avez pas besoin d'Angular. De même, si votre application n'est pas un réseau social, il y a peu de chance que React soit un choix rentable.
KISS (Keep It Simple Stupid) : utilisez les fonctionnalités natives HTML5/CSS3, revenez à des librairies plus simples (Jquery), abandonnez des effets graphiques inutiles, et vous diminuerez vos coûts.

Tirer partie de la JAMstack
Utiliser l'approche JAMstack permet de refactoriser rapidement une application web, en bénéficiant d'un scalabilité quasi infinie.
il peut être intéressant de démarrer notre V2 en remplaçant certaines fonctionnalités natives de notre solution SAAS par des API tierces (paiement, panier, emailing, etc.). Cela peut permettre de rénover rapidement et à peu de frais des portions de code devenues fragiles ou coûteuses à maintenir. Et donner du temps pour les rénover en profondeur. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10278/cto-conjurer-malediction-v2/ CTO : Comment structurer les équipes de développement ? https://www.developpez.net/forums/blogs/654313-fluctus/b10280/cto-structurer-equipes-developpement/ Thu, 13 Jan 2022 05:00:00 GMT Pas de réponse tranchée dans... Pas de réponse tranchée dans ce billet, mais des pistes à explorer...

Ford vs Toyota
  • Le modèle tayloriste a assuré à Henri Ford le succès que l'on sait dans l'industrie naissante de l'automobile.
  • La méthode Toyota a par contre permis aux entreprises qui l'ont adopté de dépasser leurs concurrentes adeptes du taylorismes.


Pour quoi ?
  • Le modèle tayloriste est conçu pour réaliser une produit standardisé, voir unique (la Ford T), avec des structures de production ne nécessitant pas une main d’œuvre qualifiée. Le travailleur est généralement recruté pour la seule force de ses bras.
  • Le système Toyota favorise au contraire l'adaptation, en se focalisant à l'origine sur l'optimisation du temps de changement d'outil. Dans ce contexte, l'intelligence individuelle et collective des opérateurs est au contraire fortement sollicitée.


Je vous laisse deviner à quel système ressemble le plus le développement logiciel...

Loi de Conway
« les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. »
— M. Conway
Dit autrement :
“If you have four groups working on a compiler, you'll get a 4-pass compiler”
Faut-il réorganiser votre entreprise ?
"Les entreprises ont recours à la réorganisation comme à un remède miracle au lieu de diagnostiquer leurs maux"
— Peter Drucker

Découpage horizontal vs découpage vertical
  • Le découpage horizontal organise les équipes suivant une logique technologique (frontend, backend, mobile, etc).
  • Le découpage vertical oganise les équipes selon une logique produit (1 équipe = 1 produit ou 1 gamme).


Dans cet article, Thiga liste les antipatterns, ainsi que les forces et faiblesses associées à ces typologies : 4 grands modèles d'organisation produit.

Cas de l'entreprise à produit unique
Si je suis Spotify ou Deezer, quel modèle me permettra d'accompagner au mieux ma croissance ?
Component team vs feature team — Que choisir ?
Le framework LeSS pourra vous aider à faire un choix et à le mettre en œuvre.

Et Scrum là-dedans
Pour faire simple :
1 produit = 1 Product Owner = 1 à 9 équipes de développement (Scrum + Nexus).

Cas de l'entreprise à produit unique et projets multiples
C'est le cas par exemple d'un éditeur de logiciel B2B : chaque client doit être accompagné individuellement pour l'intégration, le paramétrage, la formation et le déploiement de la solution.

Le plus mauvais choix : des équipes écartelées entre les projets
Avec une organisation purement technique des équipes, on se retrouve souvent à jouer aux petits trains. Les clients stratégiques passent devant les autres, comme le TGV passe avant les TER en cas de retard. Avec à la clé un bad buzz chez les clients TER.
L'origine du mal se trouve dans la parallélisation des projets. Et vous la payez au prix double :
  • non seulement vous payez le prix de la gestion complexe des plannings ;
  • mais en plus, vous payez le prix du context switching chez les équipes.

A la clé : démotivation des équipes, clients énervés, stress, équipes poussées à la faute du fait du stress et des retards permanents.

Pistes pour améliorer le delivery
Selon le contexte, on peut notamment essayer de :
  • gérer certains clients en mode projet (rassemble dans la même pièce toutes les compétences nécessaires) : permet d'éviter que les clients stratégiques perçoivent les effets de notre organisation "startp & stop";
  • gérer le portfolio projets en mode Kanban avec un Work In Progress de 1 pour chaque équipe : soulage les équipes et améliore le delivery en évitant le context switching;
  • découper finement les incréments du portfolio, pour obtenir un temps de cycle faible : chaque semaine chaque équipe sert au moins 1 client. Fluidifie le delivery.
  • sprints très courts (1 jour à 2 semaines) : pour fluidifier le delivery, une fois qu'on a réalisé un découpage fin. Permet à chaque équipe de livrer les clients 1 à 1. Célébrer chaque livraison permet de donner aux équipes un feedback motivant.


Cas de l'entreprise avec plusieurs produits
Dans ce contexte, aller vers un découpage horizontal me semble globalement aller contre l'orientation produit nécessaire.
Cependant, lorsque l'expertise nécessaires à certaines couches techniques est très élevée, les équipes pluri-disciplinaires peuvent manquer d'autonomie. On choisit souvent de mettre sur pied quelques équipes qui mutualiseront les expertises nécessaires (data, infra...). Ces équipes deviennent naturellement des goulots d'étranglement.

Pour conserver un delivery global fluide, il est donc nécessaire de conserver du "slack" dans notre système en ne saturant pas l'emploi du temps de ces équipes. Il est nécessaire de conserver des marges confortables à leur niveau.

Dans le système Toyota, l'optimisation des ressources s'obtient en protégeant ce bottleneck grâce à du stock en entrée. Ainsi cette équipe sera toujours au plus près de 100% d'efficacité. Par contre, notre delivery sera entièrement dépendant du rythme de cette équipe.

Globalement, conserver un logiciel en état de livraison permanent et livrer fréquemment, seront des éléments clés pour conserver une réelle visibilité dans le portfolio... et des clients heureux ! ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10280/cto-structurer-equipes-developpement/ Editeurs de logiciels : la malédiction de la V2 https://www.developpez.net/forums/blogs/654313-fluctus/b10274/editeurs-logiciels-malediction-v2/ Sat, 08 Jan 2022 16:03:28 GMT Presque tous les éditeurs de... Presque tous les éditeurs de logiciels rencontrent le même obstacle à leur croissance : la plupart échouent à sortir la V2 de leur application.
Sortez les pop corns et glissez-vous confortablement dans votre fauteuil préféré.
Cette histoire combine tous les ingrédients du film catastrophe : des choses sales cachées dans les ténèbres, des secrets de famille qui explosent au grand jour, des héros trop téméraires, un naufrage annoncé, et au final des clients abandonnés à leur triste sort.

Vous avez dit dette technique ?
L'histoire commence comme un conte de fées. Un professionnel expert de son domaine, sorte de Geo Trouvetout, se confectionne un outil sur-mesure avec Excel ou un outil noCode.
Ayant enfin découvert la pierre philosophale, il en fait un logiciel qu'il vend comme des petits pains aux professionnels de sa spécialité.

S'il vend si facilement, c'est parce qu'il promet à chacun une solution sur-mesure à ses problèmes. Et voilà le code qui enfle sournoisement à coup de "if client" et "if site". Ajoutez à cela que la V1 a été codée dans l'urgence au fond du garage avec un livre d'initiation à VB6 sur les genoux. Ce secret de famille est d'autant moins visible pour les clients, que l'équipe n'a même pas encore conscience du problème. Minuit est près de sonner...

Un héritage empoisonné
Le temps passant, la complexité cyclomatique augmente donc, et avec elle son lot de patchs destinés à rafistoler le code qui tourne au monstre de Frankeinstein.
L'architecture est incertaine et chancelante. Quelques professionnels ont bien tenté courageusement de redresser la qualité, mais l'entropie ramène toujours le code du côté obscur.

Pourtant côté commercial, le soleil est au beau fixe. D'outsider, l'éditeur est devenu reconnu sur son marché et attire des clients de plus en plus importants. Des clients bien plus mûrs aussi en termes de relation fournisseur. Ils demandent des garanties sur la qualité du produit : certification CMMI, audit technologique, audit de qualité du code. Pour convaincre ces juteux marchés, il va falloir opérer une refonte complète.

Le temps des héros
Difficile de mener de front le support de la V1 et l'écriture de la V2. On met sur pied une seconde équipe faite de professionnels expérimentés. La direction les charge de concevoir une version faite pour durer.

La pression les amène à minimiser les risques : ils révisent les livres de Jacques Printz, et mènent une veille active sur les meilleures architectures logicielles du moment. Persuadés de bâtir une cathédrale, forts d'un cahier des charges précis et soigneusement documenté (copier la V1 dans une nouvelle technologie), ils passent de longues semaines à concevoir l'architecture de la V2.
Après quelques semaines ou mois, les voilà plongés dans l'écriture du code qui constituera les fondations. Les pourcentage de progrès sont encourageants, le cap est ferme et les commits fréquents.

Pendant ce temps, l'autre équipe se mobilise héroïquement pour assurer le support et les développements pour les nouveaux clients qui démarrent sur la V1. Il faut tenir, le temps que la V2 arrive.

La relève ne viendra pas
Les départs et les burn out se succèdent dans l'équipe V1. Le code est de plus en plus difficile à comprendre. Les compilations échouent de plus en plus souvent. La fragmentation des versions augmente : certains clients préférant rester sur des versions anciennes pour limiter leurs coûts d'exploitation.
Côté V2 ce n'est guère plus brillant : les progrès se font de plus en plus lents. Plus le temps passe, plus le cahier des charges enfle, plus on allonge la liste des nouvelles fonctionnalités pour justifier l'investissement dans la nouvelle version. Pire, la qualité est de plus en plus difficile à assurer, on commence la guerre aux bugs. L'effort de test devient de plus en plus important.

C'est le moment où la direction devrait se rendre à l'évidence : cette méthode ne mènera nulle part.
La V2 lui semble toujours atteignable, à l'horizon, même si à chaque démo force est de constater qu'on n'a toujours pas une version complète.
Parfois, dans un éclair de lucidité, les commerciaux acceptent d'abandonner des clients historiques qui s'obstinent à conserver des versions obsolètes. Mais cela ne suffira malheureusement pas.

Game over
Les chiffres sont implacables : la croissance à 2 chiffres appartient maintenant au passé.
La réalité a rattrapé l'entreprise, on supprime une partie des effectifs et on recentre ceux qui restent sur le support de la V1, pour continuer à toucher les abonnements des clients. La V2 est abandonnée ou fusionnée tant bien que mal avec la V1.

On maquille la mariée, dans l'espoir de vendre à un repreneur. Avec des effectifs réduits, les finances semblent redevenir saines et les bénéfices reviennent, même si on sait qu'on n'a plus les moyens de développer l'avenir.

Si elle a trop attendu pour réagir, l'entreprise dépose le bilan puis est éventuellement rachetée pour 1€ symbolique par un concurrent.

Dans un prochain billet je vous propose quelques pistes pour conjurer cette malédiction de la V2. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10274/editeurs-logiciels-malediction-v2/ Le site est down ! Quelle architecture pour résister à un passage TV ? #QVEMA https://www.developpez.net/forums/blogs/654313-fluctus/b10273/site-down-architecture-resister-passage-tv-sharpqvema/ Fri, 07 Jan 2022 16:39:11 GMT Chaque année c'est la même chose :
des entrepreneurs peu aguerris se présentent devant les investisseurs de l'émission "Qui veut être mon associé ?", et ce passage TV génère une telle fréquentation que leur site tombe.
Je vous propose donc un passage en revue d'architectures web adaptées à l'hyper croissance des startups et aux pics de charge du e-commerce.

Architectures web classiques difficiles à scaler
  1. CMS sur un hébergement mutualisé : solution très économique, à réserver pour de très petits trafics ;
  2. Site (CMS ou sur mesure) hébergé sur un serveur dédié : pour des trafics constants et des budgets fixes ;
  3. Site hébergé sur un VPS : possibilité de scaler "à la main" de façon non linéaire, en dimensionnant l'hébergement avec des coeurs, de la RAM et de l'espace disque supplémentaires. Ca peut fonctionner pour absorber les périodes de forte charge "prévisibles" et suffisamment homogènes. Avec le risque de perdre des ventes aux plus mauvais moment...


Si vous êtes déjà dans une de ces configurations, il existe évidemment de multiples optimisations possibles :


Architectures web scalant plus facilement
Lorsque la startup passe du MVP à une plateforme plus durable, le CTO peut adopter l'un des styles d'architecture suivants :


JAMstack : pour scaler vite et bien avec un petit bugdet
La JAMstack est un style d'architecture frugal qui consiste à servir des ressources statiques et s'appuyer sur des services cloud pour générer certaines fonctionnalités.
O'Reilly et Netlify proposent un excellent ebook gratuit d'initiation à cette philosophie. L'ebook propose en cas d'étude la refonte du site de Smashing Magazine, et montre comment aborder les aspects gestion de contenu et ecommerce avec la JAMstack.
Un effet de bord intéressant est qu'il est possible d'accélérer les développements grâce à la JAMstack pour délivrer plus vite des fonctionnalités et générer de la croissance pour la startup.

Quelle organisation humaine pour gérer les pics de charge ?
Doctolib a fait un retour d'expérience intéressant sur leur organisation en période de pics de charge.

Globalement, votre organisation devra être mature sur le monitoring et l'alerting pour dimensionner correctement votre infrastructure sans engendrer de coût inutile. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10273/site-down-architecture-resister-passage-tv-sharpqvema/ Budgets IT/prestation : comment décaler vos projets de 2 mois peut booster votre ROI https://www.developpez.net/forums/blogs/654313-fluctus/b10262/budgets-it-prestation-decaler-vos-projets-2-mois-booster-roi/ Sat, 11 Dec 2021 12:06:38 GMT Traditionnellement, les... Traditionnellement, les budgets de prestation informatique suivent les périodes comptables.

Par souci de simplification comptable, les budgets doivent être exécutés entre le 1er janvier et le 31 décembre. ce qui donne lieu chaque année à la même valse improbable :
à partir d'octobre, les plateaux IT ayant trop consommé de budget se séparent de leurs prestataires. On attend ensuite le résultat des arbitrages budgétaires de début d'année pour finaliser les embauches. Alors que les recrutements ne seront généralement pourvus qu'en février-mars, voire parfois à l'été. Ce qui réduit les périodes d'activité pleine à 8 mois maximum sur l'année complète (10 mois - 2 mois de perturbations pendant les vacances d'été).

Les conséquences financières sont imparables : chaque année l'entreprise paie donc le prix de la montée en compétence des prestataires en début d'année, avant de jeter cet investissement en fin d'année. Le prestataire évincé se positionne chez un autre client l'année suivante, et il faut reprendre à zéro le recrutement et la formation. Vous avez dit "jeter l'argent par les fenêtres" ?

Pourtant il existe d'autres façons, plus efficientes de gérer les budgets IT.
L'approche No Estimates (Not Only Estimates) propose d'économiser à la fois sur la perte de valeur et sur le coût des estimations :

L'approche Beyond Budgeting propose d'utiliser des budgets "roulants" pour tenir compte de la réalité des projets IT tout en produisant une comptabilité claire :


Si vous pensez qu'aucune de ces approches ne prendra dans votre contexte d'entreprise, voici quelques pistes qui ont été expérimentées avec succès dans un contexte de cycle en V :
  • décaler les débuts et fins de projet de projet au début février plutôt que janvier : prend acte de la réalité des projets. Nécessite un petit "jeu" comptable simple.
  • décaler les embauches en octobre (période favorable au recrutement) sur les projets pluri-annuels : permet de recruter à la période la plus favorable et évite les perturbations de l'été au milieu du projet, mais nécessite une certaine anticipation du CODIR.


La solution qui marchera dans votre contexte sera peut-être un mélange de l'ensemble de ces approches dans votre portfolio, en choisissant pour chaque projet l'approche la plus adaptée.

Pour aller plus loin
La structure des équipes de développement joue aussi un rôle dans la réussite de vos projets de prestation. ]]> fluctus https://www.developpez.net/forums/blogs/654313-fluctus/b10262/budgets-it-prestation-decaler-vos-projets-2-mois-booster-roi/