softify.pro - Insiders

Il existe un moyen simple de rendre un logiciel d'entrepôt convaincant.
Ouvrir un tableau de bord.
Afficher quelques chiffres verts.
Ajouter un graphique.
Placer du stock sur une carte de l'entrepôt.
Terminer par un rapport.
Tout semble aller bien.
Et tout peut quand même être faux.
Parce qu'un entrepôt se moque de la beauté du tableau de bord.
Ce qui lui importe, c'est que chaque partie du système soit d'accord sur ce qui s'est réellement passé.
C'est devenu la partie intéressante de la dernière expérience softify.pro Flow.
Pas un autre écran.
Pas un autre KPI.
Pas un autre rapport.
Quelque chose de beaucoup moins visible.
La cohérence.
Tout a commencé avec un entrepôt.
La démo actuelle de softify.pro Flow fonctionne avec plusieurs environnements d'entrepôt synthétiques.
Des identifiants d'entrepôt différents.
Des capacités différentes.
Des structures de zones différentes.
Aucun stock de production.
Aucune donnée client.
Aucune information opérationnelle réelle.
Mais la logique du processus se comporte comme si tout cela comptait.
Parce qu'en logistique réelle, c'est le cas.
Une fois un entrepôt sélectionné, ce contexte fait partie de tout ce qui suit.
Flows.
SSCC.
Mouvements.
Opérateurs.
Analytics.
Rapports.
Cela paraît évident.
Cela devient nettement moins évident lorsque le même processus commence à apparaître dans plusieurs parties différentes de l'application.
Puis nous avons ouvert une autre vue.
Operational Analytics.
Soudain, l'entrepôt avait l'air complètement différent.
Aucune position de stockage.
Aucune flèche de mouvement.
À la place :

• Flows terminés,
• commandes actives,
• taux d'occupation de l'entrepôt,
• exceptions,
• entrées,
• sorties,
• temps de traitement.

La représentation visuelle avait changé.
L'entrepôt, non.
Cette distinction est devenue importante.
Parce que sous les KPI se trouvaient toujours des enregistrements individuels.
Identifiants de Flow.
SSCC.
Zones.
Statuts.
Opérateurs.
Temps de traitement.
Vue différente.
Même réalité opérationnelle.
Jusque-là, tout allait bien.

Operational Analytics — état agrégé de l'entrepôt, avec les enregistrements Flow sous-jacents toujours visibles.

88 % n'est utile que si le système peut l'expliquer.
Supposons que le tableau de bord indique :
Taux d'occupation de l'entrepôt : 88 %.
Utile.
Mais incomplet.
Certaines positions sont occupées.
Certaines sont réservées.
Certaines restent libres.
Ces états ne sont pas interchangeables.
Le chiffre ne devient fiable que si le système peut encore expliquer d'où il vient.
Cinq Flows terminés ?
Montrez-les.
Deux commandes actives ?
Montrez-les.
Une exception ?
Laquelle ?
88 % d'occupation ?
Qu'est-ce qui est occupé ?
Qu'est-ce qui est réservé ?
Qu'est-ce qui reste libre ?
Un tableau de bord devrait résumer la réalité.
Il ne devrait pas la remplacer.
Puis nous avons changé la langue.
Néerlandais.
L'entrepôt est resté le même.
Les identifiants de Flow sont restés les mêmes.
Les SSCC sont restés les mêmes.
Les opérateurs sont restés rattachés à leurs enregistrements.
Seule la langue a changé.
Plus tard, le même état opérationnel est apparu en croate.
Puis en français.
C'est là que le logiciel multilingue devient bien plus intéressant que des boutons traduits.
Une mauvaise traduction est facile à remarquer.
Un changement d'état provoqué par un changement de langue est bien plus dangereux.
Imaginez passer de l'allemand au français et perdre silencieusement le Flow sélectionné.
Ou reconstruire un filtre sur le mauvais entrepôt.
Ou afficher le bon SSCC dans le mauvais contexte de processus.
L'interface pourrait toujours sembler parfaite.
Le système ne le serait pas.
Flow suit donc une règle simple :
La langue peut changer les mots. Elle ne peut pas changer la vérité.
Ensuite, le Flow a acquis un historique.
Browse & Drill-down ne cherche pas particulièrement à être impressionnant.
C'est peut-être pour cela qu'il est utile.
Sélectionner un Flow.
Son contexte apparaît.
Entrepôt.
Zone.
Statut.
Opérateur.
SSCC.
Et ensuite la chaîne documentaire.
ASN.
Réception de marchandises.
Mouvement d'entrepôt.
Ordre de prélèvement.
Prélèvement.
Expédition.
FLOW.
Sept étapes.
Le processus n'est plus seulement un état actuel.
Il a un passé.
Et cela change la question.
Au lieu de :
Que se passe-t-il ?
nous pouvons demander :
Comment en sommes-nous arrivés là ?
C'est une bien meilleure question quand quelque chose finit par mal tourner.

Un Flow, un SSCC, une chaîne documentaire — de l'ASN à la finalisation.

Le SSCC devient le fil conducteur.
Au premier abord, un SSCC ressemble à ce qu'il est.
Un identifiant.
Un long numéro dans un tableau.
Mais à travers Flow, il devient quelque chose de plus utile.
Un fil conducteur à travers le processus.
En le suivant, d'autres éléments commencent à se relier.
Un entrepôt.
Un Flow.
Une zone.
Un statut.
Un opérateur.
Une chaîne documentaire.
Finalement, un rapport.
Le même objet logistique physique est désormais visible depuis plusieurs parties différentes de l'application.
Utile.
Dangereux aussi.
Parce que chaque vue supplémentaire crée une nouvelle occasion pour le système de raconter une histoire différente.
Et c'est là que les choses deviennent intéressantes.
Supposons qu'Analytics indique que le Flow est actif.
Le Drill-down indique que le SSCC appartient à ce Flow.
La chaîne documentaire indique que l'opération a progressé davantage.
Le rapport indique autre chose.
Lequel est correct ?
Ce n'est pas un problème spécifique à Flow.
C'est l'un des plus anciens problèmes des logiciels d'entreprise.
Différentes parties du même système développent progressivement leur propre version de la réalité.
Un écran lit l'état transactionnel.
Un autre lit un agrégat.
Un autre s'appuie sur des données en cache.
Un rapport calcule quelque chose légèrement différemment.
Une exception est résolue sur le plan opérationnel mais disparaît du reporting.
Chaque composant fonctionne.
Le système complet ment.
Généralement poliment.
Nous avons donc ouvert le Report Center.
Vue d'ensemble opérationnelle quotidienne.
Stock et occupation.
Performance des Flows.
Traçabilité SSCC.
Exceptions et SLA.
La même histoire opérationnelle est réapparue.
Flows terminés.
Commandes actives.
Taux d'occupation de l'entrepôt.
Exceptions.
Entrées.
Sorties.
Temps de traitement.
Mais cette fois, la question n'était pas de savoir si le rapport semblait correct.
La question était :
Peut-il se défendre lui-même ?
Un bon rapport vous donne un chiffre.
Un meilleur système peut expliquer d'où vient ce chiffre.

Le reporting issu du même état opérationnel — pas une seconde version de la réalité.

L'exception était toujours là.
L'un des détails les plus discrets s'est révélé être l'un des plus importants.
Les données de démonstration contiennent une exception.
Elle apparaît dans Analytics.
Elle apparaît dans le Drill-down.
Elle apparaît dans la traçabilité SSCC.
Elle apparaît dans le Report Center.
Et elle reste visible dans Exceptions & SLA.
C'est exactement ce qui devrait se passer.
Se rétablir opérationnellement d'une exception ne signifie pas que l'exception doit disparaître de l'historique.
« Le processus a continué » et « rien ne s'est passé » ne sont pas la même affirmation.
En logistique, cette différence compte.
À ce stade, nous avions un problème de test.
Pas un problème logiciel.
Un problème de test.
Nous avions désormais le même entrepôt représenté sous forme de :

• analytics,
• Flows individuels,
• historiques SSCC,
• chaînes documentaires,
• rapports,
• et vues des exceptions.

Chacun pouvait être testé indépendamment.
Ouvrir.
Cliquer.
Filtrer.
Vérifier.
Valider.
Suivant.

Ce serait facile.
Cela manquerait aussi la partie intéressante.
Parce que six coches vertes ne prouvent pas que six vues concordent entre elles.
Entrée en scène de COCO.
Encore.
COCO avait déjà eu affaire à Flow auparavant.
Authentification.
Utilisateurs.
Rôles.
Environnements de base de données.
Langues.
Exécution sur poste de travail.
Puis est venue la logistique.
Entrepôts.
Stock.
Prélèvement.
Mouvements.
Exceptions.
Documents.
Ubuntu.
Red Hat Enterprise Linux.
Cette fois, nous avons donné à COCO quelque chose de légèrement différent.
Pas un écran à vérifier.
Une histoire à suivre.
Prends cet entrepôt.
Prends ce Flow.
Prends ce SSCC.
Ouvre Analytics.
Ouvre Drill-down.
Change la langue.
Regarde à nouveau.
Ouvre le rapport.
Retrouve le même Flow.
Retrouve le même SSCC.
Retrouve l'exception.
Compare.
Puis compare à nouveau.

COCO suit le même contexte opérationnel à travers softify.pro Flow — analytics, traçabilité, changements de langue et reporting.

Cela change la nature du test.

La question n'est plus :

• Chaque module fonctionne-t-il ?

Elle devient :

• Tous les modules croient-ils qu'il s'est passé la même chose ?

Une bien meilleure question.
Bien moins confortable.
Un système d'entrepôt devrait avoir une seule mémoire.
Les opérateurs peuvent voir des positions.
Les responsables d'entrepôt peuvent voir des KPI.
Le support peut utiliser le drill-down.
Les auditeurs peuvent utiliser des rapports.
COCO peut voir tout cela.
Mais sous ces perspectives, il devrait y avoir un seul historique.
Un Flow ne devrait pas acquérir plusieurs biographies selon le module ouvert.
Un SSCC ne devrait pas avoir plusieurs passés.
Une exception ne devrait pas exister uniquement là où c'est pratique.
Un entrepôt ne devrait pas devenir un autre entrepôt parce que la langue de l'interface a changé.
Voilà de quoi il s'agit vraiment dans l'expérience Flow actuelle.
Pas des tableaux de bord.
Pas des rapports.
Pas même des écrans individuels.
Une seule vérité opérationnelle, exprimée de différentes manières.
Contrôle.
Connaître l'entrepôt.
Connaître l'état.
Savoir ce qui bouge.
Savoir quel processus le possède.
Clarté.
Retransformer les KPI en enregistrements.
Transformer les enregistrements en historique.
Transformer les exceptions en preuves.
Transformer un SSCC en quelque chose de traçable.
Flow.
Un entrepôt est sélectionné.
Analytics commence à le décrire.
Un Flow avance.
Le SSCC reste rattaché.
Une chaîne documentaire se développe.
Une exception apparaît.
Le processus continue.
Le rapport s'en souvient.
Puis la langue change.
L'entrepôt est toujours le même.
Le Flow est toujours le même.
L'historique est toujours le même.
C'est la partie que nous attendions.
Ce qui s'est passé ensuite était plus intéressant.
COCO a cessé de tester les vues indépendamment.
Il a commencé à les comparer.
Pendant un moment, rien de remarquable ne s'est produit.
Même entrepôt.
Même Flow.
Même SSCC.
Même histoire.
Encore.
Encore.
Encore.
Et puis COCO s'est arrêté.
Pas parce que l'application avait planté.
Ce n'était pas le cas.
Pas parce qu'un test avait échoué au sens habituel.
Ce n'était pas le cas.
Il s'est arrêté parce que deux réponses parfaitement raisonnables ont produit une troisième question.

Nous savons quelle est la question.
Flow sait pourquoi il existe.
COCO sait où regarder ensuite.

Le reste peut attendre.

Control. Clarity. Flow.

Nous devrions probablement arrêter de donner des idées à COCO.
L'expérience précédente était censée suffire.
Une application réelle.
Une navigation réelle.
Des utilisateurs.
Des rôles.
Des bases de données.
Des langues.
Des preuves.

Une étude de cas respectable.
Une conclusion propre.
Puis quelqu'un l'a montré : Logistics in Motion.
C'était probablement l'erreur.

Tout a commencé avec trois entrepôts
Rien de particulièrement excitant.
Trois entrepôts DEMO.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Données synthétiques.
Aucune information client.
Aucun stock de production.

Exactement le type d'environnement où rien d'important n'est censé se produire.
Puis le premier entrepôt a été sélectionné.
Et l'application a acquis un contexte.
À partir de ce moment, chaque écran avait une autre question qui lui était attachée.

Cela appartient-il toujours au même entrepôt ?
La langue change-t-elle seulement l'interface ?
Le processus reste-t-il à la même étape ?
L'inventaire concorde-t-il toujours ?
La référence du document pointe-t-elle toujours vers le bon événement ?
L'opérateur voit-il exactement ce qui est nécessaire pour l'action suivante ?

Soudain, la partie intéressante n'était plus l'écran.
C'était la continuité entre les écrans.

COCO a tendance à faire ça.

La logistique n'est pas une collection d'écrans
Vu de l'extérieur, un logiciel d'entrepôt peut sembler trompeusement simple.
La marchandise arrive.
On la stocke.
Quelqu'un la commande.
On la prélève.
On l'expédie.
Terminé.
Sauf qu'il y a tout un monde opérationnel caché entre arrivé et expédié.
Attendu.
Reçu.
Vérifié.
Disponible.
Réservé.
Déplacé.
Prélevé.
Bloqué.
Corrigé.
Expédié.
Audité.

Le mouvement physique compte.
Mais c'est la transition d'état qui rend ce mouvement compréhensible pour le logiciel.
Et quand ces deux réalités cessent de correspondre, quelqu'un finit par avoir une mauvaise journée.



Un entrepôt est plus facile à comprendre quand le mouvement est visible, pas seulement enregistré.
C'est pourquoi notre travail logistique n'a jamais vraiment commencé par des menus, des tableaux de bord, ou de la technologie.
Il commence par le Flow matériel.

Où l'information entre-t-elle ?
Où change-t-elle ?
Où peut-elle se perdre ?

Où quelqu'un est-il forcé de demander à une autre personne ce qui s'est passé ?
Où une étape manuelle devient-elle silencieusement le maillon le plus faible d'un processus par ailleurs automatisé ?
Parfois la réponse est une nouvelle interface.
Parfois une intégration.
Parfois un scanner.
Parfois simplement un meilleur modèle d'état.

Plus de logiciel n'est pas automatiquement un meilleur logiciel.
L'objectif n'est pas l'automatisation pour elle-même.
L'objectif est un processus qui reste compréhensible.

Control. Clarity. Flow.

Le processus commence avant la première saisie.
Avant la réception de marchandises.
Avant le prélèvement.
Avant le mouvement d'inventaire.
Avant la première transaction.
Flow pose une question très basique :
Dans quel entrepôt travaillons-nous ?
Cela semble presque trivial.
Ça ne l'est pas.
Le contexte de l'entrepôt appartient à tout ce qui suit.
Inventaire.
Documents.
Emplacements.
Prélèvement.
Transferts.
Historique d'audit.
Exceptions.

Le processus peut sembler parfaitement sain tout en fonctionnant dans le mauvais contexte.
C'est exactement le genre de problème qu'une capture d'écran révèle rarement.
Et exactement le genre de frontière que COCO aime remettre en question.

La langue est facile, jusqu'à ce qu'elle ne le soit plus
Allemand.
Anglais.
Croate.
Norvégien.
Et d'autres.

Un profil utilisateur définit les langues disponibles.
L'opérateur change de langue pendant que l'application est active.
L'interface change immédiatement.
Le processus métier ne doit pas changer.
Cette distinction est importante.
L'entrepôt ne bouge pas parce que le mot pour entrepôt a changé.
L'ordre de prélèvement ne redémarre pas parce que l'utilisateur a sélectionné une autre langue.
Une réservation ne disparaît pas.
Une exception n'appartient pas soudainement à une autre transaction.
Le processus reste où il est.
Seule sa représentation change.
Cela semble évident.

Jusqu'à ce qu'on réalise combien d'applications traitent un changement de langue presque comme une nouvelle session.

Une application métier multilingue ne devrait pas le faire.
L'état de présentation peut changer.
L'état métier doit rester stable.
Cela fait du changement de langue un test de régression étonnamment utile.
Une petite fonctionnalité.
Une très bonne ligne de faille.
COCO aime les lignes de faille.

Étape par étape, l'application commence à accumuler de l'historique
La marchandise arrive.
Le processus avance.
La réception de marchandises est enregistrée.
L'inventaire change.
L'état de l'entrepôt reflète la nouvelle réalité.
Le prélèvement commence.
Le stock devient réservé.
L'opérateur reçoit une tâche.

Une vue mobile réduit l'ensemble du processus à ce qui compte à ce moment précis :
Position.
Emplacement de stockage.
Quantité.
SSCC.
Opérateur.
Rien de plus.
Rien de moins.
C'est important.
L'interface mobile n'est pas un second processus métier.
C'est une autre vue du même processus.
L'application d'entrepôt peut tout savoir.
Le préleveur ne devrait pas avoir à le savoir.
Clarity ne signifie pas toujours montrer plus d'informations.
Parfois clarity signifie avoir la discipline de cacher presque tout.

Puis quelqu'un scanne le mauvais emplacement
C'est là qu'un workflow logistique devient plus intéressant qu'une liste de fonctionnalités.
L'emplacement attendu est une chose.
L'emplacement scanné en est une autre.
Flow s'arrête.
Ne plante pas.
S'arrête.
Il y a une différence.
L'état du processus reste visible.
Le stock concerné reste compréhensible.
L'exception devient explicite.

L'aide contextuelle explique ce qui est pertinent pour la situation actuelle.
L'utilisateur résout l'écart.
Le processus continue.
Ce moment en dit plus sur un logiciel opérationnel que plusieurs pages de captures d'écran du chemin idéal.
La logistique réelle n'est pas difficile quand tout est correct.
La logistique réelle devient difficile quand quelque chose est presque correct.
Un système utile ne cache pas cela derrière un tableau de bord vert.
Il donne un état à l'exception.

Une raison.
Un historique.
Et une voie à suivre.

Les documents se souviennent de ce que les gens oublient

À mesure que le workflow progresse, les références commencent à s'accumuler.
ASN.
Réception de marchandises.
Mouvement d'entrepôt.
Prélèvement.
Expédition.
Flow.
La partie intéressante n'est pas que les documents existent.
La partie intéressante est qu'ils racontent la même histoire que le processus.
Pourquoi ce stock est-il ici ?
Quelle réception l'a introduit ?
Quelle opération l'a réservé ?
Quel prélèvement l'a consommé ?
Quelle expédition l'a fait sortir ?
Une exception a-t-elle été résolue avant l'étape suivante ?
Quel était l'entrepôt actif ?
Que s'est-il passé avant l'état actuel ?
Quand l'état et la documentation sont produits par le même processus, la traçabilité devient plus facile à faire confiance.
Quand ce n'est pas le cas, les gens finissent par reconstruire l'historique.
Généralement dans Excel.
Généralement sous pression.
Généralement après que quelque chose a déjà mal tourné.
COCO préfère les preuves avant ce moment.
Apparemment, COCO voyage aussi
Il y a eu un autre petit changement entre les exécutions.
Ubuntu a eu son tour.
Red Hat Enterprise Linux 10 a pris le suivant.
COCO a continué.
Aucune cérémonie.
Aucun « mode Red Hat » spécial.
Aucun workflow réécrit.
Aucun test commodément simplifié.
Même Flow.
Un terrain différent en dessous.
Une exécution précédente de COCO avait déjà testé l'application sur Ubuntu Linux.
L'exécution actuelle est passée à Red Hat Enterprise Linux 10.
Environnement de bureau différent.
Bibliothèques système différentes.
Packaging différent.
Environnement d'exploitation différent.
Même entrepôt.
Mêmes états métier.
Mêmes transitions d'inventaire.
Mêmes changements de langue.
Même logique d'exception.
Mêmes preuves.
C'est une assez belle façon de tester un logiciel multiplateforme.

