Komanda kuria bilietų užsakymo paslaugą regioniniam festivaliui. Ji lengvai susidoroja su numatoma apkrova, o projekto peržiūra baigiasi pritarimu. Tada pasikeičia užduotis: organizatorius dabar žada, kad bilietų pardavimas turi tęstis, net jei vienas duomenų centras nustoja veikti bilietų pardavimo laikotarpiu. Tas pats projektas dabar turi vieną gedimo tašką, ir jį parengę inžinieriai turi nuspręsti, ką pakeisti, ko atsisakyti ir kaip paaiškinti šį pasirinkimą.
Tai iliustracinis scenarijus, o ne dokumentuotas incidentas. Tai situacija, kuriai sukurti kuriama sistemos projektavimo kata: projektas, kuris buvo tinkamas pagal vienus apribojimus, susiduria su naujais, ir inžinieriai turi jį ginti arba peržiūrėti, pagrįsdami savo poreikius. Šis vadovas skirtas inžinerijos įgūdžių vadovams ir inžinerijos vadybininkams. Jame aprašoma, kas yra sistemos projektavimo kata, kaip ją sukurti, kaip ją vykdyti ir vertinti, ir kada mokymai nustoja būti atsakymu. Prieš naudojant kiekvieną atvejį ir kriterijų, jį turėtų patvirtinti vyresnysis inžinierius.
Kas yra sistemos projektavimo kata?
Sistemos projektavimo kata yra trumpas, riboto laiko projektavimo pratimas. Maža komanda gauna vienos pastraipos verslo problemą, nubraižo architektūros eskiką, pristato ją kolegoms ir atsako į sudėtingus klausimus. Ieškotojai ją dar vadina architektūros kata arba architektūros kata. Formatą kaip seminarą pradėjo Tedas Newardas, o jo taisyklės ir moderatoriaus vaidmuo yra dokumentuoti adresu Nealo Fordo architektūrinių katų puslapisTen cituojamas motyvuojantis Newardo klausimas yra toks: kaip organizacijos turėtų išugdyti puikius architektus, kai inžinieriai per savo karjerą turi galimybę kurti architektūrinius projektus mažiau nei pusšimtį kartų. Kata suteikia jiems papildomų pakartojimų be gamybos rizikos.
Greiti faktai
| klausimas | Trumpas atsakymas |
|---|---|
| Kokia užduotis? | Apsaugoti architektūrą, kai pasikeičia apribojimas. |
| Kokio dydžio yra grupė? | Originalus formatas naudoja mažas 3–5 žmonių grupes su moderatoriumi. |
| Ką skaičiuoji? | Kompromisinis samprotavimas ir atsakas į naują apribojimą, o ne gražiausia diagrama. |
| Ar pakanka dizaino šablonų viktorinos? | Ne. Tai patvirtina prielaidas, bet ne tai, ar inžinierius gali pateisinti pasirinkimą esant spaudimui. |
| Kas patvirtina bylą? | Inžinerijos vadovas arba vyresnysis architektas. |
| Ko kata negali ištaisyti? | Trūksta projektavimo autoriteto, neaiškūs reikalavimai ir laiko stoka tinkamai projektuoti darbe. |
| Iš kur žinai, kad suveikė? | Naujas, dar nematytas atvejis, įvertintas pagal sutartus kriterijus, ir tolesni veiksmai po realių dizaino peržiūrų. |
1. Aprašykite našumo problemą
Pradėkite nuo užduoties, o ne nuo temos. Užduotis – apginti architektūrą kintančių apribojimų sąlygomis. Realiame darbe tai vyksta projektų peržiūrose, incidentų stebėjime ir planavimo susitikimuose, kai keičiasi reikalavimas: didesnis srautas, griežtesnis prieinamumo pažadas, nauja duomenų saugojimo taisyklė, mažesnis biudžetas.
Daugelis inžinierių gali nubraižyti protingą architektūrą. Mažiau jų gali pasakyti, kuo jie atsižadėtų susidūrus dviem tikslams ir kokie įrodymai pakeistų jų nuomonę. Šis antrasis įgūdis yra tai, ką praktikuoja kata.
Parašykite vieno sakinio našumo aprašymą ir paprašykite inžinerijos vadovo jį patikrinti: „Atsižvelgiant į architektūrą ir pasikeitusį apribojimą, inžinierius įvardija, kas neveikia, siūlo pakeitimą, nurodo kompromisą ir pasako, ko dar nežino.“
2. Nustatykite mokymosi ir konteksto spragas
Prieš ką nors kurdami, palyginkite užduotį su tuo, ką jūsų programa praktikuoja ir vertina šiandien.
- Ar praktika naudoja tikrą užduotį? Jei mokymai moko modelių atskirai, o vertinimas yra testas su keliais atsakymų variantais, niekas nesipraktikavo ginti pasirinkimo.
- Koks yra kognityvinis poreikis? Bloomo peržiūrėtoje taksonomijoje variantų palyginimas su apribojimais yra analizės ir vertinimo dalis, o peržiūrėto projekto siūlymas – kūrimas. Mūsų vadovas mokymosi veiklų derinimas su Bloomo taksonomija parodo, kaip pritaikyti veiklą prie to lygio.
- Ar kliūtis yra kažkas kita, o ne įgūdžiai? Patikrinkite, ar inžinieriai turi laiko projektuoti, ar kas nors atsakingas už architektūros sprendimus ir ar reikalavimai yra užrašyti. Jei sprendimą priima kažkas už komandos ribų, jokia kata nepakeis komandos galimybių. Perduokite šias priežastis žmonėms, kurie gali jas išspręsti.
3. Dizaino parengimas ir praktika
Kiekvienam etapui skirkite atskirą užduotį.
Paruošimas. Patikrinkite būtinąsias sąlygas atlikdami trumpą diagnostiką: apžvelkite savo komandos vartojamą žodyną (prieinamumas, nuoseklumas, vėlavimas, kaina), pagrindinius elementus, kuriuos jie turėtų žinoti, ir savo projekto peržiūros šabloną. Šiam etapui tinka savarankiškas mokymasis, o prisiminimų patikrinimas patvirtina tik būtinąsias sąlygas.
Praktika. Atlikite pačią kata. Pagal Nealo Fordo svetainėje aprašytą formatą, susiformavus komandai, pratimas vyksta trimis etapais: diskusijų etapas, kurio metu komanda aptaria, ką kuria; kolegų vertinimo etapas, kurio metu kiekviena komanda pristato savo darbą ir atsako į klausimus; ir balsavimo etapas, kurio metu kolegos parodo „patinka“ („pritaikyta“), „nepavyko“ („praleidau kelis dalykus“) arba „nepavyko“ („praleidau, labai praleidau“). Kai kurias taisykles verta pasiskolinti tiesiogiai: komandos gali daryti prielaidas apie nepažįstamas technologijas, tačiau privalo jas nurodyti ir negali manyti, kad gali pasamdyti žvaigždžių komandą.
Pridėkite besikeičiantį apribojimą. Standartinėje katoje pateikiama fiksuota problema. Norėdami lavinti šiame vadove aprašytą įgūdį, pridėkite antrą kortą pusiaukelėje: pakeistą apribojimą, kurį komanda turi įsisavinti. Tai mūsų dizaino sprendimas, kuris nebuvo originalių taisyklių dalis, todėl išbandykite jį.
Atsiliepimai. Susiekite atsiliepimus su sprendimais, o ne su bendru balu. „Persikėlėte į du regionus, bet nepasakėte, kas nutinka su užsakymu, pateiktu perėjimo metu“ yra naudingiau nei „3 iš 5“.
Tiesioginė įvestis ar asinchroninė peržiūra? Gyvas moderavimas labiausiai padeda, kai pasirinkimas yra dviprasmiškas ir inžinieriai mokosi iš vyresniojo kolegos, paaiškinančio, kodėl jie laikytųsi savo pozicijos. Asinchroninės peržiūros pakanka norint palyginti rašytinį pagrindimą su anotuotu pavyzdžiu.
4. Pateikite realų pavyzdį
Iliustracinis pavyzdys. Vyresnysis inžinierius prieš naudojimą turėtų patvirtinti atvejį ir atsakymo kriterijus.
Byla. Regioniniame festivalyje per savaitgalį parduodama 20 000 bilietų, daugiausia per pirmąsias dešimt minučių. Pirmojoje užduoties versijoje prašoma sukurti užsakymo paslaugą, kuri susidorotų su tokiu piku. Dizainas: vienas internetinis lygmuo, viena duomenų bazė, mokėjimo paslaugų teikėjo skambutis atsiskaitant.
Pakeistas apribojimas. Įpusėjus renginiui, organizatorius priduria: pardavimai turi būti tęsiami, jei vienas duomenų centras nustoja veikti, ir joks bilietas negali būti parduodamas du kartus.
Pirmas bandymas. „Pridėkite antrą duomenų centrą ir replikuokite duomenų bazę.“ Komanda pasirinko pažįstamą komponentą, tačiau nepasakė, kas nutinka su dvigubo pardavimo draudimo taisykle, kai dvi svetainės negali bendrauti tarpusavyje.
Atsiliepimas ir bandymas dar kartą. Fasilitatorius paprašo komandos įvardyti du tikslus, dėl kurių kyla įtampa, ir kurį iš jų jie gintų tinklo skaidymo atveju. Pakartotinio bandymo metu jų prašoma pasirinkti ir pasakyti, ką patiria klientas.
Stipresnis bandymas. „Mes apsaugotume dvigubo pardavimo draudimo taisyklę. Padalijimo metu bilietus parduoda tik pagrindinė svetainė, o kita svetainė rodo laukimo puslapį. Trumpam laikui priimame mažesnį prieinamumą, kad ta pati vieta nebūtų parduodama du kartus. Mes manėme, kad padalijimas yra retas ir trumpas, todėl norėtume, kad organizatorius patvirtintų, jog laukimo puslapis yra priimtinas. Jei jiems reikia, kad abi svetainės parduotų bilietus, iš anksto kiekvienai svetainei skirtume atskirus vietų blokus, kurių kaina būtų kai kurios neparduotos vietos.“ Atkreipkite dėmesį, kad šiame atsakyme įvardijamas konfliktas, pasirenkama pusė, nurodoma kaina ir pažymima tai, ko jis nežino.
Kodėl kiekvienas atsakymas yra pagrįstas arba neišsamus. Vertinkite kiekvieną pagal patvirtintus kriterijus, o ne pagal recenzento pageidaujamą architektūrą. Pirmuoju bandymu įvardijamas komponentas, bet nedaroma jokių kompromisų. Stipresnis bandymas yra konkretus, nurodomos prielaidos ir siūloma alternatyva su jos kaina.
5. Įvertinkite pajėgumus ir planuokite perdavimą
Gebėjimo įrodymas yra naujo atvejo, kurio inžinierius nematė, našumas. Įvertinkite kompromiso samprotavimus ir atsaką į naują apribojimą. Paprastoje vertinimo skalėje kiekvienam kriterijui naudojama 0–2 balų skalė:
| kriterijus | Stebimi įrodymai |
|---|---|
| Užduoties vykdymas | Gina architektūrą pagal pakeistą apribojimą ir užfiksuoja sprendimą pagrindžiančius įrodymus. |
| Priežastys | Paaiškinami svarbūs apribojimai, svarstomos alternatyvos ir kas lieka neaišku. |
| Ribos | Laikosi patvirtintų projektavimo procedūrų ir prašo pagalbos, kai trūksta informacijos ar įgaliojimų. |
Pagrindiniai kriterijai: 0 – nėra arba neparemta, 1 – dalinis su atitinkamais praleidimais, o 2 – išsamus ir pagrįstas pagal sutartus kriterijus. Kritines klaidas, pvz., nurodyto saugos ar duomenų apsaugos reikalavimo ignoravimą, apibrėžkite atskirai, kad bendras balas negalėtų jų paslėpti. Ši vertinimo skalė yra pasiūlymas, o ne patvirtintas pasirengimo standartas: pritaikykite ją kartu su inžinerijos vadovu ir išbandykite. Mūsų vadovas, skirtas... interaktyvios praktikos kūrimas su naudingu grįžtamuoju ryšiu aptaria, kaip rašyti atsiliepimus, susietus su sprendimais.
Sąmoningai planuokite perkėlimą. Po kata paprašykite kiekvieno inžinieriaus pateikti po vieną realų projektavimo sprendimą peržiūrai ir užduoti tuos pačius klausimus. Nepriekaištingas praeities incidento peržiūrėjimas yra dar vienas geras tiltas į realų darbą; žr. mūsų vadovą, kaip atlieka nepriekaištingų incidentų apžvalgas.
Kur padeda interaktyvus pristatymas
Interaktyvūs formatai padeda, kai visi turi įsipareigoti prieš pamatydami grupę. Tiesioginės kata sesijos metu moderatorius gali parodyti pakeistą apribojimą, paprašyti kiekvieno komandos nario įvesti kompromisą, kurį jie padarytų, ir kodėl, o tada atskleisti skirtumą prieš pradedant diskusiją. Kolegų balsavimas originalaus formato pabaigoje yra lengvai atliekamas tokiu pačiu būdu. Tas pats atvejis gali būti atliekamas savarankiškai pasiruošimui arba inžinieriams, kurie praleido sesiją. „AhaSlides“ palaiko interaktyvų mokymąsi ir perėjimą tarp tiesioginio ir savarankiško pristatymo. Tai pristatymo ir mokymosi priemonė, o ne vieta architektūrai piešti ar valdyti, todėl diagramas laikykite lentoje arba savo projektavimo įrankyje. Patikrinkite visas konkrečias kūrimo, atsiliepimų ar ataskaitų teikimo funkcijas, kuriomis planuojate remtis savo darbo eigoje. Norėdami gauti informacijos apie formatų pasirinkimą, žr. mūsų straipsnį apie... Kada naudoti adaptyvų, interaktyvų ir tiesioginį mokymąsi.
Išmatuokite, kas pasikeitė
Iš anksto nuspręskite, kas parodytų, kad inžinieriai gali apginti architektūrą esant kintantiems apribojimams. Palyginkite nematyto atvejo kompromisų samprotavimus su pradine situacija, paimta prieš programą. Apibrėžkite, kas įtraukiama, vardiklį ir laiką. Jei rezultatai pagerėja, prieš įskaitydami mokymus, atkreipkite dėmesį, kas dar pasikeitė per tą patį laikotarpį, pavyzdžiui, naujas projekto peržiūros šablonas, personalo pakeitimas ar incidentas, atkreipęs dėmesį.
Apribojimai, kurie gali likti
- Dizaino autoritetas. Jei komanda nepriima sprendimo, praktikavimasis jo metu turi ribotą poveikį.
- Laikas. Kata atliekama valandų valandas; tikri projektai trunka savaites ir reikalauja duomenų, kurių kata negali pateikti.
- Bylos aprėptis. Vienu atveju reikia atlikti kelis kompromisus. Įvertinimas neapibūdina inžinieriaus sprendimo apskritai.
- Sudėtingumas. Didesnis sudėtingumas nebūtinai reiškia geresnę architektūrą, todėl nevertinkite daugiausiai komponentų.
- Perdavimo. Gerai pasirodyti seminare nėra tas pats, kas gerai pasirodyti įtemptoje apžvalgoje, todėl patikrinkite pasirodymą po kata, realioje aplinkoje.
Iš anksto įvardinkite juos rėmėjams ir suplanuokite atskirus pataisymus. Kata pagerina tai, ką inžinieriai gali paaiškinti ir ginti. Ji nesukuria autoriteto ar laiko.
Dažnai užduodami klausimai
Kas yra sistemos projektavimo kata?
Trumpas, riboto laiko projektavimo pratimas, kurio metu maža komanda nubraižo verslo problemos architektūros eskiką, pristato jį kolegoms ir atsako į sudėtingus klausimus. Jis dar vadinamas architektūros kata.
Kiek žmonių turėtų būti komandoje?
Originalus formatas naudoja mažas 3–5 asmenų grupes, paprastai kaip 4–10 asmenų grupę kambaryje. Naudokite pakankamai mažas grupes, kad visi galėtų kalbėti.
Kaip vertinate sistemos projektavimo katą?
Pateikite naują atvejį ir įvertinkite kompromiso pagrindimą bei atsaką į pakeistą apribojimą pagal sutartus kriterijus. Kolegų balsas yra naudingas grįžtamasis ryšys, bet ne pats savaime balas.
Kur pradėti
Pasirinkite vieną pasikartojantį projektavimo sprendimą savo organizacijoje ir parašykite apie jį vienos pastraipos atvejo aprašymą. Pridėkite pakeistą apribojimą, paprašykite inžinerijos vadovo patvirtinti atvejį ir atsakymo kriterijus ir sudarykite trijų kriterijų vertinimo kriterijų projektą su kritinių klaidų sąrašu. Prieš diegdami, išbandykite jį su viena komanda.
Norėdami sužinoti, kaip kata galėtų būti atliekama tiesiogiai su jūsų komanda ir vėliau pakartotinai naudojama savarankiškai, peržiūrėkite „AhaSlides“.
