DéveloppeurWeb.Com
    DéveloppeurWeb.Com
    • Agile Zone
    • AI Zone
    • Cloud Zone
    • Database Zone
    • DevOps Zone
    • Integration Zone
    • Web Dev Zone
    DéveloppeurWeb.Com
    Home»Agile Zone»Responsable de l’ingénierie vs responsable technique : qu’est-ce qui est le mieux ?
    Agile Zone

    Responsable de l’ingénierie vs responsable technique : qu’est-ce qui est le mieux ?

    novembre 18, 2021
    Responsable de l'ingénierie vs responsable technique : qu'est-ce qui est le mieux ?
    Share
    Facebook Twitter Pinterest Reddit WhatsApp Email

    Que doit posséder un responsable de l’ingénierie ?

    Les entreprises divisent les rôles et les responsabilités d’un directeur d’ingénierie de plusieurs manières. Cet article décrit les différentes façons de diviser ces responsabilités. Je fournis également les compromis.

    Responsabilités du responsable technique

    De nombreuses startups commencent avec un modèle de leader technologique. C’est bien pour les premiers stades d’une entreprise, mais a tendance à être quelque chose que vous dépassez.

    Modèle Tech Lead

    • Un Tech Lead gère les personnes, les projets et les processus. Ils dirigent également la prise de décision technique.
    • La gestion des personnes en souffre, car le Tech Lead a tellement de responsabilités. Et ils ne sont souvent pas un responsable de l’ingénierie de formation.
    • Le processus en souffre, car le Tech Lead a tellement de responsabilités. Et ils ne sont souvent pas un responsable de l’ingénierie de formation.
    • La gestion de projet en souffre, car le Tech Lead a tellement de responsabilités. Et ils peuvent ne pas avoir d’expérience en gestion de projet.
    • Le responsable technique supervise la qualité du travail technique de l’équipe. Ils aident leur équipe à améliorer leur réflexion technique. Ils s’assurent que les plans techniques de l’équipe sont bien raisonnés et évolutifs.
    • Le chef de produit discute avec les clients et intègre les commentaires de nombreuses sources. Ils priorisent le travail de l’équipe. Ils s’assurent également que l’équipe dispose d’un contexte afin de pouvoir créer des logiciels de grande valeur.

    Le directeur de l’ingénierie dirige des projets

    C’est l’approche vers laquelle je gravite. Avec cette approche, vous disposez d’un responsable technique, d’un chef de produit et d’un responsable technique.

    Le directeur de l'ingénierie dirige des projets

    • Le directeur de l’ingénierie gère la gestion des personnes. Ils coachent les membres de leur équipe pour les rendre plus percutants.
    • Le Responsable Ingénierie pilote les projets : découpage du projet, séquençage, gestion des risques et communication du projet. Cela leur donne une vision quotidienne du travail de l’équipe et les aide à être des entraîneurs efficaces pour leur équipe.
    • Le responsable de l’ingénierie gère le processus de l’équipe. Ils adaptent et améliorent le fonctionnement de l’équipe. Cela aide l’équipe à toujours s’améliorer.
    • Un responsable technique supervise la qualité du travail technique de l’équipe. Ils aident leur équipe à améliorer leur réflexion technique. Ils s’assurent que les plans techniques de l’équipe sont bien raisonnés et évolutifs.
    • Le chef de produit discute avec les clients et intègre les commentaires de nombreuses sources. Ils priorisent le travail de l’équipe. Ils s’assurent également que l’équipe dispose d’un contexte afin de pouvoir créer des logiciels de grande valeur.

    Le chef de produit gère les projets

    L’intention est d’impliquer fortement le Product Manager dans le travail de l’équipe. Et d’avoir des directeurs d’ingénierie très techniques, qui révisent le code et parfois même écrivent du code. Au moins certaines parties de Google fonctionnent avec ce modèle.

    Le chef de produit gère les projets

    • Le directeur de l’ingénierie gère la gestion des personnes. Ils coachent les membres de leur équipe pour les rendre plus percutants.
    • Le responsable de l’ingénierie gère le processus de l’équipe. Ils adaptent et améliorent le fonctionnement de l’équipe. Cela aide l’équipe à toujours s’améliorer.
    • Le Responsable Ingénierie veille à la qualité du travail technique de l’équipe. Ils aident leur équipe à améliorer leur réflexion technique. Ils s’assurent que les plans techniques de l’équipe sont bien raisonnés et évolutifs. Étant donné que le gestionnaire est en position de pouvoir, cela peut causer des problèmes. Ces problèmes peuvent survenir parce que les gens ne voudront pas s’opposer aux points de vue de leur gestionnaire. De plus, les responsables de l’ingénierie peuvent avoir du mal à se concentrer sur le travail technique. Alternativement, vous pouvez demander à un Tech Lead de gérer cette zone. Cela peut fonctionner correctement, mais a un inconvénient. Le responsable de l’ingénierie sera alors trop éloigné du travail. Cela les empêchera de guider le processus de l’équipe ou de coacher leur équipe.
    • Le Product Manager pilote les projets : découpage du projet, séquençage, gestion des risques et communication du projet. Cela leur donne une vue quotidienne du travail de l’équipe et les aide à donner beaucoup de contexte aux membres de l’équipe.
    • Le chef de produit discute avec les clients et intègre les commentaires de nombreuses sources. Ils priorisent le travail de l’équipe. Ils s’assurent également que l’équipe dispose d’un contexte afin de pouvoir créer des logiciels de grande valeur.
    • Parce que le chef de produit est tellement concentré sur l’équipe, il passe moins de temps avec les clients. Il est difficile d’équilibrer les deux aspects du travail lorsque vous êtes responsable de projets. Je considère cela comme un inconvénient majeur.

    Propriétaire à thread unique

    Le propriétaire à thread unique possède tout. Ils peuvent embaucher des personnes pour déléguer certaines parties de leur travail. J’ai un rapport d’expérience plus long sur le modèle Single Threaded Owner. Amazon a popularisé cette approche.

    Le propriétaire à thread unique exécute tout

    • Le propriétaire à thread unique (STO) possède tout. Soit ils font le travail eux-mêmes, soit ils trouvent quelqu’un à qui déléguer.
    • La STO gère des personnes. Ils coachent les membres de leur équipe pour améliorer leur impact.
    • La STO peut conduire des projets ou confier la conduite du projet à un chef de projet. Cette personne s’occupe de la répartition, du séquençage, de la gestion des risques et de la communication du projet.
    • La STO gère le processus de l’équipe. Ils modifient la façon dont l’équipe fonctionne pour être plus efficace.
    • La STO s’occupe de la qualité du travail technique de l’équipe. Ils peuvent déléguer cette responsabilité. Ils aident leur équipe à améliorer leur réflexion technique. Ils s’assurent que les plans techniques de l’équipe sont bien raisonnés et évolutifs.
    • Le STO ou un Product Manager échangent avec les clients et intègrent les retours de nombreuses sources. Ils priorisent le travail de l’équipe. Ils s’assurent également que l’équipe dispose d’un contexte afin de pouvoir créer des logiciels de grande valeur.

    Modèle SCRUM

    L’approche SCRUM est une approche classique du développement logiciel. Il n’évoque pas explicitement les responsabilités managériales. Voici un aperçu de SCRUM.

    Modèle SCRUM

    • Il n’est pas spécifié dans SCRUM comment fonctionne la gestion des personnes. Habituellement, cette personne assume le rôle de Scrummaster ou de Product Owner. Ignorez que le Scrummaster ne devrait pas avoir autorité sur l’équipe. Le coaching individuel des membres de l’équipe a tendance à en souffrir. Le manager peut ne pas être assez proche du travail pour coacher le membre de l’équipe.
    • Vous ne voyez pas beaucoup de gestion de projet avec SCRUM. Tout est concentré sur des points ou des burndown charts. Les équipes SCRUM avec lesquelles j’ai travaillé ont négligé la décomposition, le séquençage et la gestion des risques des projets. SCRUM divise les responsabilités du projet entre le Product Owner et le Scrummaster.
    • Les incitations pour le Scrummaster sont de se concentrer sur le processus et les réunions. Ils ont tendance à en faire trop. Ils ont tendance à trop s’appuyer sur le processus.
    • L’équipe est propriétaire de la qualité de ses plans et travaux techniques. Cela se fait généralement de manière égalitaire. Ce qui peut être bien si l’équipe fonctionne bien.
    • Le Product Owner agit comme un chef de produit léger. Le rôle Product Owner est un sous-ensemble du rôle Product Manager. Généralement, un Product Owner ne fera pas le travail aussi bien.

    Sommaire

    Domaine d’intérêt Modèle
    Engineering Manager (EM) réalise des projets Product Manager (PM) réalise des projets Responsable technique (TL) Propriétaire à filetage unique (STO) SCRUM
    Personnes DANS DANS TL (mal) STO Gérant (mal)
    Traiter DANS DANS TL (mal) STO Scrummaster (mal)
    Projets DANS PM TL (mal) STO ou chef de projet Partagé (mal)
    Direction technique TL EM (mal) TL STO ou TL Équipe, non définie
    Produit PM PM PM STO ou PM Product Owner (mal)
    Parler avec les clients PM PM (mal) PM STO ou PM Product Owner (mal)

    Retour d’information

    J’ai de l’expérience avec tous ces modèles énumérés ci-dessus. Un modèle que je n’ai pas inclus est le responsable de l’ingénierie qui gère les personnes, les processus et les techniques, mais travaille avec un chef de projet. Je suis sûr qu’il est possible de réussir avec n’importe lequel de ces modèles. J’attends vos retours et commentaires !

    N’oubliez pas non plus de vous abonner si vous souhaitez être informé des prochaines publications.

    Share. Facebook Twitter Pinterest LinkedIn WhatsApp Reddit Email
    Add A Comment

    Leave A Reply Cancel Reply

    Catégories

    • Politique de cookies
    • Politique de confidentialité
    • CONTACT
    • Politique du DMCA
    • CONDITIONS D’UTILISATION
    • Avertissement
    © 2023 DéveloppeurWeb.Com.

    Type above and press Enter to search. Press Esc to cancel.