Comment puis-je réussir en tant que développeur principal? [fermé]

Je suis devenu développeur principal dans un projet particulier, mais j'ai du mal à me concentrer sur une vue d'ensemble et à veiller à ce que toutes les parties du projet soient couvertes.

Que dois-je garder à l'esprit lors de la gestion de ce projet? Comment puis-je m'assurer que tout est géré comme il se doit?

J'ai vu ce projet monter en avant d'autres développeurs alors qu'ils effectuaient la transition vers le niveau senior ou principal. Voici quelques suggestions que j'ai faites aux autres.

• Comprendre quel est l'objectif du projet.

Souvent, il ne s'agit 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 répondant à un besoin de l'entreprise. Gardez toujours cela à l'esprit car c'est votre objectif principal.

• Découpez ce qui doit être fait en tâches. Comprendre 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 dissimuler des éléments, sachez qu’ils présentent 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 devriez essayer). Assurez-vous que votre responsable 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 sur une base quotidienne, mais hebdomadaire fonctionne) quel est le statut du projet. Et par statut, je veux dire ce qui a été fait, ce qu'il reste à faire, des questions en suspens, des problèmes, etc. Tout ce qui peut avoir une incidence sur l'achèvement du projet doit être signalé.

• Chaque jour, passez en revue la grande image.

Vous devriez passer en revue la grande image chaque jour pendant une heure. Posez-vous les questions. Qu'est-ce qui a été complété? Que reste-t-il à faire? Quelles sont les questions ouvertes? Quel est le but? Vous devriez pouvoir donner à quelqu'un le statut 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 la réalisation de vos propres tâches de programmation. Cela signifie que lorsque vous avez 3 juniors qui ont besoin d’aide, votre travail est d’aider à ne pas gémir sur le fait que cela vous éloigne du développement. En tant que responsable, vous devenez souvent le frein au progrès si vous êtes d'abord trop concentré sur vos propres tâches de développement.

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'ils vont se débattre toute la journée. Cependant, ils ne progresseront jamais à moins d’obtenir les tâches et vous ferez des heures supplémentaires pendant que votre équipe joue à des jeux.

De plus, ne corrigez jamais le code de quelqu'un d'autre. Dites-leur ce qui ne va pas (et pourquoi) et demandez-leur de le réparer. Ou vous entrerez dans un cycle où vous devrez tout régler, car ils ne vont pas mieux. S'ils ne peuvent pas résoudre le problème, demandez-leur s'ils devraient rester dans l'équipe. Ne laissez pas les membres faibles de l'équipe rester parce que vous corrigez tout ce qu'ils font.

En tant que responsable, vous devez être le méchant et lui donner les mauvaises nouvelles (à la fois en haut et en bas de la chaîne). Cela va aussi avec le travail. Cela signifie que vous devez faire la mauvaise évaluation de la performance; vous devez leur dire que la date limite a été avancée ou que les exigences ont changé; il faut pousser le paresseux qui ne progresse pas; 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 à obtenir des logiciels, pas à vous faire des amis. La communication est essentielle et éviter les mauvaises nouvelles aggrave la situation. Un client est beaucoup plus susceptible de supporter de se faire dire qu'il lui faudra trois semaines de plus par mois avant le lancement qu'il ne le fera quand la date de lancement passera, puis vous lui direz qu'il vous faut trois semaines de plus.

Voici ma liste de contrôle informelle. C'est très informel ... Je ne fais pas tout ce que je fais tous les jours, mais si je ne frappe pas toutes ces choses chaque semaine, je m'inquiète un peu et si je ne les frappe 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 à chaque équipe individuellement - est-ce que tous les membres de votre équipe ont un travail utile à faire? connaissez-vous l'objectif général du produit et de la version actuelle? savent-ils comment vous faites de l'argent et quelle est la principale orientation de votre entreprise? savent-ils en quoi leur travail actuel correspond à tout cela?

• Parlez à l'équipe collectivement - rassemblez-les avec les principales actualités, réunissez des 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, vous devrez les guider à travers les points principaux et deviendra inévitablement un scénario à vous de jouer. Ce n'est pas faux - il est parfois très important que tout le monde vous entende dire l'information publique à tout le monde . Donc tout le monde sait que vous donnez l'information universellement. Mais la réunion "vous-pour-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 de vous faire une petite enquête sur le travail de tout le monde. Lisez leur code, exécutez leurs fonctions, essayez leurs scénarios de test. Ne visez pas 100% du travail de chacun, essayez de goûter un peu de tout le monde. Donnez-leur des commentaires, mais notez également les points forts et les points faibles de l'équipe.

• Renseignez-vous tôt et souvent auprès de votre direction - il ne s'agit pas d'un nez brun, mais d'une mise à l'écart. Si vous ne savez pas ce que votre direction a besoin et ce que votre direction pense, alors comment votre équipe peut-elle éventuellement répondre aux attentes? Vous devez avoir une très bonne réputation avec votre patron et vous devez faire partie de son équipe, comme vos collaborateurs le sont dans votre équipe. Etre capable de communiquer efficacement avec le patron sur des sujets triviaux augmente la confiance que vous pourrez obtenir de l'aide et une compréhension claire lorsque la crise frappe. C'est également un bon moyen de vérifier la réalité de vos grands aveugles.

