Le rôle de PM-a est toujours là, et s'il n'est pas attribué à une personne ayant la formation nécessaire, il est redistribué.
À qui?- Tous les membres de l'équipe également.
- Un membre de l'équipe qui est prêt à combiner cela avec son rôle principal.
- Une personne de l'extérieur, qui ne participe pas vraiment au processus, mais qui contrôle d'une manière ou d'une autre.
Toutes ces options sont bien réelles et se retrouvent dans la pratique, notamment dans les jeunes entreprises qui n'ont pas encore de structure et de processus.
Gardez à l'esprit les questions suivantes:- Qui communique avec le client?
- Qui garde à l'esprit l'ensemble du projet? Un meilleur document.
- Qui organise le processus?
1. Le rôle du manager est partagé par tous - et l'équipe a une expérience moyenne - ce sera difficile. Les gens ne sauront pas quoi faire et il faudra beaucoup de temps pour se rallier. Le coût global de leurs heures de discussion ira rapidement au paradis. Et pas le fait qu'un compromis sera trouvé.
Il est également nécessaire de pouvoir communiquer avec le client - même avec un niveau adéquat, avec un niveau insuffisant, il est parfois plus difficile. Quelqu'un est impatient avec les questions et les déclarations d'un client ignorant, quelqu'un ne comprend pas du tout son entreprise et pourquoi il a besoin d'un produit. Selffasking et autres joies sont également semées d'embûches, et les développeurs n'aiment tout simplement pas faire cela - ce qui signifie qu'ils le font de manière médiocre. N'oubliez pas que quelqu'un doit tout contrôler.
Un tel schéma ne fonctionne qu'avec des spécialistes très compétents, plus impliqués dans l'ensemble du processus et capables de comprendre l'entreprise, les objectifs du projet, leurs tâches en son sein, et ils n'ont pas besoin de contrôle, car ils sont censurés par eux-mêmes. Je pense que tout le monde conviendra qu'il y a peu de ces développeurs et qu'ils sont au travail.
2. L'un des programmeurs - tout de suite, sera-t-il capable de bien comprendre les besoins de l'entreprise et de traduire ses combattants dans un langage compréhensible? Après tout, vous devez admettre qu'une personne ne comprend pas les choses - elle passe par ses oreilles, mais le développeur moyen ne comprend pas beaucoup de choses dans les affaires, car sa sphère n'est pas du tout, et souvent tout simplement pas intéressante. Puis il expliquera brièvement à ses enfants - ce qui est nécessaire, chacun comprend à nouveau à sa manière et le résultat est un échec complet. Parce que vous devez être en mesure d'interviewer un client, vous devez également être en mesure d'expliquer aux autres, et il est également nécessaire de broyer et de coller l'équipe avec les gens.
La combinaison des rôles de Timlid et PM ne peut être qu'un spécialiste très cool qui sait comprendre le client, gérer, communiquer et, bien sûr, programmer. Un ensemble sérieux, peu de ces personnes sont des exceptions.
3. Une personne qui n'est pas profondément immergée dans le projet est la pire option, à mon humble avis. Souvent, il n'a tout simplement pas le temps pour cela, il a pris une commande à l'occasion via des communications, beaucoup d'argent, a trouvé une équipe de techniciens - et c'est parti. En parallèle, il a toujours, en règle générale, une leçon plus importante.
En conséquence, les techniciens n'ont aucune idée de quoi faire et ne demandent pas à nouveau - ils scient quelque chose. Lui-même n'a aucune idée de ce qu'ils développent, vérifie parfois, mais fondamentalement, rien ne vient du test. Je suis généralement silencieux sur le client. En effet, dans 80% des cas, de tels projets incombent à des indépendants indépendants qui ne savent pas comment et / ou ne veulent pas travailler avec quelqu'un, et qui ne savent pas vraiment comment faire quelque chose de compliqué, où ils ne peuvent pas le faire seuls, car il n'y a pratiquement pas de tels projets sur les échanges. En conséquence, il n'y aura pas d'équipe auto-organisée de durs à cuire. Il y aura un groupe de célibataires mal compris. C’est de la chance qu’ils trouvent un leader qui peut les rallier. Et puis ce n'est pas immédiatement et sans garanties.
Alors pourquoi PM?
La première consiste à garder l'image entière à l'esprit et à la documenter à temps du point de vue de la conception. Les membres de l'équipe doivent travailler sur les détails et le projet dans son ensemble leur échappe souvent. Il est difficile de passer constamment du privé au général et vice versa. Mais le manager est obligé de le faire, et au mieux de ses compétences pour répondre à toutes les questions.
La seconde est d'être un interlocuteur unique pour tout le monde. Toutes les informations doivent passer à travers, sinon le désordre commencera immédiatement. Le client sera d'accord avec un développeur individuel, ou lui présentera des bugs, il ne le dira à personne, les bugs concernent les autres et ainsi de suite.
Plus les réclamations - le manager est aussi un paratonnerre, il écoute, accepte toutes les réclamations, et sous une forme constructive les transfère à l'équipe, sachant qui et comment influencer. Il y a des cas fréquents où des pierres volent sur un programmeur particulier, et celle du choc initial commence à faire des choses stupides: parler trop, faire tomber les autres, attaquer en réponse, fuir.
Le troisième est de résoudre les problèmes. Et ce n'est pas s'ils apparaissent, mais quand ils apparaissent. Parce qu'ils apparaîtront à coup sûr. Après tout, vous devez tout planifier clairement, le surveiller, puis le tester, le réparer, le montrer au client, obtenir l'argent, compter les heures de chacun, idéalement, également mener un débriefing. Dans toutes ces choses, des collisions surviennent qui doivent être prévenues ou résolues en cours de route. Autrement dit, pour construire le processus initial et déterminer les règles du jeu, continuer à résoudre les problèmes actuels et introduire de nouvelles règles si nécessaire.
Soit dit en passant, sans connaissances spécialisées en gestion, c'est assez difficile à faire.
Globalement, soit vous avez suivi une formation dans ce domaine auparavant, soit vous avez testé tous les râteaux sur vous-même et vous êtes devenu un manager battu en bosses. Bien sûr, l'éducation au profil de tous les râteaux ne disparaîtra pas, mais en partie, et la vitesse de maîtrise de l'expérience sera beaucoup plus élevée.