Работа с бэклогом задач с точки зрения проектного менеджера в Retail Rocket

    Хабр, привет! Мы продолжаем делиться с сообществом внутренней кухней Retail Rocket, и сегодня расскажем о нашем подходе к работе с бэклогом. Правильная приоритезация задач — это первый шаг в решении таких важных проблем проекта как:

    • уменьшение технического долга,
    • поддержка скорости работы производства,
    • поддержка качества продукта.

    За годы существования проекта у нас сложилась система, при которой вся работа со списком задач подчиняется двум принципам: «не начинай новое, если не закончил старое» и «всегда расчищай место для нового функционала».

    Вот как эти два принципа воплощаются в правила приоритезации бэклога.



    Первый приоритет всегда отдается работе с багами


    Если вы уверены, что нашли баг, его следует исправить в первую очередь, до разработки любого нового функционала. Следовать этому правилу необходимо по следующим причинам:

    • Баг- это ранее разработанный функционал, в котором допущена ошибка, а следовательно, подчиняется первому принципу «не начинай новое, если не закончил старое».
    • Из-за багов в системе может быть затруднена разработка новых функций системы, т.к. эти функции приходится вписывать в среду с багами. Это не только сложно, но и деморализует команду. Здесь вступает в силу второй принцип «всегда расчищай место для нового функционала».

    Вторым приоритетом идут все доработки по созданному ранее функционалу


    Важно подчеркнуть, что речь идет не о расширении функционала, а о доработках, каких-то неточностей (они могут быть довольно существенные). Если вдруг после выпуска функционала в бой выяснилось, что какие-то детали не были учтены на этапе проектирования, эти доработки должны идти по приоритету сразу после багов. Причина, по которой этот тип задач идет впереди остальных, та же, что и в работе с багами — это ранее начатый, но не законченный функционал, а значит, нужно закончить все доработки прежде, чем браться за что-то новое.

    Третий по значимости приоритет — задачи по удалению старого функционала или MVP-разработок, которые оказались не нужны


    Я еще не встречал компаний за свою практику (а это более 10 компаний в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют. Каждая новая фича увеличивает стоимость производства следующей фичи, иными словами сделать 10-ю фичу в проекте гораздо проще, чем 5000-ую фичу. Это происходит из-за того, что при разработке последней надо разобраться, как она вписывается во все 4999 ранее сделанных фич.

    Также большое кол-во фич снижает скорость сборки проекта и скорость прохождения тестов, что в совокупности сильно усложняет работу над 5000-ой фичей, а значит снижение количества фич в проекте положительно влияет на скорость производства новых.

    И в последнюю очередь нужно заниматься задачами по разработке нового функционала


    Мы разработали для себя следующую формулу: на каждые 3 человеко-дня разработки нового функционала берутся в работу 2 человеко-дня на устранение технического долга и 2 человеко-дня на улучшения системы в целом (intangible задачи). О коэффициентах (2 или 3 человеко-дня) можно спорить, и они, конечно же, могут и должны меняться в зависимости от этапов жизни проекта. Но сама идея о том, что на каждый затраченный на новый функционал человеко-день, мы должны выполнить и задачи по техническому долгу, и задачи по улучшению системы в целом, довольно очевидна.

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

    Пишите в комментариях ваши мысли о том, как вы работаете в бэклогом и делитесь ссылками на материалы которые вам понравились.

    Андрей Чиж,
    CTO Retail Rocket


    P.S.
    Мы всегда рады новым членам команды и у нас открыто сразу несколько вакансий на позицию “.NET Разработчик”. Наш технологический стек и уровень задач можно оценить в самом первом посте на Хабре. Резюме можно прислать сразу мне на почту avchizh@retailrocket.ru (HR-ов у нас нет, общаться будем сразу напрямую).
    • +13
    • 3,6k
    • 2
    Retail Rocket 95,71
    Платформа для персонализации интернет-магазинов
    Поделиться публикацией
    Комментарии 2
    • +2
      Максимализм в полный рост. «Если вы уверены, что нашли баг, его следует исправить в первую очередь» и т.д. Окей, а если мы выкатываем MVP или PoC или у нас раунд финансирования на носу и он сильно зависит от фич и баг не ломает намертво фичи или затрагивает Х% пользователей и т.д.?

      Обычно баг оценивается по severity и сколько пользователей затронуто. Например 1% не проходит логин или 100% не видят доп. данные на дашборде, пока не обновят страницу. И потом решение принимается с учетом целей проекта, тактических и стратегических, которые следуют бизнес-целям. И общих рекомендаций здесь быть не может.
      Проект может вырабатывать свои правила скоринга и приоритезации дефектов, но этот скоринг напрямую зависит от целей и меняется часто.
      И если итерацию назад баг 1 был приоритетнее бага 2, то сегодня наоборот. Меняются цели. Что-то можно разрулить некодовыми изменениями.

      Ладно, это уже статья в комментариях начала разводиться.

      Догматизм — это практически всегда плохо.
      • 0
        Мне кажется ваш текст только подчеркивает то, что из правил есть исключения. И этим и отличаются опытные менеджеры, они знают в какой момент правила не работают. Не скажу, что автор статьи на 100% прав, но считаю что правила и догмы нужны, чтобы не придумывать велосипед каждый день заново.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое