Veuillez noter qu'il n'y a pas de point d'interrogation dans le titre. Je ne veux pas me demander si les chefs de projet sont nécessaires dans le développement de logiciels modernes ou non. La pratique montre que non. J'essaie juste de comprendre pourquoi c'est arrivé.
Ayant travaillé pendant plus de 20 ans dans l'industrie informatique, j'ai commencé à construire chaque nouveau développement à partir du bureau de projet. De plus, j'ai dû expliquer à plusieurs reprises à la direction pourquoi embaucher des piems. Étant donné la présence des chefs de département, il n'est pas si facile d'expliquer aux personnes qui ne sont pas directement impliquées dans le développement de logiciels ce que feront exactement les chefs de projet. J'ai dû surmonter une résistance notable.
Mais pour moi, c'était un axiome que le bureau de projet et les chefs de projet sont la base du succès. Et dites-moi quelqu'un il y a environ cinq ans que les chefs de projet ne sont pas nécessaires, je discuterais avec lui jusqu'à la fin.
Note de la rédaction: ce texte est le résultat d'un rapport de Dmitry Kruglov, d'Arrivée au rassemblement de Piemnaya
Ou avez-vous encore besoin
Commençons par essayer de protéger cette profession. Ne serait-ce que parce que les résultats sur les derniers lieux de travail ont été atteints, notamment grâce aux bureaux de projet construits avec succès.
La gestion de projet n'est pas l'apanage de l'informatique. C'est une science qui a plus de 50 ans. Une science qui a son propre livre sacré . Bien sûr, PMBoK n'est pas unique en son genre, il y a PRINCE et, probablement, plusieurs autres livres qui prétendent plus ou moins à des lauriers. Mais PMB®K est la base des normes internationales et cela indique son haut niveau de reconnaissance. Nous allons donc en tirer parti.
Jouons le jeu: si vous travaillez en tant que chef de projet, essayez, sans anticipation, de rappeler vos principaux domaines d'activité du point de vue d'une norme internationale et d'un institut de plus de 50 ans?
Par exemple, gérer les exigences du projet. Ou gérez les attentes. Vous vous souvenez peut-être de la gestion du temps. Certes, des collègues représentant l'entreprise demandent régulièrement quand exactement telle ou telle tâche sera prête. Vous vous souviendrez peut-être de la gestion des parties prenantes, qui est beaucoup moins courante. Quoi d'autre? Gestion des communications. Ce dernier est aussi rare que les parties prenantes. Mais c'est une tâche importante et difficile à notre époque, lorsque tous les participants au projet préfèrent partager des informations importantes sur Telegram, au lieu des e-mails requis par le projet de charte. Comment pouvez-vous gérer les communications si vous n'êtes tout simplement pas invité à un chat dans lequel ils discutent, par exemple, de la qualité de votre travail?
Comparez ce que vous vous rappelez avec la liste de PMBoK:
Tous les articles sont très sensés. Il semble que cette activité doive vraiment être effectuée par chaque chef de projet. Certains de ces éléments peuvent être moins évidents, comme l'intégration de projets. Mais si vous avez utilisé la puissance de plusieurs équipes pour créer une fonctionnalité vraiment importante, que vous devez assembler avant le lancement, vous comprenez de quoi il s'agit. Soit dit en passant, la tâche de développer une fonctionnalité dans plusieurs équipes en parallèle n'a pas encore été systématiquement résolue.
Diagramme de Gantt
S'il y a une activité, il doit y en avoir le résultat. Mon opinion personnelle est que le travail a été fait avec l'artefact approprié. Pour un programmeur, cela fonctionne avec du code. Pour un spécialiste des tests, des scripts de test développés ou exécutés, des erreurs introduites dans le système ou des autotests créés. Pour le concepteur - dispositions graphiques.
Qu'est-ce qu'un artefact de chef de projet? De tous les artefacts possibles, y compris les messages dans le télégramme: "Ajoutez-moi, enfin, à votre chat, je ne peux pas gérer le projet sans lui!", Je voudrais d'abord noter le diagramme de Gantt. Il s'agit d'un excellent outil qui peut répondre à de nombreuses questions sur le projet et permet de visualiser la plupart des domaines d'activité du chef de projet. Après tout, un bon diagramme de Gantt contient le calendrier, les ressources, le coût et les dépendances. Vous pouvez y ajouter des exigences de communication en tant que tâches. Vous pouvez même ajouter un contrôle aux parties prenantes et à leurs attentes avec des jalons et une description du résultat attendu. Il s'avère un outil universel pour toutes les occasions.
La plupart des tâches dans ces domaines sont résolues grâce à la gestion d'une entité - le diagramme de Gantt.
Sa popularité et sa polyvalence sont confirmées par le nombre d'outils et de services qui vous permettent de créer vos diagrammes. Essayez de rechercher «Gantt en ligne» et voyez combien de temps la liste de liens pour chaque goût et couleur que vous obtenez.
Ce qui s'avère: nous avons une profession, une activité et un bon artefact, comme résultat. Alors quel est le problème?
Tout est dans les nuances. Par exemple, avec Gantt, tout n'est pas si bon.
Premièrement, les diagrammes des grands projets deviennent tôt ou tard illisibles. J'ai eu de l'expérience avec un projet «sur un an» chez Microsoft Project. Pour imprimer son plan, il a fallu coller six feuilles de A4. Sur une feuille, le texte était trop petit.
Deuxièmement, les diagrammes des grands projets demandent beaucoup de main-d'œuvre à entretenir. Faire des changements souvent ne peut être fait que par l'auteur lui-même, sinon le plan s'effondre en raison d'un système complexe de dépendances.
Troisièmement, il faut admettre que personne, à l'exception de nombreux chefs de projet, ne lit de nombreux diagrammes. Il s'avère que cet artefact a été produit par le PM et lui seul en a besoin et le comprend.
Dans le développement de logiciels modernes, Gantt, pour la plupart, a été abandonné. Nous avons cessé d'utiliser cet artefact pour créer un produit, avons-nous vraiment besoin de son auteur?
Si vous essayez de google le sujet de l'utilité des chefs de projet en informatique, il devient clair que cette discussion dure depuis longtemps. Elle a réussi à devenir un autre holivar, comme la confrontation entre les amoureux d'iOS et d'Android, Windows ou OS X. Seules les citations dans les résultats de recherche sont encore plus émouvantes: «Avons-nous besoin de PM?», «Pourquoi avons-nous décidé de nous débarrasser des PM», «Est-ce que le travail de PM est-il sans valeur?
Je ne prétends pas dire que l'équilibre dans le différend mondial est en faveur du rejet du PM, mais au moins le nombre de partisans de ce point de vue est important.
Méthodologies agiles
En commençant à travailler dans une entreprise où j'ai la tâche de constituer une équipe de développement à partir de zéro, je me suis rendu compte que pendant les six prochains mois à un an, je n'ai aucune tâche pour PM. Au début, je l'ai ajouté à la structure organisationnelle par habitude. Et puis il a frappé de sa propre main. Barré intuitivement, mais se demanda: "Pourquoi est-ce arrivé?".
Mes recherches sur les raisons ont conduit à comprendre que l'informatique possède un certain nombre de qualités uniques qui ont permis la mise en œuvre de méthodologies flexibles. Il y a une comparaison classique: construire une maison et développer des logiciels. Ce sont des disciplines quelque peu similaires, non sans raison dans les deux il y a un rôle de l'architecte. Les deux là-bas, et il existe un ensemble d'exigences fonctionnelles et non fonctionnelles, il y a l'infrastructure, les communications internes, l'assemblage, la livraison et l'intégration.
Mais la construction est réalisée dans le monde réel et a un cycle de production très long et coûteux jusqu'au premier test, avant de recevoir le premier feedback, avant de recevoir le résultat. Le prix d'une erreur de construction est très élevé.
Le produit informatique est numérique. Et le cycle de production peut être très court. Pendant deux décennies, nous avons pu créer des outils et des technologies qui ont conduit à l'émergence de méthodologies de développement flexibles. Ici, je suis prêt à affirmer qu'une relation causale n'est que cela: la capacité d'expérimenter rapidement et d'obtenir un résultat de travail a conduit à l'émergence de méthodologies sur la façon de le faire. Bien sûr, il s'agit d'une brève rétroaction positive, et les outils ont continué à se développer. Et là encore, la méthodologie a été finalisée. Et ainsi de suite dans une spirale, nous nous précipitons vers un délai de commercialisation de plus en plus court.
Rôles
Les méthodologies agiles sont devenues la norme de facto et ont apporté de nouveaux rôles au processus de développement logiciel. Et ces nouveaux rôles ont commencé à retirer des activités et des artefacts aux chefs de projet.
Propriétaire du produit (PO)
Il y a des projets qui ont plusieurs clients, plusieurs propriétaires et plusieurs décideurs. PM pour eux est la personne qui cherche un compromis. Il les rassemble, aide à prioriser, réconcilie. Il dit à quelqu'un: «Non», le lobbying de quelqu'un. Mais l'entreprise comprend que dans une recherche continue de compromis, les ressources sont gaspillées de manière inefficace. La ressource la plus précieuse est dépensée la plupart du temps - le temps.
C'est pourquoi les méthodologies flexibles font exactement cela - elles disent à une personne de l'entreprise quelque chose dans l'esprit: «Vous êtes extrême pour l'argent, pour le trafic et pour la conversion. Et pour être honnête, nous ne nous soucions pas de quoi et avec quelle priorité vous faites dans le produit. L'essentiel est que d'ici la fin de l'année, la conversion passera de 1% à 1,1%, sinon le projet ne sera pas rentable. » Et le PO obtient le droit de prendre des décisions individuellement, il détermine la priorité, crée les artefacts correspondants (plans, feuilles de route, exigences) et prend un travail du PM.
Techlide (TL)
Il y a une dizaine d'années, l'informatique a commencé à modifier l'architecture établie.
Avant ces changements, les technologies et les outils étaient principalement créés pour «l'architecture en couches» - la couche de base de données, la couche de processus métier, la couche d'agrégation, la couche client. Mais dès que cette approche est devenue classique, dès que les entreprises ont acquis les couches de départements correspondantes, des méthodologies souples sont apparues. Et tout le monde a décidé à l'unanimité que les «tartes feuilletées» étaient mauvaises et qu'il fallait former des équipes transversales.
Pour ne pas dire que c'était une nouvelle idée. Comment s'appellent les développeurs universels? Pile complète Un des développeurs de plus de 30 ans lors de l'interview a déclaré: "J'étais développeur full stack à une époque où le terme full stack n'existait pas." Autrefois, nous étions tous pleins, car nous devions tout faire, y compris l'administration de la base de données et la configuration de l'ordinateur du directeur.
Les équipes interfonctionnelles ont apporté un nouveau rôle: les techlides. Tehlid a non seulement pressé les chefs de département, mais a également repris la partie technique du travail du PM. Tout d'abord, tout ce qui concerne l'évaluation de la complexité et du timing. Au moment de la transition vers des méthodologies flexibles, beaucoup se sont mis d'accord avec le fait que l'équipe de développement doit elle-même évaluer les termes de son travail.
Analyste système (SA)
Un analyste de systèmes n'est pas un nouveau rôle, et de nombreuses méthodologies Agiles ne le font pas. Je ne prétends pas le dire avec certitude, mais il est possible qu'il soit explicitement disponible dans SAFE. Mais SAFE, en général, est une méthodologie limite. Cependant, ce rôle est extrêmement utile et intéressant. Il, comme un lubrifiant dans un mécanisme complexe, lui permet de fonctionner silencieusement et en douceur. Un analyste de systèmes est en partie propriétaire du produit, en partie architecte. Il clarifie et détaille les exigences métier au niveau des fonctionnalités spécifiques. Les meilleurs analystes de systèmes sont capables de faire avancer leurs idées et leur vision dans les deux sens, en utilisant une combinaison de connaissances techniques et de compétences générales. Lorsque les analystes système travaillent, le chef de projet est privé des activités de gestion des exigences.
Scrum Master (SM)
Scrum Master a fortement resserré le rôle de chef de projet. Il est regrettable que les SM eux-mêmes soient désormais candidats à l'extinction.
Sérieusement, tôt ou tard, Scrum Master enseignera dans les écoles. Il y aura des leçons sur Agile, où Scrum Master expliquera aux élèves de 12 ans comment fonctionnent les méthodologies agiles et quelles pratiques existent. L'expérience Agile est désormais devenue une expérience de développement omniprésente. Dans une interview, 19 personnes sur 20 travaillent sur des itérations de deux semaines, et parler des processus se transforme en une liste de leurs paramètres:
- Quelle est l'évaluation?
- Points d'histoire.
- Qu'est-ce que Velocity?
- 68.
- Comment planifiez-vous les projets?
- Dans les notes «t-shirt» de S, M, L.
Ceci est une conversation très rapide. Avec les techlides actuels, tous les paramètres du processus peuvent être discutés en une heure. Après cela, ils vont travailler avec l'équipe et ils n'ont pas besoin de Scrum Master pour cela. L'industrie a presque digéré ce rôle et progresse.
Bien sûr, ce n'est pas le cas partout. Il y a sûrement de nombreuses entreprises qui doivent atteindre les normes du marché et ce n'est pas un processus rapide. En Russie, après 10 ans, il sera possible de trouver un emploi de Scrum Master dans une sorte de «Lenoblkhozpromlespoval» lorsque l'organisation décidera de transférer ses trois programmeurs vers Agile.
Au cours de leur popularité, Scrum Master a réussi à supprimer complètement toutes les questions de l'équipe de projet de PM. Ils ne l'ont pas pris à eux, mais aux membres de l'équipe, facilitant leur implication dans le travail de conception. Soit dit en passant, cela a considérablement augmenté le niveau de maturité informatique aux yeux de l'entreprise.
Ou toujours pas nécessaire
Que reste-t-il? J'ai pris la liberté de mettre en évidence les tâches qui, lorsque l'on travaille sur des méthodologies flexibles, sont résolues par d'autres rôles.
Que reste-t-il aux chefs de projet après cela? Communications, intégration et approvisionnement restants. Il semble qu'il n'y ait pas grand chose pour garder une personne dévouée sur ce rôle? Il est temps de dire que les PM ne sont pas nécessaires. Mais non.
Encore besoin
Il existe des catégories de projets informatiques dans lesquels l'échec sans un gestionnaire dédié est pratiquement garanti.
Projets du monde réel
Ceux qui travaillent avec le développement mobile savent qu'avec la rapidité des changements et le coût des erreurs, les choses ne sont pas si fluides. Si vous avez manqué une erreur dans le développement mobile et que vous ne l'avez pas remarquée immédiatement, il sera difficile de faire une mise à jour pour l'ensemble du public. Certains utilisateurs ne mettront pas à jour leurs applications et l'erreur restera. A partir de ce problème, par exemple, des approches avec contrôle à distance des fonctionnalités des applications mobiles se sont développées.
Mais c'est un centième de la douleur des PM qui gèrent le développement de logiciels, par exemple pour gérer le convoyeur de tri dans un entrepôt à l'échelle de 5 millions d'unités de marchandises. Dans de tels projets, des dizaines de dépendances à l'égard des fournisseurs d'équipements, les itérations sont mesurées en mois et le prix des erreurs augmente d'un ordre de grandeur.
Les projets liés à l'équipement nous ramènent des mondes numériques à notre réalité, dans laquelle le contrôle PMBoK classique est toujours d'actualité.
Projets parapluie
Sur les projets parapluie, les méthodologies flexibles ont calé. Ces projets sont vastes et complexes. La complexité signifie des dépendances explicites et implicites, et à une certaine échelle, le développement sans gestionnaire de projet dédié devient extrêmement inefficace. Dans ces projets, les tâches principales de PM sont l'intégration des projets, la gestion des dépendances et des délais.
Projets avec un coût d'erreur élevé
Il y aura toujours des industries dans lesquelles les erreurs doivent être éliminées au maximum - la médecine, l'aviation, l'industrie spatiale et la sphère militaire. Dans ces domaines, lorsqu'une erreur se produit, des personnes meurent ou beaucoup d'argent est perdu. Les exemples sont faciles à trouver sur Internet. Commencez avec une histoire sur le missile européen Arian-5.
Dans ces domaines, les PM resteront en demande, mais des exigences très élevées leur seront imposées en termes de compétences et d'expérience. Et plus la proportion de ces projets est faible, plus la sélection des candidats sera rigoureuse.
Projets sans rôle
La vie est une chose difficile, et prendre une personne dédiée pour chacun des rôles n'est pas toujours possible. Jusqu'à ce que le monde soit parfait, il restera des PM qui font le travail de Product Owner. Ou des PM qui fonctionnent de facto comme des diaporamas. De telles combinaisons sont souvent caractéristiques des startups.
Si nous étendons dans le temps les tendances qui se produisent actuellement dans l'industrie, nous aurons un avenir dans lequel le rôle de PM dans sa forme pure restera pertinent pour un petit nombre de projets de développement logiciel dont nous ne savons pas encore comment automatiser ou distribuer le travail les membres de l'équipe.
Texte préparé par:
Auteur - Dmitry Kruglov
Éditeurs - Eugene Shklyar, Denis Vonsarovsky
L'avis de l'auteur sur certaines questions peut ne pas coïncider avec l'avis du comité de rédaction du blog et de la société Yandex.Money.