Как стигнахме до нулеви грешки и приложихме политика за нулеви грешки

И така, колко грешки имате във вашето изоставане? Стотици? Повече ▼? По-малко? Не сте съвсем сигурни? Е, мога да ви кажа колко грешки са в нашето изоставане в момента. Броят на грешките в нашето изоставане е ... изчакайте ... ZERO. Нула, зилч, нада. Не четете това погрешно Нямаме грешки в нашето изоставане. - Ние не само имаме нулеви грешки в нашето изоставане, но смятаме да го запазим по този начин с нашата политика за нулеви грешки. Как постигнахме този невероятен момент и как смятаме да се придържаме към нулевите бъгове, движещи се напред? Отговорът не е толкова сложен, колкото може би си мислите, но не и без препятствия.

Първо, малко история

Преди малко повече от 2 години, когато се присъединих към ConceptShare, за да ръководя в екипа за качество, имаше над 350 документирани грешки в изоставането (не луди, но и не малки). Първият ми въпрос след надникване дълбоко в бездната беше „Мога ли да изтрия всички бъгове, които са над една година? Какво ще кажете за всички грешки, които са на възраст над шест месеца? "Отговорът, разбира се, беше" Не "- има знания, съдържащи се в този обширен списък на бъгове, знания, които бихме могли да използваме, за да подобрим качеството на нашия продукт и от своя страна да подобрим опит за нашите клиенти. В същото време, ние все още се нуждаем от начин за справяне с изоставането на стари грешки, заедно с всички нови грешки, които оказват влияние върху клиентското изживяване, И продължаваме разработването на нови функции и подобрения на продуктите.

Защо е важно да се стигне до нула грешка?

Наличието на бъгове в изостаналото събиране на прах наистина е гадно.

  1. Това е гадно за нашите клиенти, тъй като бъговете влияят върху ефективността на нашия продукт - не ни харесва това. Ние искаме нашите клиенти да използват и да изпитват нашия продукт по начина, по който е било предназначено да бъде изпитан - без обходни ситуации, без „упс, това сме пропуснали“, не „няма да го извадим…… след като бъдат отстранени тези други грешки…“. Нашата прогресивна политика поставя нашите клиенти отпред и в центъра, което ни позволява да се съсредоточим върху техния опит с нашия продукт и прехвърляме разговора от „Би било хубаво, ако ConceptShare направи X правилно“ на „Това работи чудесно! Нека да проучим още начини, по които ConceptShare може да ни помогне да свършим работата си “.
  2. Това е гадно за нашите съветници за творчески операции, които са нашата първа линия подкрепа за нашите клиенти. Вместо да прекарват времето си в изслушване на едни и същи оплаквания от клиенти относно известни бъгове и не могат да предоставят никаква реална времена за това кога ще бъдат поправени, те могат да прекарват времето си, показвайки на нашите клиенти новите и вълнуващи начини ConceptShare им помага да започнат работата си Свършен. Това означава, че те могат да преместят фокуса си от обслужване / поддръжка на клиенти към истински успех на клиента.
  3. И накрая, това е гадно за нашия екип за разработка на продукти. Навигацията през съществуващите недостатъци при изграждането на нови функции добавя ненужно време и сложност към тяхната работа, което означава по-малко функции и подобрения, което в крайна сметка се отразява на нашите клиенти. Да можеш да кажеш „кое голямо нещо следваме?“ Е невероятно освежаващо от „Трябва ли да поправим тези грешки, преди да стартираме тази функция?“ Съществуващите бъгове не са „gotcha“ за нова работа и държи нашия екип за разработка да се фокусира върху идеи и иновации, а не корекции на грешки.

Получаване на вход

Да имаш идея да стигнеш до Zero Bugs и да приложиш стратегия и политика около нея беше едно. Преди да успеем дори да планираме как ще се справим, се нуждаехме от поддръжка и вход от старшия мениджърски екип. В противен случай изпращането на нови функции и отговарянето на заявки на клиентите винаги би поставило корекции на грешки на задната горелка. Ето случая, който направихме:

- Защо тази важна цел беше да се стремим? 1. за нашите клиенти (външно) и 2. за членове на нашия екип (вътрешно)

- Каква е текущата цена на нашето изоставане на грешки (производителност, невъзможност за изпращане на повече функции по-бързо), загубени приходи, въздействие върху растежа на сметките и загуба на пари за ненужна инфраструктура за поддържане на нивата на ефективност)

- Как бихме стигнали до нула?

- Как да поддържаме нашата политика за нулеви грешки, след като достигнем нула?

Трябваше време и няколко цикъла на дискусия, за да се наложи изцяло изпълнителният ни директор на борда. Идеята да отделим време за разработка единствено за намаляване на броя на нашите грешки не изглеждаше възможна. Въпреки това, обяснявайки горното, стана ясно, че става въпрос не само за нулеви грешки. Това беше за много повече за нашите клиенти, за нашия екип и за способността ни да продължаваме да иноваваме и изграждаме продукт, който нашите клиенти обичат. (и най-долната ни линия!)