N'annoncez pas que c'est multiplateforme. Déplacez-le. Puis regardez ce qui casse.

État de la langue.
Contexte de l'entrepôt.
Comportement des boîtes de dialogue.
Timing.
Thèmes.
Transitions de processus.
Gestion des exceptions.
Preuves.
Les systèmes d'exploitation ont des façons étonnamment créatives d'exposer des suppositions.

Ubuntu en a exposé certaines.
Red Hat en expose d'autres.
C'est utile.

Parce que l'ingénierie multiplateforme n'est pas la capacité de démarrer l'exécutable deux fois.

C'est la capacité de changer l'environnement sans changer le sens du processus.
Un opérateur d'entrepôt ne devrait pas se soucier de savoir si l'application tourne sous Ubuntu ou Red Hat.
Un ordre de prélèvement ne devrait pas non plus s'en soucier.
Ni une piste d'audit.
Si les différences de plateforme commencent à changer le comportement métier, le logiciel n'est pas vraiment multiplateforme.
Il est simplement portable.
COCO semble considérablement plus intéressé par la première définition.
Nous aussi.

COCO ne décide pas ce que signifie une logistique correcte
Cette partie est importante.
COCO ne devient pas un expert en entrepôt simplement parce qu'il peut suivre un workflow d'entrepôt.
Les humains continuent de définir la correction.
Les humains décident quand l'inventaire devient disponible.
Les humains définissent ce que signifie une livraison bloquée.
Les humains décident qui peut corriger une quantité.
Les humains définissent quel mouvement nécessite une piste d'audit.
Les humains décident à quoi ressemble une résolution d'exception valide.
Les humains décident quand une expédition est vraiment complète.
Le travail de COCO est différent.

Répéter.
Observer.
Comparer.
Se souvenir.
Laisser des preuves.

Puis le refaire après que le logiciel change.
Et encore.
Et encore.
Sans jamais s'ennuyer.
Sans décider que le résultat de la semaine dernière est probablement encore valide.
Sans sauter l'exception ennuyeuse parce que le déjeuner est dans douze minutes.
L'avenir glamour du testing par IA contient une quantité surprenante de répétition.
Nous considérons cela comme une fonctionnalité.

Les preuves changent la conversation
Le testing traditionnel se termine souvent par une phrase parfaitement raisonnable :
« Ça a fonctionné quand je l'ai testé. »

COCO s'intéresse à la phrase suivante.

Qu'est-ce qui a fonctionné exactement ?
Quel entrepôt ?
Quel utilisateur ?
Quelle langue ?
Quel état de processus ?
Quelle séquence ?
Quel document ?
Quelle valeur d'inventaire ?
Que s'est-il passé immédiatement avant l'étape de test ?
Qu'est-ce qui a changé immédiatement après ?
Un autre ingénieur peut-il comprendre le résultat sans demander à la personne qui a effectué le test ?
C'est là que le testing de régression devient plus qu'un clic répété.
Un écran peut être correct tandis que le processus est faux.
Une fenêtre de prélèvement peut sembler parfaite tandis que l'inventaire a déjà dérivé.
Un document peut exister tandis que l'état qui aurait dû le créer ne s'est jamais produit.
Une application peut afficher 100 % tandis qu'une piste d'audit est silencieusement en désaccord.
COCO suit le Flow parce que c'est dans le Flow que ces contradictions deviennent visibles.

Quelque part entre Control et Flow
Il y a une symétrie intéressante ici.
Un bon logiciel de logistique essaie de réduire l'incertitude au sein d'une opération.
Un bon testing essaie de réduire l'incertitude sur le logiciel qui l'exécute.
L'un demande :
Où est l'article ?
L'autre demande :
Comment savons-nous que le logiciel le sait encore ?
L'un demande :
Ce mouvement a-t-il été complété ?
L'autre demande :
Quelle preuve démontre que l'état a changé correctement ?
L'un demande :
La prochaine équipe peut-elle continuer ?
L'autre demande :
Le prochain ingénieur peut-il comprendre ce qui s'est passé ?
Des questions différentes.
Le même instinct.
Rendre l'état visible.
Préserver le raisonnement.
Réduire la quantité de connaissances qui existe uniquement dans la tête de quelqu'un.
C'est peut-être le lien que nous n'avions pas prévu à l'origine.

