Test Steve’a: czy ta praca zasługuje na istnienie?

Wcześniej w tym tygodniu zakończyłem jeden fragment pracy, w którym właściwą decyzją była odmowa wdrożenia. Potok tłumaczeń zapisuje treści tej witryny do Cloudflare D1 dla dziesięciu wersji językowych. Trzy zadania tłumaczeniowe jednocześnie trafiły na limit żądań; mechanizm awaryjny po cichu zapisał angielskie źródło w D1 jako „tłumaczenie” dla sześciu z tych wersji, a następnie zaktualizował hashe punktów kontrolnych tak, by pasowały do angielskiej treści. Na dysku wyglądało to jak sukces. Potok zgłosił „ukończono”. Metryka mówiła, że wdrożono dziesięć wersji językowych. Każda automatyczna kontrola przeszła.

Niemiecki czytelnik trafiający na /de/guides/claude-code zobaczyłby akapit po niemiecku, akapit po angielsku, kolejny akapit po niemiecku i nagłówek sekcji po angielsku. Żaden znacznik nie wyjaśniałby tych przejść. Strona wyglądała, jakby tak miała wyglądać, a przez to cała witryna sprawiała wrażenie niewiarygodnej: jak produkt, który prawdopodobnie zawiódłby też we wszystkim innym, do czego miał służyć. Test Jiro (czy praca jest poprawna?) przeszedł na każdej warstwie, którą opomiarowałem. A mimo to ta rzecz nie zasługiwała na istnienie. Wyglądała jak produkt, a zachowywała się jak obelga.

Właściwa odpowiedź była prosta: zatrzymać się, przejrzeć każdą partię z angielskim tekstem awaryjnym, precyzyjnie wyczyścić hashe punktów kontrolnych, uruchamiać potok tłumaczeń po jednym zadaniu naraz, zweryfikować wersję po wersji, zrobić commit, zrobić push. Około sześciu godzin czasu zegarowego na tłumaczenia i jedna poprawka ochronna, żeby sytuacja się nie powtórzyła. Artefakt na dysku przez cały czas „działał”. Artefakt w produkcji był szkodą, którą sam wyrządziłem.

Kształt tej porażki jest taki sam niezależnie od tego, czy artefaktem jest potok tłumaczeń, ścieżka rejestracji, przełącznik funkcji, eksport CSV czy strona marketingowa. Każda automatyczna kontrola przechodzi. To, co trafia przed prawdziwego użytkownika, jest szkodą.

Nadrzędne pytanie w pracy nad produktem nie brzmi: Czy to jest skończone? ani Czy to działa? Nadrzędne pytanie brzmi: Czy ta praca zasługuje na istnienie? Każdy artefakt musi odpowiedzieć na nie przed wdrożeniem, obok osobnego testu poprawności. Poprawność bez wartości tworzy zapasy: rzeczy, które działają, trafiają do produkcji i nie zdobywają zaufania użytkownika. Wartość bez poprawności tworzy teatr: rzeczy, które sprawiają dobre wrażenie i się psują. Oba testy muszą przejść.

Mój skrót to Test Steve’a. Stoi obok Testu Jiro, który pilnuje rygoru i dowodów. To dwa różne pytania zadawane przez ten sam umysł, a ja nie wdrażam pracy, która oblewa którekolwiek z nich.

TL;DR

Test Steve’a to drugi test, który musi przejść każdy artefakt. Jiro pyta, czy praca jest poprawna; Steve pyta, czy praca zasługuje na istnienie jako część całości, którą się buduje. Ten test jest konkretny, nie abstrakcyjny. Mierzy wobec prawdziwego użytkownika w prawdziwym momencie, a jego najczęstszym wynikiem jest odmowa. Ograniczam zakres. Usuwam funkcje. To, co zostaje, musi móc nosić moje nazwisko. Oba testy muszą przejść. Jeśli Jiro oblewa, należy się zatrzymać i naprawić. Jeśli Steve oblewa, trzeba przebudować. Limitem są trzy uczciwe przebudowy; potem problem leży wcześniej, w sposobie ujęcia sprawy.

Dlaczego „czy to jest skończone?” to złe pytanie

Większość zespołów produktowych optymalizuje pod możliwość wdrożenia. Mierzalne wyniki to commity, wdrożenia, wykresy tempa pracy, obecność czegoś w produkcji. Tryb porażki jest przewidywalny: zespoły wytwarzają stały strumień artefaktów, które działają poprawnie i po cichu zużywają zaufanie użytkowników. Onboarding się kończy, druga sesja nigdy się nie wydarza. Zgłoszenia do obsługi klienta skupiają się wokół zadań, które produkt rzekomo obsługuje. Krzywa odpływu użytkowników opada ku zeru, zamiast wypłaszczyć się wokół rdzenia.

