Les rôles écrits du directeur du développement logiciel
Nous savons tous ce que fait un gestionnaire de développement logiciel, mais je crains de ne le savoir que vaguement. Nous pensons que nous savons ce qu'il fait, mais énumérer exactement quelle est la portée du travail est un peu difficile.
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 heureuse si possible) - éloignez les choses qui les empêchent de travailler si possible, expliquez pourquoi ce n'est pas possible là où elles ne peuvent pas être déplacées pour essayer de réduire tout stress résultant (les gens sont plus susceptibles d'accepter des choses s'ils les comprennent au moins). En fin de compte, s'il y a un conflit entre le projet et l'équipe qui ne peut pas être résolu, normalement le projet gagnera. 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. La compétence évidente consiste à minimiser la fréquence à laquelle cela se produit.
Assurez-vous que l'équipe communique avec le client le montant correct . Cela tend à être des parties égales en gardant le client loin de l'équipe et en s'assurant que l'équipe interroge le client sur des choses qu'il ne comprend pas complètement (plutôt que de simplement faire des hypothèses qui peuvent être incorrectes). Les développeurs sont très importants pour s'assurer que le client ne les dérange pas et oublient parfois que le client peut avoir quelque chose d'utile à ajouter.
Planification et priorisation du projet 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 priorité sur celui-ci, ou que ce bogue doit être corrigé avant d'être expédié, mais que celui-ci peut être considéré comme un problème connu.
Gérer le côté commercial du développement - c'est s'assurer que les choses qui devraient être facturées et facturées et que nous n'essayons pas de facturer les choses qui devraient être couvertes par le support.
Soyez la voix de l'équipe dans l'entreprise et de l'entreprise au sein de l'équipe - aidez chacun à comprendre la position de l'autre et aidez à résoudre les différences là où elles surviennent. Cela tend généralement à 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 qu'en cas de désaccord, vous êtes l'ennemi de tout le monde.
Travailler avec l'équipe pour s'assurer que des processus et des outils suffisants 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. Une partie de cela consiste à s'assurer que l'équipe définit les processus (par exemple pour les choses techniques qu'ils comprennent mieux que moi), certains les définissent moi-même (pour les choses que je comprends mieux qu'eux - la planification, l'estimation, etc.). Le mot important ici est suffisant - vous ne voulez pas de processus pour le processus, mais il y a des choses qui doivent se produire 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, et idéalement au-delà. Travaillez avec eux pour aider à résoudre les problèmes qui les empêchent d'atteindre ce niveau. J'adorerais dire que mon rôle est de les rendre les meilleurs possible, mais bien que cela soit vrai dans une certaine mesure, d'autres exigences (projet, budget, temps) signifient que cela sera presque toujours compromis dans une plus ou moins grande mesure.
- Faire tout le administration et farcir l'organisation (et la loi) l'exigent
Dans l'ensemble, il s'agit en partie de mentorat, en partie de secrétariat, en partie de gestion de projet, en partie de gestion de compte et en partie de relations publiques (pour l'équipe). Il y a beaucoup de choses que les développeurs n'ont pas besoin de penser ou de penser à faire, et certains s'assurent qu'ils font les choses qu'ils doivent faire mais ne veulent pas faire.
Ce qu'il ne s'agit pas d'être le meilleur développeur (en général, vous êtes trop discret pour rester à jour pendant longtemps, vous devez donc accepter que les gens en savent plus que vous - la compétence consiste à savoir où votre expérience plus longue mais obsolète 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 penser n'est pas que vous soyez plus âgé, mais simplement que vous avez des responsabilités différentes. Parfois, cela impliquera de faire le dernier appel sur quelque chose (ce qui peut aller à l'encontre des vues de l'équipe) mais le plus souvent, il devrait s'agir d'un consensus ou d'un compromis.