L'excellence en ingénierie sans la bannière
Personne ne clique sur un bouton Engineering Excellence.
Il n'y en a pas.
Et il ne devrait probablement pas y en avoir.
L'excellence en ingénierie apparaît indirectement.
Le contexte de l'entrepôt survit à un changement de langue.
Le même processus survit à une autre plateforme Linux.
Un mouvement de stock reste traçable.
Un préleveur mobile voit exactement ce qui est nécessaire et rien d'autre.
Une exception interrompt le processus sans détruire son état.
La fenêtre d'aide explique le contexte actuel au lieu d'afficher une documentation générique.
La chaîne de documents concorde avec la séquence opérationnelle.
Le prochain ingénieur peut comprendre ce qui s'est passé sans demander à la personne qui se trouvait là par hasard.
Il y a beaucoup de théâtre disponible dans les logiciels modernes.
L'IA peut générer des démonstrations impressionnantes.
Les tableaux de bord peuvent s'animer.
Les chiffres peuvent bouger.
Les vidéos peuvent sembler très convaincantes.
Rien de tout cela ne prouve que deux opérations d'inventaire ne peuvent pas silencieusement produire un résultat incorrect.
Rien de tout cela ne prouve qu'une exception peut encore être reconstruite des semaines plus tard.
Rien de tout cela ne prouve que l'employé d'entrepôt, l'expéditeur, et le développeur regardent la même vérité opérationnelle.

L'excellence en ingénierie commence à un endroit moins photogénique.

Avec la cohérence.
Avec les preuves.
Avec les frontières.

Avec la volonté de garder les parties ennuyeuses ennuyeuses.
La fiabilité invisible produit rarement la capture d'écran la plus spectaculaire.
Jusqu'à ce qu'on commence délibérément à la chercher.

Control. Clarity. Flow.
Control c'est savoir quel entrepôt, quel processus, et quel état sont actifs.
Clarity c'est comprendre ce qui a changé, quand ça a changé, et pourquoi.
Flow c'est permettre à l'opération de continuer sans perdre l'histoire qui la sous-tend.
Cela fonctionne pour la logistique.
Cela fonctionne pour le testing de logiciels.
Cela fonctionne étonnamment bien pour l'ingénierie elle-même.
La première expérience Flow a donné à COCO l'Administration.
Utilisateurs.
Rôles.
Bases de données.
Langues.
Puis quelqu'un lui a donné un entrepôt.
Puis plusieurs langues.
Puis le prélèvement mobile.
Puis l'inventaire.
Puis les transferts.
Puis les exceptions.
Puis les documents.
Puis un autre système d'exploitation.
À ce stade, nous devrions probablement arrêter d'ajouter des choses.
Nous ne le ferons probablement pas.

Control. Clarity. Flow.

Ubuntu a eu son tour.

Red Hat a le tour actuel.

Le Flow continue de bouger.

COCO continue de regarder.
Et quelque part au milieu de la dernière exécution, il est devenu évident qu'une autre question attend derrière celle-ci.

Nous savons ce que c'est.
COCO sait ce que c'est.
Vous ne le savez pas.
Pas encore.

Nous pourrions vous le dire.

Mais alors vous pourriez arrêter de vérifier si un nouvel article Insiders est apparu.
Et cela ruinerait l'expérience.

À l'ingénieur ou l'ingénieure qui ouvre ce dépôt pour la première fois : Bienvenue.

Vous êtes peut-être arrivé ici parce que quelque chose a échoué.

Un service a cessé de répondre.

Un déploiement s'est comporté de façon inattendue.

Une alerte vous a réveillé en pleine nuit.

Ou peut-être êtes-vous simplement curieux de savoir comment fonctionne cette plateforme.

Quoi que ce soit qui vous ait amené ici,
sachez que ce projet a été construit exactement pour des moments comme celui-ci.

Non pas pour supprimer les problèmes difficiles.