Skończone i warte istnienia to różne miary. Funkcja może być skończona i nie zasługiwać na istnienie. Strona może się renderować i obrażać czytelnika. Tłumaczenie może technicznie istnieć i w praktyce być kłamstwem. Test skończenia sprawdza, czy coś wykonuje określone zachowanie. Test tego, czy coś zasługuje na istnienie, sprawdza, czy prawdziwy użytkownik w prawdziwym momencie jest w lepszej sytuacji dlatego, że to zostało wdrożone.

Mój argument w Minimalnym produkcie godnym wydania jest taki, że kultura MVP w praktyce zlała dwa pytania w jedno: ucz się szybko zdegradowało się do wdrażaj szybko, a samo wdrażanie stało się metryką, która miała znaczenie.⁷ Lekarstwem jest podwójny standard. Minimum ogranicza zakres. Godne wydania utrzymuje pozostałą powierzchnię na poziomie, który użytkownik może odczuć. Test Steve’a to narzędzie używane wtedy, gdy trzeba rozstrzygnąć, czy ta pozostała powierzchnia przekroczyła próg.

Pytanie nadrzędne

Czy ta praca zasługuje na istnienie?

Używam tego pytania dosłownie. Kiedy kończę fragment pracy i muszę zdecydować, czy go wdrożyć, zadaję je na głos. Odpowiedź jest werdyktem, nie nastrojem. Jeśli brzmi „tak”, praca kwalifikuje się do wdrożenia, a następne pytanie dotyczy tego, czy przechodzi również Test Jiro w zakresie poprawności. Jeśli brzmi „nie”, pracę trzeba przebudować albo usunąć. Jeśli odpowiedź brzmi jeszcze nie, ale będzie po zdefiniowanym ruchu naprawczym, należy pracować dalej.

Pytanie działa tylko wtedy, gdy odpowiedź może brzmieć nie. Test Steve’a, który automatycznie zatwierdza wszystko, co ma przed sobą, nie jest testem. Sygnałem, że test naprawdę działa, jest to, że część pracy go oblewa.

Biegun użytkownika: zasadność istnienia nigdy nie jest abstrakcyjna

Test Steve’a oblewa w chwili, gdy staje się rozmową o guście wobec pracy rozpatrywanej w izolacji. To, czy praca zasługuje na istnienie, należy mierzyć wobec konkretnego użytkownika w konkretnym momencie. Właściwie sformułowane pytanie brzmi: Czy ta praca zasługuje na istnienie dla tego użytkownika w tym momencie?

Dla blakecrosley.com użytkownikiem jest czytelnik trafiający z wyszukiwarki bez wcześniejszego kontekstu, z pytaniem dotyczącym Claude Code, Codex albo infrastruktury. Moment to pierwsze pięć sekund po załadowaniu strony, zanim strona zdąży zasłużyć na jakiekolwiek zaufanie. Strona, która ładuje się szybko, czytelnie przedstawia swój punkt widzenia i mówi czytelnikowi coś, czego jego wyszukiwanie jeszcze nie wyjaśniło, przekroczyła próg. Strona, która karze go powolnym pakietem JavaScript, banerem cookies bez możliwości zamknięcia i ścianą generycznego tekstu uformowanego pod SEO, oblała, niezależnie od tego, jak dobrze wypada na osi Jiro.

Dla ResumeGeni użytkownikiem jest osoba szukająca pracy w momencie, który traktuję jako wrażliwy. Większość pierwszej listy oczekujących trafiła tam po zwolnieniu albo w trakcie cyklu rozmów kwalifikacyjnych.⁶ Wersja godna istnienia odmawia traktowania takich osób jako metryki konwersji. Tekst nie kluczy. Parser nie kłamie o tym, co znalazł. Porady są na tyle konkretne, że można na ich podstawie działać. Przepływ nie porzuca użytkownika w połowie procesu tylko dlatego, że wdrożona została wyłącznie optymistyczna ścieżka.

Biegun użytkownika to kontrola, która chroni Test Steve’a przed przemianą w schowek na moje własne preferencje. Jeśli nie potrafię nazwać użytkownika, nazwać jego momentu i wyjaśnić, jak wdrożona powierzchnia go szanuje i wzmacnia, nie zastosowałem testu. Tylko go zadeklarowałem.

Podwójny test: Jiro plus Steve

Pełna doktryna wymaga dwóch testów, nie jednego.¹ Nie wdrażam niczego, co oblewa którykolwiek z nich.

