Deux dans une boîte (si vous le pouvez) et tout le monde dans la documentation (toujours).
Dans un contexte informatique, « deux dans une boîte » fait référence à deux serveurs ou composants conçus pour fonctionner ensemble afin de fournir une redondance et une fiabilité accrue. Cette configuration peut garantir que si un composant tombe en panne, l'autre prendra le relais de ses opérations, maintenant ainsi la continuité du service. L'objectif d'avoir « deux dans une boîte » est de fournir une haute disponibilité et une reprise après sinistre. Cela s'applique également aux rôles humains dans une organisation ; cependant, il est rarement mis en œuvre.
Prenons un exemple Analytics pertinent. Nous connaissons probablement tous une personne de notre entreprise ou organisation par son nom qui est la personne de référence pour Analytics. Ce sont eux qui ont des rapports ou des tableaux de bord qui portent leur nom - Mike's Report ou Jane's Dashboard. Bien sûr, il y a d'autres personnes qui connaissent l'analyse, mais ce sont les vrais champions qui semblent savoir comment faire les choses les plus difficiles et dépasser les délais. Le problème, c'est que ces gens sont seuls. Dans de nombreux cas, sous pression, ils ne travaillent avec personne car cela pourrait les ralentir et c'est là que le problème commence. Nous ne pensons jamais que nous allons perdre cette personne. Je m'abstiendrai du typique "disons qu'ils se font renverser par un bus" ou d'utiliser un exemple tirant parti des opportunités actuelles du marché du travail et de dire quelque chose de positif comme "ils ont gagné à la loterie !", car nous devrions tous faire notre part pour être positifs ces jours.
Notre histoire
Lundi matin arrive, et notre expert en analyse et champion MJ a présenté sa démission. MJ a gagné à la loterie et a déjà quitté le pays sans se soucier du monde. L'équipe et les personnes qui connaissent MJ sont ravies et jalouses, mais le travail doit continuer. C'est maintenant que la valeur et la réalité de ce que faisait MJ sont sur le point d'être comprises. MJ était responsable de la publication finale et de la validation des analyses. Ils semblaient toujours être en mesure d'améliorer l'efficacité ou d'effectuer ce changement difficile avant de fournir les analyses à tout le monde. Personne ne se souciait vraiment de la façon dont cela se faisait et était sûr que cela venait de se produire, et MJ était une Rock Star individuelle d'Analytics, donc un niveau d'autonomie était accordé. Maintenant, alors que l'équipe commence à ramasser les pièces, les demandes, les problèmes quotidiens, les demandes de modification, ils sont perdus et commencent à se brouiller. Les rapports/tableaux de bord se trouvent dans des états inconnus ; certains actifs n'ont pas été mis à jour pendant le week-end, et nous ne savons pas pourquoi ; les gens demandent ce qui se passe et quand les choses seront corrigées, les modifications qui, selon MJ, ont été effectuées ne s'affichent pas et nous ne savons pas pourquoi. L'équipe a mauvaise mine. C'est un désastre et maintenant nous détestons tous MJ.
Les cours
Il y a des plats à emporter faciles et évidents.
- Ne laissez jamais une personne travailler seule. Cela semble bien, mais dans les petites équipes agiles, nous n'avons ni le temps ni les personnes pour y arriver. Les gens vont et viennent, les tâches sont nombreuses, il s'agit donc de diviser pour mieux régner au nom de la productivité.
- Chacun doit partager ses connaissances. Ça sonne bien aussi, mais partageons-nous avec la ou les bonnes personnes ? Gardez à l'esprit que de nombreux gagnants de loterie sont des collègues. Faire des sessions de partage des connaissances prend également du temps sur les tâches et la plupart des gens n'investissent dans les compétences et les connaissances qu'au moment où c'est nécessaire.
Alors, quelles sont les vraies solutions que tout le monde peut être en mesure de mettre en œuvre et de suivre ?
Commençons par la gestion de la configuration. Nous l'utiliserons comme terme générique pour plusieurs sujets similaires.
- Gestion du changement: Processus de planification, de mise en œuvre et de contrôle des modifications apportées aux systèmes logiciels de manière structurée et systématique. Ce processus vise à garantir que les modifications sont apportées de manière contrôlée et efficace (avec la possibilité de revenir en arrière), avec un minimum de perturbations du système existant et un maximum d'avantages pour l'organisation.
- Gestion de projet: La planification, l'organisation et le contrôle des projets de développement de logiciels pour s'assurer qu'ils sont terminés dans les délais, dans les limites du budget et selon les normes de qualité souhaitées. Cela implique la coordination des ressources, des activités et des tâches tout au long du cycle de vie du développement logiciel pour atteindre les objectifs du projet et livrer le produit logiciel dans les délais.
- Intégration continue et livraison continue (CI/CD) : Processus d'automatisation de la création, des tests et du déploiement de logiciels. L'intégration continue nécessite de fusionner régulièrement les modifications de code dans un référentiel partagé et d'exécuter des tests automatisés pour détecter les erreurs au début du processus de développement. La livraison/déploiement continu implique la publication automatique des modifications de code testées et validées en production, permettant des publications rapides et fréquentes de nouvelles fonctionnalités et améliorations.
- Contrôle de version: Processus de gestion des modifications du code source et d'autres artefacts logiciels au fil du temps à l'aide d'outils logiciels spécialisés. Il permet aux développeurs de collaborer sur une base de code, de conserver un historique complet des modifications et d'expérimenter de nouvelles fonctionnalités sans affecter la base de code principale.
Tout ce qui précède fait référence aux bonnes pratiques de développement de logiciels. Les analyses qui pilotent et gèrent l'entreprise ne méritent rien de moins car elles sont essentielles à la prise de décision. Tous les actifs d'analyse (tâches ETL, définitions sémantiques, définitions de métriques, rapports, tableaux de bord, histoires, etc.) ne sont que des extraits de code avec une interface visuelle pour la conception et des modifications apparemment mineures peuvent faire des ravages sur les opérations.
L'utilisation de la gestion de la configuration nous permet de continuer à fonctionner en bon état. Les actifs sont versionnés afin que nous puissions voir ce qui s'est passé au cours de leur durée de vie, nous savons qui travaille sur quoi ainsi que les progrès réalisés et les délais, et nous savons que la production continuera. Ce qui n'est couvert par aucun processus pur, c'est le transfert de connaissances et la compréhension du pourquoi les choses sont comme elles sont.
Chaque système, base de données et outil d'analyse a ses propres particularités. Des choses qui les font aller vite ou lentement, des éléments qui les font se comporter d'une certaine manière ou produisent un résultat souhaité. Il peut s'agir de paramètres au niveau système ou global ou d'éléments de la conception des actifs qui les font fonctionner comme ils le devraient. Le problème est que la plupart de ces choses sont apprises au fil du temps et qu'il n'y a pas toujours de place pour les documenter. Même lorsque nous passons aux systèmes Cloud où nous ne contrôlons plus la façon dont l'application s'exécute et nous comptons sur le fournisseur pour la rendre aussi rapide que possible, le peaufinage des définitions se poursuit au sein de nos actifs pour débloquer exactement ce que nous recherchons. C'est cette connaissance qui doit être capturée et partagée en la mettant à la disposition des autres. Cette connaissance doit être requise dans le cadre de la documentation des actifs et faire partie intégrante du contrôle de version et du processus d'enregistrement et d'approbation CI/CD et, dans certains cas, même dans le cadre d'une liste de contrôle avant la publication des choses à faire et à ne pas faire. faire.
Il n'y a pas de réponses magiques ou d'IA pour couvrir les raccourcis dans nos processus d'analyse ou leur absence. Quelle que soit la taille de l'équipe qui assure la circulation des données et des analyses, il est indispensable d'investir dans un système pour suivre les modifications, versionner tous les actifs et aider à documenter le processus de développement et à capturer les connaissances. L'investissement dans les processus et le temps à l'avance permettra d'économiser une tonne de temps perdu plus tard à comprendre les choses pour maintenir un état sain de nos analyses. Les choses arrivent et il est préférable d'avoir une police d'assurance pour les MJ et les autres gagnants de la loterie.
