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

Кога ја добив мојата работа во Wayfair во 2020 година, бев возбуден што ќе се приклучам на слаб, лош тим кој одржуваше b2b алатка која водеше огромни количини на бизнис. Доаѓав од улога каде што работев претежно во силос, па бев особено возбуден што повторно ќе бидам дел од развојниот тим. Меѓутоа, многу брзо открив дека голем дел од тимот има толкава експертиза за алатките што ги користевме што ја имаа оваа однапред одредена претпоставка дека другите програмери го имаат истото искуство, искуство и знаење што го имале. Главниот проблем беше што алатките на кои работевме беа внатрешни и сопственички, така што многу од поновите програмери не ги познаваа толку добро како искусните развивачи. Сега, ова воопшто не е проблем. Сепак, стана многу проблематично кога билетите на Jira беа креирани, приоритетни, проценети и доделени со малку детали. Секако, насловот го објасни општото прашање, а искусниот програмер кој го напиша веројатно знаеше точно од каде да почне да бара за да направи промени, но оние од нас кои беа понови на платформите имаа многу малку да се надоврзат за да започнете. Ова предизвика огромни дупки во ефикасноста, каде што постојано ги баравме посериозните програмери за повеќе информации.

Друг нуспроизвод на оваа поставеност беше тоа што нашите состаноци за технолошки дизајн имаа тенденција да се одолговлекуваат бидејќи сè повеќе од нас имаа прашања за билетите што беа претставени за проценка. Постојано се вадеа детали во разговорот, но никој не се снима. Овие состаноци ќе се одолговлекуваат, а потоа истите прашања ќе се појавуваат откако ќе се додели тикетот (освен ако нарачателот би можел магично да се сети на разговорот од пред неколку недели каде што првично биле поставени прашањата).

Овој работен тек беше неверојатно фрустрирачки и неефикасен. Но, има надеж! Кратко време откако го препознавме ова прашање и разговаравме за него, состаноците почнаа да течат понепречено, одземаа помалку време и беа повлијателни. Билетите беа богати со детали и лесни за акција, тестирање и комплетирање. Еве како го направивме тоа.

Проблемот: Неподготвени билети и долги состаноци

Нашите состаноци за технолошки дизајн честопати беа исфрлени од шините со билети на кои им недостасуваа доволно детали. Програмерите, дизајнерите и другите засегнати страни би потрошиле премногу време барајќи дополнителни информации или разјаснување на нејасните аспекти на задачата. Ова не само што ги продолжи нашите состаноци, туку и го одложи развојот бидејќи доделените билети честопати се враќаа, што бара повеќе разјаснување пред да продолжи работата.

Одличен пример за ова може да биде билет што бил пријавен од овластен мајстор кој едноставно навел „Треба да ги поправиме цените за подот за подови“.

Јасно е дека без доволно количество на заднински информации нема апсолутно ништо што можете да направите кога ќе го добиете овој билет. Што е проблемот со цените на подот? Што се очекува да се случи? Дали е важна количината на sku во количката? Има многу отворени прашања и навистина нема начин да се започне со работа без да скокне на состанок. Може да биде подобар опис на билетот.

„Подните скали имаат рефусна цена и нашиот систем не се справува правилно со математиката за цените/количината кога количината во количката ги надминува праговите за масовно цени“.

Сега, сè уште нема доволно детали овде, но барем правилно го објаснува проблемот.

Нема да го заморувам примерот, но развивачот(ите) би морале да ги објаснат сите овие детали со повторени прашања, разговори и презентации додека немаме доволно детали за проценка или работа на билетот, во зависност од моменталната задача. Ова доведе до многу изгубено време што ние, како програмери, не можевме да го вратиме.

Решението: Имплементација на шаблони за билети

За да го решиме овој проблем, развивме сет на структурирани шаблони за билети прилагодени на видот на работата што се врши. Овие шаблони гарантираа дека секој билет - без разлика дали е извештај за грешка, промена на дизајнот, барање за функции или задача за оптимизација - ги содржи сите потребни информации пред да се дискутира или додели. Правилото беше едноставно: ако шаблонот не беше целосно завршен, билетот не беше подготвен за состанок или за развој.

Извештаи за грешки

Промени во дизајнот

Барања за карактеристики

Задачи за оптимизација

Влијанието на шаблоните

Резултатите беа веднаш.

Видовме брзо дека можеме да добиеме околу 3 пати повеќе билети на еден часовен состанок за технолошки дизајн отколку што можевме порано. Исто така, дискусиите што ги водевме на овие состаноци беа покорисни и повлијателни. Одвојувавме време да ги повикаме рабните случаи, погодените тимови и потенцијалните затварачи или тесни грла во процесот, подготвувајќи ги развивачите за работата наместо да го трошиме целото наше време обидувајќи се да сфатиме повеќе детали. Ние, исто така, се присиливме на шема каде што ги снимивме сите овие повратни информации во билетот или во описот или во коментарите. Шаблоните беа постојан потсетник дека овие детали се важни и дека треба да бидат присутни и лесно да се најдат. На некој начин, овие шаблони повторно го обучија нашиот мозок да преземе пристап до документацијата кон овие билети, осигурувајќи дека секој што ќе го земе билетот, без разлика дали е помлад развивач или искусен инженер, ќе има доволно информации за да напише некој висококвалитетен код. .

