OK en tant que chef de file, c'est votre travail de faire sortir les projets. Vous devez donc être celui qui applique les normes, examine les codes, demande des rapports d'étape et toutes ces choses lorsque les développeurs préfèrent que vous les laissiez seuls. Ces choses ne sont que des exigences de la direction et, à l'exception des revues de code, elles n'augmentent pas vraiment les compétences des employés.
Cependant, vous voulez les aider à grandir, ce qui est un excellent attribut d'un leader.
Les révisions de code sont certainement une première étape, elles vous aideront à voir qui a moins que des habiletés stellaires et a besoin d'être amélioré pour avoir même des performances satisfaisantes. Ils aideront les développeurs à voir d'autres façons de faire et à comprendre différentes parties de la base de code que celles sur lesquelles ils ont personnellement travaillé. À mon avis, les révisions de code sont mieux effectuées en personne dans une salle de conférence avec le développeur et le réviseur (qui devrait être un autre développeur lorsque cela n'est pas toujours le responsable, la révision du code des autres est également une compétence qui doit être développée) et vous en tant que un modérateur. Vous devriez prendre des notes sur ce qui devait être changé pour identifier les tendances. Ce que vous recherchez vraiment, ce ne sont pas des erreurs ou des changements (le code de tout le monde peut être amélioré), mais un échec constant à apprendre des erreurs. Ne dites pas à la haute direction que vous conservez ces notes ou vous vous retrouverez obligé de les utiliser comme mesures dans le processus d'examen des performances, ce qui va franchement à l'encontre de l'objectif. Si plusieurs développeurs font les mêmes erreurs, une session de formation ou une entrée wiki sur la façon de faire X peut être nécessaire.
Passons maintenant au vice croissant pour atteindre le niveau minimal. Tout d'abord, vous devez savoir quels sont les ensembles de compétences dont disposent les développeurs et quels ensembles de compétences il serait utile qu'ils aient et ce qu'ils pourraient être intéressés à obtenir. n'aime pas faire.
Ne donnez pas toutes les tâches intéressantes uniquement aux plus qualifiés. Cela n'aide pas les autres à se familiariser avec les nouveaux problèmes et technologies. Vous ne pouvez pas passer du type le plus subalterne aux tâches les plus petites et les moins importantes au type senior à moins que quelqu'un ne prenne une chance et vous assigne un travail plus difficile. Cela dit, les moins expérimentés devront peut-être d'abord être affectés au programme de jumelage avec une personne âgée pour acquérir des compétences plus avancées. L'inclusion des juniors dans les revues de code les exposera également à des techniques plus avancées.
Donnez-leur d'abord une chance de comprendre le problème eux-mêmes. Mais parfois, les gens sont bloqués et ne savent pas par où commencer (une compétence que vous devez également développer en particulier chez les nouveaux programmeurs) ou quoi faire pour résoudre un problème.
Si vous leur donnez quelques jours pour rechercher quelque chose et qu'ils n'ont toujours pas de direction sur la façon dont ils vont faire quelque chose, alors vous devrez peut-être intervenir avec quelques suggestions. Si vous êtes vous-même technique, vous pouvez leur donner quelques idées pour résoudre le problème. Sinon, une réunion avec plusieurs personnes où vous réfléchissez à des idées peut aider si la personne est coincée. Ou demander à une personne plus expérimentée de faire quelques suggestions. Ce que vous ne voulez pas, c'est leur enlever le problème et le résoudre vous-même. Mais vous devez équilibrer la réalisation du projet avec l'ego du programmeur et parfois vous devez les envoyer dans une direction spécifique. S'il a une mauvaise solution et qu'elle doit être corrigée, la pire chose que vous puissiez faire est de la donner à quelqu'un d'autre, sauf si vous avez l'intention de virer le programmeur.
J'ai vu de mauvais programmeurs choyés, où quelqu'un d'autre doit réparer presque tout ce qu'ils font. Les autres programmeurs en veulent et veulent juste que la personne sorte de leur vie. Choyer un mauvais programmeur fait partir les bons programmeurs. Vous devez trouver la frontière entre les compétences de dorloter et de développement. Si vous donnez à quelqu'un plusieurs chances et qu'il ne s'améliore jamais, coupez-le.
Pour les seniors qui sont déjà compétents dans leurs compétences actuelles, les choses sont plus faciles. Habituellement, il suffit de leur donner l'occasion de faire quelque chose de nouveau et ils se jettent à l'eau et l'apprennent. Assurez-vous simplement que les opportunités intéressantes se propagent et ne vont pas tous à Joe the Wonder Programmer qui peut tout réparer. Vous voulez vous retrouver avec dix Joes et pas un seul.
Une autre façon de développer des compétences est d'avoir une session de formation hebdomadaire d'une heure. Rendez chaque développeur responsable d'un sujet particulier. Cela les aidera à mieux communiquer, leur fera faire des recherches approfondies et donnera à chacun le bénéfice de leurs recherches. Certains sujets devraient être attribués à des personnes qui ne sont pas familières avec le sujet pour les forcer à acquérir des connaissances dans ce domaine et certains devraient être attribués à des personnes que vous connaissez être les experts locaux sur ce sujet. Les sujets devraient être une combinaison de choses dont vous avez besoin que les gens soient bons dans le futur proche ou en ce moment et une couverture des nouvelles technologies à venir que vous n'utilisez pas en ce moment mais les gens sont intéressés à savoir s'ils pourraient être utiles. Mais tout le monde, y compris les plus jeunes, doit se voir attribuer un sujet.
Selon la façon dont le temps de vos développeurs est facturé (c'est plus difficile dans une situation de facturation client), cela vaut généralement la peine que les développeurs disposent de 4 à 8 heures par semaine pour travailler sur des projets personnels. Ils seront ravis de le faire. Les meilleures personnes voudront y travailler et apprendront beaucoup qui deviendront utiles pour l'avenir. Il est difficile pour les compteurs de haricots de comprendre la nécessité de cela, mais ce temps sera remboursé à plusieurs reprises en termes de satisfaction des employés, de nouvelles fonctionnalités ou logiciels dont personne n'a besoin (ou qui aideront à automatiser une partie de la corvée) et un développement plus rapide en raison de nouvelles techniques apprises. Certains développeurs utiliseront ce temps strictement pour des projets personnels sans rapport avec ce que vous faites (et c'est bien, ils continueront à acquérir des compétences et seront heureux de l'opportunité), mais beaucoup d'autres l'utiliseront pour résoudre des problèmes persistants que, en raison de la nature de la gestion des projets, ndbody a eu le temps de régler au préalable. Vous pouvez donc obtenir des refactorisations qui profitent à tout le monde; certaines personnes pourraient passer des tests pour améliorer la couverture des tests afin de faciliter la refactorisation; d'autres pourraient explorer de nouvelles fonctionnalités qui pourraient rendre votre logiciel plus utile à ses clients. En général, si vous pouvez convaincre les compteurs de haricots, il n'y a aucun moyen de perdre en leur accordant cette liberté.
Vous devez apprendre à équilibrer en laissant aux gens un peu d'étirement pour leurs compétences et en gardant le projet sur la bonne voie. Moins le développeur est expérimenté, plus quelqu'un a besoin de vérifier les progrès, en particulier dans les premiers stades, lorsque le changement de direction est plus facile. Les inexpérimentés peuvent avoir du mal et avoir peur de parler. Ces personnes ont tendance à partir juste avant le lancement et vous constatez que leur partie du projet n'est pas loin d'être terminée. Soyez particulièrement prudent pour vérifier les progrès de toute personne que vous avez qui a changé d'emploi fréquemment (à moins qu'il ne s'agisse d'un entrepreneur car c'est la nature du contrat).
On peut généralement faire confiance aux plus expérimentés pour vous dire quand ils ont du mal à trouver la solution et ont besoin de l'aide de quelqu'un ayant plus de connaissances dans le domaine ou ils iront chercher cette personne et obtenir le transfert de connaissances. Ils n'ont donc pas besoin d'être surveillés aussi étroitement dans les phases initiales d'apprentissage d'un nouvel ensemble de compétences pour un projet. Ils trouveront un moyen de livrer le projet. Ceux qui ont un historique de livraison peuvent généralement être laissés seuls, sauf pour les rapports d'étape minimes (vous devez généralement faire rapport à votre direction aussi et donc avoir besoin de certaines informations).