À mon avis, l'article
«Bosses of Bloodsuckers in the Context ...» n'a pas révélé la raison de la rupture des équipes autonomes, mais la raison en était la faible vitesse de distribution des exigences de produits et le manque de compréhension que le leader fait toujours partie de l'équipe.
En modifiant l'approche de la planification du département de conception lors du développement d'un nouveau produit, vous pouvez augmenter la vitesse de distribution des informations, ce qui est beaucoup plus important pour un projet que de simplement disposer d'informations.
Design classique
Dans le schéma classique, le processus de planification du travail et le processus de développement ont des délais clairs. En règle générale, le processus de planification a lieu avant le développement. À la fin de la planification de chaque mois, un «horaire de travail en réseau» apparaît, selon lequel le processus de développement de produits par le bureau d'études commence. Il n'y a pas beaucoup de types de graphiques réseau - ce sont principalement
PERT et
GANTT . Les termes dans la planification du réseau sont généralement déclaratifs et ne sont pas étayés par quoi que ce soit, ce qui crée une portée imaginaire lors de l'exécution des travaux dans le processus de développement par le département de conception et de développement. En fait, les termes du calendrier du réseau sont convenus avec le client et le contractant est obligé de les respecter, sinon le non-respect des délais clés de développement pourrait menacer la clôture du projet dans son ensemble. Personne ne demande aux développeurs dans le schéma classique, et le chef de projet réduit simplement les délais pour chaque travail aux développeurs.
De côté, il semble que le chef de projet donne à chacun une sorte de canne à pêche (outil) et dit: «Attrapez en carpe carassin. À la fin du mois, je viendrai vérifier combien ont été capturés. Nous devons attraper 2 tonnes. " Au cours du mois, le chef de projet tient des réunions au cours desquelles il indique qui, combien de tonnes et quel type de poisson il a pêché. A la fin du mois, le chef de projet publie un nouveau planning réseau «mis à jour», selon lequel le client veut attraper non pas des carpes carottes, mais par exemple des
«courgettes» . Le «chef de projet avisé» a une chance d'obtenir un bonus pour l'achat d'un nouveau plasma ou d'un nouveau SUV moderne. S'il a de la chance et qu'il y en aura au moins un qui attrapera le "poisson courgette", alors il paiera un bonus à lui-même et au pêcheur chanceux, et imposera une amende aux autres.
Ce mode de fonctionnement oblige le chef de projet à assumer certaines des tâches de développement pour lui-même, et les développeurs d'un tel projet sont constamment en retard au travail, et parfois ils doivent aller le week-end pour pouvoir développer de nouvelles interfaces d'interaction utilisateur avec le produit à temps. Tout cela, comme je l'ai mentionné ci-dessus, est encore aggravé par le fait que les exigences pour le produit final peuvent changer, puis la planification du réseau est ajustée et l'ajustement est effectué de manière à ne pas affecter les dates clés du projet.
Dans un tel schéma, tout travail dépend du facteur humain, qui joue un rôle clé. Le facteur humain peut être minimisé en introduisant des systèmes de planification et de développement automatisés, ce que font essentiellement de nombreuses personnes en implémentant
CAD ,
CAM ,
CAE ,
PDM ,
ERP ,
CRM ,
PLM , etc. dans leurs entreprises.
Cependant, la base sous la forme d'un schéma classique, lorsque la planification et le développement ont des limites de temps claires, reste inchangée. En conséquence, les développeurs doivent maintenir à jour de nombreuses éditions du produit logiciel et de la documentation dans chaque système automatisé, ainsi que soutenir constamment l'intégration du système, ce qui est très problématique dans les conditions concurrentielles actuelles du marché informatique. Le client n'a finalement besoin que d'une chose: le produit fini ou la production rationalisée. Dans le schéma classique, la liste des documents élaborés par le contractant sera toujours redondante, car ni le client ni le contractant n'ont une confiance totale dans la réalisation de l'objectif, ce qui signifie qu'il est nécessaire de documenter le processus au maximum afin d'identifier qui blâmer pour le non-respect des délais. Même si l'objectif final est initialement formulé comme un spécifique (spécifique), mesurable, réalisable, réaliste et basé sur le temps, par conséquent, après la première exigence supplémentaire, l'artiste peut perdre confiance l'atteinte de l'objectif final, et donc il y aura une rupture des délais et la clôture du projet.
Comment alors s'assurer que le client ne modifie pas trop souvent les exigences et que l'entrepreneur remplit toutes les exigences du client à temps?
Dans le schéma classique, le processus de planification est effectué par un expert expérimenté dans le domaine de la planification de projet, qui, en fonction de son expérience, détermine la liste des tâches et leurs termes. Je crois que tout cela n'aurait pas pu être fait par un expert expérimenté, car l'équipe elle-même peut déterminer les délais d'exécution des tâches, ainsi que la liste des tâches nécessaires à l'exécution. Pour cela, l'expert de la part du client doit décrire le produit le plus en détail possible dans ses
savoirs traditionnels et la date limite à laquelle le produit est nécessaire, et c'est tout! L'équipe, sous la conduite du chef de projet, peut elle-même réaliser la planification du travail, identifier les écueils, décomposer les tâches, bref tout le travail d'un expert expérimenté.
Le «problème» est que dans ce cas, chaque membre de l'équipe connaît le but final, il est transparent et à chaque instant, on sait à quelle distance l'équipe en est éloignée. Le «chef de projet avisé» ne pourra pas inclure son méga-objectif dans cet objectif: «acheter un SUV moderne». Pour réussir à 100% à atteindre son méga-objectif, il doit séparer les processus de planification et de développement et donner des listes de tâches par lots à mesure que des «problèmes» surviennent. Dans ce cas, la tâche du chef de projet est de détourner autant que possible l'attention de l'équipe vers l'objectif ultime du projet, et de focaliser son attention sur la solution exactement à temps pour le travail spécifique du planning réseau. En d'autres termes: «remplir l'équipe de travail de routine».
Un plan de travail fondamentalement différent est un plan de travail utilisant des méthodologies de développement flexibles, dont le principe principal est:
livraisons fréquentes et continues d'un produit de valeur pour le client.Pour y parvenir, tout d'abord, la transparence du processus de planification permet, lorsque chaque membre de l'équipe connaît l'objectif final et participe à la formation du pool de tâches pour les 1-4 prochaines semaines, après quoi le client verra la première version du produit avec de nouvelles fonctionnalités. Il est de la responsabilité du chef de projet d'obtenir l'approbation du client ou simplement de lui notifier la version du produit avec de nouvelles fonctionnalités, qui sera prête après la fin de l'itération. Toutes les exigences supplémentaires provenant du client doivent être prises en compte lors de la planification de l'équipe du pool de tâches dans les itérations suivantes.
Afin de ne pas s'éloigner du chemin vers l'atteinte de l'objectif ultime, l'équipe se réunit chaque jour pour des rallyes de 15 minutes, au cours desquels chaque membre de l'équipe répond à trois questions:
- Qu'est-ce qui a été fait depuis la dernière réunion?
- Que fera-t-on pour le prochain rallye?
- Quels sont les problèmes?
Dans le cas où la planification est effectuée séparément du développement, la réponse à la deuxième question est toutefois donnée par le chef de projet, tout comme la réponse à la troisième.
À la fin de chaque itération (sprint), l'équipe présente le produit avec de nouvelles fonctionnalités au client. Après chaque démonstration, l'équipe se réunit séparément du client pour mener une rétrospective. Il y a beaucoup de méthodes pour mener des rétrospectives, je veux noter une rétrospective dans le style "PLUS / DELTA", dans laquelle chaque membre de l'équipe exprime 10 points positifs (PLUS) et dix points qui ont fait dévier l'équipe (DELTA) de la réalisation de l'objectif visé.
Dans le schéma de travail utilisant des techniques de développement flexibles, les systèmes automatisés jouent un rôle clé, vous permettant d'obtenir un produit avec les nouvelles fonctionnalités les plus avancées à la fin de l'itération. Après chaque itération, le produit peut être envoyé pour développement technologique dans des systèmes
ERP ou
CRM afin de démarrer la production d'un prototype de produit à tester dans des conditions aussi proches que possible des vraies. Ainsi, après chaque itération, le produit logiciel est affiné et de nouvelles exigences fonctionnelles sont créées. Les clients eux-mêmes déjà au stade du développement technologique ou d'un projet pilote par le biais de la rétroaction dans le système
CRM exprimeront des exigences auxquelles vous ne pensez même pas. L'essentiel est de transmettre ces exigences aux développeurs dans le temps, et non de les cacher dans leurs couloirs de la raison, comme le font parfois les «Wise Project Managers».
Tirer des conclusions
Les tentatives de construire le processus de développement selon le schéma classique en utilisant des méthodologies flexibles échouent généralement, et voir autant de chefs de projet pour le bien de leurs «mégacels» ou simplement suivre automatiquement le principe fondamental de «diviser pour mieux régner» refusent d'appliquer dans la pratique les connaissances modernes en gestion de projet.