Test Jiro pyta: Czy to jest zrobione poprawnie? Wymaga dowodów. Obsłużonych przypadków brzegowych. Dokończonych niewidocznych szczegółów. Twierdzeń opartych na konkretnych potwierdzeniach. Bez asekuracji: wierzę nie jest dowodem. Testy przechodzą. Nie ma regresji. Próg dowodowy to wersja Testu Jiro, którą stosuję wobec raportów kodu i wyników agentów, a filozofia jakości Jiro jest głębszym opracowaniem.

Test Steve’a pyta: Czy ta praca zasługuje na istnienie? Wymaga wartości. Spójności z całością. Widocznego punktu widzenia. Nazwanej odmowy albo usunięcia, które utrzymało powierzchnię w czystości. Mechanizmu zachwytu albo klarowności, który czytelnik potrafi wskazać, a nie tylko opisać machnięciem ręki. Gotowości, by praca nosiła nazwisko autora.

Arbitraż jest prosty. Jeśli Jiro oblewa, należy się zatrzymać i naprawić. Niepoprawna praca nie trafia do produkcji; weto Jiro jest absolutne. Jeśli Jiro przechodzi, a Steve oblewa, trzeba przebudować. Poprawna, ale niewarta wdrożenia praca również nie trafia do produkcji. Jeśli oblewają oba, problem leży wcześniej: w briefie, ujęciu albo zakresie. Do wdrożenia kwalifikuje się tylko praca, która przechodzi oba testy.

Większość kultur wdrażania po cichu uruchamia tylko jeden z dwóch testów. Kultury prowadzone przez inżynierię często mają silnego Jiro i słabego Steve’a: produkt trafia do produkcji, kiedy testy przejdą, a wartość staje się sprawą innego działu. Kultury prowadzone przez design czasem mają silnego Steve’a i słabego Jiro: produkt trafia do produkcji, kiedy wygląda właściwie, a poprawność staje się problemem operacyjnym. Oba tryby porażki produkują rozpoznawalne artefakty. Piękne bzdury. Poprawną, ale bezduszną pracę. Wszyscy je znają. Być może zdarzyło się je wdrożyć.

Te dwa testy stoją obok siebie:

Całość produktu: odpowiada się za pełne doświadczenie

Test Steve’a nie ocenia artefaktów w izolacji. Ocenia je jako część całego doświadczenia, na które natrafia użytkownik.

Incydent z tłumaczeniami, od którego zacząłem, jest najczystszym świeżym przykładem. Warto rozpisać konkretny mechanizm porażki, bo pokazuje kształt pułapki. Mechanizm awaryjny potoku zapisał angielskie źródło do D1, kiedy podproces Claude trafił na limit żądań. Moduł zapisujący do D1 przyjął te bajty, bo były bajtami. Aktualizator punktów kontrolnych obliczył hash zapisanej treści i zapisał ten hash na dysku. Ponieważ zapisane „tłumaczenie” było identyczne z angielskim źródłem, hashe zgadzały się dokładnie: identyczne bajty dały identyczne hashe. Kolejny przebieg --update porównał hash angielskiego źródła z zapisanym hashem, uznał je za równe i oznaczył partię jako niezmienioną. Każdy komponent osobno przeszedł własny Test Jiro. Defekt ujawnił się dopiero w ich połączeniu. Użytkownik przez wiele godzin widział sześć wersji językowych z mieszaną prozą, zanim człowiek otworzył jedną ze stron.

„Odpowiadamy za całość produktu” to reguła. Zachowanie produktu, ścieżki UX, język, prawda danych, systemy wsparcia, opakowanie, poprawność dokumentacji, prompty, reguły, pamięć, umiejętności, hooki, skrypty, orkiestracja, struktura wyniku. Wszystko, nie tylko artefakt wdrożony najpóźniej. Żadne lokalne zwycięstwo nie jest akceptowalne, jeśli obniża integralność całości. Test Steve’a uruchamia się wtedy, gdy powierzchnia przechodzi lokalnie, a pełne doświadczenie użytkownika nie.

Usuwanie: warstwa Steve’a, która tylko dodaje, jest fałszywa

Najbardziej użyteczną rzeczą, jaką produkuje Test Steve’a, jest usunięcie.

Przegląd, który kończy się bez usunięcia czegokolwiek, tak naprawdę się nie odbył. Zadanie pytania Czy ta praca zasługuje na istnienie? wobec powierzchni o realnej złożoności prawie zawsze ujawnia przynajmniej jeden kawałek zakresu, tekstu, funkcji albo elementu interakcji, który nie potrafi obronić swojej obecności. Przegląd, który nie znajduje ani jednego takiego elementu, jest zwykle przeglądem wykonywanym dla pozoru, nie w praktyce.

