Аптымізацыя сустрэч па тэхнічным дызайне з дапамогай структураваных шаблонаў білетаў

Калі я ўладкаваўся на працу ў Wayfair у 2020 годзе, я быў вельмі рады далучыцца да стройнай, лагоднай каманды, якая падтрымлівала інструмент b2b, які стварыў велізарны бізнес. Я прыходзіў з пасады, дзе я працаваў у асноўным у бункеры, таму я быў асабліва рады зноў стаць часткай каманды распрацоўшчыкаў. Аднак я вельмі хутка заўважыў, што большая частка каманды мае такі вялікі вопыт у інструментах, якімі мы карыстаемся, што ў іх было прадвызначанае здагадка, што іншыя распрацоўшчыкі валодаюць такім жа вопытам, вопытам і ведамі, што і яны. Асноўная праблема заключалася ў тым, што інструменты, над якімі мы працавалі, былі ўнутранымі і запатэнтаванымі, таму многія новыя распрацоўшчыкі не ведалі іх так добра, як вопытныя распрацоўшчыкі. Зараз гэта не праблема ў цэлым. Аднак гэта стала вельмі праблематычным, калі білеты Jira былі створаны, расстаўлены па прыярытэтах, ацэнены і прызначаны з невялікай колькасцю дэталяў. Безумоўна, назва тлумачыла агульную праблему, і дасведчаны распрацоўшчык, які яе напісаў, верагодна, дакладна ведаў, з чаго пачаць пошук, каб унесці змены, але тым з нас, хто быў пачатковец у платформах, было вельмі мала чаго абапірацца, каб пачаць. Гэта прывяло да вялізных дзірак у эфектыўнасці, у выніку чаго мы пастаянна патрабавалі ад больш штатных распрацоўшчыкаў дадатковай інфармацыі.

Яшчэ адным пабочным прадуктам гэтай налады было тое, што нашы сустрэчы па тэхнічным дызайне, як правіла, зацягваліся, бо ўсё больш і больш з нас узнікалі пытанні наконт білетаў, якія прадстаўляліся для ацэнкі. У размове пастаянна высвятляліся падрабязнасці, але нічога не запісвалася. Гэтыя сустрэчы зацягнуліся, а потым тыя ж пытанні ўзніклі зноў, як толькі білет быў прызначаны (калі толькі праванаёмнік не мог чароўным чынам успомніць размову тыдня таму, калі пытанні былі зададзены першапачаткова).

Гэты працоўны працэс быў неверагодна расчаравальным і неэфектыўным. Але надзея ёсць! Неўзабаве пасля таго, як мы заўважылі гэтую праблему і абмеркавалі яе, сустрэчы сталі праходзіць больш гладка, займаць менш часу і быць больш эфектыўнымі. Квіткі былі багатыя падрабязнасцямі, з імі было лёгка дзейнічаць, тэставаць і запаўняць. Вось як мы гэта зрабілі.

Праблема: непадрыхтаваныя білеты і працяглыя сустрэчы

Нашы сустрэчы па тэхнічным дызайне часта збіваліся з-за білетаў, у якіх не было дастаткова падрабязнасцей. Распрацоўшчыкі, дызайнеры і іншыя зацікаўленыя бакі марнавалі б занадта шмат часу на пошук дадатковай інфармацыі або высвятленне расплывістых аспектаў задачы. Гэта не толькі падоўжыла нашы сустрэчы, але і затрымала распрацоўку, бо прызначаныя білеты часта вярталіся назад, што патрабавала дадатковых тлумачэнняў, перш чым праца магла працягвацца.

Выдатным прыкладам гэтага можа быць білет, пра які паведаміў штатны распрацоўшчык, у якім проста сцвярджалася: «Нам трэба выправіць цэны на падлогавыя пакрыцця».

Відавочна, што без дастатковай колькасці даведачнай інфармацыі вы абсалютна нічога не зможаце зрабіць, калі атрымаеце гэты білет. У чым праблема з цэнамі на падлогавыя нумары? Што чакаецца? Ці мае значэнне колькасць інвентара ў кошыку? Ёсць шмат адкрытых пытанняў, і сапраўды немагчыма пачаць працу, не заскочыўшы на сустрэчу. Лепшае апісанне білета можа быць.

