En cliquant sur "Accepter tout", vous autorisez l'utilisation de tous les cookies (marketing, personnalisation et analytiques) pendant votre visite sur ce site.
Projets multiples : ne chargeons pas trop la mûle !
Idées principales
Je m’intéresse ici aux personnes intervenant dans la réalisation d’applications : product owner, développeur, chef de projet, …
Je m’intéresse à l’impact que peut avoir sur ces personnes le fait travailler en parallèle sur plusieurs projets d’applications
En fonction du nombre de projets menés en parallèle
En fonction de la complexité des projets
Comment évaluer la complexité d’une application ?
C’est d’abord la complexité du domaine métier (là, on n’y peut rien, quoique … - voir plus bas)
Mais aussi celle de l’application (là, on y peut quelque chose)
Je dis que dès que la complexité devient trop grande :
Passer d’un projet à un autre peut demander jusqu’à 2 heures pour seulement “se remettre dans le bain”
Que si on travaille sur 2 projets par jour (un projet le matin, 4 heures), un autre projet l’après-midi (4 heures) :
La productivité sera d’au mieux 2/4 = 50%
Et que de plus cette productivité maximale ne pourra être atteinte qu’au prix d’un effort cognitif certain :
Pouvant user la personne sur le long terme
Pouvant fatiguer suffisamment la personne pour qu’il y ait des impacts visibles :
En termes de qualité du travail
En termes de relation avec les autres (collègues, clients, …)
Risques :
Risque de burnout des personnes concernées
Et si la personne est en burnout, cela signifie perte d’une ressource, donc encore un coût supplémentaire pour l’entreprise)
Perte de productivité, donc :
Augmentation du coût total du projet, retard
Dans le cas où l’activité est réalisée par une société de services :
Manque-à-gagner pouvant être significatif sur ses marges, voire une perte nette
Impact sur le client (application en retard, problèmes de qualité, dépassements budgétaires)
Perte de qualité
Ma vision :
Agir sur la complexité métier
En règle générale, la complexité métier est ce qu’elle est et on ne peut pas y faire grand-chose, mais :
Ne pas hésiter à remettre en cause certains processus métier, certaines pratiques, bref toute complexité qui pourrait être réduite (ne pas avoir froid aux yeux, être force de proposition)
Réduire au strict minimum le périmètre des applications :
C’est d’ailleurs le principe même du MVP et des développements agiles : on avance par petits pas, on ne veut pas construire d’emblée une usine à gaz
Construire un référentiel documentaire de qualité :
C’est l’ensemble des livrables standards que je produis !
Permet à quiconque, non familiarisé avec le domaine métier et l’application envisagée, de se faire rapidement une image mentale claire des choses, ce qui permet :
Aux différents membres de l’équipe d’avoir une référence partagée :
A jour
Facile à lire
Ce même ensemble documentaire aidant aussi grandement pour accueillir de nouveaux membres dans l’équipe de développement
Comment cela se traduit-il pour mon activité à Midwoo :
D’abord, le fait de travailler sur la base d’un ensemble documentaire enrichi itérativement permet, à tout moment, d’avoir plus vite les idées claires sur “là où on en est” (et de ce point de vue, les “Meeting Minutes” sont d’une aide très précieuse)
Pour les projets complexes, je travaille par journée entière (pour éviter justement la perte de productivité vue plus haut)
Je ne travaille pas sur plus de 3 projets complexes simultanément
Cela signifie que je peux être amené à refuser un projet (ou à le commencer plus tard, si cela convient au client)
