Привет!
Итак, как мы сражались с остальными всадниками.
🔥 Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.
Этот противник может воздействовать на всю команду и компанию. Его коварство заключается в том, что в определённый момент он может победить и вас, если вы будете недостаточно настойчивыми.
Выиграть здесь возможно только через создание новой системы мотивации, в которой продукт должен не только существовать, но и быть лучшим на рынке, самым стабильным и востребованным. Но здесь без продакта не обойтись)
Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта
Критерии обязательно должны быть засмартованы, чтобы и бизнесу, и разработке был очевиден переход от одного уровня к другому.
🔥 Недальновидность. Чем больше багов у вас в продукте, тем меньше скорость поставки решений до клиента в будущем. Недальновидность образуется там, где нет четкого планирования и ответственности за принятые решения. Но чтобы изменить ситуацию важно провести ретроспективу.
Во-первых, команде нужно будет признать, что ранее принятые решения действительно создают множество проблем и выявить их причины. Имеет смысл проводить это регулярно и чинить процессы, а не людей.
Во-вторых, начинайте всегда с изменений, которые обойдутся команде малой кровью и при этом дадут максимальный результат (принцип Парето, да-да).
Ну и очевидное, проведите ретроспективу, на которой вы покажите результат проведенных изменений.
К каким же результатам мы пришли в Skyeng:
🍀 количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
🍀 Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
🍀 Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
🍀 В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.
Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать 😜
Итак, как мы сражались с остальными всадниками.
🔥 Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.
Этот противник может воздействовать на всю команду и компанию. Его коварство заключается в том, что в определённый момент он может победить и вас, если вы будете недостаточно настойчивыми.
Выиграть здесь возможно только через создание новой системы мотивации, в которой продукт должен не только существовать, но и быть лучшим на рынке, самым стабильным и востребованным. Но здесь без продакта не обойтись)
Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта
Критерии обязательно должны быть засмартованы, чтобы и бизнесу, и разработке был очевиден переход от одного уровня к другому.
🔥 Недальновидность. Чем больше багов у вас в продукте, тем меньше скорость поставки решений до клиента в будущем. Недальновидность образуется там, где нет четкого планирования и ответственности за принятые решения. Но чтобы изменить ситуацию важно провести ретроспективу.
Во-первых, команде нужно будет признать, что ранее принятые решения действительно создают множество проблем и выявить их причины. Имеет смысл проводить это регулярно и чинить процессы, а не людей.
Во-вторых, начинайте всегда с изменений, которые обойдутся команде малой кровью и при этом дадут максимальный результат (принцип Парето, да-да).
Ну и очевидное, проведите ретроспективу, на которой вы покажите результат проведенных изменений.
К каким же результатам мы пришли в Skyeng:
🍀 количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
🍀 Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
🍀 Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
🍀 В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.
Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать 😜