«На мінімальныя нумары прызначаецца аптовая цана, і наша сістэма не апрацоўвае належным чынам цану/колькасць, калі колькасць у кошыку перавышае парог аптовага цэнаўтварэння».

Цяпер тут усё яшчэ недастаткова дэталяў, але, па меншай меры, гэта правільна тлумачыць праблему.

Я не збіраюся спыняць прыклад, але распрацоўшчык(ы) павінны былі б удакладніць усе гэтыя дэталі з дапамогай паўторных пытанняў, размоў і прэзентацый, пакуль у нас не будзе дастаткова дэталяў для ацэнкі або працы над білетам, у залежнасці ад бягучага задача. Гэта прывяло да вялікай колькасці страчанага часу, які мы, як распрацоўшчыкі, не змаглі вярнуць.

Рашэнне: укараненне шаблонаў білетаў

Каб вырашыць гэтую праблему, мы распрацавалі набор структураваных шаблонаў білетаў, адаптаваных да тыпу выконваемай працы. Гэтыя шаблоны гарантавалі, што кожны білет - няхай гэта будзе справаздача аб памылцы, змяненне дызайну, запыт функцыі або задача аптымізацыі - утрымлівае ўсю неабходную інфармацыю перад абмеркаваннем або прызначэннем. Правіла было простым: калі шаблон не быў цалкам завершаны, білет не быў гатовы ні да сустрэчы, ні да распрацоўкі.

Справаздачы пра памылкі

Змены ў дызайне

Запыты аб функцыях

Задачы па аптымізацыі

Уплыў шаблонаў

Вынікі былі неадкладныя.

Мы хутка пераканаліся, што можам атрымаць прыкладна ў 3 разы больш білетаў за адну гадзінную сустрэчу па тэхнічным дызайне, чым раней. Акрамя таго, дыскусіі, якія мы праводзілі на гэтых сустрэчах, былі больш карыснымі і эфектнымі. Мы знаходзілі час, каб назваць перадавыя выпадкі, каманды, якія пацярпелі ад гэтага, і патэнцыйных перашкод або вузкіх месцаў у працэсе, рыхтуючы распрацоўшчыкаў да працы замест таго, каб марнаваць увесь свой час на тое, каб зразумець больш дэталяў. Мы таксама прымусілі сябе ўвесці ўзор, калі мы запісвалі ўсе гэтыя водгукі ў білет альбо ў апісанні, альбо ў каментарыях. Шаблоны былі пастаянным напамінам аб тым, што гэтыя дэталі важныя і што яны павінны прысутнічаць і іх лёгка знайсці. У пэўным сэнсе гэтыя шаблоны навучылі наш мозг прымяняць дакументацыю да гэтых білетаў, гарантуючы, што той, хто схапі білет, няхай гэта будзе малодшы распрацоўшчык або вопытны інжынер, будзе мець дастаткова інфармацыі, каб напісаць высакаякасны код .

Далей мы заўважылі, што нашы цыклы распрацоўкі былі больш кароткімі, нашы ацэнкі больш дакладнымі, і мы дасягалі жаданай адзнакі 100% завяршэння ў спрынтах значна часцей, чым калі-небудзь раней. Мы змаглі ачысціць нашу дошку амаль паслядоўна. Гэта не толькі важна для бізнесу, таму што яны атрымлівалі абнаўленні, калі мы сказалі ім, што яны іх атрымаюць, але гэта вельмі ўмацавала ўпэўненасць у камандзе, бо вы пастаянна ставіце сябе ў пазіцыю поспеху. Нашы зацікаўленыя бакі ўбачылі павышэнне эфектыўнасці і прапускной здольнасці і заваявалі большы давер да нашай каманды і нашага працэсу. Яны таксама заўважылі, што наш код быў больш высокай якасці, так як мы маглі марнаваць больш часу на сапраўдную праблему.

Мы з самага пачатку ведалі, што гэта палепшыць наша жыццё як распрацоўшчыкаў, але мы не ўсведамлялі, наколькі станоўчы ўплыў гэта акажа і на нашых дзелавых партнёраў.

Ключавыя вынікі для іншых каманд

