Оптимизирање на состаноци за технолошки дизајн со структурни шаблони за билети

Кога ја добив мојата работа во Wayfair во 2020 година, бев возбуден што ќе се приклучам на слаб, лош тим кој одржуваше b2b алатка која водеше огромни количини на бизнис. Доаѓав од улога каде што работев претежно во силос, па бев особено возбуден што повторно ќе бидам дел од развојниот тим. Меѓутоа, многу брзо открив дека голем дел од тимот има толкава експертиза за алатките што ги користевме што ја имаа оваа однапред одредена претпоставка дека другите програмери го имаат истото искуство, искуство и знаење што го имале. Главниот проблем беше што алатките на кои работевме беа внатрешни и сопственички, така што многу од поновите програмери не ги познаваа толку добро како искусните развивачи. Сега, ова воопшто не е проблем. Сепак, стана многу проблематично кога билетите на Jira беа креирани, приоритетни, проценети и доделени со малку детали. Секако, насловот го објасни општото прашање, а искусниот програмер кој го напиша веројатно знаеше точно од каде да почне да бара за да направи промени, но оние од нас кои беа понови на платформите имаа многу малку да се надоврзат за да започнете. Ова предизвика огромни дупки во ефикасноста, каде што постојано ги баравме посериозните програмери за повеќе информации. Друг нуспроизвод на оваа поставеност беше тоа што нашите состаноци за технолошки дизајн имаа тенденција да се одолговлекуваат бидејќи сè повеќе од нас имаа прашања за билетите што беа претставени за проценка. Постојано се вадеа детали во разговорот, но никој не се снима. Овие состаноци ќе се одолговлекуваат, а потоа истите прашања ќе се појавуваат откако ќе се додели тикетот (освен ако нарачателот би можел магично да се сети на разговорот од пред неколку недели каде што првично биле поставени прашањата). Овој работен тек беше неверојатно фрустрирачки и неефикасен. Но, има надеж! Кратко време откако го препознавме ова прашање и разговаравме за него, состаноците почнаа да течат понепречено, одземаа помалку време и беа повлијателни. Билетите беа богати со детали и лесни за акција, тестирање и комплетирање. Еве како го направивме тоа. Проблемот: Неподготвени билети и долги состаноци Нашите состаноци за технолошки дизајн честопати беа исфрлени од шините со билети на кои им недостасуваа доволно детали. Програмерите, дизајнерите и другите засегнати страни би потрошиле премногу време барајќи дополнителни информации или разјаснување на нејасните аспекти на задачата. Ова не само што ги продолжи нашите состаноци, туку и го одложи развојот бидејќи доделените билети честопати се враќаа, што бара повеќе разјаснување пред да продолжи работата. Одличен пример за ова може да биде билет што бил пријавен од овластен мајстор кој едноставно навел „Треба да ги поправиме цените за подот за подови“. Јасно е дека без доволно количество на заднински информации нема апсолутно ништо што можете да направите кога ќе го добиете овој билет. Што е проблемот со цените на подот? Што се очекува да се случи? Дали е важна количината на sku во количката? Има многу отворени прашања и навистина нема начин да се започне со работа без да скокне на состанок. Може да биде подобар опис на билетот. „Подните скали имаат рефусна цена и нашиот систем не се справува правилно со математиката за цените/количината кога количината во количката ги надминува праговите за масовно цени“. Сега, сè уште нема доволно детали овде, но барем правилно го објаснува проблемот. Нема да го заморувам примерот, но развивачот(ите) би морале да ги објаснат сите овие детали со повторени прашања, разговори и презентации додека немаме доволно детали за проценка или работа на билетот, во зависност од моменталната задача. Ова доведе до многу изгубено време што ние, како програмери, не можевме да го вратиме. Решението: Имплементација на шаблони за билети За да го решиме овој проблем, развивме сет на структурирани шаблони за билети прилагодени на видот на работата што се врши. Овие шаблони гарантираа дека секој билет - без разлика дали е извештај за грешка, промена на дизајнот, барање за функции или задача за оптимизација - ги содржи сите потребни информации пред да се дискутира или додели. Правилото беше едноставно: ако шаблонот не беше целосно завршен, билетот не беше подготвен за состанок или за развој. Извештаи за грешки Опис: Краток, но детален опис на проблемот Очекувано однесување: Подетално објаснување, вклучувајќи слики од екранот или референци на Figma, за тоа како работите треба да функционираат. Реално однесување: Детален опис за тоа што се случува и како тоа се разликува од очекуваното однесување Чекори за повторно создавање: Специфични, детални, чекори за тоа како да се рекреира проблемот. Ова треба да се пристапи така што некој може да отвори нов прозорец за инкогнито во алатката и да го рекреира проблемот без да отстапува од чекорите. (изборно) Забелешки за програмерите: Ова е изборен дел каде што можеме да вклучиме предложени пристапи ако веќе имаме добра идеја за тоа каде треба да оди или како треба да се развие. Не сакаме да ги принудуваме програмерите да ги прават работите на одреден начин, но секое упатство овде може да помогне да се забрза извршувањето на билетите подоцна. (изборно, но претпочитано) Надворешни влијанија: Ова е местото каде што ги повикуваме сите надворешни извори што може да влијаат на оваа работа. Дали има тимови кои веќе создале решение за грешка во нашето API, а кои ќе треба да бидат известени кога ќе го поправиме? Дали оваа грешка се потпира на други тимови/apis/извори за информации кои потенцијално би можеле да влијаат на тоа колку време е потребно за да се поправи ова? (опционално) Влијание: Дали ова има познато, мерливо влијание врз тимот или бизнисот? Ова не е секогаш познато или лесно за мерење, поради што е изборно поле. Но, важно е да се знае за приортизација ако постои. Промени во дизајнот Опис: Краток, но детален опис на проблемот Очекувано однесување: Слики од екранот или Figma врски за очекуваното, дизајнирано однесување. Реално однесување: Слики од екранот или видеа со детали за тоа што всушност се случува, како и опис на она што се случува и како тоа се разликува од очекуваното однесување (изборно) Чекори за повторно создавање: Ако ова е специфичен елемент на интерфејсот што се појавува само во одредени ситуации, треба точно да знаеме како/кога треба да биде присутно за да знаеме како да ги тестираме нашите промени. (изборно) Забелешки за програмерите: Ова е изборен дел каде што можеме да вклучиме предложени пристапи ако веќе имаме добра идеја за тоа каде треба да оди или како треба да се развие. Не сакаме да ги принудуваме програмерите да ги прават работите на одреден начин, но секое упатство овде може да помогне да се забрза извршувањето на билетите подоцна. (опционално) Влијание: Дали ова има познато, мерливо влијание врз тимот или бизнисот? Ова не е секогаш познато или лесно за мерење, поради што е изборно поле. Но, важно е да се знае за приортизација ако постои. Барања за карактеристики Опис: Целосна детална слика за тоа што е карактеристиката. Како треба да функционира, кои се очекуваните влезови/излези, итн. Тука треба да го вклучиме и секое резонирање што го имаме за тоа зошто оваа функција се бара. Забелешки за програмерите: Програмерот треба да го користи овој дел за да обезбеди насоки за познати рамки/шеми што треба да се користат за беспрекорно да се вклопат во остатокот од нашата база на кодови. Не сакаме да ги принудиме програмерите да пишуваат код на одреден начин, но секое упатство овде ќе го направи извршувањето на билетите побрзо и треба да доведе до попрецизни ПР разговори. (опционално, но претпочитано) Макети: Ако имаме примери за носивост, слики од екранот или референци за Figma кои треба да го водат развојот, сето ова треба да биде вклучено овде. (изборно, но претпочитано) Надворешни влијанија: Ова е местото каде што ги повикуваме сите надворешни извори што може да влијаат на оваа работа. Дали има тимови кои веќе создале решение за функцијата што недостасува во нашето API, а кои ќе треба да бидат известени кога ќе ја додадеме? Дали оваа функција се потпира на други тимови/апи/извори за информации кои потенцијално би можеле да влијаат на тоа колку време е потребно за да се изгради ова? (опционално) Влијание: Дали ова има познато, мерливо влијание врз тимот или бизнисот? Ова не е секогаш познато или лесно за мерење, поради што е изборно поле. Но, важно е да се знае за приортизација ако постои. Задачи за оптимизација Опис: Краток, но детален опис на проблемот Тековна состојба: Подетално објаснување за тоа како моментално работи кодот и зошто е неефикасен. Претпочитана држава: Детален опис на она што сакаме да го поправиме со оваа оптимизација, кои цели се обидуваме да ги постигнеме Забелешки за програмерите: Ова е водич од развивачот кој ја повикува потребата за оптимизација. Ова треба да повика специфични датотеки и тестови што треба да се уредуваат, како и специфичните делови за кои веруваме дека се тесно грло во перформансите или предизвикуваат конфузија. : Тестирање Забелешки за тоа како оваа оптимизација може да се потврди или потврди. Не само што треба да видиме дека навистина добивме нешто од овој процес (и можеби е нешто со кое можеме да се пофалиме), туку треба да потврдиме и дека промените не влијаеле на ниту еден познати надворешни процеси кои се потпирале на кодот изменета. Надворешни влијанија: Ова е местото каде што ги повикуваме сите надворешни извори што може да влијаат на оваа работа. Дали оваа функција се потпира на други тимови/apis/извори за информации кои потенцијално би можеле да влијаат на тоа колку време е потребно за да се изгради или тестира ова? Влијание: Дали ова има познато, мерливо влијание врз тимот или бизнисот? Ова не е секогаш познато или лесно да се измери, но за да се оправда рефактор или оптимизација треба да ги имаме овие информации. Влијанието на шаблоните Резултатите беа веднаш. Видовме брзо дека можеме да добиеме околу 3 пати повеќе билети на еден часовен состанок за технолошки дизајн отколку што можевме порано. Исто така, дискусиите што ги водевме на овие состаноци беа покорисни и повлијателни. Одвојувавме време да ги повикаме рабните случаи, погодените тимови и потенцијалните затварачи или тесни грла во процесот, подготвувајќи ги развивачите за работата наместо да го трошиме целото наше време обидувајќи се да сфатиме повеќе детали. Ние, исто така, се присиливме на шема каде што ги снимивме сите овие повратни информации во билетот или во описот или во коментарите. Шаблоните беа постојан потсетник дека овие детали се важни и дека треба да бидат присутни и лесно да се најдат. На некој начин, овие шаблони повторно го обучија нашиот мозок да преземе пристап до документацијата кон овие билети, осигурувајќи дека секој што ќе го земе билетот, без разлика дали е помлад развивач или искусен инженер, ќе има доволно информации за да напише некој висококвалитетен код. . Следно, забележавме дека нашите развојни циклуси беа поконцизни, нашите проценки беа попрецизни и дека ја постигнувавме посакуваната ознака за 100% завршување на спринтови многу почесто отколку што некогаш сме имале. Бевме во можност да ја исчистиме нашата табла речиси постојано. Не само што е важно за бизнисот затоа што добиваа ажурирања кога им кажавме дека ќе ги добијат, туку тоа беше огромно засилување на самодовербата за тимот бидејќи постојано се ставате себеси во позиција на успех. Нашите засегнати страни ја видоа нашата подобрена ефикасност и пропусната моќ и стекнаа поголема доверба во нашиот тим и нашиот процес. Тие, исто така, забележаа дека нашиот код е со повисок квалитет, бидејќи можевме да трошиме повеќе време фокусирајќи се на вистинскиот проблем. Од самиот почеток знаевме дека ова ќе ни го подобри животот како програмери, но не знаевме колку позитивно ќе има влијание и врз нашите деловни партнери. Клучни средства за преземање за други тимови Ако се чувствувате како вашиот тим постојано да е оптоварен со недостаток на инфирмација, можеби вреди да се испита дали креирањето структурирани шаблони за билети може да работи за вас. Важно е да се запамети дека ова бара дополнително време на програмерите да ги обработи билетите со доволно детали за акција. Верувам дека ова е оправдана цена и води до огромни заштеди на долг рок бидејќи неверојатно ги подобрува вашите работни текови, но важно е да се повика дека овие промени не се случуваат само бесплатно. Некој треба да посвети време на истражување и пишување висококвалитетен билет и дека некој најверојатно ќе биде вашиот тим за развој. Како што е кажано, лесно е да се види колку голема победа може да биде ова за еден тим. За да започнете, би препорачал неколку кратки чекори. , проценете дали навистина имате проблем или не. Понекогаш еден или двајца програмери се борат со документација или трансфер на знаење, но тоа не е показател за целосен проблем со вашите билети. Можеби други работи, како што е подобро подигање или документација, може да решат некои од тие проблеми. Прво ако сфатите дека ова е широко распространето прашање за кое треба да се реши, следниот чекор е да категоризирате каков тип билети вообичаено добивате и каков тип на информации се потребни за секој од нив. Очигледните кандидати се грешки и карактеристики, но во зависност од природата на бизнисот на вашата компанија, можеби имате други видови билети кои постојано течат низ вашиот систем и имаат различни потреби. Можеби вашиот тим управува со гасоводот ETL и треба да знаете кои влезови/излези се под влијание на билетите поврзани со тоа. Можеби вашиот тим поседува SDK и билетите поврзани со него треба да се постапуваат на посебен/приоритетен начин и треба да вклучи кои деловни функции би можеле да бидат засегнати од промената? Знајте го вашиот тим и неговите барања за да можете точно да одредите какви типови шаблони се потребни. Второ, откако ќе ги имате сите овие информации, ставете ги на писмено некаде споделено до кое секој има пристап. Можеби ова е споделен документ, или вики-страница на која тимот управува и пристапува, или можеби дури и можете да креирате шаблони во самиот Jira, принудувајќи ги луѓето да ги користат. Без разлика каков е вашиот пристап, треба да добиете согласност од тимот и програмерите, што значи дека тие треба да можат да го видат. Ова е еден од најважните чекори бидејќи овој процес нема да оди понатаму освен ако немате 100% купување од секој што ќе пишува билети. Презентирајте ги овие шаблони на вашиот тим, собирајте повратни информации, објаснете како мислите дека овој нов процес ќе влијае на вас и на вашите засегнати страни. Погрижете се сите во тимот да се чувствуваат удобно со новиот процес. Следно, , треба да ги спроведете овие промени. Билетите презентирани без доволно детали треба веднаш да се фрлат назад без дискусија. Важно е да се биде строг за следење на упатствата за шаблоните или луѓето секогаш ќе најдат причини да го заобиколат. „Ова прашање е премногу критично, немам време да го напишам“ е вообичаена поплака што ја добиваме. Меѓутоа, ако сте строги со потребата за шаблон и работите со луѓе кои се обидуваат да го заобиколат, на крајот ќе ги освоите. Последно На Wayfair видовме огромни подобрувања во процесот на нашиот тим, како и моралот со правење на малите промени наведени погоре. Се надевам дека ова ќе му помогне и на вашиот тим.