Kuidas luua süsteemidisaini katasid, mis koolitavad insenere arhitektuuriliste kompromisside hindamiseks

Meeskond disainib piirkondliku festivali piletibroneerimisteenust. See saab eeldatava koormusega mugavalt hakkama ja disaini läbivaatamine lõpeb heakskiitvate märkustega. Seejärel muutub ülesanne: korraldaja lubab nüüd, et piletimüük peab jätkuma ka siis, kui üks andmekeskus müügiakna ajal võrgust välja läheb. Samal disainil on nüüd üksainus rike ja insenerid, kes selle joonistasid, peavad otsustama, mida muuta, millest loobuda ja kuidas oma valikut selgitada.

See on illustreeriv stsenaarium, mitte dokumenteeritud juhtum. See on olukord, mille harjutamiseks süsteemi disaini katat ehitatakse: ühtede piirangute korral toiminud disain kohtub uutega ja insenerid peavad seda põhjendustega kaitsma või muutma. See juhend on mõeldud inseneriõppe juhtidele ja insenerijuhtidele. See käsitleb, mis on süsteemi disaini kata, kuidas seda luua, kuidas seda käivitada ja hinnata ning millal koolitus lakkab olemast lahendus. Enne iga juhtumi ja kriteeriumi kasutamist peaks vaneminsener valideerima.

Mis on süsteemi disaini kata?

Süsteemidisaini kata on lühike, ajaliselt piiratud disainiharjutus. Väike meeskond saab ühe lõigu pikkuse äriprobleemi, visandab arhitektuuri, esitleb seda kolleegidele ja vastab keerulistele küsimustele. Otsijad nimetavad seda ka arhitektuurikataks või arhitektuurikataks. Selle formaadi algatas Ted Neward töötoa raames ja see on koos reeglite ja moderaatori rolliga dokumenteeritud aadressil Neal Fordi arhitektuuriliste kataste lehtNewardi motiveeriv küsimus, mida seal tsiteeritakse, on see, kuidas peaksid organisatsioonid kasvatama suurepäraseid arhitekte, kui inseneridel on karjääri jooksul võimalus arhitektina töötada vähem kui pool tosinat korda. Kata annab neile lisakordusi ilma tootmisriskita.

Quick faktid

1. Kirjeldage jõudlusprobleemi

Alusta ülesandest, mitte teemast. Ülesanne on kaitsta arhitektuuri muutuvate piirangute tingimustes. Tegelikkuses toimub see projektide ülevaadetes, intsidentide järelmeetmetes ja planeerimiskoosolekutel, kus nõue muutub: suurem liiklus, rangem kättesaadavuse lubadus, uus andmete asukoha reegel, kitsam eelarve.

Paljud insenerid suudavad joonistada mõistliku arhitektuuri. Vähem oskavad öelda, millest nad loobuksid kahe eesmärgi põrkumisel ja millised tõendid muudaksid nende meelt. See teine ​​oskus on see, mida kata harjutab.

Kirjutage ühest lausest koosnev toimivusaruanne ja laske see insenerijuhil üle vaadata: "Arhitektuuri ja muudetud piirangu korral nimetab insener, mis on rikutud, pakub välja muudatuse, toob välja kompromissi ja ütleb, mida ta veel ei tea."

2. Õppimis- ja kontekstilünga diagnoosimine

Enne millegi loomist võrdle ülesannet sellega, mida sinu programm täna harjutab ja hindab.

1. Kas harjutamine kasutab tegelikku ülesannet? Kui koolitus õpetab mustreid isoleeritult ja hindamine on valikvastustega test, siis pole keegi harjutanud valiku kaitsmist.
2. Mis on kognitiivne nõudlus? Bloomi muudetud taksonoomias on valikute võrdlemine piirangutega analüüsi ja hindamise küsimus ning muudetud kujunduse pakkumine viib loomiseni. Meie juhend ... õppetegevuste sobitamine Bloomi taksonoomiaga näitab, kuidas tegevust sellele tasemele sobitada.
3. Kas peale oskuste on teel midagi muud? Kontrolli, kas inseneridel on aega projekteerimiseks, kas kellelgi on õigus arhitektuuriotsuste tegemisel ja kas nõuded on kirjalikult kirja pandud. Kui otsuse teeb keegi väljaspool meeskonda, ei muuda ükski kata meeskonna tegutsemisvõimalusi. Anna need põhjused edasi inimestele, kes saavad need lahendada.

3. Kujunduse ettevalmistamine ja harjutamine

Andke igale etapile eraldi ülesanne.

Ettevalmistus. Kontrollige eeltingimusi lühikese diagnostika abil: teie meeskonna kasutatav sõnavara (saadavus, järjepidevus, latentsus, maksumus), ehitusplokid, mida neilt oodatakse, ja teie enda disaini ülevaatuse mall. Sellele etapile sobib iseseisvalt õppimine ja meeldetuletuse kontroll kinnitab ainult eeltingimusi.