Czego Test Steve’a szuka konkretnie:

• Powierzchni, które istnieją dlatego, że wydawały się bezpieczne do dodania, a nie dlatego, że zasługują na swoje miejsce.
• Tekstu, który się asekuruje, bo usunięcie asekuracji wymagałoby prawdziwego twierdzenia.
• Funkcji przeniesionych z poprzedniej wersji, które nie służą już obecnej obietnicy.
• Elementów interakcji dodanych do obsługi przypadków brzegowych, które w obecnym zakresie tak naprawdę nie występują.
• Opcji konfiguracyjnych, które przerzucają decyzję, którą powinien był podjąć twórca.
• Dokumentacji opisującej zachowanie, którego produkt już nie ma.
• Testów pokrywających kod, który powinien zostać usunięty.

Usuwanie jest aktem odróżniającym wyczucie od akumulacji. Powierzchnia godna wdrożenia jest mniejsza niż wersja, którą wdrożono by bez zadania pytania. Nigdy nie żałowałem usunięcia czegoś z wdrożonego produktu. Regularnie żałowałem tego, co zostawiłem.

Odmowa jako główny akt

Z usuwaniem wiąże się coś silniejszego: Test Steve’a często uruchamia się przed budową czegokolwiek, nie po niej. Głównym aktem wyczucia jest odmowa: decyzja, żeby w ogóle nie robić danej rzeczy.

Ważne zdanie Steve’a Jobsa brzmi tutaj: „Jestem tak samo dumny z tego, czego nie robimy, jak z tego, co robimy”, przytoczone w okładkowym tekście BusinessWeek z 2006 roku o dyscyplinie produktowej Apple.⁵ Ludzie często cytują to zdanie, bo jest prawdziwe w konkretny techniczny sposób. Każdy wdrożony produkt otacza niewidzialna aureola produktów, których odmówiono wdrożyć. Ta aureola jest właściwym punktem widzenia. To dowód, że decyzję podjął człowiek, a nie backlog.

W przypadku blakecrosley.com stos jest zapisem tego, co przyciąłem. Rozważałem React i odmówiłem. Rozważałem Tailwind i odmówiłem. Bundler leżał na stole przez pierwsze dwa tygodnie przebudowy, zanim go wyciąłem. Brak node_modules/ gdziekolwiek w repozytorium nie jest wyborem projektowym; to odmowa, którą utrzymuję w czasie przeciw grawitacji domyślnych narzędzi. Te odmowy kształtują pracę bardziej niż jakiekolwiek dodanie. Definiują standard, którego byłem gotów pilnować.

W przypadku ResumeGeni walidacja wróciła czysta. Trzysta czterdzieści zapisów e-mail, dwanaście bezpośrednich zapytań, trzy nieproszone oferty zapłaty za wczesny dostęp.⁶ Backlog ujawniony przez ten popyt był duży: szablony, współpraca zespołowa, panele analityczne, integracja z LinkedIn, integracja z Indeed, historia wersji, wiele formatów eksportu, aplikacja mobilna. Odmówiłem tego wszystkiego w pierwszej wdrożonej wersji. Nie mogłem odmówić dokładnego parsowania, uczciwej oceny luk, konkretnych przeredagowań dopasowanych do opisu stanowiska, eksportu otwierającego się czysto w Wordzie i przepływu, który daje wrażliwemu użytkownikowi poczucie bezpieczeństwa. Rzeczy odrzucone nie zniknęły na zawsze. Czekają po drugiej stronie pierwszej powierzchni godnej wydania.

Powierzchnia, która niczego nie odmawia, nie ma punktu widzenia. Jeśli zespół niczego nie odmówił, zakres jest zły.

Nazywać fałsz wcześnie, najpierw u siebie

Odmowa i usuwanie działają tylko wtedy, gdy test potrafi nazwać fałszywy sukces, kiedy ten się pojawia. Test Steve’a musi szybko nazywać fałsz w przypadku:

• Pozornego postępu. Ruchu, który wygląda jak postęp i niczego nie wytwarza.
• Skażonych dowodów. Testu, który przechodzi z niewłaściwego powodu; statystyk, które dowodzą tego, co chciano udowodnić, a nie tego, co było prawdą.
• Liczenia próżnościowych metryk. Liczby commitów, liczby wdrożonych artefaktów, wykresy tempa pracy: wszystko obecne, wszystko obok sedna.
• Niespójnych systemów, które osobno wdrażają się czysto, a razem wzajemnie się degradują. Incydent z tłumaczeniami powyżej jest jednym z nich.
• Raportów „wszystko idzie zgodnie z planem”, które przykrywają decyzję, której nikt nie podjął. Test Steve’a jest ich wrogiem.
• Maszynowej aktywności o niskiej wartości. Pracy, którą komputer wykonuje, bo może, a nie dlatego, że wynik zasługuje na miejsce.

