Il semble à beaucoup que Yandex est une grande société monolithique avec des processus strictement réglementés, mais ce n'est pas le cas. Nous recherchons constamment de nouvelles directions, démarrons de nouveaux projets et essayons de nouveaux marchés. Le service de consultations en ligne avec le médecin Yandex.Health est l'une des startups internes classiques.
Je suis venu diriger le développement de la santé à une époque où le service n'était encore qu'une page avec un brief sur le wiki interne. Dans cet article, je veux partager les approches de développement que nous avons développées au cours de deux ans et demi de travail sur le service.
Avertissement:Une startup a ses propres caractéristiques. Notre tâche principale est de faire le nombre maximum d'expériences par unité de temps et de publier les caractéristiques du produit à la vitesse la plus élevée possible. Dans le même temps, nous devons maintenir la qualité du produit à un niveau tel qu'il ne soit pas dommage.
[Un endroit pour une flamme sur le manque de conscience de certains] . Je note qu'une vitesse de livraison élevée des fonctionnalités implique, entre autres, le maintien d'un code de qualité assez élevée. Sinon, le produit s'étouffe tôt ou tard dans les bugs.
Tous les points ci-dessous sont d'une manière ou d'une autre subis, presque chacun a un cas de la vie réelle.
Qualité et architecture du code
- Nous minimisons le temps nécessaire pour apporter des fonctionnalités à la production tout en maintenant une qualité acceptable.
- Toute tâche implique deux solutions: rapide et correcte. Pour n'importe quelle fonctionnalité, nous réfléchissons aux deux options afin qu'il soit possible de mettre à niveau la solution rapide vers la bonne, en minimisant le travail inutile d '«éjection». Après avoir déployé une solution rapide, nous attendons un moment et comprenons si la bonne est nécessaire.
- De façon critique. Souvent, la différence de temps entre «résoudre le premier moyen que vous obtenez en marquant une béquille» et «résoudre magnifiquement et avec précision» est de dix minutes. Par conséquent, nous réfléchissons toujours avant d'écrire.
- S'il y a un choix entre une optimisation mineure et une lisibilité / architecture - choisissez la seconde. Deux millisecondes ne résoudront rien, et avec ce code, nous devons encore vivre et maintenir.
- Nous pensons à l'avenir. L'avenir proche est plus important que les perspectives lointaines. Si la décision peut être rendue difficile (lire «longue») et flexible, ou simple, mais clouée, cela vaut la peine d'être cloué puis refactorisé si nécessaire. Il vaut mieux passer une journée sur une solution simple maintenant et un mois sur un éventuel refactoring dans un an, que deux semaines maintenant (oui, c'est ce qu'on appelle la dette technique). Il est important que ces décisions méritent d'être discutées avec l'équipe. Seul, vous ne pouvez pas évaluer correctement la probabilité d'extension de cette fonctionnalité dans un proche avenir.
Nouvelle technologie
Les nouvelles technologies sont cool, utilisons-les. Mais notre produit n'est pas un terrain d'essai. Si vous souhaitez appliquer un nouvel algorithme ou une nouvelle technologie, cela peut être fait dans les conditions suivantes:
- la technologie apporte un profit tangible (optimisation, qualité de l'architecture, code, évolutivité, et tout cela devrait vraiment être nécessaire, et pas exagéré);
la technologie s'intègre normalement dans la pile actuelle (vous n'avez pas besoin d'écrire une partie des services dans Go si tout le code est écrit en Python); - la technologie ne dégrade pas la qualité de l'architecture et la lisibilité du code (c'est subjectif, donc c'est discuté avec l'équipe);
- Il ne faut pas plus de temps pour mettre en œuvre et prendre en charge une nouvelle technologie (y compris la recherche de nouveaux développeurs) que de travailler dans le cadre de la technologie actuelle. Encore une fois, tout dépend du bénéfice attendu et est discuté avec l'équipe;
- toute nouvelle technologie est discutée avec l'équipe: si c'est cool, alors il est juste pour tout le monde de l'utiliser, sinon vraiment, alors une discussion de groupe vous permet de comprendre rapidement cela;
vous n'avez pas besoin d'implémenter indépendamment les algorithmes déjà implémentés dans des bibliothèques prêtes à l'emploi (sauf dans le cas où il s'agit d'un petit morceau d'un cadre énorme et cela n'a aucun sens de le faire glisser pour une seule solution). - si vous avez fait quelque chose de cool et de pratique, partagez la solution avec l'équipe (ou mieux, à l'intérieur de Yandex).
La communication
- Nous discutons ensemble de la solution. Plus la fonctionnalité est complexe et critique, plus cette discussion est importante. Si quelqu'un n'aime pas la solution, nous nous convainquons jusqu'à ce qu'un accord soit trouvé. Ou le temps de discussion ne dépassera pas un temps raisonnable.
- S'il n'a pas été possible de se mettre d'accord, le dernier mot revient à la tête. Nous avons une démocratie raisonnable, pas le Sejm polonais du 17ème siècle . Dans le même temps, le leader reçoit un gros moins dans le karma et doit subir des souffrances morales. Et certainement pas pour utiliser ce droit souvent.
- Une fois que nous avons décidé, nous faisons comme convenu. Même si je suis fortement en désaccord. Aucun "Je sais mieux que tous ces experts en produits comment rendre un service, donc je ferai ce que je pense nécessaire"
- "Pas dans la prod - pas fait." Chacun suit ses propres tâches. Si la fonctionnalité est prête pour les tests, vous devez vous assurer qu'elle se déploie dans les tests. Si elle est prête à être libérée, vous devez vous assurer qu'elle pénètre dans le produit dès que possible. Les personnes responsables de la formation de la version ne se souviennent pas toujours de chaque fonctionnalité. N'hésitez pas à vous souvenir d'elle. [Un lieu pour une flamme sur la répartition des responsabilités entre les rôles dans une équipe.] .
- Il est nécessaire d'allumer la tête. Si la tâche vous semble étrange, incompréhensible ou trop longue, alors cela doit être clairement et clairement annoncé au responsable. Et faites-le jusqu'à ce que vous compreniez clairement pourquoi tout devrait être ainsi. Il arrive que les bonnes questions posées au bon moment économisent des semaines de développement.
Gestion du temps
- Si la tâche ne rentre pas dans un délai raisonnable, il faut en parler fort. Vous ne devez pas vous asseoir et couper la tâche pendant plusieurs mois avec une évaluation de trois jours. S'il traîne lourdement, alors quelque chose ne va pas. Il y a peut-être un malentendu dans la production ou nous avons sous-estimé la quantité de travail. Dans tous les cas, ces tâches doivent être réexaminées (et, par conséquent, parfois différées ou même enterrées).
- Les problèmes qui se posent doivent être résolus indépendamment. Mais s'il est clair que le processus est retardé, assurez-vous d'en parler et de demander l'aide de vos collègues. Rester plusieurs jours dans l'état "Je dois tout faire moi-même et ne pas distraire mes camarades" est très mauvais.
- Personne ne regarde à quelle heure chacun de nous vient et part jusqu'à ce que nous réussissions, et notre régime ne commence pas à interférer avec le travail de l'équipe. Mais s'asseoir la nuit uniquement parce que vous n'avez pas le temps de faire quelque chose n'est pas nécessaire. Si cela devient une habitude, le problème est plus profond - dans la planification, la réévaluation de ses propres capacités, etc. Alors que le développeur fait des heures supplémentaires la nuit (et que tout est à l'heure), les chances que quelqu'un voie et résolve ce problème sont considérablement réduites.
- Il arrive que nous devions lancer une fonctionnalité importante avant la date convenue (ou le plus tôt possible). Dans ce cas, nous allons travailler en heures supplémentaires. De plus, le leader reçoit un gros moins dans le karma et doit subir une souffrance morale. Et certainement pas pour profiter de cette opportunité souvent. Ces heures supplémentaires sont compensées. [Un endroit pour une flamme sur les heures supplémentaires et la rémunération] .
Péchés capitaux
Ceci est une section distincte. Ici, j'ai essayé d'énumérer ce que je pense être mal et nuisible lorsque je travaille en équipe. Chacun des articles a son propre poids. Certains parlent de très gros problèmes, d'autres ne sont pas aussi critiques. Alors, ce qu'il faut éviter par tous les moyens:
- Travail, sans compter la tête: "On m'a dit de faire - je l'ai fait." Chaque membre de l'équipe doit comprendre l'essence de la fonction qu'il crée et son impact sur le produit.
- Lancer des fonctionnalités non dégonflées dans la prod avec les mots "J'ai tout fait". Ce que nous faisons doit fonctionner en production. Bien que la fonctionnalité ne soit pas en production, elle n'est pas prête.
- Acceptez de le faire d'une manière, puis faites-le tranquillement à votre façon. Ci-dessus était déjà sur "Je sais mieux que quiconque ce qui est mieux." Mais rappeler encore une fois que c'est mauvais ne fera pas de mal.
- Resserrer les fonctionnalités importantes, en creusant dans la discussion des problèmes rares et irréalistes, mais potentiellement possibles. Si, dans un délai raisonnable, vous ne savez pas comment contourner un problème mineur et rarement reproductible , nous convenons simplement de la façon de vivre avec.
- N'exprimez pas les problèmes à temps, en essayant de tout résoudre vous-même (généralement la nuit). Un tel héroïsme ne mène qu'à l'échec des termes, à la fatigue et à un sentiment de sous-estimation: «Je fais des exploits ici, mais on me critique aussi pour le lent travail!»
- Il est douloureux de réagir aux critiques du code et de clarifier la relation. Même si un collègue dit que le code est coprolit comme ça ("réécrivons tout!"), Traitez cela avec compréhension et discutez pourquoi il pense ainsi. Pour vous personnellement, cela n'est pas moins utile que pour le service dans son ensemble.
- Allez à la personne. Critiquant un code ou une solution, nous ne critiquons que le code ou la solution, mais en aucun cas la personne qui l'a écrit ou suggéré. Compte tenu du paragraphe précédent, n'ayez pas peur de critiquer. Mieux vaut un délai raisonnable pour discuter avec des collègues que d'envoyer une décision infructueuse à prod.
Total
Ici, vous pouvez en écrire plus sur un million de choses. Mais plus le message est court, plus il est facile de le lire
jusqu'au bout , et je l'espère vraiment. Et oui, je ne prends pas la critique douloureusement (à condition que vous ne deveniez pas personnel;). Alors discutons!