🏣 ⏭️ 🚕 Mauvais conseil au développeur: que faire pour «faire plaisir» à la direction 👭 🕊️ 🕖

Comme promis dans l'article précédent , nous tournons la situation dans la direction opposée. Il se trouve que je suis non seulement développeur, mais aussi leader à différents niveaux. J'ai déjà mentionné que récemment, j'ai eu de la chance pour les équipes et les collègues. Mais tout le temps, tout s'est passé.

(Grigory Oster)

Parlons des développeurs dont la gestion rêve. Cette fois, j'agirai en tant que gestionnaire abstrait ...

Au début de tout projet ...

Saviez-vous que la compétence la plus élevée d'un gestionnaire est de prendre des décisions avec un minimum d'informations initiales. Ne nous empêchez pas, dirigeants, de former cette compétence. Suivez ces tactiques:

Nommez les dates brumeuses, mais n'en parlez pas du tout.
Lorsque nous demandons si les améliorations proposées ne casseront pas les modules existants, taisez-vous, à la rigueur, faites une expression faciale mystérieuse!
En parlant des problèmes à venir du projet, ne proposez jamais vos solutions, rappelez-vous, nous avons besoin de personnes-questions, pas de personnes-options-solutions.
— , , ? 48- , 10 , .
— , .

Si au stade de la définition de la tâche, vous avez été admis chez le client pour lui poser des questions de clarification, apprenez des attaques DDoS - donnez le meilleur de vous-même. Le client attend de vous au moins 50 messages avec des questions, de préférence en détail - il appréciera votre performance dans le genre épistolaire. Vous n'avez pas besoin de joindre de captures d'écran ou de vidéos. Laissez-les décrypter votre message, même s'il ne contient que "Bonjour!" et un long "dactylographie ...".

N'oubliez pas: le client et l'utilisateur final sont des personnes différentes. Ne communiquez jamais avec les utilisateurs finaux et n'essayez pas de les imaginer! Si tante Masha à la caisse voit 25 lignes de texte sur le moniteur, placez-les calmement sans regarder la taille de l'écran. Laissez la loupe prendre si elle n'aime pas.

Ne nous dites jamais quelles tâches spécifiques seront résolues dans le cadre du projet. Ne parlez que des méthodes de solution. Et c'est souhaitable dans tous les détails - comment le CTO pourrait-il dormir paisiblement ce soir?

Dans votre histoire, ne mentionnez en aucun cas l'argent, le temps ou d'autres mesures que les autres comprennent. Après tout, même le secrétaire du directeur peut traduire des histoires sur les structures abstraites utilisées dans des scénarios utilisateur et le montant exact des bénéfices que nous obtenons. Ainsi, lors de l'évaluation des tâches, utilisez le système de quantités le plus abstrait. Rappelez-vous, 1 boa constrictor est 38 perroquets!

Récoltez autant de surprises que possible. Laissons en plus du temps pour résoudre le problème, il faudra également des abonnements payants ou des outils, que nous ne connaîtrons qu'au dernier moment. Nous aimons les pièges et serons heureux de chercher un moyen de sortir de l'impasse avant la sortie. Mon client et moi aimons augmenter le budget alloué chaque semaine, en le coordonnant constamment dans toutes les instances. Conduisez Ivan Tsarevich à travers une nouvelle itération depuis le début du conte après chaque mise à jour des informations sur l'endroit où la mort de Koshcheev est stockée.

Code parfait ...

Essayez d'écrire uniquement du code parfait pour le code parfait. Il n'est pas nécessaire de le faire la première fois. Si vous êtes pressé, écrivez rapidement, puis recommencez, puis à nouveau. N'oubliez pas: la répétition est la mère de l'apprentissage. Si le code a été réécrit trois fois et au moins légèrement différent de l'idéal, commencez d'urgence la refactorisation dans le cadre d'une petite tâche qui ne s'applique pas à cela. Mieux encore, transférez votre code vers une autre bibliothèque ou framework. Que le code soit à la mode et jeune. L'essentiel est qu'en aucun cas tous ces processus ne puissent être formulés comme des tâches distinctes. Et puis tout à coup on devine que quelque chose n'était pas idéal sur le projet? Il vaut mieux faire ce genre de choses juste avant la sortie. En ce moment, toute l'équipe travaille beaucoup plus vite!