Najtrudniejsza i najbardziej konsekwentnie użyteczna wersja reguły brzmi: najpierw nazwać fałsz we własnym wyniku. Incydent tłumaczeniowy z początku tego eseju jest dokładnie tym. Potok zgłosił sukces. Logi były czyste. Każda opomiarowana przeze mnie metryka przeszła. Praca była fałszywym sukcesem i musiałem nazwać to sam, zanim zrobiliby to użytkownicy. Bezwzględne sprawdzanie własnej pracy pod kątem fałszu to dyscyplina, która utrzymuje test w uczciwości. Uprzejmość nie jest tarczą przed prawdą; zajętość nie zastępuje wartości.

Gradient obszarów: kalibracja progu

Test Steve’a nie jest jednym przejściem z jednym progiem. Im trudniej wycofać powierzchnię, tym mocniejszy musi być próg zaliczenia.²

Pytanie jest to samo. Rygor odpowiedzi rośnie wraz z promieniem rażenia. Odpowiedź na czacie można poprawić w następnej turze; nikt nie ginie. Wdrożenie produkcyjne, które oblewa Test Steve’a, spala zaufanie użytkownika budowane miesiącami, a naprawa kosztuje więcej niż zaoszczędziła pierwotna decyzja o wdrożeniu.

Praktyczna konsekwencja jest taka, że tempo wdrażania powinno zwalniać, gdy obszary stają się trudniejsze do odwrócenia, a nie przyspieszać. Zespoły wdrażające z jednolitą prędkością na powierzchniach o bardzo różnej odwracalności sygnalizują, że nie uważają testu za zmienny. Zwykle przestały go uruchamiać.

Wyczucie to nie temperament

Test Steve’a wymaga jeszcze jednego rozróżnienia, bo właśnie ono najczęściej ginie. Przywoływanie Steve’a oznacza przywoływanie jego wyczucia, nie temperamentu.

Doktryna jawnie zakazuje następujących rzeczy:³

• Okrucieństwa.
• Upokarzania.
• Teatralnej pogardy.
• Odgrywania wizjonera.
• Agresji jako substytutu osądu.
• Teatralnego pielęgnowania urazy.
• Dramatu mylonego ze standardami.

Sygnałem, że warstwa Steve’a rzeczywiście działa, jest spokojna odmowa. „Nie, ta praca nie jest jeszcze godna” wypowiedziane jako werdykt, a potem uzupełnione konkretnym ruchem naprawczym. Nie występ. Nie upokorzenie osoby, która zbudowała niegodną wersję, często samego siebie. Nie widoczna pogarda wobec zespołu. Nie nadawanie komunikatu, że ma się wyższe standardy. Praca albo przekracza próg, albo nie. Próg nie jest estetyką surowości.

To rozróżnienie ma znaczenie, bo karykaturalna wersja Steve’a Jobsa skupia się na temperamencie. Każdy, kto był zarządzany przez osobę odgrywającą Steve’a, wie, o co chodzi. Okrucieństwo nie poprawia pracy. Pogarsza miejsce pracy, a ponieważ zastępuje osąd teatrem, pogarsza też to, co trafia do produkcji.

Operacyjny test odróżniający warstwę wyczucia Steve’a od odgrywania temperamentu Steve’a brzmi: czy wynikiem testu jest konkretny ruch techniczny. „Ta praca nie zasługuje na istnienie” nie jest wnioskiem; to początek pytania. Odpowiedź musi nazwać oś, która oblała, ruch naprawczy i następny test. Jeśli przegląd kończy się na „praca jest zła”, bez wskazania, co uczyniłoby ją godną, przegląd był występem.

Limit przebudów i klauzula antyparaliżu

Wysoki standard bez reguły zatrzymania staje się unikaniem. Dyscyplina, którą stosuję wobec każdego nietrywialnego kawałka pracy, ma limit trzech uczciwych prób przebudowy.

Uczciwa próba oznacza, że zidentyfikowano oś porażki, nazwano konkretny ruch naprawczy, materialnie zmieniono podejście i ponownie oceniono pracę wobec obu testów. Trzy powtórzenia tej samej rundy wygładzania nie liczą się jako trzy próby. Liczą się jako jedna nieudana próba powtórzona trzy razy.