Следно, забележавме дека нашите развојни циклуси беа поконцизни, нашите проценки беа попрецизни и дека ја постигнувавме посакуваната ознака за 100% завршување на спринтови многу почесто отколку што некогаш сме имале. Бевме во можност да ја исчистиме нашата табла речиси постојано. Не само што е важно за бизнисот затоа што добиваа ажурирања кога им кажавме дека ќе ги добијат, туку тоа беше огромно засилување на самодовербата за тимот бидејќи постојано се ставате себеси во позиција на успех. Нашите засегнати страни ја видоа нашата подобрена ефикасност и пропусната моќ и стекнаа поголема доверба во нашиот тим и нашиот процес. Тие, исто така, забележаа дека нашиот код е со повисок квалитет, бидејќи можевме да трошиме повеќе време фокусирајќи се на вистинскиот проблем.

Од самиот почеток знаевме дека ова ќе ни го подобри животот како програмери, но не знаевме колку позитивно ќе има влијание и врз нашите деловни партнери.

Клучни средства за преземање за други тимови

Ако се чувствувате како вашиот тим постојано да е оптоварен со недостаток на инфирмација, можеби вреди да се испита дали креирањето структурирани шаблони за билети може да работи за вас. Важно е да се запамети дека ова бара дополнително време на програмерите да ги обработи билетите со доволно детали за акција. Верувам дека ова е оправдана цена и води до огромни заштеди на долг рок бидејќи неверојатно ги подобрува вашите работни текови, но важно е да се повика дека овие промени не се случуваат само бесплатно. Некој треба да посвети време на истражување и пишување висококвалитетен билет и дека некој најверојатно ќе биде вашиот тим за развој.

Како што е кажано, лесно е да се види колку голема победа може да биде ова за еден тим. За да започнете, би препорачал неколку кратки чекори.

Прво , проценете дали навистина имате проблем или не. Понекогаш еден или двајца програмери се борат со документација или трансфер на знаење, но тоа не е показател за целосен проблем со вашите билети. Можеби други работи, како што е подобро подигање или документација, може да решат некои од тие проблеми.

Второ, ако сфатите дека ова е широко распространето прашање за кое треба да се реши, следниот чекор е да категоризирате каков тип билети вообичаено добивате и каков тип на информации се потребни за секој од нив. Очигледните кандидати се грешки и карактеристики, но во зависност од природата на бизнисот на вашата компанија, можеби имате други видови билети кои постојано течат низ вашиот систем и имаат различни потреби. Можеби вашиот тим управува со гасоводот ETL и треба да знаете кои влезови/излези се под влијание на билетите поврзани со тоа. Можеби вашиот тим поседува SDK и билетите поврзани со него треба да се постапуваат на посебен/приоритетен начин и треба да вклучи кои деловни функции би можеле да бидат засегнати од промената? Знајте го вашиот тим и неговите барања за да можете точно да одредите какви типови шаблони се потребни.

Следно, откако ќе ги имате сите овие информации, ставете ги на писмено некаде споделено до кое секој има пристап. Можеби ова е споделен документ, или вики-страница на која тимот управува и пристапува, или можеби дури и можете да креирате шаблони во самиот Jira, принудувајќи ги луѓето да ги користат. Без разлика каков е вашиот пристап, треба да добиете согласност од тимот и програмерите, што значи дека тие треба да можат да го видат. Ова е еден од најважните чекори бидејќи овој процес нема да оди понатаму освен ако немате 100% купување од секој што ќе пишува билети. Презентирајте ги овие шаблони на вашиот тим, собирајте повратни информации, објаснете како мислите дека овој нов процес ќе влијае на вас и на вашите засегнати страни. Погрижете се сите во тимот да се чувствуваат удобно со новиот процес.

Последно , треба да ги спроведете овие промени. Билетите презентирани без доволно детали треба веднаш да се фрлат назад без дискусија. Важно е да се биде строг за следење на упатствата за шаблоните или луѓето секогаш ќе најдат причини да го заобиколат. „Ова прашање е премногу критично, немам време да го напишам“ е вообичаена поплака што ја добиваме. Меѓутоа, ако сте строги со потребата за шаблон и работите со луѓе кои се обидуваат да го заобиколат, на крајот ќе ги освоите.

На Wayfair видовме огромни подобрувања во процесот на нашиот тим, како и моралот со правење на малите промени наведени погоре. Се надевам дека ова ќе му помогне и на вашиот тим.