Praktika. Esita kata ise. Neal Fordi veebisaidil kirjeldatud formaadis toimub harjutus pärast meeskonna moodustamist kolmes etapis: aruteluetapp, kus meeskond selgitab välja, mida nad ehitavad; vastastikuse hindamise etapp, kus iga meeskond esitleb oma mõtteid ja vastab küsimustele; ning hääletamise etapp, kus kolleegid näitavad pöidlaid püsti („täiesti okei“), pöidlaid „meh“ („jäin paar asja kahe silma vahele“) või pöidlaid alla („jäin halvasti kahe silma vahele“). Mõned reeglid on otse laenamist väärt: meeskonnad võivad teha oletusi tundmatu tehnoloogia kohta, kuid peavad need välja ütlema ja ei tohi eeldada, et nad saavad palgata staaridest koosneva meeskonna.

Lisa muutuv piirang. Standardkatas on fikseeritud probleem. Selle juhendi oskuse treenimiseks lisa poole peale teine ​​kaart: muudetud piirang, millega meeskond peab leppima. See on meie disainivalik, mis ei olnud osa algsetest reeglitest, seega katseta seda.

Tagasiside. Seo tagasiside otsustega, mitte koguhinnanguga. „Kolisid kahte piirkonda, aga ei öelnud, mis juhtub ülemineku ajal esitatud tellimusega” on kasulikum kui „3 viiest”.

Otseülekanne või asünkroonne arvustus? Otseülekanne annab kõige rohkem lisaväärtust siis, kui valik on mitmetähenduslik ja insenerid õpivad vanemalt kolleegilt, kes selgitab, miks nad oma seisukohta säilitaksid. Asünkroonsest ülevaatest piisab kirjaliku põhjenduse võrdlemiseks kommenteeritud näitega.

4. Töötage läbi realistlik näide

Illustreeriv. Vaneminsener peaks enne kasutamist juhtumi ja vastuse kriteeriumid valideerima.

Juhul. Regionaalsel festivalil müüakse nädalavahetusel 20 000 piletit, kusjuures suurem osa müügist toimub esimese kümne minuti jooksul. Ülesande esimeses versioonis palutakse luua broneerimisteenus, mis selle tippkoormusega toime tuleb. Kujundus: üks veebitasand, üks andmebaas, makseteenuse pakkuja kõne kassas.

Muutunud piirang. Poole peal lisab korraldaja: müük peab jätkuma, kui üks andmekeskus võrguühenduseta läheb, ja ühtegi piletit ei tohi kaks korda müüa.

Esimene katse. „Lisage teine ​​andmekeskus ja kopeerige andmebaas.“ Meeskond on leidnud tuttava komponendi, kuid pole öelnud, mis juhtub topeltmüügi keeluga, kui kaks saiti ei saa omavahel suhelda.

Tagasiside ja proovi uuesti. Moderaator palub meeskonnal nimetada kaks pinge all olevat eesmärki ja seda, millist nad võrgustiku jagunemise korral kaitseksid. Korduskatsel palutakse neil valida ja öelda, mida klient kogeb.

Tugevam katse. „Me kaitseksime topeltmüügi keelu reeglit. Jagamise ajal müüb pileteid ainult peamine sait ja teine ​​sait kuvab ootelehe. Me aktsepteerime lühikese aja jooksul madalamat saadavust, et vältida sama koha topeltmüüki. Oleme eeldanud, et jagamine on haruldane ja lühike ning me sooviksime, et korraldaja kinnitaks ootelehe vastuvõetavust. Kui nad vajavad mõlema koha müümist, eraldaksime eelnevalt igale saidile eraldi istekohad mõnede müümata kohtade arvelt.“ Pange tähele, et see vastus nimetab konflikti, valib poole, märgib maksumuse ja märgib ära selle, mida see ei tea.

Miks iga vastus on õigustatud või mittetäielik. Hinnake igaüht heakskiidetud kriteeriumide, mitte retsensendi eelistatud arhitektuuri alusel. Esimesel katsel nimetatakse komponent, kuid kompromissi ei tehta. Tugevam katse on konkreetne, esitab oma eeldused ja pakub alternatiivi koos hinnaga.

5. Hinnake võimekust ja plaanige üleandmist

Võimekuse tõendiks on sooritus uue juhtumi puhul, mida insener pole varem näinud. Hinnake kompromissi põhjendust ja vastust uuele piirangule. Lihtne rubriik kasutab iga kriteeriumi kohta skaalat 0 kuni 2:

Ankrud: 0 puudub või ei ole toetatud, 1 on osaline oluliste puudujääkidega ja 2 on täielik ja põhjendatud kokkulepitud kriteeriumide alusel. Määrake kriitilised vead eraldi, näiteks kehtestatud ohutus- või andmekaitsenõude eiramine, et üldskoor ei saaks neid varjata. See rubriik on ettepanek, mitte valideeritud valmisoleku standard: kohandage seda koos insenerijuhiga ja katsetage seda. Meie juhend... interaktiivse praktika kujundamine kasuliku tagasiside abil käsitleb, kuidas kirjutada otsustega seotud tagasisidet.