Po trzech uczciwych przebudowach, które nie dają pracy godnej wdrożenia, problem prawie nigdy nie leży w rzemiośle. Problem mieszka wcześniej: w ujęciu, zakresie, briefie albo składzie zespołu. Należy przestać przebudowywać powierzchnię i spojrzeć na założenie. Czasem obietnica była zbyt duża wobec zakresu, który realistycznie da się utrzymać w standardzie. Czasem walidacja była miększa, niż się wydawało. Czasem problem w ogóle nie jest problemem produktowym.

Limit przebudów rozwiązuje dwa przeciwne tryby porażki jednocześnie. Nie błogosławi słabej pracy i nie pozwala, by dopracowywanie stało się chowaniem. Odmowa wdrożenia nie jest sama w sobie cnotą. Niekończąca się przebudowa w pogoni za perfekcją to własny tryb porażki: rzemiosło bez odwagi. Celem nie jest perfekcja. Celem jest godne i wdrożone. Nie czyste i wiecznie oczekujące.

Jeśli ktoś jest przy czwartej przebudowie tej samej powierzchni, przestał robić produkt i zaczął używać projektu jako miejsca do ukrycia się.

Obserwowalne sygnały: czy test naprawdę został przeprowadzony?

Test Steve’a łatwo zadeklarować i trudno naprawdę przeprowadzić. Dyscyplina polega na konkretnym nazwaniu tego, co test wytworzył.

Zanim uznam nietrywialny kawałek pracy za skończony, upewniam się, że potrafię odpowiedzieć na wszystkie poniższe pytania:⁴

1. Kim jest użytkownik? Nie archetyp persony. Prawdziwa osoba w prawdziwej sytuacji.
2. Jaki punkt widzenia niesie ta powierzchnia? Jeśli nie da się go nazwać, nie ma punktu widzenia, jest tylko backlog.
3. Czego odmówiono albo co usunięto, żeby utrzymać czystość? Usunięcie jest dowodem, że test został uruchomiony.
4. Jak to służy całości produktu? Element musi być spójny z każdym innym elementem. Lokalne zwycięstwa degradujące całość nie są zwycięstwami.
5. Jakie dowody potwierdzają, że to jest solidne? Oś Jiro. Weryfikacja została uruchomiona; twierdzenie ma poparcie.
6. Dlaczego to jest godne? Odpowiedź powinna paść wprost. Jeśli jest mglista, test się nie odbył.
7. Czy podpisałbym to swoim nazwiskiem bez wahania? Ostateczny test wyczucia. Gdy osąd jest niepewny, najważniejsze pytanie w całym zestawie.

Jeśli nie potrafię odpowiedzieć na wszystkie siedem konkretnie, zadeklarowałem doktrynę zamiast ją zastosować. Odsyłam pracę z powrotem.

Przykład roboczy: siedem sygnałów wobec prawdziwej powierzchni

Oto sygnały zastosowane do jednej konkretnej powierzchni wdrożonej po incydencie z tłumaczeniami: blokady współbieżności, którą dopisałem do potoku tłumaczeń. Około 100 wierszy Pythona, które odmawiają uruchomienia guide_bootstrap.py albo blog_translate_batch.py, jeśli inny proces tłumaczeniowy już działa.

1. Kim jest użytkownik? Ja na początku przebiegu tłumaczeniowego za dwa tygodnie, kiedy zapomnę już dokładny tryb porażki limitu żądań, który spalił sześć wersji językowych. Także każdy agent, który wywoła którykolwiek skrypt w przyszłej sesji.
2. Jaki punkt widzenia niesie ta powierzchnia? Równoległe przebiegi tłumaczeń nigdy nie są właściwym narzędziem. Blokada zapisuje ten werdykt w kodzie, żeby kolejny wywołujący nie musiał go pamiętać.
3. Czego odmówiłem albo co usunąłem, żeby utrzymać czystość? Odmówiłem zrobienia z blokady ostrzeżenia. Odmówiłem krótkiej, wygodnej flagi obejścia w rodzaju --force. Jedynym obejściem jest zmienna środowiskowa, I18N_ALLOW_CONCURRENT=1, na tyle długa, żeby nikt nie wpisał jej przypadkiem.
4. Jak to służy całości produktu? Potok tłumaczeń, moduł zapisujący do D1 i mechanizm awaryjny są osobno poprawne. Blokada jest elementem, który nie pozwala im połączyć się w całość po cichu powodującą uszkodzenie.
5. Jakie dowody potwierdzają, że to jest solidne? Zweryfikowałem blokadę dwoma ręcznymi kontrolami. Pierwsza: czysty powrót, gdy nie działa żadne inne zadanie tłumaczeniowe. Druga: niezerowy kod wyjścia, gdy żywy jest prawdziwy podproces guide_bootstrap.py. Obie kontrole działały na faktycznych skryptach, nie na mockach.
6. Dlaczego to jest godne? Ten sam wyścig równoległych przebiegów, który uszkodził sześć wersji językowych, nie może wytworzyć mieszanych językowo wierszy D1, gdy blokada jest na miejscu. To nie jest zapobieganie wszystkim przypadkom; to zapobieganie konkretnemu trybowi porażki, którego doktryna właśnie się nauczyła.
7. Czy podpisałbym to swoim nazwiskiem? Tak. Jedno zadanie, czysta semantyka obejścia, udokumentowane w notatce w pamięci, żeby przyszła sesja odziedziczyła powód istnienia blokady.

