Comment réussir en tant que développeur principal?
Je suis devenu le développeur principal d'un projet particulier, mais j'ai du mal à me concentrer sur la vue d'ensemble et à m'assurer que toutes les parties du projet sont couvertes.
À quoi dois-je faire attention lors de la gestion de ce projet? Comment puis-je m'assurer que tout est traité comme il se doit?
J'ai vu ce voyage chez d'autres développeurs alors qu'ils faisaient la transition vers senior ou lead. Voici quelques suggestions que j'ai faites aux autres.
- Comprendre quel est l'objectif du projet.
Il ne s'agit souvent pas de toutes les fonctionnalités qui ont été intégrées au projet. Il s'agit d'un ensemble de fonctionnalités de base qui répond à un besoin métier. Gardez toujours cela à l'esprit car c'est votre objectif principal.
- Découpez ce qui doit être fait en tâches. Comprenez les dépendances entre eux.
Décomposer un projet devrait être assez simple. Décomposez-le le plus tôt possible dans le projet. Si vous devez masquer des pièces, comprenez qu'elles posent un risque jusqu'à ce que vous compreniez ce qui doit être fait.
- Comprenez quelles sont les questions ouvertes ou les ambiguïtés du projet.
Vous ne pourrez pas résoudre toutes les ambiguïtés au départ (bien que vous deviez essayer). Assurez-vous que votre gestionnaire et les parties prenantes du projet comprennent ce qu'ils sont et quels risques ils présentent pour le projet.
- Les entreprises détestent la surprise.
Assurez-vous que tout le monde sait (idéalement tous les jours, mais les travaux hebdomadaires) quel est le statut du projet. Et par statut, je veux dire ce qui a été fait, ce qui reste à faire, les questions ouvertes, les problèmes, etc. Tout ce qui peut avoir un impact sur l'achèvement du projet doit être signalé.
- Tous les jours, passez en revue la grande image.
Vous devriez passer en revue tous les jours pendant une heure. Posez-vous les questions. Qu'est-ce qui a été réalisé? Que reste-t-il à faire? Quelles sont les questions ouvertes? Quel est le but? Vous devriez être en mesure de donner à quelqu'un un état détaillé du projet chaque fois qu'il le demande.
Le premier conseil que je vais vous donner est d'accepter que la gestion de l'équipe est plus critique que de faire vos propres tâches de programmation. Cela signifie que lorsque 3 juniors ont besoin d'aide, il est de votre devoir de ne pas vous plaindre de la façon dont cela vous éloigne du développement. En tant que chef de file, vous devenez souvent le barrage routier pour progresser si vous êtes trop concentré sur vos propres tâches de développement en premier.
De plus, vous devez apprendre à déléguer. Il est difficile de confier des tâches à quelqu'un lorsque vous pouvez le faire facilement en une heure et que vous savez qu'il va patauger pendant une journée. Cependant, ils ne progresseront jamais à moins qu'ils n'obtiennent les tâches et que vous fassiez des heures supplémentaires pendant que votre équipe joue à des jeux.
De plus, ne corrigez jamais simplement le code de quelqu'un d'autre. Dites-leur ce qui ne va pas (et pourquoi) et faites-les réparer. Ou vous entrerez dans un cycle où vous devrez tout réparer car ils ne s'améliorent pas. S'ils ne peuvent pas le réparer, réfléchissez s'ils devraient rester dans l'équipe. Ne laissez pas les membres faibles de l'équipe rester parce que vous réparez tout ce qu'ils font.
En tant que leader, vous devenez le méchant et leur donnez les nouvelles désagréables (à la fois en amont et en aval). Cela va de pair avec le travail aussi. Cela signifie que vous devez faire une mauvaise évaluation des performances; vous devez leur dire que le délai a été avancé ou que les exigences ont changé; vous devez pousser le gars paresseux qui ne fait pas de progrès; et vous devez dire à vos supérieurs quand le délai ne sera pas respecté et pourquoi et ce que vous faites à ce sujet. Être leader, ce n'est pas être aimé, mais être efficace. Votre travail consiste à sortir le logiciel, pas à vous faire des amis. La communication est essentielle et éviter les mauvaises nouvelles finit par aggraver la situation. Un client est beaucoup plus susceptible de se faire dire que trois semaines de plus par mois avant le lancement qu'il ne le fera lorsque la date de lancement sera passée, puis vous lui dites que vous avez besoin de trois semaines de plus. Gérer par des vœux pieux (bien sûr, nous pouvons simplement tirer quelques nuits et le faire) est le chemin le plus sûr de l'échec que je connaisse.
Voici ma liste de contrôle informelle. C'est très informel ... Je ne fais pas tout tous les jours, mais si je ne touche pas toutes ces choses chaque semaine, je suis un peu inquiet, et si je ne les touche pas tous les mois, je devrais paniquer. Et le kilométrage varie entièrement en fonction de la culture de l'entreprise/de l'équipe, du style personnel et du type de projet.
Parlez à l'équipe individuellement - Est-ce que tout le monde dans votre équipe - a un travail utile à faire? savoir quel est l'objectif global du produit et de la version actuelle? savent-ils comment vous gagnez de l'argent et quel est l'objectif principal de votre entreprise? savent-ils comment leur travail actuel s’inscrit dans tout cela?
Parlez à l'équipe collectivement - rassemblez-les tous avec les principales nouvelles, réunissez les groupes pour vous assurer que la communication se passe avec et sans vous. En tant que petite équipe, il s'agit probablement de séances de stratégie de groupe. Au fur et à mesure que l'équipe s'agrandit, il deviendra le cas où vous devrez les guider à travers les points principaux, et cela deviendra inévitablement un scénario de discussion avec eux. Ce n'est pas faux - il y a des moments où il est très important que tout le monde vous entende dire les informations publiques à tout le monde . Donc, tout le monde sait que vous donnez l'information universellement. Mais la réunion "vous-à-tout le monde" est très différente de la réunion de stratégie de groupe où vous êtes davantage un guide.
Échantillon du travail de l'équipe - essayez d'obtenir un aperçu du travail de chacun. Lisez leur code, exécutez leurs fonctions, essayez leurs cas de test. Ne visez pas 100% du travail de chacun, essayez d'en échantillonner un peu. Donnez-leur des commentaires, mais limitez également les points forts et les points faibles de l'équipe.
Renseignez-vous tôt et souvent auprès de votre direction - ce n'est pas du nez brun, cela vous tient au courant. Si vous ne savez pas ce dont votre direction a besoin et ce que pense votre direction, comment votre équipe peut-elle répondre aux attentes? Vous devez avoir un très bon repore avec votre patron et vous devez être dans son équipe, la façon dont vos gens sont dans votre équipe. Être en mesure de communiquer efficacement avec le patron sur des choses triviales augmente la confiance que vous pourrez obtenir de l'aide et une compréhension claire lorsque la crise éclatera. C'est aussi une bonne vérification de la réalité pour savoir où se trouvent vos oeillères.
Examiner périodiquement les ressources de l'équipe - les gens hurleront lorsqu'une ressource précédemment disponible deviendra indisponible, mais vérifieront les points de douleur inconnus. Où sont vos chokepoints? Existe-t-il de nouveaux outils qui seraient utiles? La plupart des équipes ont un gars que je considère comme le Tool Hunter qui est toujours au courant des derniers et meilleurs gadgets. Équilibrez les conversations entre Tool Hunter et GuyWhoHatesEverythingNew pour trouver le prochain point d'évolution. Les outils incluent tout - SW, HW, espace physique, ressources d'apprentissage.
Connaissez et restez en contact avec les équipes de support. Chaque entreprise est différente, mais connaissez les personnes en charge de votre contrôle qualité, rédaction de documents, juridique, installations, finances et tout autre groupe de soutien unique à votre entreprise . Ce sont les meilleurs déclencheurs à grande échelle auxquels je puisse penser, car ils voient le monde entièrement différent de vous.
Connaissez vos concurrents - passez au moins un peu de temps chaque semaine à découvrir comment quelqu'un pourrait résoudre les problèmes que votre produit résout s'il n'utilisait pas votre produit. Ce n'est peut-être pas une seule entreprise, mais qu'offre cette autre solution que vous ne proposez pas?
Revoir les coûts et le calendrier - Quelle est la probabilité que votre équipe respecte sa date limite actuelle? Et la prochaine date limite? Quel est le taux de combustion de vos coûts? Quels gros achats à venir n'avez-vous pas encore payés? Que reste-t-il de votre budget? Les détails varient selon la façon dont vous effectuez le suivi financier, mais même dans une entreprise très informelle, vous devriez avoir une idée du nombre de jours/semaines/mois de budget qui vous reste et de la date limite pour le produit actuel. Quelque part, d'une manière ou d'une autre, il vaut mieux planifier "combien de personnes avons-nous besoin pour faire ce travail?" et "pouvons-nous nous permettre de les payer le mois/trimestre/année prochain?". Vous devez connaître ces chiffres et avoir une entrée sur les prochaines étapes. Vous avez besoin d'un plan clair pour la semaine prochaine que vous pourriez expliquer dès maintenant si quelqu'un est entré et a demandé. Vous avez besoin d'un assez bon plan pour le mois prochain, qui ne changera qu'à 2-3 endroits lorsque la réalité arrivera. Vous avez besoin d'un plan sommaire pour le trimestre et d'un général sur le dessus de votre tête Gist pour l'année. Après cela, même dans un projet d'envergure, les chiffres ne sont que des chiffres. Écoutez-les, mais réalisez que personne n'a signé de sang.
C'est ma tête de liste. J'ajoute généralement à cela car je me fais gifler la tête par une "surprise" (imaginez-moi très sensible à une zone que j'ai manquée, puis je parviens à la replier dans la liste de contrôle. "Surprise" avec un sourire forcé et des dents serrées) ).
Aussi - soyez prêt pour le commutateur de contexte Dread. Si vous débutez dans la gestion, il est probable que vous ayez une petite équipe et que quelqu'un dans la gestion pense que ce serait bien pour vous de passer du temps à gérer une équipe et du temps à faire des contributions individuelles. Cela peut être fait, mais le changement de contexte entre les deux est approximatif. Planifiez-le. Bloquez le temps pour changer (comme avant et après le déjeuner) et connaissez votre ensemble de compétences moins pratiqué et réalisez que vous devrez vous y entraîner les premières fois - alors réservez du temps pour faire quelque chose de "global" et comprenez que vous aurez besoin d'au moins deux heures pour vraiment aller n'importe où.
Le changement de contexte fonctionne dans les deux sens - de la gestion au travail pratique et vice versa. Mais lorsque vous passez de votre point de force et de pratique à votre lieu de gêne et moins de pratique, vous ressentez davantage la douleur et l'impulsion à battre en retraite est forte. Sachez qu'il est là et combattez-le et réalisez que le fait de vous débattre dans la grande image vous permet de mieux tout comprendre. Donnez-vous le temps de battre.
Lisez ce livre: Herding Cats: A Primer for Programmers Who Lead Programmers
Il y a quelque temps, j'ai offert ce livre à mon patron et il l'a aimé. Quand je l'ai lu, il semblait qu'il savait de quoi il parlait. Et c'est ainsi. L'auteur raconte sa propre expérience. N'est pas une collection de "vérités simples" du gestionnaire - ce sont les mots de l'ancien programmeur. Et il faut comprendre que c'était son expérience, mais la vôtre pourrait être différente. Donc, sur certaines choses, vous devriez regarder d'un œil critique. "Manager ne peut plus être programmeur - c'est important".
Lorsque j'ai récemment pris la direction technique d'une petite entreprise sur un produit que je n'avais pas développé, ce que j'ai trouvé très utile dans la gestion des choses était de documenter en anglais le fonctionnement du produit - des fonctionnalités que j'ai documentées dans le concombre et pour les internes J'ai écrit des explications sur le modèle objet et je passe par différents contrôleurs. Ce que j'ai trouvé en faisant cela, c'est que A) le produit était un peu en désordre :) Et B) j'ai appris beaucoup plus rapidement comment l'application fonctionnait, afin que je puisse avoir une conversation intelligente sur les problèmes et les besoins de refactorisation, ou ce qu'il faudrait pour implémenter une fonctionnalité donnée.
Les images aident aussi — je ne plaisante pas avec des produits comme Visio, j'utilise juste des crayons et du papier vierge (vraiment, je le fais — je travaille à la maison et souvent aux côtés de mon enfant de 2 ans) mais tout ce qui fonctionne pour vous est ce que vous devez utiliser.