Peu de temps en ce moment pour écrire sur ce blog, entre mon challenge agile à plein temps, visionproduit.fr et l’animation de la communauté des chefs de produits sur Paris…
Inscrivez-vous aux mises à jour de ce blog pour être informés des futurs posts !
Lorsque j’ai démarré le projet Dropspot avec quelques amis en Décembre 2011, l’objectif était de repenser complètement le service que j’avais proposé avec mon premier projet MonDVDClub. Ce projet avait une ambition sociale, celle de permettre de se rapprocher de ses voisins, de ses collègues de travail, en créant des sujets de discussion autre que le travail ou les problèmes de copropriété. Continue reading “Fin de l’expérience Dropspot” »
Je suis loin d’être un expert de la méthode KANBAN, je suis plutôt habitué à SCRUM et plus généralement aux méthodes agiles encadrées par des timeboxes. J’ai rencontré cette méthode lors d’une mission en Mars dernier, un projet de refonte avec une date butoir fixe.
Je me demandais à l’époque comment le leader technique pouvait bénéficier de l’intérêt de KANBAN en mettant dans un même tableau des ressources différentes et qui ne pouvaient pas échanger leur poste en cas d’engorgement (ex : des graphistes et des développeurs, et comment il pouvait garantir que tout serait fait pour la date prévue, alors que les tâches étaient de durée assez variables. Continue reading “L’importance de la durée des tâches dans un KANBAN” »
En plus d’un tableau style KANBAN permettant de suivre l’avancement du projet en terme de séquencement, j’aime mettre en place une vision synthétique de l’ensemble du projet, orientée “pages” ou “fonctionnalités”. C’est ce que j’ai donc fait dans le cadre de ma nouvelle mission, afin que je puisse maîtriser l’ensemble du périmètre de manière visuelle.
Pour cela, j’ai travaillé à partir du plan du site qui doit être livré, que j’ai représenté sous forme de gros post-it jaune que j’ai scotchés sur une feuille. Pour chacune de ce pages, j’ai identifié à partir des spécifications fonctionnelles les composants,gabarits et fonctions associés a ces pages, et j’ai associé des couleurs pour chaque état :
J’aurais préféré faire des copies d’écran réelles et les coller au mur, comme je l’avais fait pour ma dernière mission qui consistait en une refonte totale d’un site. Mais ici, nous n’avons la chance d’avoir de grands murs blancs à disposition.
Certains composants transverses ont été isolés pour plus de lisibilité. L’intérêt de cette approche est de pouvoir avoir une vue globale sur l’état global des pages, et de se concentrer sur les pages les plus rapides à finir.
Afin de dé-risquer le projet, j’ai choisis de ré-allouer les efforts sur les pages les plus complexes, les pages plus simples seront réalisées en dernier. Cependant, il s’agit en fait d’un décision plus subtile : il faut qu’une partie de l’équipe travaille sur les pages les plus complexe, et les développeurs junior peuvent travailler sur les pages les plus simples ou les correctifs.
Cela permet d’avancer sur deux tableaux : la complétion totale du projet, et la réduction de l’incertitude sur la durée réelle de fin de projet.
Cette vision “fonctionnelle”, combinée à la vision processus KANBAN est rassurante, et naviguer entre les deux et bénéfique : cela force à ne pas entretenir le flou sur le nom des tâches qui doivent être identiques : cela permet par exemple de remonter des incohérences ou des oublis.
L’intérêt d’un tableau style Kanban, même simplifié, est de pouvoir être adapté en fonction de la découverte du processus. Comme je suis arrivé depuis peu chez mon nouveau client, je découvre le processus de validation qui peut être très différent d’une organisation à une autre.
Je me suis concentré uniquement sur l’activité de l’équipe technique, pour deux raisons :
Depuis mon dernier post, j’ai ajouté une tâche “bugfix”, car je m’aperçois que les développements une fois “finis” par le développeur doivent être systématiquement testés par un chef de projet, et éventuellement repasser en correction.
Cela rajoute une phase qui n’était pas prévue dans le diagramme MPP d’origine : encore un avantage d’une vision “flux” plutôt qu’une vision “tâche”.
J’ai également pris le parti d’intégrer l’ensemble des tâches du projet, et pas seulement les tâches de la semaine, car certaines tâches trop longues ne se finissaient pas dans une “timebox” d’une semaine.
J’ai également choisis des codes couleurs différents pour illustrer les tâches en retard par rapport à la planification initiale (en jaune), les tâches normales (en orange), et les tâches qui avaient été livrés dans les lots lots précédents mais qui nécessite de les retravailler. Encore une charge de plus non prévue dans le planning, et qui mérite d’être plus visible.
J’ai enfin choisis de tracer une ligne horizontale pour séparer les tâches livrées, afin d’encourager l’équipe en leur montrant les progrès.
Réflexion pour la suite: découper les tâches trop longues (supérieures à 8J !) car nous rentrons dans un mini “waterfall” : chaque tâche peut dériver de manière significative sans qu’on s’en aperçoive. Une des prochaines étapes sera également d’inscrire sur les tâches la date de début, en plus de la durée estimée, afin de repérer plus facilement les tâches qui prennent un retard anormal.
Je vous livre une réflexion que j’ai eu récemment, en étant confronté une nouvelle fois à un projet déléguant une partie de son travail en “offshore”. Un mot tellement décrié que nous avons inventé le “near shore” pour le Maghreb, le “rural shore” pour les zones franches en France… le point commun de ces façons de travailler : le prix du développeur à la journée qui est de 1,5 à 3 fois moins élevé qu’à Paris.
Aujourd’hui je déjeunais avec mon équipe et d’autres chefs de projets techniques chez mon nouveau client. J’ai été frappé, mais pas surpris, à quel point les chefs de projets techniques sont unis “contre” les chefs de projets fonctionnels.
J’ai déjà rencontré ce phénomène dans plusieurs entreprises ou les critères de réussite entre les départements fonctionnels et techniques sont divergents. Les chefs de projets fonctionnels sont perçus comme ne voulant pas comprendre les contraintes des équipes techniques, donnant l’air d’être du côté du client plutôt que du projet, essayant de “caser” des nouvelles demandes non prévues sans décalage du planning et sans augmentation du budget… J’ai été chef de projet fonctionnel, et je comprend ce cynisme. Il est le résultat d’une rupture causée par des objectifs différents, souvent dictés par des directions différentes.
Cependant, durant ce déjeuner, l’un des chef de projets a annoncé qu’il avait obtenu un poste de chef de projet fonctionnel. Curieusement, celui-ci a été félicité, et pour plusieurs raisons :
Passer chef de projet fonctionnel est perçu comme une promotion pour un chef de projet technique, signe que la technique n’est pas valorisée. Mais pourquoi ? Tout simplement car la technique ne se présente pas comme un centre de profit, mais un centre de coût.
La technique doit changer et se réinventer, afin que les chefs de projets techniques soient estimés par les autres départements, pas seulement comme des geeks, mais comme des éléments générant du profit : il ne devrait pas y avoir de raison pour qu’un chef de projet technique soit frustré par son travail.