Команда розробляє сервіс бронювання квитків на регіональний фестиваль. Він легко справляється з очікуваним навантаженням, і огляд дизайну завершується схваленням. Потім короткий опис змінюється: організатор тепер обіцяє, що продаж квитків має продовжувати працювати, навіть якщо один центр обробки даних вийде з ладу протягом періоду продажу. Той самий дизайн тепер має єдину точку відмови, і інженери, які його розробляли, повинні вирішувати, що змінити, від чого відмовитися та як пояснити свій вибір.
Це ілюстративний сценарій, а не задокументований інцидент. Це ситуація, для якої створюються ката системного проектування: проект, який був прийнятним за одного набору обмежень, зустрічається з новим, і інженери повинні його захищати або переглядати з обґрунтуванням. Цей посібник призначений для керівників інженерних розробок та менеджерів інженерів. Він розповідає, що таке ката системного проектування, як його створити, як його запустити та оцінити, а також коли навчання перестає бути відповіддю. Кожен випадок та критерій повинні бути перевірені старшим інженером, перш ніж використовувати його.
Що таке ката системного проектування?
Ката системного проектування — це коротка, обмежена в часі вправа з проектування. Невелика команда отримує бізнес-проблему з одного абзацу, створює ескіз архітектури, презентує її колегам та відповідає на складні запитання. Пошукачі також називають це ката архітектури або архітектурним ката. Формат був започаткований Тедом Ньюардом як семінар і задокументований, разом з його правилами та роллю модератора, на Сторінка Ніла Форда про архітектурні катаМотиваційне питання Ньюарда, цитоване там, полягає в тому, як організації мають виховувати чудових архітекторів, якщо інженери мають можливість займатися архітекторською діяльністю менше півдюжини разів за кар'єру. Ката дає їм додаткові повторення без виробничого ризику.
Швидкі факти
| Питання | Коротка відповідь |
|---|---|
| Яке завдання? | Захищати архітектуру при зміні обмеження. |
| Якою є величина групи? | В оригінальному форматі використовуються невеликі групи від 3 до 5 осіб з модератором. |
| Який бал ви отримуєте? | Компромісне мислення та реакція на нове обмеження, а не найгарніша діаграма. |
| Чи достатньо вікторини з шаблонів проектування? | Ні. Це підтверджує передумови, але не те, чи може інженер обґрунтувати свій вибір під тиском. |
| Хто підтверджує справу? | Керівник інженерного відділу або старший архітектор. |
| Що не може виправити ката? | Відсутність повноважень у сфері проектування, нечіткі вимоги та брак часу для належного проектування на роботі. |
| Звідки ви знаєте, що це спрацювало? | Новий, раніше не бачений корпус, оцінений за узгодженими критеріями, а також подальші дії на основі реальних оглядів дизайну. |
1. Опишіть проблему продуктивності
Почніть із завдання, а не з теми. Завдання полягає в тому, щоб захистити архітектуру за умов змінних обмежень. У реальній роботі це відбувається під час оглядів дизайну, подальших дій після інцидентів та зустрічей з планування, де змінюються вимоги: більше трафіку, суворіші обіцянки доступності, нове правило зберігання даних, обмеженіший бюджет.
Багато інженерів можуть намалювати розумну архітектуру. Менше з них можуть сказати, чим вони поступляться, коли дві цілі зіткнуться, і які докази змінять їхню думку. Саме цю другу навичку відпрацьовує ката.
Напишіть опис продуктивності з одного речення та попросіть керівника інженерної роботи перевірити його: «За заданої архітектури та зміненого обмеження інженер називає, що ламається, пропонує зміни, оголошує компроміс і каже, чого він досі не знає».
2. Діагностуйте прогалини у навчанні та контексті
Перш ніж щось створювати, порівняйте завдання з тим, що ваша програма практикує та оцінює сьогодні.
- Чи використовує практика реальне завдання? Якщо навчання навчає шаблонам окремо, а оцінювання – це тест із множинним вибором, то ніхто не практикувався в захисті вибору.
- Що таке когнітивний попит? У переглянутій таксономії Блума порівняння варіантів з обмеженнями полягає в аналізі та оцінці, а пропонування переглянутого дизайну охоплює створення. Наш посібник з зіставлення навчальних завдань з таксономією Блума показує, як зіставити діяльність з цим рівнем.
- Чи щось, окрім майстерності, заважає? Перевірте, чи мають інженери час на проектування, чи хтось відповідає за архітектурні рішення та чи вимоги записані. Якщо рішення приймає хтось поза командою, жодні ката не змінять те, що може зробити команда. Передайте ці причини людям, які можуть їх виправити.
3. Підготовка та практика проектування
Дайте кожному етапу окреме завдання.
Підготовка. Перевірте передумови за допомогою короткої діагностики: словник, який використовує ваша команда (доступність, узгодженість, затримка, вартість), структурні блоки, які вони повинні знати, та ваш власний шаблон перевірки дизайну. На цьому етапі підходить самостійне навчання, а перевірка повторення підтверджує лише передумови.
Практика. Виконайте сам ката. У форматі, описаному на сайті Ніла Форда, після формування команди вправа проходить у три фази: фаза обговорення, де команда визначає, що вона створює, фаза колегіальної оцінки, де кожна команда презентує та відповідає на запитання, і фаза голосування, де колеги показують схвальний відгук («вдало»), схвальний відгук («пропустив кілька речей») або схвальний відгук («пропустив, дуже погано»). Деякі правила варто запозичити безпосередньо: команди можуть робити припущення щодо незнайомої технології, але повинні їх висловлювати, і не можуть вважати, що можуть найняти команду зірок.
Додайте змінне обмеження. Стандартне ката дає фіксовану проблему. Щоб відпрацювати навичку з цього посібника, додайте другу картку посередині: змінене обмеження, яке команда повинна врахувати. Це наш дизайнерський вибір, а не частина оригінальних правил, тому пілотуйте його.
Зворотний зв'язок. Пов’яжіть відгук із рішеннями, а не із загальною оцінкою. «Ви переїхали до двох регіонів, але не сказали, що відбувається із замовленням, розміщеним під час переходу» корисніше, ніж «3 з 5».
Живий ввід чи асинхронний огляд? Жива фасилітація найбільше додає, коли вибір неоднозначний, і інженери дізнаються від старшого колеги, чому вони дотримуються своєї позиції. Асинхронного огляду достатньо для порівняння письмового обґрунтування з анотованим прикладом.
4. Розгляньте реалістичний приклад
Ілюстрація. Старший інженер повинен перевірити випадок та критерії відповіді перед використанням.
Справа. Регіональний фестиваль продає 20 000 квитків за вихідні, причому більшість продажів відбувається протягом перших десяти хвилин. У першій версії брифу запитується сервіс бронювання, який впорається з таким піком. Дизайн: один веб-рівень, одна база даних, дзвінок постачальника платіжних послуг під час оформлення замовлення.
Змінене обмеження. На середині акції організатор додає: продаж має продовжуватися, якщо один центр обробки даних вийде з ладу, і жоден квиток не може бути проданий двічі.
Перша спроба. «Додайте другий центр обробки даних та скопіюйте базу даних». Команда взялася за знайомий компонент, але не сказала, що відбувається з правилом заборони подвійних продажів, коли два сайти не можуть взаємодіяти один з одним.
Зворотній зв'язок та повторна спроба. Фасилітатор просить команду назвати дві цілі, що виникають у конфлікті, і яку з них вони б захистили у разі розколу мережі. Під час повторної спроби їх просять вибрати та розповісти, що відчуває клієнт.
Сильніша спроба. «Ми б захистили правило заборони подвійного продажу. Під час спліту квитків лише основний сайт продає квитки, а інший сайт показує сторінку очікування. Ми приймаємо нижчу доступність протягом короткого часу, щоб уникнути продажу одного й того ж місця двічі. Ми припустили, що спліт трапляється рідко та коротко, і ми хотіли б, щоб організатор підтвердив, що сторінка очікування є прийнятною. Якщо їм потрібно, щоб обидва сайти продавали місця, ми заздалегідь виділимо окремі блоки місць кожному сайту ціною деяких непроданих місць». Зверніть увагу, що ця відповідь називає конфлікт, обирає сторону, вказує вартість і позначає те, що їй невідомо.
Чому кожна відповідь є обґрунтованою або неповною. Оцінюйте кожен варіант за затвердженими критеріями, а не за бажаною архітектурою рецензента. Перша спроба називає компонент, але не пропонує жодного компромісу. Більш сильна спроба є конкретною, визначає свої припущення та пропонує альтернативу зі своєю ціною.
5. Оцінка можливостей та планування передачі
Доказом можливостей є виконання роботи над новим випадком, з яким інженер ще не стикався. Оцініть міркування щодо компромісу та реакцію на нове обмеження. Проста рубрика використовує шкалу від 0 до 2 за кожен критерій:
| критерій | Спостережувані докази |
|---|---|
| Виконання завдання | Захищає архітектуру з урахуванням зміненого обмеження та записує докази, що лежать в основі рішення. |
| Обґрунтування | Пояснює відповідні обмеження, розглянуті альтернативи та те, що залишається невизначеним. |
| Межі | Дотримується затверджених процедур проектування та звертається по допомогу, коли інформація або повноваження відсутні. |
Опорні точки: 0 – відсутнє або непідтверджене, 1 – часткове з відповідними пропусками, а 2 – повне та обґрунтоване відповідно до узгоджених критеріїв. Визначте критичні помилки окремо, такі як ігнорування заявленої вимоги безпеки або захисту даних, щоб загальна оцінка не могла їх приховати. Ця рубрика є пропозицією, а не затвердженим стандартом готовності: адаптуйте її разом з керівником інженерії та проведіть пілотне випробування. Наш посібник з розробка інтерактивної практики з корисним зворотним зв'язком охоплює, як писати відгуки, що містять посилання на рішення.
Плануйте передачу обдумано. Після ката попросіть кожного інженера представити одне реальне проектне рішення для перегляду та застосувати ті ж самі питання. Бездоганний огляд минулого інциденту – це ще один хороший спосіб перейти до реальної роботи; див. наш посібник з проведення оглядів безвинних інцидентів.
Де допомагає інтерактивна доставка
Інтерактивні формати допомагають усім взяти на себе зобов'язання, перш ніж вони побачать групу. Під час живого ката-сеансу фасилітатор може показати змінене обмеження, попросити кожного члена команди ввести компроміс, на який вони пішли б, і чому, а потім розкрити розкид перед початком обговорення. Голосування колег в кінці оригінального формату легко виконати таким самим чином. Той самий кейс може виконуватися у власному темпі для підготовки або для інженерів, які пропустили сеанс. AhaSlides підтримує інтерактивне навчання та перехід між живим та власним темпом. Це інструмент для презентацій та навчання, а не місце для малювання чи запуску архітектури, тому зберігайте діаграми на дошці або у своєму інструменті дизайну. Перевірте будь-яку конкретну функцію створення, зворотного зв'язку чи звітності, на яку ви плануєте покладатися, у порівнянні з вашим власним робочим процесом. Щоб отримати рекомендації щодо вибору форматів, дивіться нашу статтю про коли використовувати адаптивне, інтерактивне та живе навчання.
Виміряйте, що змінилося
Заздалегідь вирішіть, що покаже, що інженери можуть захищати архітектуру за умов змінних обмежень. Порівняйте міркування про компроміси на невідомому випадку з базовим рівнем, взятим до програми. Визначте, хто бере участь, знаменник та терміни. Якщо результати покращуються, подивіться, що ще змінилося за той самий період, наприклад, новий шаблон огляду проекту, зміна персоналу або інцидент, який привернув увагу, перш ніж зараховувати навчання.
Обмеження, які можуть залишитися
- Авторитет дизайну. Якщо команда не приймає рішення, його практичне застосування має обмежений ефект.
- Час На ката потрібні години; справжні розробки займають тижні та містять дані, які ката надати не може.
- Покриття справ. В одному випадку застосовується кілька компромісів. Оцінка не описує судження інженера загалом.
- Складність. Більша складність не обов'язково означає кращу архітектуру, тому не варто винагороджувати найбільшу кількість компонентів.
- Трансфер Добре виступити на семінарі – це не те саме, що добре виступити на напруженому огляді, тому перевірте виконання після ката, в реальних умовах.
Заздалегідь назвіть їх спонсорам та сплануйте окремі виправлення. Ката покращує те, що інженери можуть пояснити та захистити. Вона не створює авторитету чи часу.
Часті питання
Що таке ката системного проектування?
Коротка, обмежена в часі дизайнерська вправа, під час якої невелика команда створює ескіз архітектури бізнес-проблеми, презентує її колегам та відповідає на складні запитання. Її також називають ката архітектури.
Скільки людей має бути в команді?
В оригінальному форматі використовуються невеликі групи від 3 до 5 осіб, зазвичай як одна з 4-10 груп в кімнаті. Використовуйте групи достатньо малі, щоб усі могли висловитися.
Як ви оцінюєте ката з проектування системи?
Наведіть новий випадок та оцініть компромісне обґрунтування та реакцію на зміну обмеження відповідно до узгоджених критеріїв. Голосування колег є корисним зворотним зв'язком, але не самодостатньою оцінкою.
З чого почати
Виберіть одне повторюване проектне рішення у вашій організації та напишіть для нього одноабзацний опис випадку. Додайте змінене обмеження, попросіть керівника інженерії перевірити варіант і критерії відповіді, а також складіть рубрику з трьома критеріями зі списком критичних помилок. Проведіть пілотне випробування з однією командою, перш ніж розгортати.
Щоб побачити, як ката може працювати в прямому ефірі з вашою власною командою та використовуватися повторно у власному темпі згодом, ознайомтеся з AhaSlides.
