👩🏾‍🎨 👰🏼 👨‍💻 Du développeur au manager et inversement 🤽🏾 🧀 🏫

À l'hiver 2012, un collègue a suggéré que moi, un programmeur C ++ avec cinq ans d'expérience, écrive la première application pour Android. Un an plus tard, j'ai commencé à diriger une petite équipe de développeurs mobiles, et depuis lors, la taille de mes équipes n'a cessé de croître. Mais l'année dernière, après 2 ans de gestion du département de développement mobile, j'ai encore soufflé de la poussière avec mon IDE préféré.

Voyons comment c'était de l'autre côté, pourquoi je suis retourné chez les développeurs à l'âge de 30 ans et plus (spoiler) et ne le regrette pas.

Chemin vers les développeurs Android

Android, qui à l'époque était un gadget dans ma ville de province, m'a semblé être un autre «jouet» amusant, en jouant, que vous pouviez laisser tomber en toute sécurité et revenir au Qt habituel. Et donc tout a commencé: un ami a lancé l'idée d'une simple application pour la comptabilité des revenus et des dépenses, nous avons commencé à la voir pendant notre temps libre et six mois plus tard, MVP était prêt à être publié.

Notre Money Keeper avait un design plutôt primitif, mais une UX bien pensée: les revenus ou les dépenses étaient enregistrés en un clic - appuyez sur l'icône de catégorie a immédiatement ouvert une fenêtre pour entrer le montant.

Je me souviens très bien de la façon dont j'ai vu les statistiques de téléchargement: la première personne à télécharger mon application était quelqu'un d'Egypte. Et celui-ci n'a pas supprimé l'application la même semaine, mais a continué à l'utiliser!

Petit à petit, plusieurs dizaines de téléchargements par jour, l'audience grandit, la note augmente, les premiers avis positifs apparaissent. Dire qu'elle a inspiré, c'était minimiser. J'ai répondu aux critiques sur le marché, prévu un développement ultérieur en fonction des souhaits des utilisateurs, tout simplement parce que mon application est nécessaire aux utilisateurs, ils en remercient et en mettent cinq. Et toutes nos publicités étaient dans un seul message sur w3bsit3-dns.com.

Il était également frappant de voir à quel point le développement mobile diffère du développement de systèmes embarqués et d'applications de bureau sur lequel j'ai travaillé auparavant. Le chemin de l'application vers l'utilisateur et ses commentaires sont très courts. Le public est immense, et tout ce que vous faites, vous devriez au moins bien le faire, sinon l'application ne sera nécessaire à personne, et tout le travail pourra être jeté.

Comment je suis devenu chef d'équipe, "car_à_pour_someone_something_is due_"

L'application s'est développée et est devenue plus compliquée, une version payante avec des fonctionnalités supplémentaires est apparue. Ma paire de mains pour le développement de deux applications a cessé d'être suffisante, surtout compte tenu du fait que je les ai écrites pendant mon temps libre à partir du travail principal. Il n'y avait pas de budget spécial pour l'embauche d'employés, car la monétisation n'apportait pas autant de revenus.

Nous avons refusé l'idée de «geler» une application gratuite pour une application payante, car nous ne voulions pas décevoir la communauté des utilisateurs reconnaissants, dont nous tirions tout le temps de l'énergie et des idées de développement. Par conséquent, nous avons décidé de prendre sur un petit salaire deux gars qui étaient loin du développement, et brûlés pour y pénétrer. Il a été décidé de les guider sur mon chemin, mais avec une différence significative: je devais leur apprendre à se déplacer et à naviguer dans le monde du robot vert et à leur montrer toutes les bosses et les trous que je connaissais sur cette route.

Je n'avais pas peur d'assumer des tâches difficiles)

je voulaisd'autres personnes ont partagé mon enthousiasme pour le développement, et même deux paires de mains n'étaient clairement pas superflues pour nous. Je suis allé chez eux, j'ai expliqué, enseigné, conseillé, aidé. J'ai défini des tâches et vérifié leur mise en œuvre. Je suis donc devenu tranquillement un petit mais manager.

Cependant, l'application a dû être fermée ... Je suis allée dans une startup, puis dans une autre, puis je suis arrivée au développement de produits dans une grande entreprise. Partout où il n'y avait pas assez de personnes pour le rôle principal, il y avait un scénario à peu près similaire: «Vous avez compris le sujet, vous êtes devenu ami avec l'équipe, n'êtes pas contre le travail de leadership, et avez-vous même une telle expérience? Essayons de définir des tâches pour d'autres personnes. Au moins dans ce sprint ... »