Mais pour rendre les problèmes difficiles compréhensibles.

Vous trouverez du code.

Vous trouverez de la documentation.

Vous trouverez des spécifications.

Mais, plus important encore,
j'espère que vous trouverez du raisonnement.

Quelqu'un avant vous a posé des questions difficiles.

Quelqu'un a rassemblé des preuves.

Quelqu'un a pris des décisions.

Quelqu'un a expliqué pourquoi.

Ces explications font partie de la plateforme.

Traitez-les avec le même respect que le code source.

Un jour,
vous améliorerez quelque chose.

Peut-être un tout petit bug.

Peut-être une toute nouvelle fonctionnalité.

Quoi que vous changiez,
souvenez-vous qu'un autre ingénieur héritera un jour de votre travail.

Laissez-lui plus qu'un logiciel qui fonctionne.

Laissez-lui de la compréhension.

Expliquez votre intention.

Documentez vos hypothèses.

Conservez vos preuves.

Racontez l'histoire derrière la décision.

Cette histoire pourra un jour épargner à quelqu'un des heures – ou des jours – d'investigation.

N'ayez pas peur de remplacer la technologie.

Remplacez les bibliothèques.

Remplacez les fournisseurs.

Remplacez les modèles de déploiement.

Remplacez les langages de programmation.

Remplacez les architectures si nécessaire.

Mais avant de remplacer une idée,
comprenez pourquoi elle existait.

Le progrès sans compréhension n'est qu'un changement.

Le progrès construit sur la compréhension devient une évolution.

Il y aura des moments où la plateforme vous surprendra.

Traitez ces moments comme des cadeaux.

Chaque surprise révèle quelque chose que l'architecture n'avait pas encore compris.

Enquêtez avec patience.

Rassemblez des preuves.

Améliorez avec réflexion.

Puis laissez la leçon derrière vous, pour ceux qui suivront.

C'est ainsi que grandit le savoir en ingénierie.

Il y aura aussi des moments où rien d'intéressant ne se passera.

Ces moments comptent aussi.

Les systèmes silencieux sont souvent des systèmes sains.

Si COCO s'efface en arrière-plan parce que les incidents sont plus courts,
parce que les explications sont plus claires,
parce que l'intégration est plus facile,
parce que les ingénieurs font confiance aux preuves,
alors la plateforme réussit.

La fiabilité invisible est l'une des formes les plus élevées d'excellence en ingénierie.

Ne mesurez pas ce projet au nombre d'automatisations qu'il exécute.

Mesurez-le à des questions comme celles-ci :

• Les personnes sont-elles moins souvent interrompues ?
• Les ingénieurs comprennent-ils les systèmes plus en profondeur ?
• Les décisions importantes sont-elles plus faciles à expliquer ?
• Le savoir opérationnel survit-il aux changements d'équipe ?
• Les erreurs se répètent-elles moins souvent ?
• Les nouveaux ingénieurs deviennent-ils efficaces plus rapidement ?

Ce sont là les résultats qui méritent d'être préservés.

Enfin, souvenez-vous qu'aucun manuel n'est complet.

Aucune spécification ne prédit chaque avenir.

Aucune architecture ne survit indéfiniment sans changer.

Ce n'est pas une faiblesse.

C'est une invitation.

Observez la réalité.

Remettez en question les hypothèses.

Améliorez la plateforme.

Enseignez à ceux qui viendront après vous.

Et lorsque votre propre temps en tant que responsable touchera à sa fin, laissez derrière vous un système plus calme, plus clair, plus compréhensible et plus digne de confiance que celui que vous avez hérité.

Si chaque génération fait cela, COCO ne deviendra jamais vraiment obsolète.

Car son plus grand atout ne sera pas son logiciel.

Ce sera la discipline d'ingénierie transmise par les personnes qui continuent à le construire.

Merci d'être devenu l'une de ces personnes.

Le prochain chapitre n'est plus dans ce manuel.

Le prochain chapitre est dans le code que vous êtes sur le point d'écrire.

Le manuel de COCO

Parce que le logiciel évolue.
Une bonne architecture évolue plus lentement.

Et une bonne philosophie devrait survivre aux deux.

softify.pro