Les rôles écrits du responsable du développement logiciel [fermé]

Nous savons tous ce que fait un responsable du développement logiciel, mais j'ai bien peur de ne le savoir que vaguement . Nous pensons que nous savons ce qu'il fait, mais il est un peu difficile de dresser une liste exacte de la portée du travail.

Selon vous, quels sont les rôles d'un responsable du développement logiciel?

Parlant en tant que personne dans le travail (qui a également été développeur), les choses clés que je dois faire sont:

• Gardez l’équipe de développement sur la bonne voie (et content si possible) : éloignez-les des tâches qui les empêchent de travailler, expliquez pourquoi il est impossible de les déplacer pour réduire le stress qui en résulte (les gens sont plus susceptibles d’accepter des choses s’ils les comprennent au moins). En fin de compte, s’il existe un conflit entre le projet et l’équipe qui ne peut pas être résolu, normalement le projet l’emportera. Cela ne vous rend pas nécessairement populaire auprès de l'équipe, mais vous êtes payé pour livrer des projets / produits, pas en tant que dirigeant syndical. L'habileté évidente consiste à minimiser la fréquence à laquelle cela se produit.

• Assurez-vous que l’équipe communique avec le client la bonne quantité . Cela tend généralement à éloigner le client de l’équipe et à s’assurer que celle-ci lui pose des questions sur des choses qu’elle ne comprend pas complètement (au lieu de simplement émettre des hypothèses qui pourraient être incorrectes). Les développeurs veillent beaucoup à ce que le client ne les dérange pas et oublient parfois que le client peut avoir quelque chose d'utile à ajouter.

• Planification de projet et hiérarchisation des conflits de ressources, des demandes des clients, des problèmes de support, etc. J'ai tendance à être la personne qui dit que ce client a la priorité sur celui-ci, ou que ce bogue doit être corrigé avant qu'il soit expédié, mais que ce problème peut être résolu en tant que problème connu.

• Gérer l'aspect commercial du développement , c'est-à-dire veiller à ce que les éléments qui doivent être facturés et facturés ne soient pas taxés, et que nous n'essayions pas de facturer des éléments qui devraient être couverts par une assistance.

• Soyez la voix de l'équipe dans l'entreprise et de l'entreprise dans l'équipe - aidez tout le monde à comprendre la position de l'autre et aidez à résoudre les différends là où ils se présentent. Cela tend en grande partie à couvrir les conflits culturels entre les besoins / désirs des équipes et les grandes organisations, et les questions budgétaires. C'est en fait assez merdique car cela signifie que quand il y a des désaccords, vous êtes l'ennemi de tous.

• Travailler avec l'équipe pour s'assurer que suffisamment de processus et d'outils sont en place pour répondre aux exigences de l'entreprise et des clients . Assurez-vous que ces processus sont suivis et ajustés au besoin. Cela consiste notamment à s’assurer que l’équipe définit les processus (par exemple pour les éléments techniques qu’ils comprennent mieux que moi), d’autres à les définir moi-même (pour les éléments que je comprends mieux qu’ils ne le font - planification, estimation, etc.). Le mot important ici est suffisant - vous ne voulez pas de processus pour des raisons de processus, mais il y a des choses qui doivent arriver et le processus est le meilleur moyen d'y parvenir de manière cohérente.

• Assurez-vous que chaque membre de l'équipe travaille au moins à un niveau raisonnable , idéalement au-delà. Travaillez avec eux pour aider à résoudre les problèmes qui les empêchent d'atteindre ce niveau. J'aimerais dire que mon rôle consiste à les rendre meilleurs, mais si cela est vrai dans une certaine mesure, d'autres exigences (projet, budget, temps) signifient que cela sera presque toujours compromis dans une mesure plus ou moins grande.

• Faire toute l' administration et remplir les demandes de l'organisation (et de la loi)

Globalement, il s’agit d’une partie mentorat, d’une partie secrétariat, d’une partie gestion de projet, d’une partie gestion de compte et d’une partie RP (pour l’équipe). Il y a beaucoup de choses que les développeurs n'ont pas besoin de penser ou ne pensent pas à faire, et certains s'assurent de faire ce qu'ils doivent mais ne veulent pas faire.

Il ne s’agit pas de devenir le meilleur développeur (en général, vous êtes trop indifférent pour rester en contact longtemps, vous devez donc accepter que les gens en sachent plus que vous; la compétence consiste à savoir où votre expérience plus longue mais dépassée est plus pertinente que leur expérience plus courte mais plus récente) ou être une sorte de dictateur. À cet égard, la meilleure façon d’y réfléchir n’est pas que vous soyez plus âgé, mais que vous ayez des responsabilités différentes. Parfois, cela impliquera de faire le dernier appel sur quelque chose (ce qui pourrait aller à l’encontre des vues de l’équipe), mais le plus souvent, ce devrait être un consensus ou un compromis.