Optimaliseer tegniese ontwerpvergaderings met gestruktureerde kaartjiesjablone

Toe ek in 2020 my werk by Wayfair gekry het, was ek opgewonde om by 'n skraal, skrapse span aan te sluit wat 'n b2b-instrument in stand gehou het wat groot hoeveelhede besigheid aangedryf het. Ek het gekom van 'n rol waar ek meestal in 'n silo gewerk het, so ek was veral opgewonde om weer deel van 'n ontwikkelingspan te wees. Ek het egter baie vinnig gevind dat baie van die span soveel kundigheid gehad het in die gereedskap wat ons gebruik het dat hulle hierdie voorafbepaalde aanname gehad het dat ander ontwikkelaars dieselfde agtergrond, ervaring en kennis gehad het. Die groot probleem was dat die gereedskap waaraan ons gewerk het intern en eie was, so baie van die nuwer ontwikkelaars het hulle nie so goed geken as die ervare ontwikkelaars nie. Nou, dit is nie 'n kwessie oor die algemeen nie. Dit het egter baie problematies geword toe Jira-kaartjies geskep, geprioritiseer, geskat en toegeken is met min besonderhede. Natuurlik, die titel het die algemene probleem verduidelik, en die ervare ontwikkelaar wat dit geskryf het, het waarskynlik presies geweet waar om te begin soek om veranderinge aan te bring, maar dié van ons wat nuwer aan die platforms was, het baie min gehad om op te bou om te begin. Dit het groot gate in doeltreffendheid veroorsaak, waar ons voortdurend die meer vaste ontwikkelaars gejaag het vir meer inligting.

Nog 'n neweproduk van hierdie opstelling was dat ons tegniese ontwerpvergaderings geneig was om te sloer, aangesien meer en meer van ons vrae gehad het oor kaartjies wat vir skatting aangebied word. Besonderhede is voortdurend in gesprek uitgestryk, maar niks is opgeneem nie. Hierdie vergaderings sou voortsleep, en dan sou dieselfde vrae terugkom sodra die kaartjie toegeken is (tensy die gevolmagtigde die gesprek van weke gelede waar die vrae aanvanklik gevra is, magies kan onthou).

Hierdie werkvloei was ongelooflik frustrerend en ondoeltreffend. Maar, daar is hoop! 'n Kort rukkie nadat ons hierdie kwessie herken en dit bespreek het, het vergaderings gladder begin vloei, minder tyd geneem en meer impak gehad. Kaartjies was ryk aan besonderhede en maklik om op te tree, te toets en te voltooi. Hier is hoe ons dit gedoen het.

Die probleem: Onvoorbereide kaartjies en lang vergaderings

Ons tegniese ontwerpvergaderings sou dikwels ontspoor word deur kaartjies wat nie genoeg besonderhede het nie. Ontwikkelaars, ontwerpers en ander belanghebbendes sal te veel tyd spandeer om bykomende inligting te soek of om vae aspekte van 'n taak uit te klaar. Dit het nie net ons vergaderings verleng nie, maar het ook die ontwikkeling vertraag aangesien toegewysde kaartjies gereeld sou terugspring, wat meer verduideliking vereis het voordat werk kon voortgaan.

'n Goeie voorbeeld hiervan kan 'n kaartjie wees wat gerapporteer is deur 'n vaste ontwikkelaar wat eenvoudig gesê het: "Ons moet pryse vir vloerskus vasstel."

Dit is duidelik dat sonder 'n voldoende hoeveelheid agtergrondinligting is daar absoluut niks wat jy kan doen wanneer jy hierdie kaartjie ontvang nie. Wat is die probleem met pryse op vloer-skus? Wat word verwag om te gebeur? Maak die hoeveelheid van die sku in die wa saak? Daar is baie oop vrae en regtig geen manier om te begin werk sonder om by 'n vergadering in te spring nie. 'n Beter kaartjiebeskrywing is dalk.

