В зрелых кросс-функциональных командах существует понятие фича-лида.

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

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

У нас довольно зрелая команда, поэтому практически каждый инженер становится фича-лидом по той или иной задаче. Это позволяет сильно разгрузить тимлида и повысить качество каждой отдельно взятой функциональности.

Зачем это инженеру?

Если с синьорами все понятно (это их обязанности), то для менее опытных инженеров - это в первую очередь:

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

Есть также и неявные преимущества, но тут большая вариативность для каждого индивидуально.

Что делает фичалид?

Лучше всего, когда инженер получает фичу на самом раннем этапе и доводит ее до запуска в прод, но бывают исключения, когда лидерство может передаваться по ходу реализации (плохая практика).

Разобьем процесс по этапам:

🌎 Дискавери

  • Погружается в контекст: пытается понять что и для чего мы делаем. Какие метрики при достижении результата важны.
  • Коммуникация с внешними командами для уточнения контекста.

🚚 Передача в разработку

  • Помощь тимлиду в составлении роадмапа на квартал
  • Составление роадмапа по своей фиче и декомпозиция работ
  • Обсуждение открытых вопросов на груминге, фасилитация процесса и фиксирование договоренностей
  • При необходимости: организация встречи 3 Амиго
  • Проработка рисков, моделирование угроз, обсуждение метрик и мониторинга фичи

🛠 Разработка

  • Качественное описание задач и критериев приемки либо делегация и контроль перед взятием задач в работу
  • Активное участие в планировании и взятии задач в спринт в соответствии с роадмапом
  • Полное владение контекстом на время разработки, взаимодействие с внешними командами и саппорт коллег по возникающим вопросам
  • Согласование изменений в контрактах и фиксация всех артефактов по результатам обсуждений
  • Обнаружение проблем по ходу и предложение альтернативных путей реализации
  • Обеспечение качества совместно с QA

🚀 Запуск

  • Если есть АБ-эксперимент, то его заведение или контроль заведения
  • Оповещение стейкхолдеров о запуске
  • Запуск
  • Поддержка запущенной фичи: реакция на баги, помощь коллегам по вопросам связанным с фичой

Как инженер, который активно занимается фича-лидерством, отмечу, что это отличный опыт, который нужно обязательно получать, если подворачивается возможность.

Особенно, если этот процесс вас пугает.

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

Но если вас что-то действительно пугает, то рекомендую начать это делать. Сразу заметите как начнете расти, а потом вас уже будет не остановить и это войдет в привычку.

Читайте оригинальный пост и присоединяйтесь к обсуждению в Телеграм: @time2code