Dans cet article, je souhaite partager un peu d'expérience concernant la constitution d'équipes dans des projets informatiques. Je veux parler d'une chose pas toujours évidente comme la «pyramide de maturité d'équipe».
Cet indicateur n'est pas un terme scientifique strict et n'a pas de formules de calcul exactes, mais son principe est bien formulé dans le nom lui-même.
Une équipe typique dans des projets de moyenne et grande taille est composée de différents participants: chef de projet, analystes commerciaux, développeurs, testeurs et ingénieurs ops. Dans chaque direction, il y a généralement des prospects - des employés de premier plan dans la direction, par exemple, un ingénieur de développement de premier plan, un ingénieur de test de premier plan, etc.
Si nous décrivons la structure d'une telle équipe sous la forme d'une pyramide reflétant l'expérience des employés et leur influence sur la prise de décision, nous obtiendrons cette pyramide:
Nous avons obtenu une sorte de "pyramide de Maslow pour l'équipe." Mais n'oubliez pas que les projets informatiques n'ont pas seulement des ingénieurs. Par exemple, les développeurs peuvent être divisés en Junior / Middle / Senior et Dieu sait comment, en fonction de l'expérience de travail et des connaissances (ou de l'imagination de l'employeur).
Il arrive qu'une personne ait un titre bas, mais par son expérience et ses connaissances, cette personne est capable de remplir le rôle d'architecte de solution (mais en raison des circonstances, elle ne remplit pas ce rôle). De toute évidence, ces personnes influencent la prise de décision au sein de l'équipe, même sans prendre de position officielle au sein du projet. Et ces personnes doivent être élevées à la deuxième étape de notre pyramide. Il est important qu'il n'y ait pas plus de personnes au deuxième niveau qu'au troisième.
Vous pouvez attribuer une certaine «manne» à chaque membre de l'équipe, selon l'expérience et l'influence sur la prise de décision. Par exemple, les membres de l'équipe de base recevront 1 pt, les prospects et les managers 2 pts.
Imaginez que nous avons une équipe de 15 personnes, alors une pyramide typique sera considérée en quelque sorte comme ceci:
1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 ptsEt nous obtenons une telle pyramide:
Eh bien, dites-vous, c'est exactement la façon ou non de notre projet et tout va bien pour nous. Et quel est le résultat pratique de cela?
L'évaluation d'une équipe à l'aide de cette méthode vous permet de comprendre deux choses: à quel point une équipe existante est gérable (stable) et combien il est étrange de voir à quel point tout le monde est à l'aise de travailler dans une telle équipe.
En fait, plus important encore, ce qui se passe lorsque la pyramide de maturité de l'équipe devient à l'envers. Ou quand il devient plat, parallélépipède ou autre chose. Et c'est un très mauvais scénario.
La pyramide correcte est très stable, mais celle inversée ne l'est pas. Vous vous souvenez de l'expérience insidieuse avec la colonie "White Swan" où certaines autorités criminelles étaient assises et comment cela s'est terminé pour elles.
Et si vous ne vous écartez pas du secteur informatique, alors vous pouvez imaginer deux situations réelles:
- ils proposent de rendre un gestionnaire de projet efficace bon marché et joyeux - embaucher 30 «Indiens» et déposer le projet en un mois au lieu de six mois;
- Un client très important coupe lors des entretiens avec tous les ingénieurs, à l'exception de ceux qui ont un titre senior ou lead.
Dans le premier cas, nous obtenons une «brique» au lieu d'une pyramide et un projet clairement incontrôlable avec une triste fin.
Dans le second cas, nous obtenons la même colonie "White Swan" sur le projet. C'est à ce moment que des personnes respectées et expérimentées se réunissent dans une seule pièce et en deux heures ne peuvent pas arriver à une solution simple. Tout simplement parce qu'ils sont tous expérimentés et cool, chacun d'entre eux veut s'exprimer et pense que son idée est bonne. Le sens de ces conversations est généralement très faible. De plus, il est difficile de savoir qui devrait «lever le savon», oh, c'est-à-dire qui devrait voir cette fonctionnalité?
Dans ma carrière, il y a eu des projets avec un tel groupe de personnes en équipe et je dis honnêtement que travailler dans les première et deuxième versions n'est pas très confortable. Le manager et l'employé ordinaire. Quand une équipe a trop de gens intelligents, ça devient stupide. La pyramide devient instable et "tombe" souvent en écrasant les insouciants.
En fait, tout est simple, un projet informatique doit avoir suffisamment d'ingénieurs qui font le travail, en profitent et ne posent pas de questions. Sans un nombre suffisant de ces personnes, le projet ne dispose tout simplement pas de suffisamment de «puissance» et il n'impose pas un avenir heureux.
La situation inverse est lorsque vous avez trop de «puissance» et peu de contrôle, alors votre voiture de course va tout simplement s'écraser sur la première clôture.
Le nombre idéal de personnes dans une équipe informatique est de 5 à 15 personnes. Bezos d'Amazon a compilé cela comme le principe de «l'équipe Two Pizza». Une nouvelle augmentation du nombre de personnes complique la communication au sein de l'équipe et n'a plus d'effet multiplicateur.
La répartition idéale des membres de l'équipe par maturité est par lead de 2 à 5 ingénieurs de niveau intermédiaire. Si nous parlons d'ingénieurs juniors ou de
Vasiliev - alors il ne devrait pas y avoir plus de 1-2 par lead (ou la personne qui en est responsable). Tout simplement parce qu'il est physiquement incapable de prêter attention à plus de gens. La révision du code élémentaire pour 5 personnes peut déjà prendre la moitié du temps de travail. De plus, les dirigeants ont toujours toutes sortes de réunions avec d'autres équipes et le client, il ne peut donc pas faire le travail à 100% en tant qu'ingénieur régulier.
C'est-à-dire nous pouvons dire qu'à l'intérieur de la pyramide de maturité des équipes, nous devons construire de petites pyramides à partir de sous-équipes distinctes pour plus de stabilité.
En ce qui concerne le niveau supérieur de la pyramide - peu importe le nombre de personnes au sommet, si vous disposez de 2 niveaux inférieurs adéquats - ils retireront l'ensemble du projet. La pyramide dans la plupart des cas ne sera pas parfaite, mais ce n'est pas effrayant. L'essentiel est d'avoir suffisamment de gens d'en bas.
Ne pas prendre en compte dans la pyramide des superviseurs - c'est-à-dire des gens qui dirigent toute une direction et contrôlent simplement le processus sur plusieurs projets sans interférer dans la gestion.
Le Product Owner d'Agile fait partie de l'équipe, mais ne doit pas interférer avec le processus de gestion. S'il commence à se lancer dans la micro-gestion ou si vous avez immédiatement 5 chefs de produit, alors vous avez de gros problèmes. Mais ce sont déjà des questions de gestion de projet compétente et de relation client. Si vous tombez dans ce piège, la pyramide inversée est déjà votre plus petit problème.
Un autre point est quand trop de gens veulent diriger le projet, et vous, en tant que seule personne qui travaille, rappelez-vous le travail de Saltykov-Shchedrin, «Comment un homme a nourri deux généraux». Ou cette
histoire . Mais une telle situation est facile à prévoir en utilisant la "pyramide de maturité d'équipe" et ne pas aller sur un tel projet.
Dans une entreprise compétente, des éléments comme la composition de l'équipe doivent être planifiés dès la phase de vente du projet. Ensuite, ils sélectionnent un chef de projet qui formera l'épine dorsale de l'équipe de leads et avec leur aide, construira des pyramides, sciera des projets et capturera des galaxies.