Как да се справим с бъгове, изоставане, приоритет и комуникация с Burndown Framework

В две предишни публикации аз представих как създадохме собствената си рамка за изграждане на продукт в Drift (Burndown) и говорих как всъщност можете да внедрите Burndown Framework във вашата собствена компания във втория ми пост.

Сега е време да поговорим за нещата, които понякога се чувстват вторични в процеса, които всъщност са ключови за правилното протичане на всички тези неща. Тези неща са ...

  1. Справяне с бъгове
  2. Работа с изоставането на вашия продукт
  3. Избор на това, което да се даде приоритет на следващия
  4. Седмична честота на напълно прозрачни актуализации

1 - Справяне с бъгове

Вярваме, че бъговете трябва да бъдат изцяло собственост на инженерния екип. По този начин проблемите на Github са къде живеят. Когато се появяват грешки, всеки от екипа може да създаде проблем с Github. Ако това е грешка, отчетена от клиент, ние му даваме червен етикет „Bug“ в Github и публикуваме връзка към разговора, където е била докладвана. Ние даваме приоритет на тези грешки пред останалите.

Като общо правило, ние изразходваме около 20% от времето си за справяне с бъгове, а останалите 80% за нови функции, работа с инфраструктура и подобрения на съществуващите функции.

Тъй като грешките се появяват, зависи от преценката на инженера, която се нуждае от незабавно внимание и която може да задържи за малко. Ето защо етикетът "Bug" в Github е толкова важен, тъй като увеличава видимостта и спешността във факта, че се случва за платен клиент, което може да доведе до отшумяване, ако грешката е критична.

Докато внедрявахме Burndown, през първите няколко месеца, веднъж седмично, продуктовият мениджър на всеки екип би седнал с технологичното ръководство и ще премине през изоставането на бъгове в репостите на Github, които техният екип притежава. По този начин министър-председателят и инженерите могат да се приведат в съответствие с това, което е най-важно, защо и да се научат да се доверяват на преценката на един друг във времето.

Тъй като принципите и рамката на Бърндоун стават все повече част от културата и тъй като премиерът ще се довери на инженерите да правят същите призиви, които и те, тази среща вече не беше необходима на седмична база. Сега, в началото на всяка седмица (обикновено през уикенда), технологичните водещи и инженерите ще преминат през проблемите на Github и ще изберат най-важните най-важни бъгове, с които планират да се справят през тази седмица.

Тъй като Бърндоун не работи в трудни седмични цикли, постоянно се въвеждат грешки, които изискват от нас веднага да спрем това, което правим и да се справим, така че гарантираме, че оставяме допълнителен капацитет, за да се справим с тези, докато се появят така по тях може да се работи паралелно.

2 - Управление на изоставането на вашия продукт

Досега може би се чудите ... какво правите с изоставането си, което има идеи за 4, 6 и 12 месеца? Къде съхранявате цялата тази информация и я поддържате организирана?

В зависимост от размера на вашето изоставане, борда на Trello, който използвате за изпълнение на рамката на Burndown, може да започне да се прекъсва от твърде много списъци в крайната дясна част на дъската, което е напълно добре. Това се случи с нас. Така ние се развихме.

Сега ние използваме основния продукт на борда Trello само като място, където обхващаме и документираме микроспринтове, които всъщност ще бъдат направени. Ако нещо е там повече от месец и продължава да се натиска и никога не се прави, това означава, че това не е основен приоритет и вероятно никога няма да бъде. Така че архивираме този списък.

Рамката на Burndown е проектирана да ви фокусира върху това, което е в краткосрочен и близък план около нещата с най-висок ливъридж, които можете да правите. Всичко, което е проектирано и обхванато за 3+ месеца, освен ако не сте по-голяма, изключително структурирана организация, често ще се промени драстично до момента, в който така или иначе достигнете до това време. Имахме дизайнер в един от нашите екипи да получи 3+ месеца по-напред от екипа и в крайна сметка повечето от това, което тя проектира, никога не го направиха светлината на деня, защото бързо научихме, че искаме да поемем нещата в друга посока. И това е добре Това е, което се регистрираме за използване на Burndown. Най-лошият сценарий там би бил да продължи да прилага тези проекти, просто защото те вече са готови. Тъй като Бърндоун по своята същност е гъвкав, ни позволи лесно да кажем „не“ и да предприемем различен курс, който имаше повече обещания.

Ако сте като мен и сте фокусирани върху развитието на клиентите, все още се нуждаете от място, което да организира всички отзиви на клиентите, които получавате ежеседмично и ежедневно. Бих препоръчал или да направите различна дъска на Trello, която да държи всички тези идеи и коментари, или да продължите да разширявате ширината на дъската си Trello за неопределено време, стига да преминете през нея и да го проверите на всеки няколко седмици и да архивирате неща, които не са в съответствие с мястото, където продуктът отива.

3 - Избор на това, което да се даде приоритет на следващия

Най-добрият начин да определите какъв следващ най-важен списък е да се запитате това ...

„Кое е единственото нещо, което осигурява най-голяма полза за нашите клиенти и привежда в съответствие с нашите бизнес цели и фокуси?“