En parlant de refactoring. Cela fonctionnera plus efficacement si vous changez simultanément les mécanismes dans le code - afin de ne pas y grimper deux fois. N'oubliez pas que ces processus devraient affecter autant de composants que possible. Pourquoi passer du temps à choisir des modules individuels? Ce n'est qu'ainsi que vous finirez par ressembler à un héros qui a sauvé tout le monde! D'autres développeurs seront ravis de découvrir les surprises des nouveaux mécanismes lorsqu'ils les tireront dans le pied.

Le code parfait doit être correctement formaté. Essayez de créer des fichiers de taille maximale, occupant de nombreux écrans et contenant plusieurs composants à la fois. En suivant ce style de conception, vous pouvez héroïquement surmonter les conflits de fusion et, pendant longtemps, être d'accord avec des collègues dont les modifications étaient plus importantes. Le code devrait ressembler aux nouilles les plus longues, pas besoin de perdre du temps à créer de petits fichiers insignifiants. Pour une seule fonction, trouvez un nom de fichier - quoi de plus douloureux?

Le code parfait que vous avez créé n'est pas nécessaire pour couvrir les tests. Vous ne pouvez parler que de la nécessité de porter la couverture à 100%, mais en réalité, 10% suffisent. Pour vous suivre, ajoutez quelques tests qui en fait ne vérifient rien, alors ils n'auront pas à être mis à jour.

S'il s'avère soudainement qu'une solution rapidement écrite ne fonctionne pas ou ne fonctionne pas comme prévu, n'hésitez pas à blâmer l'architecte système, l'API, l'administrateur du serveur, etc. pour tout. Il est clair que votre code idéal ne peut que fonctionner. Rappelez-vous l'essentiel: nous, comme vous, savons qu'un programmeur idéal ne peut travailler que sous vide dans des conditions idéales. Et si vous êtes distrait, ne donnez pas d'informations à temps, écrivez des savoirs traditionnels incompréhensibles, alors vous ne pouvez généralement pas être responsable du fait que le module implémenté ne remplit pas la tâche commerciale. Eh bien, les affaires sont notre responsabilité. Il est conseillé de garder tous les noms des coupables jusqu'à la date limite, ils seront nécessaires plus tard, ne distrayez plus les dirigeants.

Lorsque nous parlons de la nécessité de libérer rapidement MVP, n'hésitez pas à ignorer nos tentatives d'accélérer le projet au détriment de la qualité et de la rapidité. Néanmoins, ils savent qu'avec une bonne idée, vous pouvez vous lancer sur le marché à tout moment. Le temps ne joue aucun rôle. Laissez les concurrents chier, et lorsque vous écrivez le code parfait, notre MVP montera en flèche dans 5 ans. Et toutes ces années, les investisseurs seront ravis de payer pour créer un chef-d'œuvre avec leur argent.

L'ordre dans le projet ...

Votre tâche est votre personnalité. Le désordre créatif ajoutera du poids à nos yeux. La capacité de construire un gâchis et de le maintenir dans un état plutôt chaotique est si précieuse que nous transférons même des projets de main en main afin d'augmenter le degré de désordre. Dès que le chaos atteint son maximum, nous vous récompenserons avec un nouveau projet!

Si vous comprenez qu'un désordre à part entière s'est formé sur le projet, mais que vous n'avez pas encore été relocalisé, commencez à creuser vos dettes techniques avec vos pattes ou demandez un autre projet vous-même. Peut-être que nous n'avons tout simplement pas suivi la situation.

Tout ce qui se passe à l'intérieur de l'équipe doit passer par nous. Même si vous décidez de sortir fumer avec le testeur, assurez-vous d'être d'accord avec lui via le chef de projet, mais il est préférable d'impliquer le CTO dans ce processus. Nous nous sentons inutiles si personne ne se plaint de nos collègues, ne cherche pas à résoudre les conflits au sein du groupe de travail ou à introduire des règles de travail.

Sur les problèmes de conception, il est conseillé pour nous d'écrire uniquement en PM. Cela cachera toutes les traces de notre activité à la haute direction et nous obligera en même temps à raconter les solutions élaborées aux autres participants au processus. Nous l'aimons tellement!