"Vloer-sku's word grootmaat geprys en ons stelsel hanteer nie die prys-/hoeveelheidswiskunde behoorlik wanneer die hoeveelheid in die wa die grootmaatprysdrempels oorskry nie."

Nou, daar is nog nie genoeg detail hier nie, maar dit verduidelik ten minste die probleem behoorlik.

Ek gaan nie die voorbeeld moeg maak nie, maar die ontwikkelaar(s) sal al hierdie besonderhede moet invul met herhaalde vrae, gesprekke en aanbiedings totdat ons genoeg besonderhede het om te skat of aan die kaartjie te werk, afhangende van die huidige taak. Dit het gelei tot baie verlore tyd wat ons as ontwikkelaars nie kon terugkry nie.

Die oplossing: Implementering van kaartjiesjablone

Om hierdie probleem op te los, het ons 'n stel gestruktureerde kaartjiesjablone ontwikkel wat aangepas is vir die tipe werk wat gedoen word. Hierdie sjablone het verseker dat elke kaartjie - hetsy 'n foutverslag, ontwerpverandering, kenmerkversoek of optimaliseringstaak - al die nodige inligting bevat het voordat dit bespreek of toegewys is. Die reël was eenvoudig: as die sjabloon nie volledig voltooi was nie, was die kaartjie nie gereed vir die vergadering of vir ontwikkeling nie.

Foutverslae

Ontwerp veranderinge

Kenmerkversoeke

Optimaliseringstake

Die impak van sjablone

Die resultate was onmiddellik.

Ons het vinnig gesien dat ons ongeveer 3x meer kaartjies in 'n enkele uur lange tegniese ontwerpvergadering kon deurkom as wat ons voorheen kon. Die besprekings wat ons tydens hierdie vergaderings gehad het, was ook meer voordelig en impakvol. Ons het in die proses die tyd geneem om randgevalle uit te roep, spanne wat geraak is, en potensiële vertoningsstoppers of bottelnekke in die proses, en het ontwikkelaars voorberei vir die werk in plaas daarvan om al ons tyd te spandeer om te probeer verstaan vir meer besonderhede. Ons het onsself ook in 'n patroon ingedwing waar ons al hierdie terugvoer in die kaartjie aangeteken het, hetsy in die beskrywing of kommentaar. Die sjablone was 'n konstante herinnering dat hierdie besonderhede belangrik was en dat dit teenwoordig en maklik moes wees om te vind. Op 'n manier het hierdie sjablone ons brein opgelei om 'n dokumentasie-eerste benadering tot hierdie kaartjies te volg, om te verseker dat wie ook al die kaartjie gegryp het, of dit nou 'n junior ontwikkelaar of gesoute ingenieur is, genoeg inligting sal hê om 'n hoë-gehalte kode te skryf .

Vervolgens het ons opgemerk dat ons ontwikkelingsiklusse meer bondig was, ons skattings meer akkuraat was, en ons het daardie gesogte 100%-voltooiingsmerk op naellope baie meer gereeld bereik as wat ons ooit tevore gehad het. Ons kon ons bord byna konsekwent skoonmaak. Nie net is dit belangrik vir die besigheid omdat hulle opdaterings ontvang het toe ons vir hulle gesê het dat hulle dit sal ontvang nie, maar dit was 'n groot vertroueversterker vir die span aangesien jy jouself voortdurend in 'n posisie van sukses plaas. Ons belanghebbendes het ons verbeterde doeltreffendheid en deurvloei gesien en 'n groter vertroue in ons span en ons proses gekry. Hulle het ook opgemerk dat ons kode 'n hoër gehalte is, aangesien ons meer tyd kon spandeer om op die werklike probleem op hande te fokus.

Ons het van die begin af geweet dat dit ons lewens as ontwikkelaars sou verbeter, maar ons het nie besef hoeveel van 'n positiewe impak dit ook op ons sakevennote sou hê nie.

Sleutel wegneemetes vir ander spanne

