Le développeur principal n'est pas en vain le "lead". Cette phrase a été entendue lors d'une conférence sur la gestion informatique et a soulevé une question, pourquoi, en fait, "pas en vain"? C'est cette question qui m'a poussé à écrire cet article.
En évaluant mon expérience, je peux dire que les principales caractéristiques d'un développeur leader peuvent être réduites à 3 points:
- Il pense non seulement à son jardin, mais aussi à tout le jardin (c'est une qualité clé). Prêt à établir des normes et à surveiller leur mise en œuvre.
- Il connaît parfaitement son propre langage et son propre cadre, connaît bien l'architecture et possède une solide expérience professionnelle. La «solidité» ne signifie pas nécessairement le temps passé au clavier, la quantité et la qualité des projets écrits sont importantes.
- Il veut et peut raisonnablement transmettre son opinion, la défendre et rechercher un compromis si nécessaire.
En plus d'écrire du code (reste la responsabilité principale), le facilitateur participe à la sélection de l'équipe et à son développement dans la bonne direction, à la recherche de solutions techniques aux problèmes douloureux ou imminents, surveille la sécurité et l'intégrité du système, et bannit régulièrement les idées folles des managers ou autres développeurs.
L'une de ses forces est une image globale du monde, dans laquelle il est précisément déterminé ce qui est bon et ce qui est mauvais. Cela vous permet de prendre rapidement des décisions et de les donner vie sans hésitation. Cette confiance est contagieuse et vous permet de gagner en crédibilité aux yeux de managers qui ne sont déjà pas si simples et clairs. En effet, outre les aspects techniques, «meilleurs», «plus fiables» et «plus rapides», au niveau de la gestion, il y a toutes sortes de «le client ne voudra pas», «l'investisseur n'appréciera pas» et toutes sortes de «Vasya seront offensés». Lorsque le manager entend "non, ici, il suffit de le faire, car 1, 2 et 3" - il soupire de soulagement. Le choix devient évident et la responsabilité tombe de ses épaules.
Il y a un peu plus d'un an, j'ai finalement quitté le poste de développeur principal et j'ai décidé de faire une petite rétrospective de mes erreurs les plus ennuyeuses. Donc:
Erreur numéro 1. Sur-gestion
J'ai eu un cas il y a environ trois ans. En plus de mes collègues qui ont reçu des tâches directement du manager, le développeur est venu nous voir dans l'un de mes projets, et j'ai déjà défini les tâches pour lui. Pour le plonger dans le travail, j'ai passé 3 jours avec lui pendant 14 heures d'affilée, tout raconter et tout montrer, en m'assurant qu'il comprenait tout correctement. Cela a donné des résultats, puis toutes les tâches ont été définies immédiatement avec la solution: ouvrir un tel module, y ajouter telle ou telle fonction, connecter cette bibliothèque, etc ... En général, cela fonctionne et porte immédiatement ses fruits, mais :
- Prend du temps au détriment de vos propres tâches.
- Soulage la responsabilité du résultat de l'employé. Vous avez dit quoi faire exactement, ce qui signifie que si cela n'a pas fonctionné, il vous informera volontiers à ce sujet, en disant que vous cherchez une autre solution.
- Le sevrage d'un employé de la pensée et l'empêchant de se développer
Après 9 mois, je me suis retrouvée
enceinte très fatiguée de ce mode de travail, et la salariée n'a pas atteint le niveau de qualification requis.
Il est plus correct de fixer les tâches à un niveau suffisamment élevé pour que la personne elle-même cherche des solutions et en porte la responsabilité. À la question "comment faire cela?" vous devez toujours répondre: «Que pensez-vous? Des idées? », Stimulant ainsi le travail de la pensée dans la bonne direction. La réponse peut être demandée, mais seulement en s'assurant que la personne elle-même a déjà posé cette question et effectué une analyse.
Erreur numéro 2. Concessions à la tête dans la solution technique
À un moment donné, mon manager a aimé l'une des nouvelles technologies sensationnelles (non, pas la technologie sensationnelle à laquelle vous avez pensé). Sa mise en œuvre a miné l'intégrité du système, créé une division inutile des fronts de travail et généralement ralenti la vitesse de développement pour toujours. Pour moi, c'était évident à l'époque, mais la belle apparence de la démo et le désir d'expérimenter ont pris le dessus sur le leadership, m'ont convaincu par le crochet ou par l'escroc, et nous l'avons mis en œuvre. La compréhension qu'il s'agissait d'une erreur a atteint la direction quelque part après un an et demi.
J'ai conclu que vous devez respecter votre instinct avec respect, lui faire confiance et le protéger.
Au fond, vous comprenez pourquoi vous vous sentez ainsi. Il faut être capable de sortir cette compréhension de soi-même, puis en formuler des arguments.
Erreur numéro 3. Manque d'empathie et de toxicité
Lorsque vous passez beaucoup de temps avec l'ordinateur et que vous êtes passionné par ce que vous faites, vous pouvez généralement oublier que les gens sont également là. Ils ne sont pas parfaits, mais chacun a son intention positive concernant ce qu'il fait. Il est important de voir cette intention positive toujours et en tout. Cela aide à maintenir une attitude bienveillante dans les situations où une personne fait une erreur. On entend constamment des histoires sur la façon dont les aînés, sans une goutte de compassion, brisent les résultats des efforts de leurs collègues moins expérimentés, que les plongent dans l'obscurité et les privent de motivation pour travailler. Après avoir analysé mon expérience, je me suis rendu compte que je m'autorisais parfois cela, bien que sans quelques formes extrêmes.
En ce qui concerne la toxicité, je voudrais noter séparément qu'en plus des critiques trop sévères, il existe d'autres formes qui peuvent dans une certaine mesure nuire au désir de travailler avec vous. La toxicité elle-même est très contagieuse et vous pouvez facilement la récupérer auprès de mes collègues, j'ai donc décidé à un moment donné de professer le principe «ne laissez pas le mal aller plus loin que vous-même» (identifiez-le et supprimez-le d'abord en vous-même) et j'ai compilé une liste de manifestations que vous pouvez considérer la toxicité (sur la base du rapport sur
TED "7 péchés capitaux de communication" ):
- Potins. Tout le monde veut bavarder un peu parfois, mais à grande échelle, les potins sont dégoûtants
- Condamnation. Il est difficile de communiquer avec quelqu'un qui vous blâme. Surtout si l'on sait qu'il condamnera à l'avance toute action.
- Négativité Il y a des gens qui ne sont satisfaits de rien et jamais.
- Pleurnicher. Les plaintes concernant la vie ne sont autorisées qu'en quantité homéopathique.
- Des excuses. Transfert de culpabilité, déni de responsabilité.
- Embellissement. L'exagération constante à laquelle de nombreuses personnes sont sujettes lorsqu'elles parlent de projets, de leur expérience, de leurs connaissances. Toute exagération au fil du temps tend à se fondre en mensonges continus.
- Dogmatisme. Lorsque l'orateur ne partage pas où se trouve le fait vérifié et où est son opinion subjective, et vous arrose d'un flux continu, le faisant passer pour une vérité prouvée. L'exact opposé de la discussion scientifique.
Erreur numéro 4. Ignorer les parties prenantes
Votre chef a des collègues de même niveau que lui et au-dessus. Ils peuvent être amis ou ennemis. Ils peuvent ne pas toujours aimer votre influence légitime sur les décisions du leader, et les décisions elles-mêmes ne correspondent pas toujours à leurs intérêts. Lorsque vous êtes programmeur, vous n'y prêtez aucune attention et n'y pensez même pas. En règle générale, votre superviseur vous encapsulera de ces choses aussi longtemps que possible. À un certain moment, vous constaterez peut-être que vous êtes gracieusement mêlé aux choses les plus inattendues et les moins évidentes par des personnes qui, à première vue, n'ont rien à voir avec votre travail. En général, vous pouvez vivre avec cela, mais si l'adversaire est sophistiqué, il est fort possible que vous souhaitiez très bientôt déménager dans un autre bureau, travailler plus à domicile ou même changer d'emploi.
Vous pouvez éviter de telles situations si vous tenez compte à l'avance des autres personnes intéressées par le projet que vous mettez en œuvre, du niveau d'influence sur ce projet, des objectifs auxquels est confronté la partie prenante, des craintes et des espoirs qui peuvent surgir pendant le travail. Les peurs doivent être dissipées, on ne peut pas les laisser grandir. Les espoirs doivent être justifiés. En général, une stratégie est définie de la manière suivante:
- Faible influence et faible intérêt: vous pouvez vous permettre de ne rien faire
- Impact faible et intérêt élevé: vous devez être informé des changements, des plans, etc.
- Impact élevé et faible intérêt: similaire
- Grande influence et grand intérêt: vous devez travailler dur, même si vous êtes dans différents départements et / ou à différents niveaux.
Erreur numéro 5. Réévaluer vos capacités
C'est commun à tout le monde d'une manière ou d'une autre, et votre manager est susceptible de le savoir. Cependant, il peut parfois aussi sous-estimer la quantité de travail à venir et la vitesse de sa mise en œuvre. Cela semble ringard, mais cela a été à plusieurs reprises la raison pour laquelle mon manager a été déçu et moi avec lui. On peut facilement se souvenir de plusieurs situations où j'ai répondu que nous pouvons le faire en une demi-journée, puis je me suis assis sur une tâche toute la semaine avec le week-end. Pendant ce temps, la tâche peut perdre de sa pertinence ou d'autres tâches plus importantes peuvent être effectuées. L'habitude de ne pas donner d'évaluation immédiatement m'a beaucoup aidé. Si la question n'est pas hypothétique, mais spécifique, alors il vaut la peine de prendre du temps pour construire l'évaluation et il est conseillé de prendre en compte les risques possibles. Après avoir pris connaissance de l'évaluation en
trois points, il est devenu beaucoup plus facile pour moi de tirer une conclusion raisonnée sur le temps nécessaire passé et, surtout, l'évaluation elle-même est devenue beaucoup plus proche de la réalité.
Résumé
En résumé, je peux dire que le développeur principal fait volontairement face à l'horizon d'un environnement de gestion plutôt agressif et inconnu. C'est cet endroit qui devient un nouveau point de croissance, car le côté technique des travaux ne soulève pas tant de questions: les investissements dans les infrastructures sont effectués régulièrement, la dette technique est remboursée en temps opportun, l'architecture se développe harmonieusement et avec compétence. Cependant, pour la mise en œuvre efficace de leur travail (et parfois juste pour «survivre»), il est nécessaire de comprendre rapidement les bases de la gestion de projet et d'équipe, d'analyser les principaux problèmes de leurs prédécesseurs dans des postes similaires, et d'essayer de les éviter ou de les résoudre à l'avance.