Résolution de problème ...

Une fois que vous avez résolu le problème ou corrigé le bogue, ne vérifiez en aucun cas votre solution. Criez «Hourra» et fuyez le lieu de travail aussi rapidement et plus loin que possible! Vous allez donc transmettre la tâche plus rapidement et trouver à l'équipe une leçon pour la première moitié du prochain sprint - vous corrigerez les montants de la tâche qui vient d'être livrée. Ce qui est important, vous ne privez pas non plus le travail de vos collègues testeurs. Un ensemble de bugs causés par la nouvelle béquille de la solution est le meilleur cadeau du vendredi soir! Archivez votre code dans un seul cas réussi, vous êtes optimiste.

La séquence d'actions correcte lors de la résolution d'un problème:

lire les savoirs traditionnels, en ignorant les notes,
fume pour oublier les détails,
mettre en œuvre rapidement et sans hésitation uniquement les fonctions de base,
passer la tâche tout aussi rapidement
Obtenez des révisions avec un décryptage clair des notes de savoirs traditionnels non lues,
Qu'il en soit ainsi, résolvez le problème en 3-4 itérations.

Pas de refactoring dans la foulée, pas de peignage de code. Laissez les variables être appelées comme votre jambe gauche le souhaitait au moment de la compréhension, et le code reste mal lu. Ce n'est pas à vous de comprendre cela plus tard! Eh bien, entraînez-vous à prendre votre code en revue immédiatement - vous êtes un bon gars, mais délicat.

À ce stade, il est impossible de prouver que la tâche est terminée (ou ils proposeront parfois une vidéo pour écrire sur le projet comment le module démarre ...). Peut-être que le testeur ne remarquera aucune anomalie avec le TOR, ou bien la tâche sera envoyée à une autre, alors que pour l'instant vous pouvez vous détendre sur une nouvelle tâche.

S'il y a des moments ambigus dans la tâche, par exemple, on ne sait pas si le champ de saisie ne doit accepter que des lettres anglaises ou russes en même temps, n'hésitez pas à répondre aux questions vous-même, en fonction de vos goûts et de votre expérience de vie. Puisqu'il n'est pas écrit dans l'énoncé des travaux, cela devrait être évident pour tout le monde!

Et ne testez jamais d'hypothèses sur une petite partie de la tâche, sinon vos collègues penseront que vous avez des doutes!

Si vous êtes pressé par une tâche à publier et que vous comprenez que certaines fonctionnalités devront être terminées plus tard, vous n'avez pas à passer du temps à définir une tâche dans le système de gestion de projet. Il vaut mieux faire une note directement dans les commentaires du code et n'en parler à personne. Il sera donc encore plus intéressant de rattraper les dettes techniques. Il y aura un sentiment qu'il y en a beaucoup et vous êtes toujours très nécessaire sur le projet.

Ne conservez pas plus de la moitié des fichiers dans le référentiel du projet! Pas étonnant que tant de lieux de stockage différents aient été inventés dans le monde. Il est important de placer les fichiers restants de manière égale entre les référentiels personnels des employés et, par exemple, la documentation (pas même nécessairement pour le projet en cours). Ainsi, les «connaissances secrètes» sur le projet seront partagées également dans l'équipe et tout le monde sera irremplaçable. Et puis un nouveau venu dans le projet viendra le découvrir rapidement dans celui déjà mis en œuvre. Quelque chose auquel vous ne pouvez pas résister à leur place - tout le monde sera instantanément remplacé par des jones moins chers.

Chaque projet doit avoir des connaissances secrètes qui se transmettent de bouche en bouche. Ce n'est que de cette façon que vous pourrez soupirer une photo et cracher: «Oh, ces juin travaillent depuis une semaine, mais ils ne savent rien du projet. Prenez du recul, faites-le vous-même! "

Si vous vous êtes engagé à effectuer une tâche à partir de Jira, il n'est absolument pas obligatoire de la marquer. Nous sommes des médiums - nous devinerons ce que vous faites maintenant, mais en même temps, nous devinerons l'état actuel du projet. Soit dit en passant, nous pouvons le faire avec le temps passé - nous n'avons rien à écrire n'importe où, nous allons connaître le nombre d'heures travaillées et calculer votre salaire.

