Bonjour, Habr! Comme je l'ai promis dans le post précédent , je continue de vous présenter Delivery Club Tech. Aujourd'hui, nous parlerons de la transformation des produits.
Par coïncidence, mon arrivée à DC en octobre 2018 a été marquée par une restructuration totale de tous les processus de l'équipe. À ce moment-là, le service informatique, et en fait toute l'entreprise, ont été confrontés à de nouveaux défis. Il était clair que les anciens processus ne répondaient pas aux nouvelles exigences. Ils concernaient principalement la baisse du Time to Market.
Il s'agit de ces changements, de nouveaux défis, d'une nouvelle structure d'équipe, de la façon dont nous travaillons sans chefs de projet et analystes techniques, et des approches de développement de produits que je veux vous raconter aujourd'hui.
En octobre 2018, j'ai pris le poste de Head of Consumer. Ce fut le début de mon parcours vers Delivery Club. Il était nécessaire de rassembler les équipes produits au sein de la direction, de décrire les processus, de les formaliser et de les étendre à tous les autres domaines. En outre, la tâche était de dériver des mesures de performance pour les équipes et de développer un cadre de recrutement à partir de zéro.
Caractéristiques de l'équipe
Le défi le plus important était d'assurer la prévisibilité et la transparence du processus de développement. La situation était compliquée par le fait qu'il n'y avait pas de paramètres de performance à ce moment-là. Mais ce qui était certain: les sorties ne se produisaient pas périodiquement, et leur composition n'était claire qu'au moment de la sortie elle-même.
Un autre problème était que les équipes n'étaient pas formées autour du produit. Cette communication compliquée avec l'entreprise, puisque le même développeur pouvait participer à des projets complètement différents, il n'y avait pas de concentration claire sur une tâche spécifique. Par conséquent, dans un premier temps, il a été décidé de reconstruire la structure du service informatique et de passer des équipes plateforme aux équipes produits.
Avec l'approche de plate-forme, les personnes backend étaient assises séparément, les front-enders étaient assis séparément et chaque équipe avait un chef d'équipe qui distribuait les tâches. Les lacunes évidentes de cette structure: les développeurs n'étaient pas immergés dans le processus et le produit, ils n'étaient pas intéressés par l'objectif commun, les équipes avaient une orientation différente, et il n'y avait pas non plus de ressources dédiées au produit. En conséquence, le développeur était défocalisé, les objectifs restaient inaccessibles. Même si par miracle il était possible d'atteindre l'objectif, le manque de communication entre les chefs de produits et les parties prenantes s'est souvent avéré pas ce qui était initialement prévu.
La première chose qui a été décidé de faire: une équipe - un produit. Les ressources sont allouées, c'est-à-dire que l'équipe effectue des tâches uniquement pour ce produit et aucun autre. Les équipes travaillant sur des produits similaires forment la direction du développement. La première transformation s'est traduite par 4 directions:
- Consommateur
- Logistique
- Vendeur
- Interne
La deuxième chose qu'il a été décidé de faire: affecter un chef de produit à chaque équipe. Il fait également partie de l'équipe. Le chef de produit développe une stratégie pour les changements dans le produit, forme des métriques de produit sur lesquelles l'équipe se concentre et définit les objectifs du sprint.
En conséquence, nous avons obtenu la cellule suivante: "Product Manager - Team Lead - Dev - QA". Nous incluons les développeurs backend et front-end en tant que développeurs, mais il y a aussi des équipes sans fronts. Les frontenders sont soit Web Angular et JS, soit iOS / Android.
Désormais, chaque équipe compte en moyenne 5 ± deux personnes. Pourquoi donc? Nous ne sommes pas arrivés à cette formule tout de suite. Nos statistiques montrent que c'est la composition de l'équipe qui vous permet d'obtenir le résultat le plus prévisible. Autrement dit, l'équipe est capable de prendre en charge suffisamment de fonctionnalités pour apporter des changements significatifs au produit, mais en même temps la complexité de la planification reste inférieure à ce qu'elle serait avec plus de personnes. Autrement dit, l'erreur de planification devient minime.
Pendant un certain temps, nous avons expérimenté des rôles au sein de l'équipe, nous avions des chefs d'équipe de développement mobile (iOS / Android) et un chef d'équipe backend. Mais nous nous sommes retrouvés avec une structure matricielle:
- Un chef d'équipe (généralement quelqu'un du backend), il rend directement compte au QA, au backend et au front-end.
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
Une autre caractéristique de la nôtre: nous n'avons pas de chefs de projet et d'analystes techniques. C'était à l'origine le cas dans Delivery Club, et nous avons décidé de ne pas le changer. Vous vous souvenez que nous avons eu un problème avec les équipes se concentrant sur le produit? Alors pourquoi créer des intermédiaires entre l'équipe et le chef de produit? Il est important pour nous que les équipes, avant tout, se soucient de la façon dont leurs fonctionnalités affectent l'utilisateur final, et pas seulement de fermer les tickets dans Jira. Pour ce faire, les utilisateurs doivent se plonger dans le contexte, le domaine, les activités et même les indicateurs de produit et les indicateurs financiers.
En conséquence, le dialogue entre l'équipe de développement et le chef de produit se poursuit. Les développeurs non seulement prennent une liste de tâches du chef de produit et partent développer tout cela, mais ils peuvent venir le voir dans quelques heures et dire, par exemple, "Hé, nous pouvons rendre le bouton ici un peu plus simple, mais une semaine plus vite", montrez-le sur les chiffres, et le chef de produit dira OK.
Ainsi, l'équipe technique effectue la tâche d'analyse technique, d'évaluation et de décomposition de manière indépendante, puis planifie un sprint avec le chef de produit. Pour que cela fonctionne, nous commençons le sprint, pour ainsi dire, une semaine avant le début. Ceci est la section suivante.
Développement et planification de sprint
Pré-planification
Une semaine avant le début du sprint, le chef de produit apporte les cas et le design, répond à la question "Que faut-il faire?" L'équipe technique décide comment elle le fera et quand tout sera prêt.
Pour ce faire, l'équipe dispose d'une semaine au cours de laquelle le chef d'équipe, les développeurs et le contrôle qualité se réunissent, discutent des détails techniques, effectuent la décomposition et se réinitialisent en planifiant le poker pour l'évaluation. Pendant cette période, QA établit une liste de cas de test, qui seront ensuite testés.
Planification
Une fois que l'équipe a effectué la décomposition et l'évaluation, la planification commence. Toutes les tâches sont divisées en 8 heures. Pour compter le nombre de tâches dans un sprint, nous multiplions le nombre d'employés par 80 heures d'une itération de deux semaines, et le résultat est multiplié par un facteur de concentration de 0,8.
D'autres tâches sont battues dans des seaux, il n'y en a que trois:
- Produit 60%
- Dette technologique 20%
- Soutenir 20%.
Laisse moi te donner un exemple. Nous avons une équipe de 3 backenders. C'est 80 * 3 * 0,8 = 192 heures utiles. Nous consacrerons 116 heures (60%) au développement de produits, 38 heures à la dette technique (20%) et 38 heures au support (20%).
Toilettage
Le lundi, nous planifions des tâches, et au milieu du sprint, c'est-à-dire une semaine plus tard, le toilettage a lieu. Le toilettage consiste à analyser les résultats de la première semaine et à décider si nous avons le temps d'atteindre l'objectif de sprint ou si quelque chose doit être coupé. Si l'objectif est atteint, le chef de produit présente les plans pour le prochain sprint lors de la même réunion, et tout le cycle se répète.
Démo
La conclusion logique du sprint est la démo, où nous invitons toutes les équipes de développement, les parties prenantes, les collègues de travail et même le responsable du Delivery Club.
Les collègues responsables de la sortie préparent des présentations, parlent des réalisations du sprint et des difficultés qui ont été surmontées. Nous partageons une histoire de produit et des idées sur la façon dont les nouvelles fonctionnalités profiteront à l'utilisateur.
C'est un jour important pour toute l'équipe!
Rétro
Pour nous, le rétro est un moyen d'améliorer l'efficacité. Tout d'abord, nous examinons les mesures de la performance de l'équipe, le succès avec lequel nous avons clôturé le sprint. Nous vérifions le rapport entre les tâches à l'état terminé et celles qui ont été effectuées au début de l'itération et enregistrons ces données par bucket.
Par exemple, dans Product, nous avons pris 20 problèmes et terminé 17. Par conséquent, le taux de réussite pour ce compartiment est de 85%. Un bon progrès dans le développement de produits pour nous est un indicateur de 90% ou plus. S'il est inférieur, nous analysons chez Retro comment cette métrique peut être améliorée.
Travail de sprint
On nous pose souvent des questions sur la révision du code et le fonctionnement des tests. Tout est assez standard ici.
La journée commence par un stand-up. Pendant 15 minutes, l'équipe discute de ce qu'elle a fait hier et de ce qu'elle fera aujourd'hui.
Nous utilisons Jira Flow et Git Flow pour travailler sur des tâches, nous avons une pile Atlassian. Il existe également un tableau Scrum avec des colonnes à faire - en cours - prêt pour la révision du code - prêt pour le contrôle qualité - prêt pour la vie - terminé.
Lorsque le développeur a préparé le code, il crée une branche avec le numéro de problème actuel dans Jira - il s'agit d'une branche de fonctionnalité. Il l'envoie également à une pull request dans Bitbucket. Le développeur a besoin d'au moins deux approbations. Nous avons également une intégration avec Jenkins, si la construction est verte, vous pouvez fusionner. Le responsable technique et le chef d'équipe ont le droit de fusionner. Parfois, vous devez préparer un test unitaire pour une demande d'extraction. Et parfois, nous ne les écrivons pas délibérément si nous savons qu'il s'agit de domaines d'activité non critiques, d'un domaine non critique ou d'une fonctionnalité expérimentale, et nous pouvons alors les supprimer.
Quand tout va bien, nous l'envoyons pour test. Un ingénieur de test écrit des tests automatiques ou exécute manuellement des cas de test. Cela dépend à nouveau de la gravité du domaine. Et puis déployez.
On peut dire que ce processus fonctionne comme une horloge. Mais en fait, en ce moment, il y a une communication constante au sein des équipes. L'objectif principal est l'objectif du sprint et la sortie à temps. Pour atteindre cet objectif, nous pouvons soit discuter des changements de produits, soit réviser la mise en œuvre technique. Tout cela se produit lorsque vous travaillez sur des tâches - il s'agit toujours d'un dialogue entre les développeurs, le chef d'équipe, le chef de produit et le contrôle qualité.
Orientations de développement et structure du service informatique
Dans le processus de transformation, nous sommes arrivés à une nouvelle structure des directions de développement. Comme vous vous en souvenez, au tout début, nous en avons écrit environ quatre. En outre, il est devenu clair que pour une mise en œuvre de haute qualité et en temps opportun des objectifs, deux autres domaines doivent être identifiés. Ainsi, il y en a maintenant 6:
- Le consommateur est tout au sujet des produits personnalisés: site Web et applications mobiles.
- Logistique - sur les logisticiens, les courriers et la livraison.
- Vendeur - sur l'intégration avec nos partenaires (restaurants / magasins).
- Interne - centre d'appels et support.
- R&D - résoudre des tâches à forte intensité scientifique.
- Plate-forme - améliorer l'architecture et la plate-forme dans leur ensemble.
Chaque direction a sa propre gamme de tâches et ses propres difficultés.
Consommateur
La priorité de cette direction est le bonheur de l'utilisateur. Les principales métriques produit sont ici: rétention, taux de conversion des commandes, NPS consommateur. D'un point de vue technique, il est important pour nous que toutes les données soient envoyées rapidement. Dans cette direction, peut-être, la plus grosse charge, car nous travaillons directement avec l'utilisateur final. Et il y a aussi un grand nombre de microservices, il y en a la plupart ici.
Les principaux produits sont un site Web, y compris une version mobile, ainsi que des applications pour iOS et Android. Les deux flux principaux sont la livraison d'épicerie et la livraison au restaurant. Pile technologique plus ou moins comme partout ailleurs: PHP, Go, Postgres, Redis et Memcache pour le cache, Kafka pour la communication asynchrone.
Logistique
La tâche de cette direction est d'assurer une livraison rapide d'une commande à un utilisateur affamé. De plus, nous développons une interface pour les répartiteurs qui, si nécessaire, aident les coursiers avec le contrôle manuel.
L'un des principaux défis de la logistique se pose lorsque le nombre de commandes augmente et, avec lui, la charge sur le système. Pour faire face aux charges, vous devez apporter des modifications de qualité à l'architecture. En outre, la livraison de nourriture est très différente de la livraison, par exemple, de fournitures de bureau, de vêtements, de livres, etc. Tout y est un peu plus simple: nous avons fait une feuille de route, l'avons planifiée et sommes allés.
Avec la livraison de nourriture, un tel numéro ne fonctionnera pas. Nous sommes tous à la demande, la situation change toutes les 5 à 15 minutes. Lorsqu'il commence à pleuvoir ou qu'il neige, la demande augmente toujours. Et quand il fait beau dehors et que vous ne voulez pas rester à la maison, la demande diminue. Les jours fériés et les week-ends, le profil de la demande diffère des jours de semaine. La situation du trafic et la congestion font également leurs propres ajustements, en particulier dans les zones où prédominent les coursiers auto / moto. Les heures du matin, de l'après-midi et du soir ont des profils de demande différents.
Cette migration de la demande est suivie par nos moniteurs. Si la demande a diminué, nous modifions les résultats de recherche, diffusons des offres plus pertinentes dans la section "Promotions". Pour améliorer la pertinence, nous incluons des modèles ML qui rendent le tri personnalisé à la fois pour l'utilisateur et pour la zone logistique dans laquelle nous observons un changement.
L'une des principales applications sur lesquelles travaille la logistique est l'application Rider. Il s'agit d'une application Android dans laquelle les coursiers voient où récupérer une commande et où elle doit être livrée.
Vendeur
Cet espace travaille avec nos partenaires internes: restaurants et magasins. Ou plutôt, avec leurs managers, qui gèrent le menu via leur compte personnel et réagissent aux statistiques dans les résultats de recherche.
Grâce aux données collectées et aux statistiques sur les commandes, nous avons une bonne compréhension du public cible et des caractéristiques des restaurants. Nous travaillons avec eux en partenariat et leur fournissons un outil qui les aide à mieux comprendre qui sont leurs clients et à activer les mécanismes de marketing. Nous aidons également les restaurants à développer des modèles d'optimisation des prix, à comprendre quels plats sont les meilleurs à afficher à quel moment et dans quel ordre.
Un autre produit qui est en cours d'élaboration dans la direction du fournisseur est un tableau de bord, dans lequel les commandes pour la cuisine tombent. La cuisine accepte la commande, voit sa composition, détermine comment la préparer et, en fait, la prépare. Lorsque la commande est préparée, la cuisine le confirme dans l'application et transfère la commande au coursier. Et puis le courrier fonctionne avec l'application Rider.
Interne
Cette zone est responsable des outils de notre centre d'appels, qui fournit une assistance aux utilisateurs. En fait, c'est le "panneau d'administration" pour tout ce qui concerne les commandes. L'opérateur peut aider le client, lui donner des informations complémentaires sur l'état actuel de la commande, effectuer des ajustements sur la commande avant qu'elle ne soit transférée au restaurant.
L'enjeu de cette direction est de faire un tel système, qui, d'une part, serait pratique et couvrirait tous les besoins de l'opérateur, et, d'autre part, rapide, car le client a besoin d'être aidé le plus rapidement possible. En plus de la tâche clé, les gars de l'Internal travaillent pour réduire le temps qu'un opérateur peut gérer un problème et réduire le nombre d'appels.
R&D
Lorsque vous avez besoin de modifier un processus métier et en même temps de comprendre comment ces changements affecteront l'ensemble de la plate-forme, la recherche et le développement sont impliqués. Les gars mènent des expériences, construisent des modèles, comptent et pèsent. Ils interagissent également plus étroitement avec le département BI, où ils travaillent avec le Big Data, les modèles ML, conçoivent des réseaux neuronaux et prévoient la demande. Dans ce contexte, la BI aide la R&D avec des recherches et des outils.
La recherche consiste principalement à travailler avec des données. Par exemple, comment le système se comportera si vous modifiez un facteur. La plupart des tâches de R&D proviennent désormais de la logistique, ce domaine présentant le niveau d'incertitude le plus élevé.
Plate-forme
C'est une direction technique. Tout d'abord, les gars se concentrent sur l'amélioration du cœur du système, la refactorisation du traitement des commandes et la décomposition de notre monolithe. Il ne s'agit pas d'un développement de produit au sens classique du terme, mais toutes les améliorations visent d'une manière ou d'une autre à rendre plus pratique et plus facile pour les utilisateurs d'interagir avec l'application Delivery Club: réduire le temps de réponse pour que les pages s'ouvrent plus rapidement, augmenter la capacité de la plateforme afin que plus d'utilisateurs puissent faire commande et en même temps l'expérience d'utilisation était pour eux aussi agréable que possible.
Résultats de la transformation et nouveaux défis
Notre tâche était de construire un processus de développement qui répondrait à toutes les exigences d'une entreprise en croissance: les équipes sont impliquées dans l'entreprise, communiquent beaucoup entre elles, sont responsables des délais qu'elles fixent elles-mêmes et comprennent comment leur travail affecte l'utilisateur final. Le processus doit être transparent, mesurable et, surtout, évolutif.
Après avoir effectué une transformation de produit et optimisé le processus de développement, nous sommes arrivés à la conclusion que chacune de nos versions devenait prévisible. Au début, nous savions avec une précision de 80% quand et dans quelle composition les sorties seraient publiées. Désormais, l'indicateur de performance moyen de toutes les équipes du département est passé à 90%. L'implication des équipes, c'est-à-dire la motivation des gars, a beaucoup augmenté, ils comprennent ce qu'ils font et pourquoi, pour qui c'est important.
Le processus comprend la capacité de répondre aux tâches dès que possible sans nuire au développement du produit, il y a suffisamment de points de communication pour estimer de manière flexible les coûts de main-d'œuvre et répondre en temps opportun aux changements d'exigences du chef de produit. En pratique, nous nous sommes assurés que le processus soit évolutif: nous avons réussi à passer de 40 personnes à 170 personnes avec le même processus de développement et sans perte de performance.
Dans le même temps, nous ne nous arrêtons pas et pensons que la transformation du produit est toujours en cours. Fin 2019, nous avons commencé à réfléchir à la manière dont les équipes pourraient influencer encore plus les affaires. Les équipes ont une grande expertise produit, il semble que vous pouvez l'utiliser, créer une sorte de symbiose entre Technologie et Business. De plus, nous devions trouver un mécanisme de vérification des hypothèses de produits. Autrement dit, pour contrôler la valeur des tâches qui entrent dans notre développement. Pour ce faire, nous avons décrit le processus GIST - un cadre de vérification des hypothèses de produit, dont nous discuterons dans l'un des articles suivants.
Merci d'avoir lu!