Comment structurer une équipe de développement
Je suis le directeur d'une équipe de 11 développeurs de logiciels qui s'occupent des sites Web/applications Web de mon entreprise, exécutant jusqu'à 4 projets simultanés et un soutien quotidien à tout moment. Au sein des 11 développeurs, il y a un mélange de compétences techniques, de titres de poste et d'expérience, bien que la structure de l'équipe soit plate, les 11 développeurs relevant directement de moi.
Toute l'équipe ayant un seul manager commence à se révéler très peu évolutive. Je commence à être trop dispersé, donc je veux réduire mon nombre de subordonnés directs. Toutes les façons dont je peux penser pour ce faire ont des inconvénients importants:
- Demandez aux développeurs juniors de faire rapport aux seniors. Cela réduit le temps consacré au développement par les meilleurs techniciens.
- Divisez l'équipe par produit logiciel, par ex. les développeurs 1-6 travaillent sur l'intranet et 7-11 travaillent sur les sites externes, chaque section ayant un nouveau chef d'équipe (éventuellement une nouvelle description de poste avec plus de responsabilités de gestion/mentorat/coaching que les développeurs seniors actuels). Cela ajoute des silos artificiels et pourrait rendre difficile la tâche d'un "développeur intranet" de travailler sur un site Web externe si je le souhaite.
- Gardez la structure plate et ajoutez un soutien managérial sous la forme de chefs de projet/administrateurs d'équipe juste pour soulager la pression. Cela ne résout pas le problème car l'équipe ne peut pas continuer à grandir comme ça pour toujours.
Existe-t-il un moyen standard de résoudre ce problème qui me manque?
Sinon, comment d'autres d'entre vous ont-ils résolu ce problème?
Quelques réflexions rapides:
- Les sous-équipes sont une bonne idée: 11 subordonnés directs sans aucune structure sont trop grands pour une équipe viable (vous n'aurez pas assez de temps pour un coaching direct, et les réunions d'équipe avec lesquelles beaucoup de gens auront tendance à être improductives).
- Envisagez de séparer les opérations du développement - c'est un ensemble de compétences légèrement différent et être interrompu toute la journée par des problèmes opérationnels peut sérieusement nuire à la productivité du développement sur les projets.
- À la suite des deux premiers points, je pense que vous devriez avoir peut-être 3 sous-équipes - Intranet, Sites externes et Opérations. Les gars des opérations s'occuperont de tous les problèmes quotidiens/correctifs de maintenance, etc. tandis que les deux équipes de développement se concentreront sur la livraison de nouveaux projets/valeur à l'entreprise.
- Faites régulièrement du vélo entre les équipes. Cela peut être occasionnel (par exemple, faire réviser le code dans une autre sous-équipe), pour un projet ou de façon permanente. Mais assurez-vous qu'il est bien entendu que les rôles d'équipe changeront chaque fois qu'il y aura un besoin commercial - personne ne "possède" un rôle spécifique pour toujours.
- N'ajoutez pas plus de gestionnaires/administrateurs - c'est un moyen infaillible de réduire l'efficacité/la productivité globale de vos équipes. Demandez à la personne la plus expérimentée de chaque sous-équipe de jouer le rôle de chef d'équipe/entraîneur. Assurez-vous qu'ils considèrent leur rôle ici comme étant le coaching et le succès de toute l'équipe, et assurez-vous qu'ils sont équipés pour se comporter de cette manière plutôt que d'agir comme un "gestionnaire de tâches".
- Votre rôle doit être axé sur la gestion des parties prenantes externes, la hiérarchisation des ressources/tâches au sein du groupe et le rôle de "coach principal". Vous devrez gérer le problème occasionnel de la part des sous-équipes, mais en général, vous devriez les encourager à résoudre les problèmes eux-mêmes sans venir à vous.
- Si vous êtes vous-même hautement technique, vous pouvez également choisir de jouer un rôle d'architecte/d'assurance de la conception. Sinon, trouvez quelqu'un qui peut, au sein de l'équipe ou ailleurs .....
De plus, cela vaut toujours la peine de lire et de (re) lire le Manifeste Agile , et surtout le douze principes .
Cette structure sera principalement depend on project specifications
Idéalement, il devrait y avoir 3 juniors par développeur senior dans une équipe. Par conséquent, il y a 2-3 développeurs seniors par responsable d'apprentissage.
Ainsi, seuls les responsables techniques feront rapport à PM sur l'état d'avancement du projet. La structure décrite suppose toujours que pour des questions non techniques (vacances, congés, conflits, etc.) tout le monde peut avoir accès à PM.
L'une des équipes de développement de logiciels relativement performantes Je faisais partie de quelque chose comme ça, par projet:
Un directeur du développement logiciel/développeur principal/mentor, à qui tout le monde relevait directement.
- Un chef de projet, qui respectait les horaires, facilitait les exigences et la négociation d'acceptation, et faisait les communications. Tout le monde en pointillé se rapportait également à cette personne. Une personne chargée de la documentation (qui était aussi parfois le PM, mais seulement lorsque l'expertise le permettait).
- Un mélange de 1 à 3 développeurs ou développeurs seniors, selon les besoins du projet.
- Un développeur junior lorsqu'il est disponible.
- Quelqu'un affecté à partir d'un pool QA.
- Une personne en infrastructure (un rôle souvent rempli par le gestionnaire, car il avait une solide compétence SA également).
Cela a parfaitement fonctionné et j'ai adoré cette organisation. D'un autre côté, j'étais responsable du développement logiciel et la structure organisationnelle de l'équipe évoluait.
Pensez à suivre le modèle d'organisation du personnel fonctionnel . Cela parlerait de votre deuxième option de scinder l'équipe par produit logiciel.
Pour citer l'article dans votre contexte:
La plus grande force d'une organisation fonctionnelle est qu'elle lie les structures sociales à la livraison de la valeur commerciale. À mon avis, les projets logiciels réussissent autant qu'ils améliorent l'efficacité de l'activité qu'ils soutiennent, ce qui génère une valeur commerciale. En organisant vos équipes de la même manière, vous avez une équipe orientée vers la satisfaction de leurs utilisateurs métier.
La structure de gestion/RH réelle n'est pas pertinente au-delà de cela.
Existe-t-il un moyen standard de résoudre ce problème qui me manque?
Pas vraiment. Cela dépendra de votre équipe, de vous, de ce que vous devez faire et des ressources que l'entreprise mettra à votre disposition.
Personnellement, le meilleur type de changement est de séparer la gestion technique de la gestion administrative. Il est rare que les gens soient bons dans les deux cas, et ils ont rarement tendance à interagir.
Une personne s'occupe des aspects techniques. Ce qui doit être fait, qui va le faire, comment les choses doivent s'aligner. L'autre gère les aspects administratifs. Examens, réunions budgétaires, planification de produits, etc. Ils travaillent ensuite ensemble pour communiquer des idées d'un côté à l'autre et pour fournir un front uni.
La façon dont cela est divisé peut prendre plusieurs formes. Le plus commun est d'avoir le directeur de l'ingénierie du côté administratif et un architecte du côté technique. Ce sont des pairs qui relèvent d'un directeur/vice-président.
Un autre travail que j'ai vu consiste à faire en sorte que le directeur de l'ingénierie soit la personne administrative, puis le ou les chefs d'équipe agissent en tant que personne technique. Ceci est plus délicat et nécessite que les bonnes personnes agissent en tant que pairs (la plupart du temps) même si le reporting est hiérarchique.
Pour votre scénario spécifique, je recommanderais d'avoir 2 à 3 équipes et d'avoir des responsables techniques pour les aspects techniques et vous concentrer sur l'administration. Oui, cela réduit le temps des leads qui écrivent du code, mais ils devraient (s'ils font du bon travail) récupérer ce temps en rendant les développeurs plus juniors plus efficaces/productifs. Cela leur donne aussi plus de motivation et un sentiment d'accomplissement avec la promotion réelle. Et le plus pratique, c'est une vente plus facile à la direction que l'ouverture d'une nouvelle position.