Communication sur le projet ...

Avez-vous entendu parler de l'omnicanal? La communication sans se diviser en différents canaux est la dernière tendance. Soyez tendance! Pour toute question, écrivez PM à un messager, c'est mieux personnel, pas un travailleur - pour qu'il sache que vous n'êtes pas derrière les dernières tendances de ce monde. Mais les équipes de projet dans Slack et d'autres messagers sont mieux utilisées pour envoyer des images drôles avec des chats et des conversations personnelles.

Soyez en retard pour les réunions régulières de 15 à 20 minutes. Mieux encore, ayez un microphone de l'ère soviétique et une connexion Wi-Fi loin du lieu de travail. Laissez tout le monde écouter votre croassement, c'est comme des peintures abstraites - tout le monde entend ce qu'il veut entendre. Et au Quotidien, vous pouvez poser toutes les questions que vous avez sur le projet. S'il n'y a pas suffisamment de problèmes de conception, ajoutez plus de sujets supplémentaires. Au pire, vous pouvez toujours demander quelque chose d'abstrait. Un tel bon exemple reflète le mieux pourquoi vous n'aimez pas téléphoner et pourquoi vous feriez mieux de ne pas y assister.

Eh bien, n'oubliez pas, chaque personne a un Bluetooth haute vitesse dans sa tête. Par conséquent, si vous avez déjà tout imaginé dans votre tête, transférez simplement cette image. Les mots ne peuvent expliquer que de petits détails qui n'étaient pas visibles sur l'image. Laissez-les essayer de vous comprendre, c'est leur travail.

Soit dit en passant, il vaut la peine d’être en retard au bureau si vous travaillez sur notre territoire. C'est le seul moyen de créer une impression de votre importance. Et ne préviens jamais d'être en retard. Cela montrera que vous étiez pressé, c'est-à-dire gâcher votre image d'un gourou calme.

Si vous quittez votre lieu de travail, vous n'avez pas à vous soucier de la disposition des statuts dans Slack ou dans d'autres messageries instantanées. Quiconque écrit en votre absence (et lance une notification) donnera une raison pour une longue et réfléchie malédiction que vous êtes distrait dans votre temps personnel. Où d'autre trouveriez-vous une telle raison? Et laissez les managers et les collègues apprendre à accumuler leurs questions rapides avant le début de votre journée de travail officielle (il y aura quelque chose à discuter dans la journée).

L'échange d'expérience est superflu. Par conséquent, si vous publiez toujours un lien vers un article ou un cadre vers le canal Éducation dans Slack, vous n'avez pas besoin de faire de description pour celui-ci. Que ce soit une quête de collègues. Ils veulent de nouvelles connaissances - laissez-les filtrer et comprendre ce que vous leur avez apporté. Et peu importe que ce ne soit pas leur domaine. Et en aucun cas ne partagez vos observations de projet, décisions intéressantes, bugs et conclusions instructives. Développeur à développeur loup. Vous devez rivaliser et ne pas développer une expérience d'équipe commune! Et oui, j'ai presque oublié! Si vous trouvez un long article, alors ne le lisez pas vous-même, il suffit de le présenter à vos collègues, peut-être qu'ils seront intéressés.

Le travail des autres développeurs peut et doit être critiqué. Vous devez trouver à redire à chaque petite chose. Ne confondez pas critique et critique. Il est nécessaire de critiquer longuement et avec goût (et de préférence aussi abstrait que possible, par exemple: «Votre code est terrible»), mais effectuez la révision le plus rapidement possible - cliquez sur la coche verte sans regarder le code et ne laisser aucun commentaire. Et ensuite, des raisons constructives d'insatisfaction devront être formulées.

Transférez-nous toute la responsabilité de votre motivation et de votre formation avancée. Nous nous reposons déjà pour vous, même des photos de casques de différentes stations. Laissez-nous également vous proposer une motivation. Il est clair que sur le projet toutes les tâches sont intéressantes et ce n'est que par mal que nous trouvons une routine pour vous. Et nous organisons des rushs exprès, car vous travaillez mieux dans ce mode. Cependant, nous ne vous inscrivons pas non plus à des cours hors de danger. Vous nous transférez tous vos besoins via Bluetooth, qui est intégré dans votre cerveau, nous les recevons, mais les ignorons. Pas besoin de les transformer en mots, on les ressent quand même.

