COCO znów uderza

Prawdopodobnie powinniśmy przestać dawać COCO pomysły.
Poprzedni eksperyment miał być wystarczający.
Prawdziwa aplikacja.
Prawdziwa nawigacja.
Użytkownicy.
Role.
Bazy danych.
Języki.
Dowody.

Szanowane studium przypadku.
Czysty wniosek.
Wtedy ktoś to pokazał: Logistics in Motion.
To był prawdopodobnie błąd.

Zaczęło się od trzech magazynów
Nic szczególnie ekscytującego.
Trzy magazyny DEMO.

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

Dane syntetyczne.
Żadnych informacji o klientach.
Żadnego zapasu produkcyjnego.

Dokładnie taki rodzaj środowiska, w którym nic ważnego nie powinno się wydarzyć.
Potem wybrano pierwszy magazyn.
I aplikacja zyskała kontekst.
Od tego momentu, każdy ekran miał dołączone kolejne pytanie.

Czy to nadal należy do tego samego magazynu?
Czy język zmienia tylko interfejs?
Czy proces pozostaje na tym samym kroku?
Czy zapas nadal się zgadza?
Czy referencja dokumentu nadal wskazuje na właściwe zdarzenie?
Czy operator widzi dokładnie to, co jest potrzebne do następnej akcji?

Nagle interesująca część nie była już ekranem.
Była nią ciągłość między ekranami.

COCO ma tendencję do tego.

Logistyka to nie kolekcja ekranów
Z zewnątrz, oprogramowanie magazynowe może wyglądać zwodniczo prosto.
Towar przybywa.
Jest przechowywany.
Ktoś go zamawia.
Jest kompletowany.
Jest wysyłany.
Gotowe.
Tylko że między przybyło a wysłano kryje się cały operacyjny świat.
Oczekiwane.
Otrzymane.
Sprawdzone.
Dostępne.
Zarezerwowane.
Przemieszczone.
Skompletowane.
Zablokowane.
Skorygowane.
Wysłane.
Zaudytowane.

Fizyczny ruch ma znaczenie.
Ale to przejście stanu sprawia, że ten ruch jest zrozumiały dla oprogramowania.
A kiedy te dwie rzeczywistości przestają się zgadzać, ktoś w końcu ma zły dzień.



Magazyn jest łatwiejszy do zrozumienia, gdy ruch jest widoczny, nie tylko zarejestrowany.
Dlatego nasza praca logistyczna nigdy tak naprawdę nie zaczynała się od menu, dashboardów, ani technologii.
Zaczyna się od materialnego Flow.

Gdzie informacja wchodzi?
Gdzie się zmienia?
Gdzie może zostać utracona?

Gdzie ktoś jest zmuszony pytać inną osobę, co się stało?
Gdzie ręczny krok cicho staje się najsłabszą częścią poza tym zautomatyzowanego procesu?
Czasami odpowiedzią jest nowy interfejs.
Czasami integracja.
Czasami skaner.
Czasami po prostu lepszy model stanu.

Więcej oprogramowania nie jest automatycznie lepszym oprogramowaniem.
Celem nie jest automatyzacja dla samej automatyzacji.
Celem jest proces, który pozostaje zrozumiały.

Control. Clarity. Flow.

Proces zaczyna się przed pierwszym księgowaniem.
Przed przyjęciem towaru.
Przed kompletacją.
Przed ruchem zapasu.
Przed pierwszą transakcją.
Flow zadaje bardzo podstawowe pytanie:
W którym magazynie pracujemy?
Brzmi to niemal trywialnie.
Nie jest.
Kontekst magazynu należy do wszystkiego, co następuje.
Zapas.
Dokumenty.
Lokalizacje.
Kompletacja.
Przemieszczenia.
Historia audytu.
Wyjątki.

Proces może wyglądać doskonale zdrowo, działając w niewłaściwym kontekście.
To dokładnie taki rodzaj problemu, którego zrzut ekranu rzadko ujawnia.
I dokładnie taki rodzaj granicy, którą COCO lubi kwestionować.

Język jest prosty, dopóki nie przestaje być
Niemiecki.
Angielski.
Chorwacki.
Norweski.
I inne.

Profil użytkownika definiuje dostępne języki.
Operator zmienia język, podczas gdy aplikacja działa.
Interfejs zmienia się natychmiast.
Proces biznesowy nie może.
Ta różnica ma znaczenie.
Magazyn nie porusza się, bo zmieniło się słowo dla magazynu.
Zamówienie kompletacyjne nie zaczyna się od nowa, bo użytkownik wybrał inny język.
Rezerwacja nie znika.
Wyjątek nie należy nagle do innej transakcji.
Proces pozostaje tam, gdzie jest.
Zmienia się tylko jego reprezentacja.
To brzmi oczywiście.

Dopóki nie zdasz sobie sprawy, ile aplikacji traktuje zmianę języka niemal jak nową sesję.

Wielojęzyczna aplikacja biznesowa nie powinna.
Stan prezentacji może się zmieniać.
Stan biznesowy musi pozostać stabilny.
To czyni zmianę języka zaskakująco użytecznym testem regresyjnym.
Mała funkcja.
Bardzo dobra linia pęknięcia.
COCO lubi linie pęknięć.

Krok po kroku, aplikacja zaczyna gromadzić historię
Towar przybywa.
Proces postępuje.
Przyjęcie towaru jest księgowane.
Zapas się zmienia.
Stan magazynu odzwierciedla nową rzeczywistość.
Kompletacja się rozpoczyna.
Zapas staje się zarezerwowany.
Operator otrzymuje zadanie.

Widok mobilny redukuje cały proces do tego, co ma znaczenie w tym dokładnym momencie:
Pozycja.
Lokalizacja magazynowa.
Ilość.
SSCC.
Operator.
Nic więcej.
Nic mniej.
To jest ważne.
Interfejs mobilny nie jest drugim procesem biznesowym.
To inny widok tego samego procesu.
Aplikacja magazynowa może wiedzieć wszystko.
Kompletujący nie musi.
Clarity nie zawsze oznacza pokazywanie więcej informacji.
Czasami clarity oznacza posiadanie dyscypliny, aby ukryć prawie wszystko.

Wtedy ktoś skanuje niewłaściwą lokalizację
Tu przepływ pracy logistycznej staje się bardziej interesujący niż lista funkcji.
Oczekiwana lokalizacja to jedno.
Zeskanowana lokalizacja to drugie.
Flow zatrzymuje się.
Nie zawiesza się.
Zatrzymuje się.
Jest różnica.
Stan procesu pozostaje widoczny.
Dotknięty zapas pozostaje zrozumiały.
Wyjątek staje się jawny.

Pomoc kontekstowa wyjaśnia, co jest istotne dla obecnej sytuacji.
Użytkownik rozwiązuje rozbieżność.
Proces trwa dalej.
Ten moment mówi więcej o oprogramowaniu operacyjnym niż kilka stron zrzutów ekranu idealnej ścieżki.
Prawdziwa logistyka nie jest trudna, gdy wszystko jest poprawne.
Prawdziwa logistyka staje się trudna, gdy coś jest prawie poprawne.
Użyteczny system nie ukrywa tego za zielonym dashboardem.
Nadaje wyjątkowi status.

Powód.
Historię.
I drogę naprzód.

Dokumenty pamiętają to, co ludzie zapominają

W miarę postępu przepływu pracy, referencje zaczynają się gromadzić.
ASN.
Przyjęcie towaru.
Ruch magazynowy.
Kompletacja.
Wysyłka.
Flow.
Interesująca część nie polega na tym, że dokumenty istnieją.
Interesująca część polega na tym, że opowiadają tę samą historię co proces.
Dlaczego ten zapas jest tutaj?
Które przyjęcie go wprowadziło?
Która operacja go zarezerwowała?
Która kompletacja go zużyła?
Która wysyłka go wyprowadziła?
Czy wyjątek został rozwiązany przed następnym krokiem?
Jaki był aktywny magazyn?
Co wydarzyło się przed obecnym stanem?
Gdy stan i dokumentacja są produkowane przez ten sam proces, śledzalność staje się łatwiejsza do zaufania.
Gdy nie są, ludzie w końcu zaczynają rekonstruować historię.
Zwykle w Excelu.
Zwykle pod presją.
Zwykle po tym, jak coś już poszło nie tak.
COCO preferuje dowody przed tym momentem.
Najwyraźniej COCO też podróżuje
Była jeszcze jedna mała zmiana między uruchomieniami.
Ubuntu miało swoje uruchomienie.
Red Hat Enterprise Linux 10 wzięło następne.
COCO kontynuowało.
Bez ceremonii.
Bez specjalnego „trybu Red Hat".
Bez przepisanego przepływu pracy.
Bez wygodnie uproszczonego testu.
Ten sam Flow.
Inny grunt pod nim.
Wcześniejsze uruchomienie COCO już przetestowało aplikację na Ubuntu Linux.
Obecne przeniosło się na Red Hat Enterprise Linux 10.
Inne środowisko desktopowe.
Inne biblioteki systemowe.
Inne pakowanie.
Inne środowisko operacyjne.
Ten sam magazyn.
Te same stany biznesowe.
Te same przejścia zapasu.
Te same zmiany języka.
Ta sama logika wyjątków.
Te same dowody.
To dość ładny sposób na testowanie oprogramowania wieloplatformowego.

Nie ogłaszaj, że jest wieloplatformowe. Przenieś je. Potem zobacz, co się psuje.

Stan języka.
Kontekst magazynu.
Zachowanie dialogów.
Timing.
Motywy.
Przejścia procesu.
Obsługa wyjątków.
Dowody.
Systemy operacyjne mają zaskakująco kreatywne sposoby ujawniania założeń.

Ubuntu ujawniło niektóre.
Red Hat ujawnia inne.
To użyteczne.

Ponieważ inżynieria wieloplatformowa to nie zdolność do uruchomienia pliku wykonywalnego dwa razy.

To zdolność do zmiany środowiska bez zmiany znaczenia procesu.
Operatorowi magazynu nie powinno zależeć, czy aplikacja działa na Ubuntu czy Red Hat.
Zamówieniu kompletacyjnemu też nie powinno zależeć.
Ani śladowi audytu.
Jeśli różnice platform zaczynają zmieniać zachowanie biznesowe, oprogramowanie nie jest naprawdę wieloplatformowe.
Jest po prostu przenośne.
COCO wydaje się znacznie bardziej zainteresowane pierwszą definicją.
My również.

COCO nie decyduje, co oznacza poprawna logistyka
Ta część ma znaczenie.
COCO nie staje się ekspertem magazynowym tylko dlatego, że może podążać za przepływem pracy magazynu.
Ludzie nadal definiują poprawność.
Ludzie decydują, kiedy zapas staje się dostępny.
Ludzie definiują, co oznacza zablokowana dostawa.
Ludzie decydują, kto może skorygować ilość.
Ludzie definiują, który ruch wymaga śladu audytu.
Ludzie decydują, jak wygląda ważne rozwiązanie wyjątku.
Ludzie decydują, kiedy wysyłka jest naprawdę kompletna.
Zadanie COCO jest inne.

Powtarzać.
Obserwować.
Porównywać.
Pamiętać.
Zostawiać dowody.

Potem zrobić to ponownie po zmianie oprogramowania.
I ponownie.
I ponownie.
Bez znudzenia się.
Bez decydowania, że wynik z zeszłego tygodnia jest prawdopodobnie nadal ważny.
Bez pomijania irytującego wyjątku, ponieważ lunch jest za dwanaście minut.
Pełna glamouru przyszłość testowania AI zawiera zaskakującą ilość powtórzeń.
Uważamy to za funkcję.

Dowody zmieniają rozmowę
Tradycyjne testowanie często kończy się całkowicie rozsądnym zdaniem:
„Działało, kiedy to testowałem."

COCO interesuje kolejne zdanie.

Co dokładnie działało?
Który magazyn?
Który użytkownik?
Który język?
Jaki stan procesu?
Jaka kolejność?
Jaki dokument?
Jaka wartość zapasu?
Co wydarzyło się bezpośrednio przed krokiem testowym?
Co zmieniło się bezpośrednio po?
Czy inny inżynier może zrozumieć wynik bez pytania osoby, która wykonała test?
Tu testowanie regresyjne staje się czymś więcej niż powtarzanym klikaniem.
Jeden ekran może być poprawny, podczas gdy proces jest błędny.
Okno kompletacyjne może wyglądać doskonale, podczas gdy zapas już odpłynął.
Dokument może istnieć, podczas gdy stan, który powinien go stworzyć, nigdy nie wystąpił.
Aplikacja może wyświetlać 100%, podczas gdy ślad audytu cicho się nie zgadza.
COCO podąża za Flow, ponieważ to w Flow te sprzeczności stają się widoczne.

Gdzieś między Control a Flow
Jest tu interesująca symetria.
Dobre oprogramowanie logistyczne stara się zmniejszyć niepewność wewnątrz operacji.
Dobre testowanie stara się zmniejszyć niepewność co do oprogramowania, które je wykonuje.
Jedno pyta:
Gdzie jest artykuł?
Drugie pyta:
Skąd wiemy, że oprogramowanie nadal to wie?
Jedno pyta:
Czy ten ruch został zakończony?
Drugie pyta:
Jaki dowód potwierdza, że stan zmienił się poprawnie?
Jedno pyta:
Czy następna zmiana może kontynuować?
Drugie pyta:
Czy następny inżynier może zrozumieć, co się stało?
Różne pytania.
Ten sam instynkt.
Uczynić stan widocznym.
Zachować rozumowanie.
Zmniejszyć ilość wiedzy, która istnieje tylko w czyjejś głowie.
Może to jest połączenie, którego pierwotnie nie planowaliśmy.

Doskonałość inżynierska bez transparentu
Nikt nie klika przycisku Engineering Excellence.
Nie ma takiego.
I prawdopodobnie nie powinno być.
Doskonałość inżynierska pojawia się pośrednio.
Kontekst magazynu przetrwa zmianę języka.
Ten sam proces przetrwa inną platformę Linux.
Ruch zapasu pozostaje możliwy do prześledzenia.
Mobilny kompletujący widzi dokładnie to, co potrzebne, i nic więcej.
Wyjątek przerywa proces bez niszczenia jego stanu.
Okno pomocy wyjaśnia obecny kontekst zamiast wyświetlać ogólną dokumentację.
Łańcuch dokumentów zgadza się z sekwencją operacyjną.
Następny inżynier może zrozumieć, co się stało, bez pytania osoby, która akurat tam była.
Jest mnóstwo teatru dostępnego we współczesnym oprogramowaniu.
AI może generować imponujące demonstracje.
Dashboardy mogą się animować.
Liczby mogą się poruszać.
Wideo może wyglądać bardzo przekonująco.
Nic z tego nie dowodzi, że dwie operacje zapasu nie mogą cicho wyprodukować niepoprawnego wyniku.
Nic z tego nie dowodzi, że wyjątek może być nadal zrekonstruowany tygodnie później.
Nic z tego nie dowodzi, że pracownik magazynu, dyspozytor, i deweloper patrzą na tę samą operacyjną prawdę.

Doskonałość inżynierska zaczyna się w mniej fotogenicznym miejscu.

Z konsekwencją.
Z dowodami.
Z granicami.

Z gotowością do utrzymania nudnych części nudnymi.
Niewidzialna niezawodność rzadko produkuje najbardziej dramatyczny zrzut ekranu.
Dopóki nie zaczniesz celowo jej szukać.

Control. Clarity. Flow.
Control to wiedza, który magazyn, który proces, i który stan są aktywne.
Clarity to rozumienie, co się zmieniło, kiedy się zmieniło, i dlaczego.
Flow to pozwolenie operacji na kontynuowanie bez utraty historii za nią.
To działa dla logistyki.
Działa dla testowania oprogramowania.
Działa zaskakująco dobrze dla samej inżynierii.
Pierwszy eksperyment Flow dał COCO Administration.
Użytkownicy.
Role.
Bazy danych.
Języki.
Potem ktoś dał mu magazyn.
Potem wiele języków.
Potem mobilną kompletację.
Potem zapas.
Potem przemieszczenia.
Potem wyjątki.
Potem dokumenty.
Potem inny system operacyjny.
W tym momencie, prawdopodobnie powinniśmy przestać dodawać rzeczy.
Prawdopodobnie tego nie zrobimy.

Control. Clarity. Flow.

Ubuntu miało swoją kolej.

Red Hat ma obecną.

Flow wciąż się porusza.

COCO wciąż obserwuje.
I gdzieś w połowie ostatniego uruchomienia stało się oczywiste, że za tym czeka kolejne pytanie.

Wiemy, co to jest.
COCO wie, co to jest.
Ty nie wiesz.
Jeszcze.

Moglibyśmy ci powiedzieć.

Ale wtedy mógłbyś przestać sprawdzać, czy pojawił się nowy artykuł Insiders.
A to zrujnowałoby eksperyment.