As jy voel dat jou span voortdurend belas word deur 'n gebrek aan bevestiging, kan dit die moeite werd wees om te ondersoek of die skep van gestruktureerde kaartjiesjablone vir jou kan werk. Dit is belangrik om te noem dat dit wel bykomende ontwikkelaartyd neem om die kaartjies uit te voer met genoeg detail om op te tree. Ek glo wel dit is 'n geregverdigde koste en dit lei tot groot kostebesparings op die lang termyn aangesien dit jou werkvloei geweldig verbeter, maar dit is belangrik om te noem dat hierdie veranderinge nie net gratis gebeur nie. Iemand moet tyd afstaan om navorsing te doen en 'n kaartjie van hoë gehalte op te skryf en dat iemand waarskynlik jou ontwikkelingspan sal wees.

Dit gesê, dit is maklik om te sien hoe groot oorwinning dit vir 'n span kan wees. Om te begin sal ek 'n paar kort stappe aanbeveel.

Evalueer eers of jy werklik 'n probleem het of nie. Soms sukkel een of twee ontwikkelaars met dokumentasie of kennis-oordrag, maar dit is nie 'n aanduiding van 'n volskaalse probleem met jou kaartjies nie. Miskien kan ander dinge soos beter onbaording of dokumentasie sommige van daardie probleme oplos.

Tweedens, as jy vind dat dit 'n wydverspreide kwessie is wat oplossing nodig het, is die volgende stap om te kategoriseer watter tipe kaartjies jy gewoonlik kry en watter tipe inligting in elkeen vereis word. Die ooglopende kandidate is foute en kenmerke, maar afhangende van die aard van jou maatskappy se besigheid, het jy dalk ander soorte kaartjies wat voortdurend deur jou stelsel vloei en verskillende behoeftes het. Miskien bestuur jou span 'n ETL-pyplyn en jy moet weet watter insette/uitsette op kaartjies wat daarmee verband hou, beïnvloed word. Miskien besit jou span 'n SDK en die kaartjies wat daarmee verband hou moet op 'n spesiale/prioriteit wyse hanteer word en moet insluit watter besigheidsfunksies deur 'n verandering beïnvloed kan word? Ken jou span en hul vereistes sodat jy presies kan bepaal watter tipe sjablone benodig word.

Volgende, sodra jy al hierdie inligting het, plaas dit op skrif iewers gedeel waartoe almal toegang het. Miskien is dit 'n gedeelde dokument, of 'n wiki-bladsy wat die span bestuur en toegang verkry, of dalk kan jy selfs sjablone in Jira self skep, wat mense dwing om dit te gebruik. Maak nie saak wat jou benadering is nie, jy moet inkoop van die span en ontwikkelaars kry, wat beteken dat hulle dit moet kan sien. Dit is een van die belangrikste stappe, want hierdie proses sal nie verder gaan nie, tensy jy 100% inkoop het van enigiemand wat kaartjies gaan skryf. Bied hierdie sjablone aan jou span, versamel terugvoer, verduidelik hoe jy dink hierdie nuwe proses sal jou en jou belanghebbendes raak. Maak seker dat almal in die span gemaklik is met die nuwe proses.

Laastens moet u hierdie veranderinge afdwing. Kaartjies wat sonder genoeg besonderhede aangebied word, moet onmiddellik sonder bespreking teruggegooi word. Dit is belangrik om streng te wees om die sjabloonriglyne te volg, anders sal mense altyd redes vind om dit te omseil. “Hierdie kwessie is te kritiek, ek het nie tyd om dit op te skryf nie” is 'n algemene klagte wat ons sal ontvang. As u egter streng is met die behoefte aan 'n sjabloon en met mense werk wat dit probeer omseil, sal u hulle uiteindelik wen.

By Wayfair het ons groot verbeterings aan ons span se proses sowel as moraal gesien deur die klein veranderinge hierbo aan te bring. Ek hoop dit help jou span ook.