softify.pro - Insiders

Istnieje prosty sposób, by oprogramowanie magazynowe wyglądało przekonująco.
Otwórz pulpit nawigacyjny.
Pokaż kilka zielonych liczb.
Dodaj wykres.
Umieść trochę zapasów na mapie magazynu.
Zakończ raportem.
Wszystko wygląda dobrze.
A mimo to wszystko może być błędne.
Bo magazynowi nie zależy na tym, jak dobrze wygląda pulpit.
Zależy mu na tym, czy każda część systemu zgadza się co do tego, co naprawdę się wydarzyło.
To stało się interesującą częścią najnowszego eksperymentu softify.pro Flow.
Nie kolejny ekran.
Nie kolejny KPI.
Nie kolejny raport.
Coś dużo mniej widocznego.
Spójność.
Zaczęło się od magazynu.
Obecna wersja demo softify.pro Flow działa z kilkoma syntetycznymi środowiskami magazynowymi.
Różne identyfikatory magazynów.
Różne pojemności.
Różne struktury stref.
Brak zapasów produkcyjnych.
Brak danych klientów.
Brak rzeczywistych informacji operacyjnych.
Ale logika procesu zachowuje się tak, jakby wszystko to miało znaczenie.
Bo w prawdziwej logistyce ma.
Gdy magazyn zostanie raz wybrany, ten kontekst staje się częścią wszystkiego, co następuje.
Flowy.
SSCC.
Ruchy.
Operatorzy.
Analityka.
Raporty.
Brzmi to oczywiście.
Staje się znacznie mniej oczywiste, gdy ten sam proces zaczyna pojawiać się w kilku różnych częściach aplikacji.
Wtedy otworzyliśmy inny widok.
Operational Analytics.
Nagle magazyn wyglądał zupełnie inaczej.
Brak pozycji magazynowych.
Brak strzałek ruchu.
Zamiast tego:

• ukończone Flowy,
• aktywne zamówienia,
• wykorzystanie magazynu,
• wyjątki,
• przyjęcia,
• wydania,
• czas przetwarzania.

Wizualna reprezentacja się zmieniła.
Magazyn nie.
To rozróżnienie stało się istotne.
Bo pod KPI wciąż znajdowały się pojedyncze rekordy.
Identyfikatory Flow.
SSCC.
Strefy.
Statusy.
Operatorzy.
Czasy przetwarzania.
Inny widok.
Ta sama rzeczywistość operacyjna.
Jak dotąd dobrze.

Operational Analytics — zagregowany stan magazynu, z wciąż widocznymi rekordami Flow leżącymi u podstaw.

88% jest użyteczne tylko wtedy, gdy system potrafi to wyjaśnić.
Załóżmy, że pulpit nawigacyjny mówi:
Wykorzystanie magazynu: 88%.
Użyteczne.
Ale niepełne.
Niektóre pozycje są zajęte.
Niektóre są zarezerwowane.
Niektóre pozostają wolne.
Te stany nie są wymienne.
Liczba staje się wiarygodna dopiero wtedy, gdy system nadal potrafi wyjaśnić, skąd pochodzi.
Pięć ukończonych Flowów?
Pokaż je.
Dwa aktywne zamówienia?
Pokaż je.
Jeden wyjątek?
Który?
88% wykorzystania?
Co jest zajęte?
Co jest zarezerwowane?
Co pozostaje wolne?
Pulpit nawigacyjny powinien podsumowywać rzeczywistość.
Nie powinien jej zastępować.
Wtedy zmieniliśmy język.
Niderlandzki.
Magazyn pozostał ten sam.
Identyfikatory Flow pozostały te same.
SSCC pozostały te same.
Operatorzy pozostali przypisani do swoich rekordów.
Zmienił się tylko język.
Później ten sam stan operacyjny pojawił się po chorwacku.
Potem po francusku.
Tu oprogramowanie wielojęzyczne staje się dużo bardziej interesujące niż przetłumaczone przyciski.
Zły przekład łatwo zauważyć.
Zmiana stanu spowodowana zmianą języka jest znacznie bardziej niebezpieczna.
Wyobraź sobie przełączenie z niemieckiego na francuski i ciche utracenie wybranego Flow.
Albo przebudowanie filtra dla niewłaściwego magazynu.
Albo wyświetlenie poprawnego SSCC w niewłaściwym kontekście procesu.
Interfejs może wciąż wyglądać idealnie.
System nie byłby taki.
Flow stosuje się więc do prostej zasady:
Język może zmienić słowa. Nie może zmienić prawdy.
Wtedy Flow zyskał historię.
Browse & Drill-down nie stara się szczególnie wyglądać imponująco.
Może właśnie dlatego jest użyteczny.
Wybierz Flow.
Pojawia się jego kontekst.
Magazyn.
Strefa.
Status.
Operator.
SSCC.
A następnie łańcuch dokumentów.
ASN.
Przyjęcie towaru.
Ruch magazynowy.
Zlecenie kompletacji.
Kompletacja.
Wysyłka.
FLOW.
Siedem kroków.
Proces to już nie tylko aktualny stan.
Ma przeszłość.
A to zmienia pytanie.
Zamiast:
Co się dzieje?
możemy zapytać:
Jak tu dotarliśmy?
To znacznie lepsze pytanie, gdy w końcu coś pójdzie nie tak.

Jeden Flow, jeden SSCC, jeden łańcuch dokumentów — od ASN do zakończenia.

SSCC staje się nitką przewodnią.
Na początku SSCC wygląda jak to, czym jest.
Identyfikator.
Długi numer w tabeli.
Ale w ramach Flow staje się czymś bardziej użytecznym.
Nitka przewodnia przez proces.
Podążaj za nią, a inne rzeczy zaczynają się łączyć.
Magazyn.
Flow.
Strefa.
Status.
Operator.
Łańcuch dokumentów.
Ostatecznie raport.
Ten sam fizyczny obiekt logistyczny jest teraz widoczny z kilku różnych części aplikacji.
Użyteczne.
Także niebezpieczne.
Bo każdy dodatkowy widok stwarza kolejną okazję, by system opowiedział inną historię.
I właśnie tu robi się interesująco.
Załóżmy, że Analytics mówi, iż Flow jest aktywny.
Drill-down mówi, że SSCC należy do tego Flow.
Łańcuch dokumentów mówi, że operacja posunęła się dalej.
Raport mówi coś innego.
Który jest poprawny?
To nie jest problem specyficzny dla Flow.
To jeden z najstarszych problemów w oprogramowaniu biznesowym.
Różne części tego samego systemu stopniowo rozwijają własną wersję rzeczywistości.
Jeden ekran odczytuje stan transakcyjny.
Inny odczytuje agregat.
Kolejny polega na danych z pamięci podręcznej.
Raport oblicza coś nieco inaczej.
Wyjątek zostaje rozwiązany operacyjnie, ale znika z raportowania.
Każdy komponent działa.
Cały system kłamie.
Zwykle uprzejmie.
Otworzyliśmy więc Report Center.
Codzienny przegląd operacyjny.
Zapasy i zajętość.
Wydajność Flow.
Identyfikowalność SSCC.
Wyjątki i SLA.
Ta sama historia operacyjna pojawiła się ponownie.
Ukończone Flowy.
Aktywne zamówienia.
Wykorzystanie magazynu.
Wyjątki.
Przyjęcia.
Wydania.
Czas przetwarzania.
Ale tym razem pytanie nie dotyczyło tego, czy raport wygląda poprawnie.
Pytanie brzmiało:
Czy potrafi się obronić?
Dobry raport daje ci liczbę.
Lepszy system potrafi wyjaśnić, skąd ta liczba pochodzi.

Raportowanie z tego samego stanu operacyjnego — nie druga wersja rzeczywistości.

Wyjątek wciąż tam był.
Jeden z cichszych szczegółów okazał się jednym z ważniejszych.
Dane demonstracyjne zawierają wyjątek.
Pojawia się w Analytics.
Pojawia się w Drill-down.
Pojawia się w identyfikowalności SSCC.
Pojawia się w Report Center.
I pozostaje widoczny w Exceptions & SLA.
Właśnie to powinno się wydarzyć.
Operacyjne wyjście z wyjątku nie oznacza, że wyjątek powinien zniknąć z historii.
„Proces trwał dalej” i „nic się nie stało” to nie to samo stwierdzenie.
W logistyce ta różnica ma znaczenie.
W tym momencie mieliśmy problem testowy.
Nie problem z oprogramowaniem.
Problem testowy.
Mieliśmy teraz ten sam magazyn przedstawiony jako:

• analityka,
• pojedyncze Flowy,
• historie SSCC,
• łańcuchy dokumentów,
• raporty,
• i widoki wyjątków.

Każdy z nich można było testować niezależnie.
Otwórz.
Kliknij.
Filtruj.
Zweryfikuj.
Zdaj.
Dalej.

