Магазин DApp | Центр Web3 для подій та ігор

Якщо цей flavor text підходить для вашої організації — чудово, але знайдіть якийсь аналогічний flavor-текст, який підійде саме для вашої організації.

«WTBU» — одна з найкорисніших комунікаційних технологій, які я знаю. Це означає «Watch Team Back-Up», я вважаю, що це з'явилося для зменшення помилок на ядерних підводних човнах. Ви напишете повідомлення комусь, де вказуєте на щось, що може бути очевидним, але хочете перевірити/підтвердити, що вони все контролюють. Наприклад, ви можете сказати: «WTBU: ви перевірили, що нам дозволено поділитися цією інформацією з особою з XYZ?» Це знімає тиск/его з повідомлення, дозволяючи комунікувати щось на кшталт: «Я кажу це не тому, що вважаю тебе некомпетентним/дурним, тож ігноруй це, якщо це не доречно/корисно — я просто хочу переконатися, що ми не помиляємося/не робимо дурниць, а розумні/компетентні люди можуть робити дурні помилки!» —хіба що після того, як ви скоординуєте використання літер WTBU для повідомлення, ви можете просто сказати «WTBU:». Це дозволяє набагато легше і з меншою кількістю его/емоцій перевіряти базові та очевидні речі з колегами, що значно полегшує виявлення помилок заздалегідь. Варто розглянути можливість впровадження у вашу організацію як стандартну практику комунікації!

(Японські офіцери-інженери мають культуру підтвердження — підтверджувати, підтверджувати підтвердження, і хоча до цього потрібно трохи звикнути, ви справді оціните це під час усіх інцидентів, яких у вас немає.)

(Ще одна організаційна технологія, яку можна вкрасти: якщо молодший інженер ставить «дурне питання», найстарший інженер має повторити це дурне питання. Адже це не дурне питання, якщо старший інженер це має.)

(25 років: «... Це підштовх?" Старший інженер, швидко: «ЦЕ ПРОД».)

(Зазвичай інструменти мають бути стійкими до цієї помилки, але оскільки багато організацій цього не роблять, або використовують постачальників, які не полегшують роботу, проблема в тому, що іноді команди, призначені для виконання в середовищах розробки чи тестування, виконуються проти продакшну.)

(Кусає більше ніж кілька організацій щороку, якщо 25-річний бачить слово «продакшн» у терміналі і думає: «Це дивно, не очікував торкнутися препарату під час цієї процедури.»)

"Можна також просто не мати ієрархічної культури." Бажаю всім удачі та навичок у сфері організаційного культурного дизайну, але якщо не заперечувати, що у тебе фактично є ієрархічна культура, можна розробити процеси, які враховують цей факт і використовують позитивно.

До речі, на початку 2026 року у нас є синтетичні 25-річні на одному виклику API, але наші термінали ще не мають постійного пасивного виявлення аномалій, що _seems як opportunity_ (або помилка).

Термінали — далеко не єдине місце помилки оператора, яке ми могли постійно виявляти. Ще одна тривіальна проблема — це провайдери електронної пошти. Ймовірність надіслати помилковий blast лист має бути на 95% меншою, враховуючи можливість LLM переглядати кожен запит із підказкою розміром з твіт.

"bob at щойно намагався надіслати повідомлення обсягом 400 байт до All Customers Revised Revised Revised Final [500 000 адрес] з темою 'TEST: Нова політика конфіденційності.' Одним словом, оцініть Задумано чи Помилково, якщо розглядати з точки зору цього користувача."

(Якщо у вас немає хоча б п'яти місць, де це легко реалізувати, попросіть свого синтетичного 25-річного читати останні N років звітів після дій і запропонувати рейтинговий список. Або справжній 25-річний! Також гарне використання часу.)

(Якщо хвилюєшся про точність, увімкни режим попередження/канарки і почни додавати звіти після дії, незалежно від того, чи пищала канарка. Через шість місяців ти маєш величезну впевненість у тому, чи достатньо вона корисна, щоб тимчасово заблокувати людину.)

(Втома від сповіщень — це реальна річ, але це тому, що більшість наших інструментів сповіщення *дурні*, бо ми не вимагали їх розумності.)