Jeśli ten tekst opisowy działa dla twojej organizacji, wspaniale, ale znajdź jakiś odpowiedni tekst opisowy, który będzie działał dla twojej organizacji.
david rein
david rein13 mar, 11:08
„WTBU” to jedna z najprzydatniejszych technologii komunikacyjnych, jakie znam. Oznacza „Watch Team Back-Up”, wierzę, że powstała, aby zredukować błędy na okrętach podwodnych. Dodajesz to na początku wiadomości do kogoś, gdy wskazujesz na coś, co może być oczywiste, ale chcesz sprawdzić/potwierdzić, że są tego świadomi. Na przykład, możesz powiedzieć „WTBU: sprawdziłeś, że możemy podzielić się tymi informacjami z osobą XYZ?” To usuwa presję/ego z wiadomości, pozwalając ci komunikować coś w stylu „Nie mówię tego, ponieważ myślę, że jesteś niekompetentny/głupi, więc zignoruj to, jeśli nie jest to istotne/przydatne — po prostu naprawdę chcę upewnić się, że nie popełnimy błędów/nie zrobimy głupich pomyłek, a mądrzy/kompetentni ludzie mogą popełniać głupie błędy!” — z wyjątkiem tego, że gdy już skoordynujesz używanie liter WTBU do komunikacji, możesz po prostu powiedzieć „WTBU:”. To pozwala ci teraz znacznie łatwiej sprawdzać podstawowe/oczywiste rzeczy z współpracownikami, z mniejszym ego/emocjami, co znacznie ułatwia wychwytywanie błędów z wyprzedzeniem. Warto rozważyć wprowadzenie tego do swojej organizacji jako standardowej praktyki komunikacyjnej!
(Japońscy inżynierowie salarymen są zanurzeni w kulturze potwierdzania, potwierdzania, potwierdzania, a chociaż wymaga to trochę przyzwyczajenia, naprawdę to docenisz podczas wszystkich incydentów, których nie masz.)
(Inna technologia organizacyjna, którą możesz tam ukraść: jeśli młodszy inżynier zadaje "głupie pytanie", najstarszy inżynier obecny powinien powtórzyć to głupie pytanie. W końcu to nie jest głupie pytanie, jeśli ma je starszy inżynier.)
(25-letni: "... Czy to jest produkcja?" Starszy inżynier, szybko: "CZY TO JEST PRODUKCJA.")
(Ogólnie rzecz biorąc, powinieneś uczynić narzędzia odpornymi na ten błąd, ale ponieważ wiele organizacji tego nie robi lub korzysta z dostawców, którzy nie ułatwiają tego, problem polega na tym, że czasami polecenia przeznaczone do uruchomienia w środowiskach deweloperskich lub testowych są uruchamiane w środowisku produkcyjnym.)
(Ugryza więcej niż kilka organizacji każdego roku, z powodu 25-latka, który widzi słowo "produkcja" w terminalu i myśli "To dziwne, nie spodziewałem się dotykać produkcji w tej procedurze.")
"Można też po prostu nie mieć kultury hierarchicznej." Powodzenia/wszystkiego najlepszego dla wszystkich w kwestii projektowania kultury organizacyjnej, ale jeśli ktoś nie jest w zaprzeczeniu, że faktycznie ma kulturę hierarchiczną, można zaprojektować procesy, które uwzględniają ten fakt i wykorzystują go pozytywnie.
Przy okazji, na początku 2026 roku mamy syntetycznych 25-latków na wyciągnięcie ręki przez API, ale nasze terminale jeszcze nie mają ciągłego pasywnego wykrywania anomalii, co _wydaje się być okazją_ (i/lub błędem).
Terminale to nie jedyne miejsce, w którym możemy nieustannie wychwytywać błędy operatorów. Innym trywialnym przykładem są dostawcy usług e-mail. Powinno być o 95% mniej prawdopodobne, że wyślą błędnego e-maila masowego, biorąc pod uwagę zdolność LLM do przeglądania każdej prośby za pomocą promptu wielkości tweeta.
"bob właśnie próbował wysłać wiadomość o wielkości 400 bajtów do Wszystkich Klientów Zrewidowane Zrewidowane Ostateczne [500 000 adresów] z tematem 'TEST: Nowa polityka prywatności.' W jednym słowie, oceń Zamiar lub Pomylka, rozważając to z perspektywy tego użytkownika."
(Jeśli nie masz przynajmniej pięciu miejsc na myśli, gdzie to jest trywialnie wdrażalne, poproś swojego syntetycznego 25-latka, aby przeczytał ostatnie N lat raportów po działaniu i zasugerował uporządkowaną listę. Lub prawdziwego 25-latka! To również dobry sposób na spędzenie czasu.)
(Jeśli martwisz się o dokładność, włącz tryb doradczy/kanarkowy i zacznij wprowadzać raporty po działaniu, czy kanarek ćwierkał, czy nie. Za sześć miesięcy powinieneś mieć przytłaczającą pewność, czy jest wystarczająco użyteczny, aby na chwilę zablokować człowieka.)
(Zmęczenie alertami to prawdziwa rzecz, ale to dlatego, że większość naszych narzędzi do alertów jest *głupia*, ponieważ nie wymagaliśmy, aby były inteligentne.)
97