To byłoby łatwe.
Umknęłaby też interesująca część.
Bo sześć zielonych znaczników nie dowodzi, że sześć widoków zgadza się ze sobą.
Wkracza COCO.
Ponownie.
COCO miał już wcześniej do czynienia z Flow.
Uwierzytelnianie.
Użytkownicy.
Role.
Środowiska bazodanowe.
Języki.
Wykonanie desktopowe.
Potem przyszła logistyka.
Magazyny.
Zapasy.
Kompletacja.
Ruchy.
Wyjątki.
Dokumenty.
Ubuntu.
Red Hat Enterprise Linux.
Tym razem daliśmy COCO coś nieco innego.
Nie ekran do zweryfikowania.
Historię do prześledzenia.
Weź ten magazyn.
Weź ten Flow.
Weź ten SSCC.
Otwórz Analytics.
Otwórz Drill-down.
Zmień język.
Spójrz ponownie.
Otwórz raport.
Znajdź ten sam Flow.
Znajdź ten sam SSCC.
Znajdź wyjątek.
Porównaj.
Potem porównaj ponownie.

COCO śledzi ten sam kontekst operacyjny w całym softify.pro Flow — analitykę, identyfikowalność, zmiany języka i raportowanie.

To zmienia naturę testu.

Pytanie nie brzmi już:

• Czy każdy moduł działa?

Brzmi:

• Czy wszystkie moduły wierzą, że wydarzyło się to samo?

Znacznie lepsze pytanie.
Znacznie mniej komfortowe.
System magazynowy powinien mieć jedną pamięć.
Operatorzy mogą widzieć pozycje.
Kierownicy magazynu mogą widzieć KPI.
Wsparcie może korzystać z drill-down.
Audytorzy mogą korzystać z raportów.
COCO może widzieć je wszystkie.
Ale pod tymi perspektywami powinna istnieć jedna historia.
Jeden Flow nie powinien zyskiwać kilku biografii w zależności od tego, który moduł jest otwarty.
Jeden SSCC nie powinien mieć kilku przeszłości.
Jeden wyjątek nie powinien istnieć tylko tam, gdzie jest to wygodne.
Jeden magazyn nie powinien stawać się innym magazynem, bo zmienił się język interfejsu.
Właśnie o to naprawdę chodzi w obecnym eksperymencie Flow.
Nie o pulpity nawigacyjne.
Nie o raporty.
Nawet nie o pojedyncze ekrany.
O jedną prawdę operacyjną, wyrażoną na różne sposoby.
Kontrola.
Znać magazyn.
Znać stan.
Wiedzieć, co się porusza.
Wiedzieć, do którego procesu należy.
Przejrzystość.
Zamienić KPI z powrotem w rekordy.
Zamienić rekordy w historię.
Zamienić wyjątki w dowody.
Zamienić SSCC w coś identyfikowalnego.
Flow.
Magazyn zostaje wybrany.
Analytics zaczyna go opisywać.
Flow posuwa się naprzód.
SSCC pozostaje dołączony.
Łańcuch dokumentów rośnie.
Pojawia się wyjątek.
Proces trwa dalej.
Raport pamięta.
Wtedy zmienia się język.
Magazyn jest wciąż ten sam.
Flow jest wciąż ten sam.
Historia jest wciąż ta sama.
To była oczekiwana część.
To, co wydarzyło się potem, było ciekawsze.
COCO przestał testować widoki niezależnie.
Zaczął je porównywać.
Przez chwilę nic godnego uwagi się nie działo.
Ten sam magazyn.
Ten sam Flow.
Ten sam SSCC.
Ta sama historia.
Znowu.
Znowu.
Znowu.
A potem COCO się zatrzymał.
Nie dlatego, że aplikacja się zawiesiła.
Nie zawiesiła się.
Nie dlatego, że test zawiódł w zwykłym sensie.
Nie zawiódł.
Zatrzymał się, ponieważ dwie całkowicie rozsądne odpowiedzi wygenerowały trzecie pytanie.

Wiemy, jakie jest pytanie.
Flow wie, dlaczego istnieje.
COCO wie, gdzie szukać dalej.

Reszta może poczekać.

Control. Clarity. Flow.

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.

