COCO frappe encore

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.