Vers la fin du projet ...

Lorsque nous vous demandons de montrer le projet au client, ne préparez en aucun cas la démonstration à l'avance. C'est clair pour tout le monde: si le projet a commencé sur votre ordinateur portable, cela signifie qu'il fonctionne à 100% et commencera n'importe où. Nous avons tous de la chance!

Si, selon les résultats de la démonstration, le client n'est pas satisfait, vous ressentirez un conflit imminent, vous devez envoyer le client en enfer. Il ne comprend tout simplement rien. Et il n'est pas nécessaire d'en informer le responsable. Soit dit en passant, un conflit avec un client est la meilleure raison de nous demander plus d'argent. Nous serons volontiers d'accord!

La date de sortie est une fiction. Nous adorons simplement marquer ces dates sur le calendrier. En fait, les gestionnaires, surtout à distance, manquent vraiment de communication. Et reporter les dates de sortie est le meilleur moyen de convoquer rapidement 3 à 5 réunions auxquelles les gens ne refuseront pas d'assister.

Lorsque la situation sur le projet se réchauffe, il est temps de dissoudre les rumeurs selon lesquelles tout va bientôt s'effondrer. Consacrez autant de collègues que possible à vos hypothèses, répandez plus de négativité. Si les rumeurs sont justifiées, leur diffusion nous motive à corriger la situation avec la vague d'une baguette magique. Et si cela n'est pas justifié, nous sommes heureux que vous soyez toujours en forme.

Soit dit en passant, si les rumeurs ne vous aident pas, commencez à paniquer en chœur. C'est la solution la plus constructive. À ce stade, vous pouvez commencer à parler de choses désagréables au sujet de l'entreprise, non seulement à l'intérieur, mais aussi à l'extérieur (par exemple, lors d'entrevues). Cela contribuera certainement à égaliser la situation financière et à devenir de solides collègues dans vos collègues!

Vers la fin du projet, vous pouvez le quitter haut et fort, en expliquant la raison du départ comme un salaire trop bas, malgré le fait que vous soyez sur le projet depuis tant d'années et pour nous ne touchez pas aux nouvelles technologies. N'hésitez pas à aller voir les concurrents - ils l'apprécieront. Notre quête préférée est de rechercher de nouveaux spécialistes une semaine avant la sortie. Lorsque vous partez pour une autre entreprise, n'oubliez pas de nous.

Parlez à tout le monde d'un côté du problème. Restez silencieux sur vos «exploits», dites-nous quels managers sont injustes. N'essayez pas de nous comprendre, dites aux étrangers. NDA a trouvé des lâches!

Tous les pièges ne doivent être signalés qu'en dernier recours - si le projet ne peut pas être mis en production. C'est le meilleur team building lorsque l'équipe «éteint le feu» conjointement la nuit avant une sortie importante ou déjà en production. Ne vous privez pas ainsi que l'équipe de ce plaisir!

Si vous avez encore rencontré une sortie dans l'équipe et que quelque chose s'est mal passé, vous pouvez mettre en sécurité des bogues en fin de file d'attente. Ils devraient avoir la même priorité que tout le monde. Laissez-les faire la queue!

Eh bien, et sachez que la nuit suivant la nomination du développeur au poste de station-service, de profondes métamorphoses se produisent avec lui. Il oublie tous les besoins des développeurs, devient myope, autoritaire, stupide et inaccessible. Par conséquent, nous - les gestionnaires, les gestionnaires et les stations-service - vous comprenons si mal, les développeurs.

Auteur de l'article: Eugene Wetsel (imater)

PS Comme la dernière fois , mon histoire n'a que des coïncidences fantomatiques avec la réalité. Et la morale est la suivante: prenons en compte tous ces sarcasmes, construisant des relations dans l'équipe.

PPS Nous publions nos articles sur plusieurs sites Runet. Abonnez-vous à nos pages sur VK, FB, Instagram ou la chaîne Telegram pour en savoir plus sur toutes nos publications et autres actualités Maxilect.