Les architectures sans serveur affectent fondamentalement les facteurs limitants qui limitent le développement de produits.Les chefs de produit de l'organisation jouent divers rôles. Parfois, ils sont appelés la «voix du client», parfois ils jouent le rôle de
«risque de chat d'entreprise» . Ce sont des frères à peau épaisse, des gens qui vous conduisent inexorablement à livrer le produit, malgré toute éthique ou excuse. Un bon chef de produit devient rarement l'idole de quelqu'un d'autre, mais c'est grâce au travail de ces personnes que la plupart des solutions technologiques que vous avez utilisées sont incarnées.
PM est toujours à la recherche d'outils de la plus haute qualité pour résoudre le problème. Nous savons que les concurrents marchent constamment sur leurs talons, les clients sont fatigués d'attendre, nous devons donc constamment agir plus intelligemment, plus rapidement et plus efficacement. Avec l'avènement des technologies sans serveur, il n'était pas immédiatement clair comment elles s'intégreraient dans la liste de souhaits de gestion des produits. Cependant, après avoir travaillé avec ces technologies pendant un an, je constate qu'elles résolvent certains problèmes de développement logiciel qui nous ont paru à jamais.
Paradoxe: taille et performances de l'équipe
La première règle de gestion des produits dit: la quantité de travail à effectuer est en constante augmentation. Le carnet de commandes continue de gonfler et s'effondre à zéro dans un seul cas: lorsque le produit est éliminé. Le plus difficile est de transformer les éléments les plus importants de votre carnet de commandes en un produit prêt à être livré. Toutes choses étant égales par ailleurs, on pense que la relation suivante doit être observée:
Si un creuseur peut recycler 1 tonne de sol par jour - on suppose que 10 creuseurs peuvent recycler 10 tonnes. En règle générale, la gestion des ressources dans les entreprises repose sur ce principe: si vous souhaitez augmenter les ventes - embauchez plus de vendeurs. Lors du développement de logiciels, lorsque l'arriéré augmente, la tentation est simplement d'augmenter l'équipe. Cependant, dans les cas de produits et services complexes, le calendrier suivant apparaît généralement avec le temps:
Il est rare de voir comment une énorme équipe fonctionne au rythme de Stakhanov; mais il arrive souvent qu'une petite équipe avec une constance enviable progresse à pas de géant.
De nombreuses startups ont ce genre d'erreur: dès que le produit réussit, de nouveaux développeurs et managers s'ajoutent au personnel. Bientôt, il s'avère que la vitesse commence à baisser. Quelle est la question? Que les premiers développeurs étaient plus talentueux, que la bureaucratie s'est développée dans l'entreprise et comment l'architecture a-t-elle été planifiée?
Je pense que ce ne sont que des symptômes, pas la racine du problème. Le problème lui-même se résume à l'interaction de trois facteurs critiques, dont seulement deux peuvent être directement contrôlés:
- La fragilité est l'effet de nouveaux changements. Si une nouvelle fonctionnalité n'affecte qu'une partie de la machine, elle est facile à tester et à mettre en œuvre. S'il affecte tous les éléments de la machine, le test devient alors plus difficile et en même temps plus important, et la mise en œuvre nécessite un ordre de grandeur plus long.
- Le volume de travail est le plus petit travail qui peut être effectué par une équipe et donne une fonctionnalité productive à la sortie. Par exemple, le résultat est «Payer avec Alexa» plutôt que «se réunir et discuter de la façon d'effectuer des paiements avec Alexa».
- Complexité - connaissances requises pour implémenter une fonctionnalité. Un développeur qui sait écrire une fonctionnalité est-il capable de faire la même chose au sein de l'organisation? Quels changements supplémentaires doivent se produire pour que le progrès ralentisse progressivement et que le produit cesse de croître avec des fonctionnalités qui sont précieuses du point de vue du client?
Je suis particulièrement curieux de savoir pourquoi, à l'aube de l'existence, tous ces facteurs sont équilibrés de manière optimale: il n'y a rien de fragile, la quantité de travail n'est pas particulièrement importante (et vous pouvez généralement être d'accord avec le client), et la complexité est pratiquement absente. Donc, si une équipe a besoin de créer un site conforme au RGPD, elle aura alors le temps de rechercher ce problème, une décision sera prise rapidement et l'équipe sera sûre que le site fonctionne exactement comme prévu.
Dans les grandes entreprises, ces facteurs sont combinés, ce qui se traduit par une taille d'équipe croissante et le volume de travail effectué est réduit. Pour créer un site Web compatible GDPR dans une telle entreprise, vous aurez besoin de la signature d'un avocat, de l'approbation des spécialistes du marketing, de l'approbation du projet au niveau du conseil d'administration, des tests A / B de la mise en œuvre la moins perturbatrice, de la coordination des interruptions de développement avec l'équipe des administrateurs, de la coordination avec les plans de déploiement adoptés par d'autres équipes - la liste continue. Même avec cette quantité de contrôle et le nombre de processus, l'équipe est beaucoup moins convaincue qu'elle réussira, en raison de la fragilité de l'ensemble du système et de nombreuses inconnues dans l'écosystème.
En étendant cet exemple à la taille d'un vrai projet, dans lequel il peut y avoir des dizaines de fonctionnalités et des centaines de changements, il est facile de comprendre comment, en raison de l'influence de ces facteurs, le graphique du rapport «taille de l'équipe / volume de travail» passe du premier au second. À mesure que l'équipe s'agrandit, vous êtes condamné à faire moins de travail par unité de temps, peu importe comment vous essayez de déjouer le colosse organisationnel. Ou cela semble juste - mais que faire alors?
Comment pirater les trois facteurs
Ce problème me hante depuis de nombreuses années, ce qui m'a poussé à étudier ses causes possibles. Est-il possible pour les startups de progresser rapidement? Pendant un moment, je le pensais juste, face aux difficultés de gestion des produits dans les grandes organisations. Cependant, j'ai ensuite examiné de plus près les trois facteurs.
La fragilité est toujours à votre détriment - elle provoque une dette technique toujours croissante dans tout projet de toute taille. La situation ressemble à la "demi-vie au contraire": tout élément du programme croît avec le temps et à cause de cela (pendant le développement) il devient plus fragile, et tout cela est aggravé à chaque nouvelle ligne de code.
La quantité de travail n'est pas associée à une caractéristique spécifique du produit («Payer avec Alexa»), mais plutôt à des différences dans les contours de l'infrastructure, si l'on compare les états «avant» et «après». Plus «l'après» devient difficile, plus la quantité de travail effectuée est réduite. C'est pourquoi dans de nombreuses entreprises, lors de la planification du travail, l'accent est mis sur les besoins du client («Payer avec Alexa») aux besoins de l'organisation («Rencontrer et discuter qui devrait être impliqué dans la mise en œuvre de la fonctionnalité« Payer avec Alexa »).
La complexité est une combinaison de facteurs sociaux, organisationnels et techniques qui affecte directement la durée d'une recherche d'un développeur approprié, la capacité de traiter les programmeurs comme des personnes multitâches qui peuvent se voir confier n'importe quel travail. De plus, c'est la complexité - l'aspect même qui risque de rester invisible, sans papiers et mal compris. Un développeur peut écrire une application React à la maison et la publier lui-même, mais dans l'organisation, il devra prendre une douzaine d'étapes supplémentaires qui prendront son temps, et les fonctionnalités intéressantes pour l'utilisateur ne changeront pas du tout. Le programmeur passera la majeure partie de la journée sur eux.
Ensemble, ces trois facteurs forment un cercle vicieux, de sorte que la quantité de travail effectuée diminue, la fragilité augmente, le développeur parvient à compléter de moins en moins de fonctionnalités et votre produit est envahi par la complexité comme une boue invisible. Par conséquent, la croissance de l'équipe n'aide pas et la vitesse ne peut être augmentée consciemment qu'en utilisant des chiffres et des indicateurs. Un symptôme classique: la position «réunion tenue» apparaît dans les rapports de sprint.
Dans les grandes entreprises, j'ai dû observer quelques approches défectueuses conçues pour briser ce cycle. Le premier est «Agile à grande échelle», ce qui donne lieu à d'énormes réunions auxquelles participent absolument tous les participants au développement d'une fonctionnalité particulière et des efforts sont faits pour coordonner le travail. Essayez donc de coordonner le travail et de comprendre la complexité. Une telle approche est bonne pour les entreprises de distribution alimentaire qui livrent des déjeuners enchanteurs, mais dans notre cas, cela ne fonctionne pas. Le fait est qu'au fur et à mesure que la taille du groupe de projets prioritaires augmente, il devient de plus en plus, et eux-mêmes diminuent. Il n'est donc pas possible de résoudre fondamentalement les problèmes de fragilité et de complexité. Au fil du temps, Agile à grande échelle fournit une liste tactique de tâches qui ressemble à une liste de courses et ressemble de moins en moins à un chemin holistique d'une fonctionnalité réfléchie à une autre.
Deuxièmement, les «groupes d'innovation» internes aux entreprises essaient souvent de pousser les changements périphériques dans l'espoir que ce travail s'enracinera dans une machine fragile et que toute la structure changera pour le mieux. Cette approche donne un effet secondaire bizarre: la conviction est consolidée que seuls ces «groupes d'innovateurs» ont le droit d'apporter des modifications au processus. Par conséquent, une méthode similaire ne résout pas non plus les problèmes de complexité organisationnelle.
Ayant vu plusieurs années d'échecs divers, je suis parvenu à la conclusion qu'il était nécessaire de pirater les trois facteurs afin d'éviter leur effet combiné sur le travail en cours et de faire face à l'inertie:
- La fragilité ne devrait pas augmenter dans les versions futures ou à mesure que le produit vieillit.
- Le travail ne doit pas être inférieur à ce qui est nécessaire pour créer une fonctionnalité significative du point de vue de l'utilisateur.
- La complexité ne devrait pas affecter le travail d'un seul développeur.
Si vous réussissez à adopter ces idées, alors vous serez protégé contre le rock, qui poursuit tous les produits logiciels de l'histoire de l'humanité. Cela semble génial, mais comment y parvenir?
Si vous réussissez à adopter ces idées, alors vous serez protégé contre le rock, qui poursuit tous les produits logiciels de l'histoire de l'humanité. Cela semble génial, mais comment y parvenir?
Limitations des technologies sans serveur
Grâce à l'avènement de la technologie cloud, il a été possible d'ouvrir des pistes importantes vers un nouvel état «piraté». En général, avec l'avènement des nuages, le processus de livraison d'un produit logiciel est devenu plus compact, car un fournisseur a commencé à faire beaucoup de choses de routine pour vous. Avant l'apparition des nuages, si vous aviez besoin d'implémenter une nouvelle fonctionnalité utilisateur, vous deviez commander un serveur, installer des équipements sur des racks, convenir de la mise en réseau dans un centre de données, puis entretenir cet équipement, qui s'use au fil du temps. Dans le cloud, tout cela peut être loué, éliminant ainsi des dizaines d'éléments d'organisation et économisant des mois entiers.
De plus, en éliminant la nécessité de mettre à niveau l'équipement d'un centre de données et en fournissant un accès au matériel à la demande, nous réduisons à la fois la fragilité et la complexité. La mise en œuvre des programmes est beaucoup plus facile que par le passé. Cependant, au fil du temps, le fardeau de l'administration d'une infrastructure virtuelle étendue a considérablement augmenté et de nombreuses méthodes de livraison obsolètes sont restées inchangées. En utilisant les nuages, l'équipe peut être considérablement augmentée avant que le travail ne commence à ralentir - cependant, il commence à ralentir, d'une manière ou d'une autre.
Les technologies sans serveur changent radicalement cette dynamique. L'application sans serveur se compose de petits morceaux de code écrits par votre équipe (ce que l'on appelle la «colle») et de «boîtes noires» fonctionnelles gérées par le fournisseur de cloud. La boîte noire accepte simplement une configuration et réagit aux changements. Dans une application avec une architecture de haute qualité, une partie standard du travail opérationnel associé au fonctionnement de l'application tombe sur les boîtes noires standard. L'application elle-même n'est plus une fonction monolithique, mais une structure fédérale de fonctions et de boîtes noires.
En pratique, cela affecte considérablement les trois facteurs que j'ai mentionnés ci-dessus:
- La fragilité est réduite en raison de coûts de gestion de l'infrastructure nuls et d'une liaison faible. Dans nos propres projets, il a été observé que la base de code résultant de ces changements peut parfois être décuplée.
- La taille de la «pièce de travail» est généralement comparable au coût de création d'une nouvelle fonctionnalité, car il devient trivial de créer de nouvelles versions de fonctions ou des fonctions complètement nouvelles qui n'étaient pas nécessaires auparavant.
- La complexité n'affecte pas le développeur - s'il peut écrire une fonction qui traite les paiements par carte de crédit, alors il n'y a pratiquement rien à faire en plus de ce code dans l'application sans serveur, pas de wrappers organisationnels et aucune considération de l'écosystème, à cause de quoi le travail pourrait ralentir.
Lors de la gestion même de très grandes applications sans serveur, il est facile pour le chef de produit de regarder de plus près les très rares éléments qui ont été affectés par les modifications apportées. De plus, il est facile de lancer deux versions de manière compétitive en plaçant des drapeaux de fonctionnalités. De plus, il n'est généralement même pas nécessaire de démolir les anciennes versions de code.
Dans les applications sans serveur, l'infrastructure est toujours construite sur la périphérie et vous n'écrivez que le code minimum nécessaire qui combine des services entièrement gérés. Vous n'avez jamais à y penser d'un point de vue opérationnel. Nous n'essayons pas de contrôler le monolithe, de nettoyer l'ancien code ou de visualiser l'ensemble du système à vol d'oiseau.
Pourquoi est-il extrêmement important
À mesure que le rythme du changement s'accélère, il devient de plus en plus difficile de prédire à quoi ressemblera votre programme à l'avenir ou ce que les utilisateurs attendront de vous. Par conséquent, les tentatives d'écrire du code «pendant des siècles», de telle sorte qu'il doit fonctionner à l'avenir, malgré tous les changements, deviennent de plus en plus futiles. Nous avons vu à quel point la réutilisation du code est mauvaise dans la plupart des entreprises et comment l'adhésion à des plateformes obsolètes ralentit les progrès.
Maintenant, tout est arrangé pour que l'ancien système soit développé et maintenu aussi longtemps que possible, jusqu'à ce que son support commence à disparaître du programmeur presque tout le temps. Après cela, l'entreprise recommence avec le nouveau système, promettant solennellement de ne pas répéter les erreurs commises dans l'ancien. Lorsque trois facteurs étranglent tôt ou tard le nouveau système, il y a un «feu de forêt» technologique, après quoi il faut recommencer.
Nous sommes tournés vers la lutte contre les symptômes de la complexité, c'est pourquoi tant de paradigmes vont et viennent, ne laissant aucune trace significative dans l'histoire de la gestion des produits. Le développement sans serveur, à son tour, permet à l'équipe de minimiser l'augmentation de la complexité et de continuer à fournir un produit précieux à un rythme assez uniforme, sans tomber dans des pièges classiques qui, pendant des décennies, sont restés le fléau de tout développement logiciel.
Le paradigme sans serveur commence à peine à se développer, mais il semble déjà extrêmement prometteur. À un moment où le client vous demande d'avoir de nouvelles fonctionnalités comme jamais auparavant, les chefs de produit peuvent enfin acquérir une plateforme qui vous permet de penser précisément en fonction de la préparation de nouvelles fonctionnalités. Ce processus n'est pas entravé par une complexité organisationnelle croissante et ne s'arrête pas non plus en raison d'une fragilité excessive.