Успяхме да го вземем от „WTF! Няма начин да посветим толкова усилия на това “на„ Това има абсолютен смисъл. Какво ви трябва, за да го направите? ”Не само, че го спечелихме, но той написа своя публикация по темата и сега е ревностен привърженик на нулевите грешки!

Приготвяме се да започнем

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

Коригиране на плана

Тъй като първият ни подход за достигане до нула бъгове не се получи точно както се очакваше, започнахме да обмисляме различни начини да се справим с това. Оказва се, че успешният подход за адресиране на бъгове беше точно пред нас, ние никога не сме обмисляли да приложим подхода към корекции на грешки. В ConceptShare работим в това, което наричаме „Feature Teams“ - давайки възможност на екипа на разработчиците да работи върху функциите, които ги интересуват най-много. Това е чудесен подход, защото ние трябва да предизвикаме себе си и да изберем върху какво работим. Щастливо мислене на работниците и всичко останало. Така че, помислихме си какво, ако третираме бъгове като всяка друга функция? Щеше ли някой от екипа на разработчиците да се интересува от смазване на бъгове, докато всички ги няма? имаше членове на екипа, които с удоволствие приеха това предизвикателство и ни заведоха в Zero Bugs. Създава се екип, прави план и се захваща за работа.

Направихме го! Нулеви бъгове. Сега какво?

След 18 месеца всеотдайна работа, някои дебати за това как да насочим усилията си, някои малки промени в нашия процес и два месеца преди нашата целева дата - постигнахме целта си - имаме нулеви грешки в нашето изоставане. Повтарям. Ние имаме грешки в ZERO. Това е фантастичен момент за постигане. Екипът ни е в екстаз. И сега какво?

  1. Внесохме нова политика за нулеви грешки:

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

2. Нашият екип за грешки се е върнал към работата с функциите на продуктите, което им позволява да избират следващата си функция (и), като има предвид, че заедно с други членове на нашия продуктов екип остават ангажирани с нашата политика за нулеви грешки.

3. Нашият продуктов екип продължава да се стреми да разраства нашия продукт, без да се притеснявате да се забавим поради стари бъгове. Вече можем да поставим крака си на газ и да доставим много повече функции и подобрения по-бързо, отколкото можехме преди

4. Нашите съветници за творчески операции вече са в състояние да се съсредоточат изцяло върху това да помагаме на нашите клиенти да осъзнаят всичко, което могат да постигнат с нашия продукт - без да чакат да бъдат коригирани Bug X и Bug Y.

5. И най-важното е, че нашите клиенти могат по-добре да използват ConceptShare, за да работят по-интелигентни, по-бързи и по-добри, без да бъдат затлачени от досадни грешки в софтуера.

Как да останем в Zero Bugs?

За да постигнем това, ние допълнихме нашия процес на грешки (който вероятно прилича на всеки друг процес на грешки там на високо ниво), за да се приведе в съответствие с нашата официална политика за нулеви грешки. Това са промените, които направихме:

Триаж на грешки

Нашите триажни срещи обикновено се провеждат седмично от група заинтересовани страни (PM / COAs / член на екипа на Dev и QA). Вече ще се задействат грешки при пристигането ни от нашия QA екип, който ще получи допълнителна информация от заинтересованите страни, ако тежестта / въздействието не е ясно. След това бъгове ще бъдат изпратени до екипа за продукти, за да вземе някой.

Обвързаните бъгове се претендират веднага

Опитаните бъгове вече не седят наоколо и чакат някой да започне да работи върху тях. Имаме отпуснати вградени в графики за функции, така че разработчиците също могат да отделят време за избиране на нови грешки, без да рискуват работата им с функции.

QA екип използва по-агресивен подход

Ако не се претендира за възникнала грешка (т.е. работата е започнала) в рамките на определен период от време, нашият QA екип ще се свърже с екипа за продукти, за да получи зададената грешка, така че работата може да започне.

Увеличаване на нашите повторения за издаване

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

Обобщавайки

Нулеви бъгове, има доста пръстен към него и това е доста пътуването досега с някои възходи / падения и луди заешки дупки - но това не спира до тук. През последната година и половина ние постигнахме много повече от това, че просто приехме нова политика за това как се справяме с нашите грешки тук в ConceptShare. Това вече е част от нашата култура - вградена в начина, по който работим, тъй като развиваме повече функции и възможности с най-високо качество, качество, което ще проникне в нашия най-важен участник, нашите клиенти.

Искам също да кажа огромно „БЛАГОДАРЯ!“ На екипа, който направи това. (вижте как празнувахме с пинати във формата на бъгове.)

Любопитен съм - някой друг се е опитал да стигне до нулеви бъгове и ако да - как го направи? Какво научи?

Тази история е публикувана в The Startup, където 258 400+ души се събират, за да прочетат водещите истории за предприемачеството на Medium.

Абонирайте се, за да получавате нашите топ истории тук.