Mais il y avait un autre aspect important: je pensais à l'avenir - et cela semblait brumeux.Il y a très longtemps, je suis tombé sur un article sur l'âge moyen des développeurs. Il a précisé que le "pic de carrière" du développeur tombe sur 27 ans. J'ai commencé à remarquer des articles similaires - et je me suis involontairement demandé: que ferai-je en tant que développeur, par exemple, à 32 ans, quand «une jeune merde viendra qui nous essuiera de la surface de la Terre»? N'est-il pas préférable de marcher lentement vers les managers et de résoudre le «problème des 30 ans» par vous-même?

Mes principes en tant que Timlida

Au moment où j'ai abandonné C ++ et suis parti pour Android, j'avais déjà travaillé avec divers leaders et je savais exactement quel genre de leader je voulais être. Et plus tard, dans des équipes complètement différentes: produit (composé d'analystes, de concepteurs, de développeurs, de testeurs) et d'équipes de développement - j'ai essayé de ne pas m'éloigner de mes principes.

Besoin de travailler avec ceux qui sont

Un étudiant aux yeux brûlants, qui est envoyé sur la bonne voie, peut, après un certain temps, commencer à apporter plus d'avantages au projet qu'une «rock star».

Lors de l'un des projets, j'ai décidé qu'il était temps de s'éloigner du bundle MVP + Dagger + RxJava familier et d'essayer en production les outils que Google recommande d'utiliser pour créer des applications mobiles modernes. Nous avions prévu d'implémenter l' architecture recommandée en utilisant uniquement Jetpack et Kotlin avec Coroutines.

Tous les développeurs et patrons expérimentés se sont tordus les doigts au temple et ont dit qu'avec une équipe de deux jones qui n'avaient jamais rien utilisé de la pile que j'avais sélectionnée, nous remplirions le projet et la responsabilité serait sur moi personnellement. Mais ces deux joons étaient ravis de pouvoir travailler avec ce que les développeurs Android ont écrit sur le blog hier.

Oui, bien sûr, nous avons attrapé un tas de maladies infantiles des versions alpha des bibliothèques au début ...

Mais les gars ont travaillé dur, sont montés à la source et ont étudié les problèmes sur Github, profilés la nuit, et à la fin nous avons eu:

code propre, stable et facile à entretenir,
produit réussi en production,
et un tas d'expérience inestimable.

Sur un autre projet, un développeur très cool est venu dans l'équipe, qui ne s'est pas immédiatement fait des amis avec toute l'équipe, mais a parfaitement scindé les tâches. Les gars l'ont contacté à travers la douleur, les larmes et les patrons, et quelqu'un a même dit qu'il valait mieux prendre n'importe quel mois de juin à sa place, mais à la fin j'ai réduit la communication en direct entre eux au minimum nécessaire, et tout est devenu calme.

Il faut aussi travailler avec des "rock stars", même si c'est parfois difficile.

Naturellement, il y a des gens qui ne font pas sciemment leur travail: quelqu'un pense qu'il est au "patron qui fera tout pour moi", quelqu'un il ne peut tout simplement pas ou ne veut pas travailler. Si les conversations et le temps ne vous aident pas, vous ne devriez pas avoir peur de vous en séparer.

Je ne travaille pas avec des subordonnés, mais avec des gens

Chacun a ses propres circonstances, besoins, tempérament et humeur. Une fois, avant de passer un sprint difficile, une testeuse, dont tout le monde attendait le résultat du test final du produit, s'est mise en colère à cause d'un scandale avec son mari qui ne trouvait pas de chaussettes propres. Date limite, ce n'est pas le premier jour de tests intenses, mais le voici. Elle n'avait pas du tout envie de travailler. Dans cette situation, il a été possible d'écraser, d'exiger et de menacer. Mais j'ai essayé de le comprendre et de redistribuer les ressources des autres testeurs de manière à combler l'écart. Après une demi-journée, il s'est refroidi et nous avons réussi à investir dans le temps.

Qui avant les vacances ne s'est pas assis sur d'autres sites pendant les heures de travail, laissez le premier me jeter un moniteur)