Отговорът на този въпрос би трябвало да ви осигури нещото, което ще ви даде най-голям ефект в дългосрочен план, за да продължите да добавяте стойност към клиентите си. Въпросът е производно на въпроса, който Гари Келер поставя в книгата си „Единственото нещо“, която е „Какво е единственото нещо, което мога да направя в момента, за да направя всичко останало по-лесно или ненужно?“ Ние сме големи почитатели на тази философия в Дрифтът, както вярваме, ни помага да се съсредоточим върху правилните неща.

Ние също тематично структурираме предстоящите приоритети на компанията, които поставяме в един слайд или списък и го повтаряме отново и отново на екипа. В нашия случай примерният списък би изглеждал така ...

  1. Поддържане на продукта стабилен
  2. Шофиране на повече регистрации
  3. Увеличаване на скоростта на активиране
  4. Иновация на нашата чат джаджа

Това ни дава всички насоки за справка, когато се питаме върху какво бихме могли да се съсредоточим по-нататък. Ако не можете да направите нещо, което е пряко в полза №1, тогава работете върху нещо, което влияе на №2 и т.н.

4 - Ежеседмична честота на напълно прозрачни актуализации

Тъй като рамката на Бърндоун е тази, която непрекъснато се измества, тъй като микро спринтовете вътре в нея непрекъснато се придвижват, за да съответстват на нуждите, желанията и желанията на клиента, важно е да се уверите, че екипът е на път и има важни етапи за постигане.

Ето как оставаме в съответствие с приоритетите в петък в Drift, продуктовият мениджър ще седне с техническото ръководство на всеки екип и ще говори през предстоящите микро спринтове на борда на Trello за около 5–10 минути. Понякога е ясно кое е следващото най-важно нещо и веднага сме на същата страница. Друг път ще бъдат изведени добри точки в разговора, а микро спринтовете / списъците ще бъдат изместени малко и договорени като фокуси за предстоящата седмица.

Всяка неделя вечер продуктовият мениджър записва вътрешен уики пост с тактическа разбивка, кои списъци от Trello ще бъдат фокусирани върху предстоящата седмица и каква стойност предоставят на клиента. Това обикновено отнема 1-2 часа, но си струва 100%, за да поддържате екипа подравнен, когато се появят на следващата сутрин. Ако се прави правилно, това е единственото управление на проекти, което ръководителят на продуктите ще трябва да прави седмично.

Този пост има четири части (всяка разбита на секции за всеки продуктов екип)…

  1. Съобщение, което ще изпратим на клиентите в петък, ако изпратим всичко, което планираме да изпратим
  2. Визуални снимки / екрани (от картите HIGH LEVEL в Trello) на това, което ще бъде доставено
  3. Разбивка на това, върху което се фокусира всеки инженер и дизайнер
  4. Списък на това, което е изпратено от предишната седмица

В горната част на тази вътрешна публикация (№1 в списъка) е писменото изявление, насочено към клиентите на Drift. Това изявление е написано така, сякаш е петъкът в края на седмицата; точно това бихме обявили на клиентите си в края на седмицата, ако изпълним всички микро спринтове, с които планирахме да се справим. Ето пример за такъв за нашия екип за уеб приложения ...

Тогава за част № 2 пускам скрийншоти на всички функции, групирани по екип. Обикновено му давам бързо заглавие и пускам пълен екран, като този ...

За част № 3 съставих списък с букви за всеки инженер и дизайнер. Целта на това е да бъдете кратки и просто да покажете на всички от компанията, към кого да се обърнете за нещо конкретно през седмицата. И да документират това, което всеки инженер и дизайнер е казал, са техните приоритети. Обикновено правя бърза проверка на Slack с членовете на екипа в края на всяка седмица, за да чуя какво им е на ум и да коригирам нещо, ако е необходимо. През повечето време премиерът вече трябва да има представа какво прави всеки инженер и дизайнер от други разговори, които се случват през седмицата. Ето пример за това как изглежда тази трета част ...

Част №4 е кратък списък на това, което е изпратено и какво все още е в ход. Това е за екипите за продажби и успех да видят какво е направено и какво почти има. Изглежда така ...

Не забравяйте, че в рамките на всяка седмица може да има 2–4 микро спринта и ние доставяме нещата веднага след приключването им. Тези седмични проверки и актуализации служат повече като начин да се гарантира, че всеки има представа за това как изглежда напредъкът и осезаемо средство да каже „имах продуктивна седмица“, преди да тръгнат в петък. Нещата, публикувани в неделната актуализация, не са списък „това трябва да се направи, независимо какво“. Понякога нещата ще се случат и нещата, които планирахме да направим, вече не се работи, тъй като се появи нещо с по-висок приоритет, което може да повлияе по-добре на текущите ни приоритети / теми на компанията.

-

Започваме да експериментираме с нов начин за комуникация на целите на компанията и приоритетите на продуктите, за които вероятно ще говоря в следваща публикация.

Моля, уведомете ме дали има други въпроси, които бихте могли да имате относно рамката на Burndown. Вярвам, че обхванах всички необходими аспекти как да направите тази работа във вашата собствена компания, така че уведомете ме, ако чувствате, че въпросите все още не са отговорили чрез коментар.

Написах и пълна електронна книга по тази тема с Дейвид Отказ. Виж това!