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

Калі я ўладкаваўся на працу ў Wayfair у 2020 годзе, я быў вельмі рады далучыцца да стройнай, лагоднай каманды, якая падтрымлівала інструмент b2b, які стварыў велізарны бізнес. Я прыходзіў з пасады, дзе я працаваў у асноўным у бункеры, таму я быў асабліва рады зноў стаць часткай каманды распрацоўшчыкаў. Аднак я вельмі хутка заўважыў, што большая частка каманды мае такі вялікі вопыт у інструментах, якімі мы карыстаемся, што ў іх было прадвызначанае здагадка, што іншыя распрацоўшчыкі валодаюць такім жа вопытам, вопытам і ведамі, што і яны. Асноўная праблема заключалася ў тым, што інструменты, над якімі мы працавалі, былі ўнутранымі і запатэнтаванымі, таму многія новыя распрацоўшчыкі не ведалі іх так добра, як вопытныя распрацоўшчыкі. Зараз гэта не праблема ў цэлым. Аднак гэта стала вельмі праблематычным, калі білеты Jira былі створаны, расстаўлены па прыярытэтах, ацэнены і прызначаны з невялікай колькасцю дэталяў. Безумоўна, назва тлумачыла агульную праблему, і дасведчаны распрацоўшчык, які яе напісаў, верагодна, дакладна ведаў, з чаго пачаць пошук, каб унесці змены, але тым з нас, хто быў пачатковец у платформах, было вельмі мала чаго абапірацца, каб пачаць. Гэта прывяло да вялізных дзірак у эфектыўнасці, у выніку чаго мы пастаянна патрабавалі ад больш штатных распрацоўшчыкаў дадатковай інфармацыі. Яшчэ адным пабочным прадуктам гэтай налады было тое, што нашы сустрэчы па тэхнічным дызайне, як правіла, зацягваліся, бо ўсё больш і больш з нас узнікалі пытанні наконт білетаў, якія прадстаўляліся для ацэнкі. У размове пастаянна высвятляліся падрабязнасці, але нічога не запісвалася. Гэтыя сустрэчы зацягнуліся, а потым тыя ж пытанні ўзніклі зноў, як толькі білет быў прызначаны (калі толькі праванаёмнік не мог чароўным чынам успомніць размову тыдня таму, калі пытанні былі зададзены першапачаткова). Гэты працоўны працэс быў неверагодна расчаравальным і неэфектыўным. Але надзея ёсць! Неўзабаве пасля таго, як мы заўважылі гэтую праблему і абмеркавалі яе, сустрэчы сталі праходзіць больш гладка, займаць менш часу і быць больш эфектыўнымі. Квіткі былі багатыя падрабязнасцямі, з імі было лёгка дзейнічаць, тэставаць і запаўняць. Вось як мы гэта зрабілі. Праблема: непадрыхтаваныя білеты і працяглыя сустрэчы Нашы сустрэчы па тэхнічным дызайне часта збіваліся з-за білетаў, у якіх не было дастаткова падрабязнасцей. Распрацоўшчыкі, дызайнеры і іншыя зацікаўленыя бакі марнавалі б занадта шмат часу на пошук дадатковай інфармацыі або высвятленне расплывістых аспектаў задачы. Гэта не толькі падоўжыла нашы сустрэчы, але і затрымала распрацоўку, бо прызначаныя білеты часта вярталіся назад, што патрабавала дадатковых тлумачэнняў, перш чым праца магла працягвацца. Выдатным прыкладам гэтага можа быць білет, пра які паведаміў штатны распрацоўшчык, у якім проста сцвярджалася: «Нам трэба выправіць цэны на падлогавыя пакрыцця». Відавочна, што без дастатковай колькасці даведачнай інфармацыі вы абсалютна нічога не зможаце зрабіць, калі атрымаеце гэты білет. У чым праблема з цэнамі на падлогавыя нумары? Што чакаецца? Ці мае значэнне колькасць інвентара ў кошыку? Ёсць шмат адкрытых пытанняў, і сапраўды немагчыма пачаць працу, не заскочыўшы на сустрэчу. Лепшае апісанне білета можа быць. «На мінімальныя нумары прызначаецца аптовая цана, і наша сістэма не апрацоўвае належным чынам цану/колькасць, калі колькасць у кошыку перавышае парог аптовага цэнаўтварэння». Цяпер тут усё яшчэ недастаткова дэталяў, але, па меншай меры, гэта правільна тлумачыць праблему. Я не збіраюся спыняць прыклад, але распрацоўшчык(ы) павінны былі б удакладніць усе гэтыя дэталі з дапамогай паўторных пытанняў, размоў і прэзентацый, пакуль у нас не будзе дастаткова дэталяў для ацэнкі або працы над білетам, у залежнасці ад бягучага задача. Гэта прывяло да вялікай колькасці страчанага часу, які мы, як распрацоўшчыкі, не змаглі вярнуць. Рашэнне: укараненне шаблонаў білетаў Каб вырашыць гэтую праблему, мы распрацавалі набор структураваных шаблонаў білетаў, адаптаваных да тыпу выконваемай працы. Гэтыя шаблоны гарантавалі, што кожны білет - няхай гэта будзе справаздача аб памылцы, змяненне дызайну, запыт функцыі або задача аптымізацыі - утрымлівае ўсю неабходную інфармацыю перад абмеркаваннем або прызначэннем. Правіла было простым: калі шаблон не быў цалкам завершаны, білет не быў гатовы ні да сустрэчы, ні да распрацоўкі. Справаздачы пра памылкі Апісанне: Кароткае, але падрабязнае апісанне праблемы Чаканыя паводзіны: Больш падрабязнае тлумачэнне таго, як усё павінна працаваць, уключаючы здымкі экрана або спасылкі на Figma. Фактычныя паводзіны: Падрабязнае апісанне таго, што адбываецца і чым гэта адрозніваецца ад чаканых паводзін Крокі для аднаўлення: Канкрэтныя, падрабязныя крокі, як узнавіць праблему. Да гэтага трэба падысці так, каб нехта мог адкрыць новае акно інкогніта ў інструменце і аднавіць праблему, не адхіляючыся ад крокаў. (неабавязкова) Заўвагі распрацоўшчыка: Гэта неабавязковы раздзел, у які мы можам уключыць прапанаваныя падыходы, калі ў нас ужо ёсць добрае ўяўленне аб тым, куды гэта павінна ісці або як гэта трэба развіваць. Мы не хочам прымушаць распрацоўшчыкаў рабіць рэчы пэўным чынам, але любыя інструкцыі тут могуць дапамагчы паскорыць выкананне білетаў пазней. (неабавязкова, але пажадана) Знешнія ўздзеянні: Тут мы паказваем любыя знешнія крыніцы, якія могуць паўплываць на гэтую працу. Ці ёсць каманды, якія ўжо стварылі абыходны шлях для памылкі ў нашым API, якім трэба будзе паведаміць, калі мы яе выправім? Ці залежыць гэтая памылка ад іншых каманд/прыкладных праграм/крыніц для атрымання інфармацыі, якая патэнцыйна можа паўплываць на тое, колькі часу патрабуецца для выпраўлення? (неабавязкова) Уплыў: Гэта аказвае вядомы, вымерны ўплыў на каманду або бізнес? Гэта не заўсёды вядома або лёгка вымераць, таму гэта неабавязковае поле. Але важна ведаць, ці ёсць прыярытэты. Змены ў дызайне Апісанне: Кароткае, але падрабязнае апісанне праблемы Чаканыя паводзіны: Скрыншоты або спасылкі на Figma для чаканага распрацаванага паводзінаў. Фактычныя паводзіны: Скрыншоты або відэа з падрабязным апісаннем таго, што адбываецца на самой справе, а таксама апісаннем таго, што адбываецца і чым гэта адрозніваецца ад чаканых паводзін (неабавязкова) Крокі для аднаўлення: Калі гэта пэўны элемент інтэрфейсу, які з'яўляецца толькі ў пэўных сітуацыях, мы павінны дакладна ведаць, як/калі ён павінен прысутнічаць, каб мы ведалі, як праверыць нашы змены. (неабавязкова) Заўвагі распрацоўшчыка: Гэта неабавязковы раздзел, у які мы можам уключыць прапанаваныя падыходы, калі ў нас ужо ёсць добрае ўяўленне аб тым, куды гэта павінна ісці або як гэта трэба развіваць. Мы не хочам прымушаць распрацоўшчыкаў рабіць рэчы пэўным чынам, але любыя інструкцыі тут могуць дапамагчы паскорыць выкананне білетаў пазней. (неабавязкова) Уплыў: Гэта аказвае вядомы, вымерны ўплыў на каманду або бізнес? Гэта не заўсёды вядома або лёгка вымераць, таму гэта неабавязковае поле. Але важна ведаць, ці ёсць прыярытэты. Запыты аб функцыях Апісанне: Поўная дэталёвая карціна таго, што гэта за функцыя. Як ён павінен функцыянаваць, якія чаканыя ўваходы/вывады і г.д. Мы таксама павінны ўключыць любыя аргументы, якія мы маем, чаму гэтая функцыя запытваецца тут. Заўвагі распрацоўшчыка: Распрацоўшчык павінен выкарыстоўваць гэты раздзел, каб даць рэкамендацыі па вядомых фрэймворках/шаблонах, якія трэба выкарыстоўваць, каб бесперашкодна ўпісвацца ў астатнюю частку нашай кодавай базы. Мы не хочам прымушаць распрацоўшчыкаў пісаць код нейкім пэўным чынам, але любыя рэкамендацыі тут паскораць выкананне заяўкі і павінны прывесці да больш рацыянальных PR-размоў. (неабавязкова, але пажадана) Макеты: Калі ў нас ёсць прыклады карысных нагрузак, скрыншоты або спасылкі на Figma, якія павінны накіроўваць распрацоўку, усё гэта трэба ўключыць сюды. (неабавязкова, але пажадана) Знешнія ўздзеянні: Тут мы паказваем любыя знешнія крыніцы, якія могуць паўплываць на гэтую працу. Ці ёсць каманды, якія ўжо стварылі абыходны шлях для адсутнай функцыі ў нашым API, якім трэба будзе паведаміць, калі мы яе дадамо? Ці абапіраецца гэтая функцыя на іншыя каманды/прыкладныя праграмы/крыніцы для атрымання інфармацыі, якая патэнцыйна можа паўплываць на тое, колькі часу спатрэбіцца для стварэння? (неабавязкова) Уплыў: Гэта аказвае вядомы, вымерны ўплыў на каманду або бізнес? Гэта не заўсёды вядома або лёгка вымераць, таму гэта неабавязковае поле. Але важна ведаць, ці ёсць прыярытэты. Задачы па аптымізацыі Апісанне: Кароткае, але падрабязнае апісанне праблемы Бягучы стан: Больш падрабязнае тлумачэнне таго, як зараз працуе код і чаму ён неэфектыўны. Пераважны штат: Падрабязнае апісанне таго, што мы імкнемся выправіць з дапамогай гэтай аптымізацыі, якія мэты мы спрабуем дасягнуць Заўвагі распрацоўшчыка: Гэта кіраўніцтва ад распрацоўшчыка, які падкрэслівае неабходнасць аптымізацыі. Гэта павінна выклікаць пэўныя файлы і тэсты, якія неабходна адрэдагаваць, а таксама пэўныя раздзелы, якія, на нашу думку, з'яўляюцца вузкім месцам у прадукцыйнасці або выклікаюць блытаніну. : Тэставанне Нататкі аб тым, як гэтую аптымізацыю можна пацвердзіць або праверыць. Нам трэба не толькі пераканацца, што мы сапраўды нешта атрымалі ад гэтага працэсу (і гэтым можам пахваліцца), але нам таксама трэба пераканацца, што змены не паўплывалі на любыя вядомыя знешнія працэсы, якія абапіраюцца на код змянілася. Знешнія ўздзеянні: Тут мы паказваем любыя знешнія крыніцы, якія могуць паўплываць на гэтую працу. Ці абапіраецца гэтая функцыя на іншыя каманды/прыкладныя праграмы/крыніцы інфармацыі, якая патэнцыйна можа паўплываць на тое, колькі часу спатрэбіцца для стварэння або тэставання? Уплыў: Гэта аказвае вядомы, вымерны ўплыў на каманду або бізнес? Гэта не заўсёды вядома або лёгка вымераць, але для таго, каб апраўдаць рэфактарынг або аптымізацыю, нам патрэбна гэтая інфармацыя. Уплыў шаблонаў Вынікі былі неадкладныя. Мы хутка пераканаліся, што можам атрымаць прыкладна ў 3 разы больш білетаў за адну гадзінную сустрэчу па тэхнічным дызайне, чым раней. Акрамя таго, дыскусіі, якія мы праводзілі на гэтых сустрэчах, былі больш карыснымі і эфектнымі. Мы знаходзілі час, каб назваць перадавыя выпадкі, каманды, якія пацярпелі ад гэтага, і патэнцыйных перашкод або вузкіх месцаў у працэсе, рыхтуючы распрацоўшчыкаў да працы замест таго, каб марнаваць увесь свой час на тое, каб зразумець больш дэталяў. Мы таксама прымусілі сябе ўвесці ўзор, калі мы запісвалі ўсе гэтыя водгукі ў білет альбо ў апісанні, альбо ў каментарыях. Шаблоны былі пастаянным напамінам аб тым, што гэтыя дэталі важныя і што яны павінны прысутнічаць і іх лёгка знайсці. У пэўным сэнсе гэтыя шаблоны навучылі наш мозг прымяняць дакументацыю да гэтых білетаў, гарантуючы, што той, хто схапі білет, няхай гэта будзе малодшы распрацоўшчык або вопытны інжынер, будзе мець дастаткова інфармацыі, каб напісаць высакаякасны код . Далей мы заўважылі, што нашы цыклы распрацоўкі былі больш кароткімі, нашы ацэнкі больш дакладнымі, і мы дасягалі жаданай адзнакі 100% завяршэння ў спрынтах значна часцей, чым калі-небудзь раней. Мы змаглі ачысціць нашу дошку амаль паслядоўна. Гэта не толькі важна для бізнесу, таму што яны атрымлівалі абнаўленні, калі мы сказалі ім, што яны іх атрымаюць, але гэта вельмі ўмацавала ўпэўненасць у камандзе, бо вы пастаянна ставіце сябе ў пазіцыю поспеху. Нашы зацікаўленыя бакі ўбачылі павышэнне эфектыўнасці і прапускной здольнасці і заваявалі большы давер да нашай каманды і нашага працэсу. Яны таксама заўважылі, што наш код быў больш высокай якасці, так як мы маглі марнаваць больш часу на сапраўдную праблему. Мы з самага пачатку ведалі, што гэта палепшыць наша жыццё як распрацоўшчыкаў, але мы не ўсведамлялі, наколькі станоўчы ўплыў гэта акажа і на нашых дзелавых партнёраў. Ключавыя вынікі для іншых каманд Калі вы адчуваеце, што ваша каманда пастаянна абцяжараная адсутнасцю пацверджання, магчыма, варта вывучыць, ці спрацуе вам стварэнне структураваных шаблонаў квіткоў. Важна адзначыць, што распрацоўнікам патрабуецца дадатковы час, каб распрацаваць білеты з дастатковай колькасцю дэталяў для дзеянняў. Я лічу, што гэта апраўданыя выдаткі, і гэта вядзе да велізарнай эканоміі сродкаў у доўгатэрміновай перспектыве, паколькі значна паляпшае працоўныя працэсы, але важна адзначыць, што гэтыя змены адбываюцца не проста бясплатна. Хтосьці павінен прысвяціць час даследаванню і напісанню высакаякаснага тыкету, і гэты нехта, верагодна, будзе вашай камандай распрацоўшчыкаў. З улікам сказанага, лёгка зразумець, наколькі гэта вялікая перамога для каманды. Каб пачаць, я рэкамендаваў бы зрабіць некалькі кароткіх крокаў. ацаніце, ці сапраўды ў вас ёсць праблема. Часам адзін ці два распрацоўшчыкі змагаюцца з дакументацыяй або перадачай ведаў, але гэта не сведчыць аб поўнай праблеме з вашымі білетамі. Магчыма, некаторыя з гэтых праблем могуць вырашыць іншыя рэчы, такія як лепшае размяшчэнне або дакументацыя. Спачатку калі вы выявіце, што гэта шырока распаўсюджаная праблема, якая патрабуе вырашэння, наступным крокам будзе класіфікацыя тыпаў білетаў, якія вы звычайна атрымліваеце, і якая інфармацыя патрабуецца ў кожным з іх. Відавочнымі кандыдатамі з'яўляюцца памылкі і асаблівасці, аднак, у залежнасці ад характару дзейнасці вашай кампаніі, магчыма, у вас ёсць іншыя тыпы квіткоў, якія пастаянна праходзяць праз вашу сістэму і маюць розныя патрэбы. Магчыма, ваша каманда кіруе канвеерам ETL, і вам трэба ведаць, якія ўводы/вывады ўплываюць на звязаныя з гэтым білеты. Магчыма, ваша каманда валодае SDK, і заяўкі, звязаныя з ім, павінны апрацоўвацца асаблівым/прыярытэтным чынам і павінны ўключаць у сябе, якія бізнес-функцыі могуць быць закрануты зменамі? Ведайце сваю каманду і яе патрабаванні, каб вы маглі дакладна вызначыць, якія тыпы шаблонаў патрэбныя. Па-другое, калі ў вас будзе ўся гэтая інфармацыя, змесціце яе ў пісьмовым выглядзе ў агульным месцы, да якога кожны будзе мець доступ. Магчыма, гэта агульны дакумент або вікі-старонка, якой каманда кіруе і мае доступ, або, магчыма, вы нават можаце ствараць шаблоны ў самой Jira, прымушаючы людзей выкарыстоўваць іх. Незалежна ад вашага падыходу, вы павінны атрымаць бай-ін ад каманды і распрацоўшчыкаў, што азначае, што яны павінны бачыць гэта. Гэта адзін з самых важных крокаў, таму што гэты працэс не працягнецца, калі ў вас няма 100% бай-іна ад тых, хто будзе пісаць білеты. Прадстаўце гэтыя шаблоны вашай камандзе, збярыце водгукі, растлумачце, як вы думаеце, што гэты новы працэс паўплывае на вас і вашых зацікаўленых бакоў. Пераканайцеся, што ўсім членам каманды падабаецца новы працэс. Затым, , вы павінны прымусова выканаць гэтыя змены. Квіткі, прадстаўленыя без дастатковай колькасці дэталяў, павінны быць неадкладна адкінуты назад без абмеркавання. Важна строга прытрымлівацца рэкамендацый па шаблонах, інакш людзі заўсёды знойдуць прычыны абысці гэта. «Гэтае пытанне занадта крытычнае, у мяне няма часу, каб яго напісаць» - частая скарга, якую мы атрымлівалі. Аднак, строга ставячыся да неабходнасці шаблону і працуючы з людзьмі, якія спрабуюць яго абысці, вы ў канчатковым выніку заваюеце іх. Нарэшце У Wayfair мы ўбачылі значныя паляпшэнні ў працэсе нашай каманды, а таксама ў маральным духу, унёсшы невялікія змены, пералічаныя вышэй. Я спадзяюся, што гэта таксама дапаможа вашай камандзе.