Sens przykładu polega na tym, że każdy sygnał ma konkretną odpowiedź. Jeśli nie potrafię jej podać, test jeszcze się nie odbył.

Dla kontrastu warto zobaczyć, jak wygląda porażka. Kiedy szkicowałem blokadę współbieżności, moja pierwsza próba odpowiedzi na punkt 3 brzmiała: „odmówiłem nadmiernego komplikowania”. To zdanie brzmi dobrze i nic nie mówi. Odmowa nadmiernego komplikowania nie nazywa żadnej konkretnej rzeczy, którą rozważyłem i odrzuciłem. To poza, nie odmowa. Zmusiłem się do napisania prawdziwej odpowiedzi: odmówiłem zrobienia z blokady ostrzeżenia; odmówiłem wygodnej nazwy flagi obejścia; odmówiłem zachowania, w którym blokada przepuszczałaby dalej, gdyby nie mogła wylistować procesów. To są decyzje. Pierwsza wersja była teatrem doktryny.

Najważniejsze wnioski

Dla założycieli i osób budujących solo: - Proszę nazwać prawdziwego użytkownika w prawdziwym momencie, zanim jakakolwiek powierzchnia zostanie uznana za godną. Abstrakcyjna wartość jest bezużyteczna. - Każda wdrożona powierzchnia powinna mieć co najmniej jedną widoczną odmowę. Jeśli niczego nie usunięto, zakres jest zły. - Należy stosować gradient obszarów. Wdrożenie produkcyjne wymaga mocniejszego progu niż szkic; twierdzenia marketingowe wymagają najmocniejszego progu ze wszystkich.

Dla liderów produktu i PM-ów: - To, czy Test Steve’a naprawdę działa, można mierzyć liczbą odmów i usunięć na cykl wydawniczy. Zero jest sygnałem ostrzegawczym. - Własne listy przeglądowe powinny rozdzielać „działa” od „zasługuje na istnienie”. To niezależne osie. - Należy chronić budżet przebudów. Trzy uczciwe próby, potem eskalacja. Nie wolno pozwolić, by perfekcjonizm stał się chowaniem ani by presja terminu zabiła test.

Dla liderów inżynierii: - Dla każdej powierzchni wdrażanej przez zespół trzeba nazwać kontrolę Jiro i kontrolę Steve’a. Obie muszą przejść. - Warto inwestować w niewidoczne szczegóły. Różnica między poprawnym a godnym zwykle mieszka na styku elementów. - Należy odmówić temperamentu. Sygnałem jest spokojna odmowa. Odgrywanie surowości jest trybem porażki.

Dla projektantów: - Punkt widzenia nie jest dekoracją. To mechanizm, dzięki któremu produkt staje się rozpoznawalny. - Godna powierzchnia odmawia rzeczy, i to widocznie. Do pracy należy również nazwanie tego, co zostało wycięte. - Test operacyjny w niejednoznaczności: czy można podpisać tę decyzję własnym nazwiskiem bez wahania?

Zamknięcie: czy podpisałbym to swoim nazwiskiem?

Nadrzędne pytanie w pracy nad produktem brzmi: Czy ta praca zasługuje na istnienie? Nadrzędne pytanie, gdy osąd jest niepewny, jest najprostsze w całym zestawie.

Czy podpisałbym to swoim nazwiskiem bez wahania?

Jeśli odpowiedź brzmi tak, praca kwalifikuje się do wdrożenia. Jeśli odpowiedź brzmi „jeszcze nie, ale będzie po maksymalnie trzech uczciwych przebudowach”, należy pracować dalej. Jeśli odpowiedź brzmi nie i pozostaje nie po trzech uczciwych próbach, trzeba przebudować brief, nie powierzchnię.

Uruchamiam ten test za każdym razem. Na kodzie. Na tekście. Na komunikacie commita. Na dokumentacji. Na powierzchni produktu. Na tym eseju.