Do inżynierki lub inżyniera, który po raz pierwszy otwiera to repozytorium: Witaj.
Być może jesteś tu, ponieważ coś zawiodło.
Usługa przestała odpowiadać.
Wdrożenie zachowało się nieoczekiwanie.
Alarm obudził cię w środku nocy.
A może po prostu jesteś ciekawy, jak działa ta platforma.
Cokolwiek cię tu sprowadziło, wiedz:
Ten projekt został zbudowany dokładnie dla takich chwil.
Nie po to, by usuwać trudne problemy.
Lecz po to, by trudne problemy uczynić zrozumiałymi.
Znajdziesz kod.
Znajdziesz dokumentację.
Znajdziesz specyfikacje.
Ale co ważniejsze:
Mam nadzieję, że znajdziesz uzasadnienia.
Ktoś przed tobą zadawał trudne pytania.
Ktoś zbierał dowody.
Ktoś podejmował decyzje.
Ktoś wyjaśniał dlaczego.
Te wyjaśnienia są częścią platformy.
Traktuj je z tym samym szacunkiem, co kod źródłowy.
Pewnego dnia coś ulepszysz.
Może to będzie drobny błąd.
Może to będzie całkiem nowa funkcjonalność.
Cokolwiek zmienisz, pamiętaj: Kiedyś inna osoba przejmie twoją pracę.
Zostaw jej więcej niż działające oprogramowanie.
Zostaw jej zrozumienie.
Wyjaśnij swój zamysł.
Udokumentuj swoje założenia.
Zachowaj swoje dowody.
Opowiedz historię stojącą za decyzją.
Ta historia może pewnego dnia oszczędzić komuś godzin - lub dni - dochodzenia.
Nie bój się zastępować technologii.
Zastępuj biblioteki.
Zastępuj dostawców.
Zastępuj modele wdrożeń.
Zastępuj języki programowania.
Zastępuj architektury, jeśli to konieczne.
Lecz zanim zastąpisz ideę, zrozum, dlaczego istniała.
Postęp bez zrozumienia to jedynie zmiana.
Postęp zbudowany na zrozumieniu staje się rozwojem.
Będą chwile, gdy platforma cię zaskoczy.
Traktuj te chwile jak dary.
Każde zaskoczenie ukazuje coś, czego architektura jeszcze nie zrozumiała.
Badaj cierpliwie.
Zbieraj dowody.
Ulepszaj przemyślanie.
I zostaw wynikającą z tego lekcję dla tych, którzy przyjdą po tobie.
Tak rośnie wiedza inżynierska.
Będą też chwile, gdy nic interesującego się nie wydarzy.
Te chwile też się liczą.
Ciche systemy są często zdrowymi systemami.

Jeśli COCO odchodzi w cień,
ponieważ incydenty stają się krótsze,
ponieważ wyjaśnienia stają się jaśniejsze,
ponieważ wdrażanie nowych osób staje się łatwiejsze,
ponieważ inżynierowie ufają dowodom, wtedy platforma odnosi sukces.
Niewidzialna niezawodność jest jedną z najwyższych form doskonałości technicznej.
Nie mierz tego projektu liczbą automatyzacji, które wykonuje.
Mierz go pytaniami takimi jak te:

• Czy ludzie są rzadziej przerywani?
• Czy inżynierowie rozumieją systemy głębiej?
• Czy ważne decyzje łatwiej wyjaśnić?
• Czy wiedza operacyjna przetrwa zmiany zespołu?
• Czy błędy powtarzają się rzadziej?
• Czy nowi inżynierowie stają się skuteczni szybciej?

To są rezultaty warte zachowania.
Na koniec pamiętaj: Żaden podręcznik nie jest kompletny.
Żadna specyfikacja nie przewiduje każdej przyszłości.
Żadna architektura nie przetrwa na zawsze niezmieniona.
To nie jest słabość.
To jest zaproszenie.
Obserwuj rzeczywistość.
Kwestionuj założenia.
Ulepszaj platformę.
Ucz tych, którzy przyjdą po tobie.
A gdy twój własny czas jako opiekunki lub opiekuna pewnego dnia się skończy, zostaw system, który jest spokojniejszy, jaśniejszy, bardziej zrozumiały, i bardziej godny zaufania niż ten, który przejąłeś.

Jeśli każde pokolenie to zrobi, COCO nigdy naprawdę się nie zestarzeje.
Ponieważ jego największym kapitałem nie będzie jego oprogramowanie.
Będzie nim dyscyplina inżynierska przenoszona przez ludzi, którzy dalej ją budują.
Dziękuję, że stałeś się jednym z nich.
Następny rozdział nie znajduje się już w tym podręczniku.
Następny rozdział znajduje się w kodzie, który zaraz napiszesz.

Podręcznik COCO

Bo oprogramowanie się rozwija.
Dobra architektura rozwija się wolniej.
A dobra filozofia powinna przetrwać obie.

softify.pro