Калі вы адчуваеце, што ваша каманда пастаянна абцяжараная адсутнасцю пацверджання, магчыма, варта вывучыць, ці спрацуе вам стварэнне структураваных шаблонаў квіткоў. Важна адзначыць, што распрацоўнікам патрабуецца дадатковы час, каб распрацаваць білеты з дастатковай колькасцю дэталяў для дзеянняў. Я лічу, што гэта апраўданыя выдаткі, і гэта вядзе да велізарнай эканоміі сродкаў у доўгатэрміновай перспектыве, паколькі значна паляпшае працоўныя працэсы, але важна адзначыць, што гэтыя змены адбываюцца не проста бясплатна. Хтосьці павінен прысвяціць час даследаванню і напісанню высакаякаснага тыкету, і гэты нехта, верагодна, будзе вашай камандай распрацоўшчыкаў.

З улікам сказанага, лёгка зразумець, наколькі гэта вялікая перамога для каманды. Каб пачаць, я рэкамендаваў бы зрабіць некалькі кароткіх крокаў.

Спачатку ацаніце, ці сапраўды ў вас ёсць праблема. Часам адзін ці два распрацоўшчыкі змагаюцца з дакументацыяй або перадачай ведаў, але гэта не сведчыць аб поўнай праблеме з вашымі білетамі. Магчыма, некаторыя з гэтых праблем могуць вырашыць іншыя рэчы, такія як лепшае размяшчэнне або дакументацыя.

Па-другое, калі вы выявіце, што гэта шырока распаўсюджаная праблема, якая патрабуе вырашэння, наступным крокам будзе класіфікацыя тыпаў білетаў, якія вы звычайна атрымліваеце, і якая інфармацыя патрабуецца ў кожным з іх. Відавочнымі кандыдатамі з'яўляюцца памылкі і асаблівасці, аднак, у залежнасці ад характару дзейнасці вашай кампаніі, магчыма, у вас ёсць іншыя тыпы квіткоў, якія пастаянна праходзяць праз вашу сістэму і маюць розныя патрэбы. Магчыма, ваша каманда кіруе канвеерам ETL, і вам трэба ведаць, якія ўводы/вывады ўплываюць на звязаныя з гэтым білеты. Магчыма, ваша каманда валодае SDK, і заяўкі, звязаныя з ім, павінны апрацоўвацца асаблівым/прыярытэтным чынам і павінны ўключаць у сябе, якія бізнес-функцыі могуць быць закрануты зменамі? Ведайце сваю каманду і яе патрабаванні, каб вы маглі дакладна вызначыць, якія тыпы шаблонаў патрэбныя.

Затым, калі ў вас будзе ўся гэтая інфармацыя, змесціце яе ў пісьмовым выглядзе ў агульным месцы, да якога кожны будзе мець доступ. Магчыма, гэта агульны дакумент або вікі-старонка, якой каманда кіруе і мае доступ, або, магчыма, вы нават можаце ствараць шаблоны ў самой Jira, прымушаючы людзей выкарыстоўваць іх. Незалежна ад вашага падыходу, вы павінны атрымаць бай-ін ад каманды і распрацоўшчыкаў, што азначае, што яны павінны бачыць гэта. Гэта адзін з самых важных крокаў, таму што гэты працэс не працягнецца, калі ў вас няма 100% бай-іна ад тых, хто будзе пісаць білеты. Прадстаўце гэтыя шаблоны вашай камандзе, збярыце водгукі, растлумачце, як вы думаеце, што гэты новы працэс паўплывае на вас і вашых зацікаўленых бакоў. Пераканайцеся, што ўсім членам каманды падабаецца новы працэс.

Нарэшце , вы павінны прымусова выканаць гэтыя змены. Квіткі, прадстаўленыя без дастатковай колькасці дэталяў, павінны быць неадкладна адкінуты назад без абмеркавання. Важна строга прытрымлівацца рэкамендацый па шаблонах, інакш людзі заўсёды знойдуць прычыны абысці гэта. «Гэтае пытанне занадта крытычнае, у мяне няма часу, каб яго напісаць» - частая скарга, якую мы атрымлівалі. Аднак, строга ставячыся да неабходнасці шаблону і працуючы з людзьмі, якія спрабуюць яго абысці, вы ў канчатковым выніку заваюеце іх.

У Wayfair мы ўбачылі значныя паляпшэнні ў працэсе нашай каманды, а таксама ў маральным духу, унёсшы невялікія змены, пералічаныя вышэй. Я спадзяюся, што гэта таксама дапаможа вашай камандзе.