Ten esej wyciął trzy sekcje, które na początku szkicowania wydawały mi się potrzebne: długą część biograficzną o Jobsie, wprowadzenie do zdania o „odciśnięciu śladu we wszechświecie” oraz obronę tego, dlaczego doktryna używa imienia prawdziwej osoby zamiast abstrakcji. Żadna z nich nie służyła użytkownikowi, dla którego pisałem: osobie budującej produkt i próbującej zdecydować, czy wdrożyć powierzchnię, co do której nie ma pewności. Cięcia uczyniły tekst mniejszym i uczciwszym. A porażka tłumaczeniowa otwierająca esej dała jeden trwały artefakt poza samą poprawką: blokadę współbieżności w potoku tłumaczeń, która teraz odmawia startu, jeśli inne zadanie tłumaczeniowe już działa. Odrzucona praca zmieniła reguły. Doktryna się nauczyła.

Steve przechodzi. Jiro przechodzi. Można publikować.

FAQ

Czym jest Test Steve’a?

Test Steve’a pyta, czy kawałek pracy zasługuje na istnienie dla prawdziwego użytkownika w prawdziwym momencie. Stoi obok filozofii jakości Jiro: Jiro sprawdza poprawność, dowody i przypadki brzegowe; Steve sprawdza wartość, spójność, odmowę i wyczucie.

Czym Test Steve’a różni się od Testu Jiro?

Jiro pyta, czy praca została wykonana poprawnie. Steve pyta, czy poprawna praca w ogóle powinna trafić do produkcji. Funkcja może przejść testy i nadal zawieść użytkownika, produkt albo punkt widzenia stojący za powierzchnią.

Kiedy zespół powinien uruchamiać Test Steve’a?

Należy go uruchamiać przed wdrożeniem powierzchni trudnych do odwrócenia: publicznych wdrożeń, twierdzeń marketingowych, onboardingów, stron cenowych, dokumentacji i funkcji produktu, które będą kształtować zaufanie użytkownika. Lżejsza praca może używać miększego progu, ale powierzchnie publiczne potrzebują rygorystycznego.

Co test powinien wytworzyć?

Test powinien wytworzyć konkretną decyzję: wdrożyć, przebudować, usunąć albo odmówić. Prawdziwe zaliczenie nazywa użytkownika, moment, punkt widzenia, dowody i co najmniej jedną rzecz usuniętą przez zespół w celu ochrony całości.

Czy Test Steve’a może stać się perfekcjonizmem?

Tak. Właśnie dlatego doktryna potrzebuje limitu przebudów. Trzy uczciwe przebudowy wystarczą; potem problem zwykle mieszka wcześniej, w briefie, zakresie, zespole albo założeniu.

Szablon przeglądu

Można wkleić to do notatnika, opisu PR, strony w Notion albo na początek komunikatu commita. Proszę wypełnić przed uznaniem nietrywialnej pracy za skończoną. Jeśli w którymkolwiek wierszu nie da się podać konkretnej rzeczy, test jeszcze się nie odbył.

Test Steve’a: zapis przeglądu

Użytkownik:      [prawdziwa osoba w prawdziwej sytuacji, nie archetyp persony]
Moment:          [konkretny moment, w którym użytkownik napotyka tę pracę]
Punkt widzenia:  [co ta powierzchnia stwierdza; czego odmawia]
Odmowa:          [co rozważyłem i wyciąłem albo czego w ogóle odmówiłem zbudować]
Całość produktu: [jak to spaja się z każdym sąsiednim elementem produktu]
Dowody:          [oś Jiro: weryfikacja została uruchomiona; konkretne potwierdzenie twierdzenia]
Werdykt:         [tak / nie / jeszcze nie w ramach N zdefiniowanych przebudów]
Podpis:          [czy podpisałbym to swoim nazwiskiem bez wahania? jeśli nie, stop]

Ten szablon ma dokładnie jedno zadanie: zmusić osobę testującą do udzielenia konkretnej odpowiedzi w każdym wierszu. Mgliste odpowiedzi nie przekraczają progu. „Odmówiłem nadmiernego komplikowania” nie jest odmową; „odmówiłem wygodnej flagi obejścia i ścieżki, która przepuszcza dalej przy błędzie” jest. „To służy użytkownikowi” nie jest odpowiedzią o całości produktu; „to zamyka konkretną lukę kompozycyjną, która spowodowała ostatni incydent” jest. Gdy wiersz opiera się konkretowi, praca nie jest gotowa; ten opór jest testem wskazującym, dokąd ma iść przebudowa.

Ten szablon jest operacyjnym artefaktem eseju. Wszystko inne na tej stronie wyjaśnia, dlaczego te wiersze istnieją.

Źródła