Ou une autre histoire: un collègue a cessé de faire quelque chose quelques jours avant les vacances, simplement parce qu'il était occupé avec les derniers rassemblements pour un voyage à vélo en Europe, qu'il préparait depuis près d'un an. Toute cette année, il a minutieusement effectué des tâches de travail, et ici - en tant que remplaçant. Et je lui ai donné ces deux jours. Après deux semaines de vacances, il est revenu reposé et s'est mis au travail au même rythme, mais j'ai réussi à ne pas gâcher la relation dans l'équipe.

Dans une situation difficile, personne n'ira de l'avant sauf si je dirige

Dans une équipe DevOps qui était nouvelle pour moi, pendant quelques mois, j'ai «dynamisé» le déploiement de CI, et les développeurs ont ouvertement saboté sa mise en œuvre, en désaccord avec les arguments sur son utilité. Ce n'est pas qu'ils étaient rétrogrades paresseux, il me semblait juste qu'ils ne fonctionnaient pas dans l'environnement où CI était préparé correctement.

Serrant avec Google, je me suis assis le soir et j'ai choisi les paramètres. Progressivement, DevOps et les développeurs se sont impliqués dans le processus. En conséquence, nous avons réussi à configurer CI et les liaisons nécessaires pour créer et distribuer des applications, qui sont rapidement et tranquillement devenues la norme pour les différentes équipes de l'entreprise.

Est-ce que je ferme les trous dans l'organisation des processus avec intervention personnelle et micro-gestion? Peut être. Mais, il me semble, dans une telle situation d'impasse, qu'il y a deux extrêmes: «resserrer les vis», s'éloigner de plus en plus de l'équipe et devenir le «patron», ou essayer d'aider une personne quand c'est difficile pour lui, même après avoir terminé son travail, devenir «le sien». Mais ils ne laissent pas «les leurs» en difficulté.

Vous devez vous développer et développer tout le monde dans l'équipe

Lieu de travail typique d'un leader:

plus je restais longtemps sur un projet, plus je sentais que le développement moderne flottait devant moi. Une pile de technologies, de langages et de frameworks a été sélectionnée il y a plusieurs années et n'a pas changé de manière significative depuis lors. Cela était dû à des dates de gravure éternelles, à un faible intérêt commercial, mais surtout - à la peur des développeurs de quelque chose de nouveau, quand il y a un ancien aussi familier.

Il est arrivé au point où les développeurs nouvellement acceptés étaient interdits d'écrire en Kotlin, parce que les principaux programmeurs ne le connaissaient pas et ne trouvaient pas le temps (ne voulaient pas trouver?) De lui enseigner. Ces problèmes ont été résolus tout simplement: j'ai organisé des conférences techniques, des réunions et des cours sur des sujets intéressants pour toute l'équipe. Il est plus facile et plus intéressant pour les développeurs de trier une technologie sur un projet pour animaux de compagnie pendant une semaine et d'en parler aux autres que de la faire aveuglément entrer en production.

Et il est plus facile pour une entreprise de justifier une augmentation de salaire pour une personne qui étudie et présente quelque chose de nouveau et d’utile pour l’ensemble de l’entreprise.

On ne peut pas aller loin des problèmes de développement

Dès que vous ne comprenez plus les problèmes des développeurs avec des dettes techniques, les fonctionnalités de la plateforme et l'interaction entre les différentes parties du système, le pourcentage de sprints s'envole.

Il y a eu des cas où les managers ont été vraiment surpris de constater qu'il était impossible de publier une application iOS le soir du Nouvel An car les critiques d'Apple étaient partis en vacances. Les concepteurs ne comprennent parfois pas les problèmes des développeurs Android avec la composition sur différents écrans. Les backenders qui n'ont pas travaillé avec des clients mobiles auparavant doivent expliquer qu'ils n'ont pas besoin de donner une erreur de page HTML au lieu de JSON.

Et si pendant le développement du système ou de sa partie vous «regardez» de tels moments, les conséquences pour les délais peuvent être très déplorables.

Oh, combien de bien peut être réalisé simplement en adoptant des solutions techniques. Et même s'ils donnent les tâches à répartir - vous pouvez rouler des montagnes!

Ai-je réussi à diriger?

Je ne prétends pas dire que ce sont les bons principes. Je ne sais même pas s'ils correspondent à ce qu'ils écrivent dans les livres sur la gestion du personnel, car je n'en ai lu aucun. Je juge par plusieurs faits:

Les relations au sein de l'équipe se sont améliorées. Si avant moi il y avait des scandales avec la clarification des relations avec les autorités, alors avec moi - un maximum de petites escarmouches.
En général, nous rentrons dans les sprints. Même l'impossible. Et si elles ne convenaient pas, ce n'était pas tellement que le client était en colère. Naturellement, c'est le mérite de l'équipe. Mais probablement un peu à moi. J'ai toujours essayé de prendre en compte tous les risques et d'effectuer une planification des tâches en les prenant en compte.
Nous avons constamment refactorisé et amélioré les produits et les processus de développement, la dette technique a diminué.
Les développeurs ont augmenté de rang et de salaire.
Mes conseils directs étaient également jolis.

D'accord, qu'en est-il des inconvénients du leadership?

Pour moi ce sont:

Plus vous êtes gestionnaire, moins vous êtes développeur. Peu importe comment vous essayez de garder une trace des subtilités de la partie technique du projet, ils vous échappent chaque jour de plus en plus. Et plus l'équipe est grande et plus le développement est actif, plus vite. Peu à peu, le volume de nouvelles informations reçues sur Android et iOS a été réduit à la lecture des notes de publication des nouvelles versions des systèmes d'exploitation et de quelques articles sur Habré par mois.
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

Peu importe comment vous l'aimez à un endroit, vous devrez partir un jour. Et à un moment donné, j'ai commencé à chercher un nouvel emploi. On pouvait s'y attendre, je voulais entrer dans une entreprise encore plus grande afin de poursuivre le développement.

La prochaine entrevue Skype était en cours: 10 enquêteurs, 2 heures , exigences - connaissance de la partie technique du niveau développeur principal et capacité à gérer les gens. Et après 2 heures, j'ai réalisé qu'en gérant les gens, je ne sais presque rien. Au moins, je ne connais pas la théorie et je ne suis basé que sur mes principes et mon expérience.

Cela ressemblait à ceci:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

Eh bien et ainsi de suite. J'ai échoué la théorie. J'ai réussi en quelque sorte à mettre en œuvre, mais pour expliquer les principes de base de la raison pour laquelle une manière ou une autre devait être faite - non. Après l'entrevue, j'ai réalisé que j'avais atteint mon plafond dans la ligue de gestion amateur et que m'asseoir sur deux chaises ne fonctionnerait pas. Pour se développer, il fallait décider où je veux aller.

Il s'agit de mon équipe actuelle pour les travailleurs à distance. Au moins une personne supplémentaire s'y est rendue de la même manière: est allée voir les chefs d'équipe et est retournée consciemment aux développeurs.

La première façon est aux gestionnaires. Pourtant, lisez les livres très corrects. Commencez à regarder des vidéos et à assister à des conférences de gestion, de planification et de motivation. La ligue de gestion professionnelle a ses propres règles et ses spécificités.

Deuxième voie- immergez-vous dans le développement, rattrapant si possible les années de gestion.

Eh bien, la troisième option, le compromis, est de «tirer vers le haut» la théorie et d'essayer de rester «au milieu», de rester «chez les amateurs» pendant encore quelques années.

Et puis je me suis rappelé comment tout avait commencé. Avec le sentiment que vous changez le monde, faites quelque chose d'utile pour les autres. Même si vous avez peint le bouton en vert, il est devenu un peu plus agréable pour des milliers d'utilisateurs. Même si j'ai corrigé une faute de frappe. Et si vous avez déjà arrosé une fonctionnalité attendue depuis longtemps par les utilisateurs, et vous en êtes remercié dans les commentaires - ce n'est qu'une explosion d'émotions et de bonne humeur pendant quelques jours!

Ai-je ressenti un sentiment si fort en travaillant comme manager? Je pense que non. Même lorsque les clients, l'équipe et les dirigeants vous félicitent. Et lorsque les utilisateurs font l'éloge de la fonctionnalité attendue, cela est bien sûr principalement dû à celui qui l'a préparée, sciée, testée et affichée. Et pas mal - le mien en tant que manager.

Par conséquent, j'ai trouvé un endroit agréable pour travailler, j'écris du code et jusqu'à présent je n'ai aucun regret.
Y a-t-il de la vie chez les développeurs à 32 ans? Il y a!

PS

Qu'est-ce qui m'a donné en tant que développeur l'expérience du leadership?

Maintenant, je comprends mieux les affaires et le PMA, même sans mots. Souvent, je sais quelle question ils veulent me poser.
Je planifie le temps et les tâches de manière plus compétente en tenant compte des risques.
Contraste. Après avoir vu comment c'était de l'autre côté, j'ai réalisé ce que j'aime chez celui-ci.

Du développeur au manager et inversement