Planeeri üleandmist teadlikult. Pärast katat palu igal inseneril tuua üks reaalajas tehtud projekteerimisotsus ülevaatusele ja esitada samu küsimusi. Varasema intsidendi laitmatu ülevaatamine on veel üks hea sild päris töö juurde; vaata meie juhendit... süütute juhtumite ülevaadete läbiviimine.

Kus interaktiivne edastamine aitab

Interaktiivsed formaadid on abiks olukorras, kus kõik peaksid enne grupiga kohtumist oma seisukoha kinnitama. Otseülekande kata sessioonil saab juhendaja näidata muudetud piirangut, paluda igal meeskonnaliikmel sisestada kompromiss, mille nad teeksid, ja miks, seejärel avaldada erinevuse enne arutelu algust. Algse vormingu lõpus toimuvat vastastikust hääletust on samamoodi lihtne läbi viia. Sama juhtumit saab ettevalmistuseks või sessioonist ilma jäänud inseneride jaoks läbi viia iseseisvalt. AhaSlides toetab interaktiivset õppimist ja liikumist reaalajas ja iseseisvalt toimuva esituse vahel. See on esitlus- ja õppevahend, mitte koht arhitektuuri joonistamiseks või käivitamiseks, seega hoidke diagramme tahvlil või oma disainitööriistas. Kontrollige kõiki konkreetseid autorimis-, tagasiside- või aruandlusfunktsioone, millele kavatsete oma töövoo suhtes tugineda. Vormingute valimise juhiste saamiseks vaadake meie artiklit Millal kasutada adaptiivset, interaktiivset ja reaalajas õppimist.

Mõõda, mis muutus

Otsusta eelnevalt, mis näitaks, et insenerid suudavad arhitektuuri kaitsta muutuvate piirangute korral. Võrdle kompromisside arutluskäiku seni nägemata juhtumi puhul programmi eel võetud lähteolukorraga. Määratle, kes on kaasatud, nimetaja ja ajastus. Kui tulemused paranevad, vaata enne koolituse arvestamist, mis samal perioodil veel muutus, näiteks uus projekti ülevaatuse mall, personali vahetus või tähelepanu äratanud intsident.

Piirangud, mis võivad jääda

• Disainiautoriteet. Kui meeskond otsust ei langeta, on selle harjutamisel piiratud mõju.
• Aeg Kata sooritamine võtab tunde; tõelised kavandid võtavad nädalaid ja hõlmavad andmeid, mida kata ei suuda esitada.
• Juhtumi katvus. Üks juhtum nõuab mõningaid kompromisse. Skoor ei kirjelda inseneri otsustusvõimet üldiselt.
• Keerukus. Suurem keerukus ei pruugi tingimata tähendada paremat arhitektuuri, seega ärge premeerige kõige rohkem komponente.
• Ülekanne. Töötoas hästi esinemine ei ole sama, mis pingelises kordamisvoorus hästi esinemine, seega kontrolli sooritust pärast katat reaalses keskkonnas.

Nimetage need sponsoritele varakult ja planeerige eraldi lahendused. Kata parandab seda, mida insenerid saavad selgitada ja kaitsta. See ei loo autoriteeti ega aega.

Korduma kippuvad küsimused

Mis on süsteemi disaini kata?

Lühike, ajaliselt piiratud disainiharjutus, mille käigus väike meeskond visandab äriprobleemi arhitektuuri, esitleb seda kolleegidele ja vastab keerulistele küsimustele. Seda nimetatakse ka arhitektuurikataks.

Mitu inimest peaks meeskonnas olema?

Algupärases formaadis kasutatakse väikeseid 3–5-liikmelisi gruppe, tavaliselt 4–10-liikmelises ruumis. Kasutage piisavalt väikeseid gruppe, et kõik saaksid rääkida.

Kuidas hinnata süsteemi disaini katat?

Esitage uus juhtum ja hinnake kompromissi põhjendusi ning reageeringut muudetud piirangule kokkulepitud kriteeriumide alusel. Vastastikune hääl on kasulik tagasiside, kuid mitte omaette punktisumma.

Kust alustada

Vali oma organisatsioonis üks korduv disainiotsus ja kirjuta selle kohta ühe lõigu pikkune põhjendus. Lisa muudetud piirang, lase insenerijuhil otsus ja vastusekriteeriumid kinnitada ning koosta kolmest kriteeriumist koosnev rubriik koos kriitiliste vigade loeteluga. Enne juurutamist katseta seda ühe meeskonnaga.

Et näha, kuidas katat saaks otseülekandes oma meeskonnaga läbi viia ja hiljem omas tempos uuesti kasutada, uurige AhaSlides'i.