Je m'appelle Alexandra Kamzeeva, je travaille en tant qu'analyste système depuis 9 ans, dont 3,5 ans chez Lamoda. Je lis beaucoup, j'analyse la documentation actuelle et j'en crée une nouvelle. Dans mon travail, je structure toujours l'information et la rend aussi pratique que possible.
Les avantages d'une bonne description de système sont:
- vous aide à trouver les informations dont vous avez besoin plus rapidement et plus facilement que dans une description non structurée;
- réduit le risque d'échec du projet;
- facilite l'intégration des employés.
Nous avons créé un modèle pour une telle description que toute équipe peut utiliser. Dans cet article, je vais vous raconter avec des exemples ce qui nous a poussé à créer un modèle de description de système, l'historique de sa création et comment il est utilisé maintenant dans Lamoda.
Qu'est-ce qu'un modèle et pourquoi est-il nécessaire
Tout d'abord, je vais décrire ma compréhension du modèle. Imaginons que j'ai besoin de trouver une petite voiture dans une pièce en désordre. Ce n'est pas un fait que je puisse le gérer. Mais je peux accidentellement marcher sur la partie Lego.
Imaginons maintenant que tous les jouets soient mis à leur place et triés. Je peux voir à l'avance dans quelle boîte se trouvent toutes les voitures, je trouverai celle dont j'ai besoin plus rapidement, plus facilement et je ne gaspillerai pas mes nerfs dessus.
De même avec la documentation. Un modèle est un tel ordre. Nous avons créé un cadre pour décrire un système que toute équipe peut utiliser.
Dans quelles conditions travaillons-nous avec la documentation
Lamoda dispose de plus de 100 systèmes qui automatisent la livraison des commandes, le centre de contact, l'entrepôt, le studio photo et d'autres processus opérationnels et commerciaux. Plus de 300 ingénieurs sont impliqués dans le développement et le support. Chacun d'entre eux peut avoir besoin d'une description de l'un de ces 100 systèmes.
Chaque équipe décrit indépendamment son système dans un espace séparé dans Confluence. Le responsable technique est obligatoirement impliqué dans la documentation, car il est obligé d'enregistrer les informations. En outre, le système est décrit par des testeurs et des développeurs actifs qui se sentent désolés de simplement perdre leurs connaissances. Et, bien sûr, les analystes, puisque la documentation est l'un de nos principaux outils.
Il peut sembler que cette liberté mène au chaos. Mais ce n'est pas le cas, car nous avons une culture d'entreprise: une attitude responsable envers la documentation, un partage ouvert des connaissances, l'habitude d'enregistrer les artefacts de projet et de système. Cette tradition s'est développée en partie grâce à des projets infructueux. Les incidents ont prouvé aux équipes de développement à quel point il est important de documenter les processus et les fonctionnalités du système.
Ci-dessous, je soulignerai quelques cas où une documentation confuse ou l'absence de documentation a entraîné des problèmes.
Il suffit d'ajouter deux boutons
Le premier problème qui nous a incité à créer un modèle - nous n'avions pas de description de certains systèmes, ce qui a entraîné des échecs et des améliorations.
Nous avions un projet de Self Order Management (SOM). Nous avons décidé d'ajouter deux boutons au compte personnel du client: "Transfert date de livraison" et "Annuler la commande". Avant cela, un client ne pouvait annuler ou reporter une commande qu'en appelant le centre de contact. Il est clair que certains acheteurs n'ont pas eu le temps ni le désir de communiquer avec l'opérateur. En conséquence, le représentant commercial pourrait apporter une commande inutile ou ne pas trouver le client chez lui. Dans de tels cas, Lamoda supporte les frais. Le projet était nécessaire et important.
Il semblerait ajouter deux boutons! En fait, il y avait beaucoup de logique derrière eux dans les quatre systèmes. La modification de l'ordre passe par le système de traitement - un énorme monolithe où vous pouvez toucher quelque chose à un endroit et tirer dans un autre. Malheureusement, les subtilités de son travail n'ont pas été décrites dans la documentation, ils n'y ont pas prêté attention lors de la conception du projet. Après la publication, les boutons ne fonctionnaient pas comme prévu et il a été annulé. En conséquence, au lieu de deux mois-homme, ce projet a duré six mois.
Bien sûr, nous avons obtenu ce résultat non seulement en raison du manque de documentation. Mais si nous avions une description claire des processus d'annulation et de transfert d'une commande, le résultat serait peut-être différent.
Onboarding complexe
Le deuxième problème qui nous a conduit à créer un modèle est la complexité de l'intégration. Je suis venu travailler pour l'équipe du système de traitement des commandes. Pour l'immersion, j'ai lu la documentation dans l'espace système et dans trois sections j'ai trouvé trois descriptions différentes de l'essence principale de notre système - l'état de la commande.
Dans ce cas, cela n'a pas fonctionné pour faciliter l'intégration. Une telle documentation n'a pas aidé à transférer des connaissances à des collègues qui n'avaient jamais rencontré notre système auparavant.
Problème d'ardoise vierge
La troisième condition préalable à la création de modèles est le problème de l'ardoise vierge. Pour chaque nouveau système, le responsable technique doit créer l'espace approprié à partir de zéro. Le responsable technique réfléchit aux sections à créer. Avant de créer le modèle, l'employé a étudié d'autres espaces et regardé quelles sections sont utilisées et seront utiles pour son système. Cela prenait du temps.
Comment nous avons créé le modèle et ce qui s'est passé
Chaque semaine, les analystes système tiennent un stand-up et discutent des problèmes rencontrés sur les projets et pas seulement. Et plus d'une fois, des collègues se sont plaints de la difficulté à trouver des informations et à comprendre les espaces des différents systèmes. Comme nous brûlions constamment à cause de cela, nous avons décidé de prendre en main la description des systèmes auxquels nous sommes attachés. Et puis, ce qu'il faut faire sera clair.
Tout d'abord, nous avons identifié les attributs d'un bon modèle:
- .
- . , , . , . .
- . , , , .
- .
Ensuite, nous avons analysé la description actuelle des différents systèmes et identifié des sections communes:
Dans la section des projets et des fonctionnalités, il y avait des spécifications pour le développement de projets. Les sections Développement et QA contenaient des informations spécifiques pour le développement et les testeurs. Dans la section des incidents, les incidents survenus dans le système et leurs solutions ont été décrits.
Nous avons partagé l'idée d'un modèle avec d'autres collègues lors de réunions informelles (déjeuners en cuisine, stand-ups, équipes voisines avec lesquelles vous discutez périodiquement) et avons créé un groupe de travail de bénévoles. Il s'agissait de représentants de compétences différentes: deux managers, trois responsables techniques et deux testeurs. Ils ont ajouté les sections suivantes au modèle:
Ensuite, nous avons testé le modèle de description du système avec des collègues aux compétences étendues: chefs de service informatique, responsables techniques expérimentés et chefs de test de grands projets d'intégration. Ils ont fini par ajouter des sections plus utiles:
Vérification de la qualité du modèle
Nous avons vérifié le document résultant par rapport à notre définition d'un bon modèle dans Lamoda:
- Il vous aide à trouver les informations dont vous avez besoin plus rapidement et plus facilement. Nous avons une structure pratique: je me déplace le long de l'arbre et je comprends ce qui se trouve et où. Si vous avez besoin d'informations sur les processus du système (par exemple, l'annulation d'une commande), alors je vais à «Description des principaux processus».
- Les informations système ne sont pas dupliquées en raison de l'atomicité des partitions. Par exemple, vous pouvez décrire les imprimables dans une section, puis créer un lien vers celle-ci à partir de la section «Description des processus principaux» afin que les informations ne se répètent pas.
- . Lamoda, . , -. — .
- . .
Nous avons créé un joli modèle pour décrire les systèmes Lamoda. J'espère que d'autres entreprises le trouveront également utile. Je tiens particulièrement à souligner les trois sections suivantes:
Description des principaux processus du système . Oui, il semble évident que cette section est nécessaire. Mais pour une raison quelconque, il n'existe pas toujours, comme ce fut le cas avec nous avec les boutons pour annuler et transférer une commande. Si nous avions décrit les processus d'annulation et de replanification à l'avance, le risque d'échec du projet serait réduit.
Listes de contrôle- une section qui rappelle les plus importants dans le processus régulier. Par exemple, nous avons une «Liste de contrôle pour connecter un nouveau moyen de paiement» dans la description du système de gestion des modes de paiement. Il dit que nous devons coordonner l'ajout ou le changement d'un mode de paiement avec le service comptable, avec le centre de contact, avec la livraison et avec d'autres unités d'affaires.
Une fois que nous avons oublié d'informer le centre de contact du changement de mode de paiement. Et lorsque le client a appelé notre centre de contact et l'a demandé, l'opérateur n'a rien pu dire. Cela a conduit à un conflit entre le centre de contact et l'équipe de développement responsable des méthodes de paiement. Après cet incident, nous créons des listes de contrôle pour les lancements de projets clés, la connexion de nouveaux partenaires, etc.
Page d'accueil de l'espace- une section contenant des informations sur les raisons pour lesquelles ce système est nécessaire, sur la composition de l'équipe et la partie prenante. Nous devons coordonner les changements de système et les ressources de développement avec les parties prenantes. C'est donc génial de pouvoir obtenir ces informations simplement en regardant Confluence.
Là, nous indiquons des informations sur la composition de l'équipe afin de comprendre qui contacter en cas de questions sur le système. Il aide également les débutants avec une tête enflée. C'est formidable quand un nouvel employé peut espionner à qui il vient de parler, qui est cette personne, quel est son rôle et quel est son nom.
Comment j'ai commencé à utiliser le modèle sur mon système
- Tout d'abord, j'ai créé les sections requises du modèle sans les remplir. C'était facile et ne prenait pas plus de 30 minutes.
- Ensuite, le plus difficile a été: nous avons organisé des réunions régulières avec le responsable technique, au cours desquelles nous avons commencé à analyser la documentation de notre système. Lors de la première réunion, nous avons divisé les pages actuelles en trois piles.
Nous avons envoyé tout ce qui n'est pas pertinent et inutile à la première pile. Nous avons supprimé ces pages ou les avons envoyées aux archives.
La deuxième pile est nécessaire, mais non pertinente. Nous avons marqué les pages comme non pertinentes, créé une tâche dans Jira, puis mis à jour ces informations conformément à notre backlog.
La troisième pile est la plus simple. Lorsque tout est clair, les sections sont pertinentes - nous les avons simplement déplacées au bon endroit.
Avant ces réunions, des descriptions de processus et d'architecture, des notes de testeurs et de développeurs, et des incidents étaient dispersés dans tout l'espace. Il n'y avait pas non plus de page d'accueil.
Pour 6 heures de réunions, nous avons obtenu un excellent résultat. Du chaos, nous avons formé la structure et l'ordre. Vous pouvez désormais comprendre où trouver la description des processus, les informations sur l'architecture et les incidents. Et surtout, nous avons maintenant une page d'accueil. Ici, il a été écrit pourquoi un système de traitement des commandes est nécessaire et qui est sa partie prenante.
Notre vaste système est impliqué dans presque tous les secteurs d'activité. Mais nous n'avions pas notre propre partie prenante auparavant. Pendant que nous faisions la page d'accueil, nous avons discuté avec le CTO avec qui coordonner les changements de système. Ainsi, un collègue a été déterminé, qui a priorisé les améliorations. Maintenant, il semble amusant que la création de la page d'accueil ait conduit à l'émergence d'une partie prenante.
Comment nous avons distribué le modèle
Des résultats similaires sur l'utilisation du modèle ont été reçus par d'autres analystes qui l'ont mis en œuvre dans leurs propres directions. Ainsi, nous avons couvert la plupart des systèmes qui ont été activement impliqués dans de nombreux projets d'intégration.
Nous avions des équipes dont les systèmes étaient souvent impliqués dans des projets d'intégration, mais il n'y avait pas assez de description à leur sujet. Il y avait généralement un besoin de documentation, il n'était donc pas nécessaire de vendre l'idée.
Nous avons démontré une expérience réussie dans l'application de modèles aux responsables techniques et aux responsables de ces équipes. Certaines équipes, sur la base de notre exemple, ont rangé elles-mêmes leur documentation, d'autres ont demandé de l'aide aux analystes.
Commentaires sur le modèle
Notre modèle n'est pas une description de système obligatoire ou obligatoire. Les collègues prennent le modèle comme base, s'ils en ont besoin, et le modifient en fonction de leurs besoins. Par exemple, ils transfèrent les échanges d'une sous-section à l'autre si le système se compose principalement d'eux.
Tous nos systèmes sont différents dans leur description, mais la structure générale et la logique générale sont toujours préservées. Désormais, nous pouvons trouver plus facilement des informations sur les processus qui composent le système, sur l'architecture du système, etc.
Chez Lamoda, nous aimons partager nos connaissances. Nous avons de grands projets d'intégration qui motivent cela. Nous envoyons des liens vers des descriptions à jour des systèmes, et les collègues reçoivent les informations nécessaires sans questions supplémentaires aux responsables techniques déjà chargés.
2 ans après la création du modèle, j'ai interviewé des collègues et reçu de bons retours de la majorité. Ils utilisent le modèle, éditant la structure à leur guise.
Mais il y a aussi des gens qui pensent que nous n'avons pas besoin de documentation et de modèle. Au fond, c'est le raisonnement des équipes de ces systèmes dans lesquels il n'y a plus besoin urgent de documenter quelque chose.
Ils travaillent sur des systèmes qui ne changent guère: il n'y a pas de projets d'intégration, il n'y a pas besoin de parler à d'autres collègues de ces systèmes, et par conséquent, il n'y a aucune volonté de documenter.
Je pense qu'avant de démarrer un grand projet, notre culture et les gros bosses vous rappelleront de documenter les principaux processus, et ils changeront d'avis.
Conseils à vous-même et à ceux qui veulent répéter notre chemin
- , , , , . , .
- . , . , .
- , , . : , , . . , .