• Examinez périodiquement les ressources de l'équipe : les personnes crient lorsqu'une ressource précédemment disponible devient indisponible, mais recherchez des points de douleur inconnus. Où sont tes points serrés? Y a-t-il de nouveaux outils qu'il serait utile d'avoir? La plupart des équipes ont un gars que je considère comme le chasseur d'outils, qui est toujours au courant des derniers gadgets. Équilibrez les conversations entre Tool Hunter et GuyWhoHatesEverythingNew pour trouver le prochain point d’évolution. Les outils incluent tout: logiciel, matériel, espace physique, ressources d’apprentissage.

• Connaître et rester en contact avec les équipes de support. Chaque entreprise est différente, mais connaissez les personnes en charge du contrôle de la qualité, de la rédaction des documents, des aspects juridiques, des installations, des finances et de tout autre groupe spécifique à votre entreprise. Ce sont les meilleurs grands déclencheurs auxquels je peux penser, car ils voient le monde entièrement différent de vous.

• Connaissez vos concurrents - passez au moins un peu de temps chaque semaine à trouver une solution au problème que votre produit résoudrait s'il n'utilisait pas votre produit. Ce n'est peut-être pas une seule entreprise, mais qu'est-ce que cette autre solution offre que vous n'aimez pas?

• Examiner les coûts et le calendrier- Quelle est la probabilité que votre équipe parle de son échéance actuelle? Que diriez-vous de la prochaine échéance? Quel est le taux de consommation 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 en fonction de la manière 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 qu'il vous reste et de votre échéance pour le produit actuel. Quelque part, il est préférable que quelqu'un planifie "combien de personnes avons-nous besoin de faire ce travail?" et "pouvons-nous nous permettre de les payer le mois / trimestre / année prochain?". Vous devez connaître ces chiffres et participer aux prochaines étapes. Vous avez besoin d'un plan clair pour la semaine prochaine que vous pouvez expliquer dès maintenant si quelqu'un entre et demande. Vous avez besoin d'un très bon plan pour le mois prochain, cela ne changera que dans 2-3 endroits où la réalité frappe. Vous avez besoin d’un plan sommaire pour le quart et d’un général pour l’année. Passé cela, même dans un projet énorme, les chiffres ne sont que des chiffres. Écoutez-les, mais sachez que personne n'a signé avec le sang.

C'est ma tête de liste. J'ajoute généralement à cela quand je me fais une tête à la tête (surprise) ).

Aussi - soyez prêt pour le changement de contexte d'effroi. Si vous débutez dans la gestion, il est probable que vous ayez une petite équipe et que quelqu'un de la direction pense qu'il serait bien que vous passiez du temps à gérer une équipe et à consacrer du temps à des tâches de contributeurs individuels. Cela peut être fait, mais le changement de contexte entre les deux est rude. Planifiez-le. Bloquez votre temps pour passer (comme avant et après le déjeuner) et connaissez vos compétences moins expérimentées et réalisez que vous devrez vous y glisser les premières fois - alors réservez-vous du temps pour faire quelque chose de «grand», et réalisez que vous aurez besoin d'au moins deux heures pour aller vraiment n'importe où.

Le changement de contexte fonctionne dans les deux sens - de la gestion à la pratique, et inversement. Mais lorsque vous passez de votre point de force et de pratique à votre lieu d'inconfort et de moins de pratique, vous ressentez davantage la douleur et l'impulsion à la retraite est forte. Connaissez-la, combattez-la et réalisez-vous que le fait de se débattre dans une vue d'ensemble vous rend plus apte à tout comprendre. Donnez-vous le temps de vous battre.

Lire ce livre: Herding Cats: Guide d'introduction pour les programmeurs qui dirigent les programmeurs

Il y a quelque temps, j'ai offert ce livre à mon patron et il l'a aimé. Quand je le lisais, il semblait qu'il sache de quoi il parle. Et c'est comme ça. L'auteur raconte sa propre expérience. N'est-ce pas un recueil de "simples vérités" du manager - tels 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 de façon critique. "Manager ne peut plus être un programmeur - c'est important".

Récemment, lorsque j’ai repris la direction technique d’une petite entreprise pour un produit que je n’avais pas développé, j’ai trouvé très utile de gérer les choses, c’était de documenter clairement 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 d'objet et les flux à travers différents contrôleurs. Ce que j’ai trouvé en faisant cela, c’est que A) le produit était un peu le bordel :) Et B) j’ai appris beaucoup plus rapidement comment l’application fonctionnait pour pouvoir discuter intelligemment des problèmes qui se posaient et de ce qui nécessitait une refactorisation, ou ce qu'il faudrait pour mettre en œuvre une fonctionnalité donnée.

Les images aident également - je ne plaisante pas avec des produits comme Visio, je n’utilise que des crayons et du papier vierge (je le fais vraiment - je travaille à la maison et souvent aux côtés de mon enfant de 2 ans), mais ce qui fonctionne pour vous est ce que vous devriez utiliser.