Wenn dieser Beschreibungstext für eure Organisation funktioniert, wunderbar, aber findet einen entsprechenden Beschreibungstext, der für eure Organisation funktioniert.
david rein
david rein13. März, 11:08
„WTBU“ ist eine der nützlichsten Kommunikationstechnologien, die ich kenne. Es steht für „Watch Team Back-Up“, ich glaube, es wurde entwickelt, um Fehler auf U-Booten zu reduzieren. Man fügt es einer Nachricht an jemanden hinzu, wenn man auf etwas hinweist, das offensichtlich sein könnte, aber man möchte überprüfen/bestätigen, dass sie darüber informiert sind. Zum Beispiel könnte man sagen: „WTBU: Hast du überprüft, dass wir berechtigt sind, diese Informationen mit der XYZ-Person zu teilen?“ Es nimmt den Druck/das Ego aus der Nachricht, indem es dir ermöglicht, etwas in der Art von „Ich sage das nicht, weil ich denke, dass du inkompetent/dumm bist, ignoriere das also, wenn es nicht relevant/nützlich ist – ich möchte nur wirklich sicherstellen, dass wir keine Fehler machen/keine dummen Fehler machen, und kluge/kompetente Menschen können dumme Fehler machen!“ zu kommunizieren – außer wenn du einmal koordiniert hast, die Buchstaben WTBU zu verwenden, um das zu kommunizieren, kannst du einfach „WTBU:“ sagen. Das ermöglicht es dir, grundlegende/offensichtliche Dinge viel einfacher und mit weniger Ego/Emotionen mit Kollegen zu überprüfen, was es viel einfacher macht, Fehler im Voraus zu erkennen. Es lohnt sich, dies als Standardkommunikationspraxis in deiner Organisation zu übernehmen!
(Japanische Gehaltsempfänger und Ingenieure sind in einer Kultur des Bestätigens, Bestätigens, Bestätigens verwurzelt, und während es etwas dauert, sich daran zu gewöhnen, werden Sie es wirklich zu schätzen wissen während all der Vorfälle, die Sie nicht haben.)
(Die andere organisatorische Technologie, die Sie dort stehlen können: Wenn ein Junior-Ingenieur eine "dumme Frage" stellt, sollte der am höchsten rangierte Ingenieur anwesend die dumme Frage wiederholen. Es ist schließlich keine dumme Frage, wenn der Senior-Ingenieur sie hat.)
(25 Jahre alt: "... Ist das Prod?" Senior Engineer, schnell: "IST DAS PROD.")
(Im Allgemeinen sollten Sie Werkzeuge robust gegen diesen Fehler machen, aber da viele Organisationen dies nicht tun oder Anbieter verwenden, die es nicht einfach machen, besteht das Problem darin, dass manchmal Befehle, die für Entwicklungs- oder Testumgebungen gedacht sind, in der Produktionsumgebung ausgeführt werden.)
(Beißt jedes Jahr mehr als ein paar Organisationen, weil ein 25-Jähriger das Wort "Produktion" in einem Terminal sieht und denkt: "Das ist seltsam, ich hätte nicht erwartet, in diesem Verfahren mit Prod in Berührung zu kommen.")
"Man könnte auch einfach keine hierarchische Kultur haben." Viel Glück/Fähigkeit an alle bezüglich des Designs der Organisationskultur, aber wenn man nicht in der Leugnung ist, dass man faktisch eine hierarchische Kultur hat, kann man Prozesse entwerfen, die diese Tatsache berücksichtigen und positiv nutzen.
Übrigens haben wir Anfang 2026 synthetische 25-Jährige, die nur einen API-Aufruf entfernt sind, aber unsere Terminals verfügen noch nicht ständig über passive Anomalieerkennung, was _wie eine Gelegenheit_ (und/oder ein Fehler) aussieht.
Terminals sind bei weitem nicht die einzige Quelle für Bedienfehler, die wir ständig erfassen könnten. Ein weiteres triviales Beispiel sind E-Mail-Dienstanbieter. Es sollte 95 % weniger wahrscheinlich sein, eine fehlerhafte Massen-E-Mail zu versenden, wenn ein LLM in der Lage ist, jede Anfrage mit einem tweet-großen Prompt zu überprüfen.
"Bob hat gerade versucht, eine 400 Byte große Nachricht an Alle Kunden Überarbeitet Überarbeitet Final [500.000 Adressen] mit dem Betreff 'TEST: Neue Datenschutzrichtlinie.' In einem Wort, bewerten Sie Absicht oder Fehler, betrachtet aus der Perspektive dieses Benutzers."
(Wenn man nicht mindestens fünf Orte im Kopf hat, an denen dies trivial umsetzbar ist, sollte man seinen synthetischen 25-Jährigen bitten, die letzten N Jahre an Nachbesprechungsberichten zu lesen und eine rangierte Liste vorzuschlagen. Oder einen echten 25-Jährigen! Auch eine gute Nutzung der Zeit.)
(Wenn Sie sich um die Genauigkeit sorgen, stellen Sie es in den Beratungs-/Canary-Modus und beginnen Sie, Nachaktionsberichte zu erstellen, ob der Canary gezwitschert hat oder nicht. In sechs Monaten sollten Sie überwältigendes Vertrauen haben, ob es nützlich genug ist, um einen Menschen vorübergehend zu blockieren.)
(Alarmmüdigkeit ist eine echte Sache, aber das liegt daran, dass die meisten unserer Alarmierungswerkzeuge *dumm* sind, weil wir sie nicht dazu gebracht haben, intelligent zu sein.)
97