Сейчас я работаю с большой командой, которая строит продукт под несколько клиентских платформ (мобилки и веб), а также через бекенд интегрирована с другими системами компании. Долгое время команда делилась на компонентные подкоманды: iOS, Android, Web, Back. Казалось бы, это самый оптимальный вариант – объединить сотрудников одной компетенции вместе, добавить им тестировщиков, и пусть они выпустят нам готовый продукт. На деле же между подкомандами существует множество зависимостей по API, по способу реализации фич, по продуктовой работе и так далее.
Очень часто у нас возникали такие проблемы:
- Бекенд всегда реализовывал API новых фич первым. И даже если были договоренности на старте, они могли быть неполными или ошибочными. В результате клиентские платформы вынуждены были подстраиваться, либо ждать, пока бекенд доделает требуемое в следующем спринте.
- Команды стеснялись обращаться друг к другу, часто возникала проблема противопоставления «мы-они», хотя ребята работали над общим продуктом.
- Команды клиентских платформ реализовывали различные решения, т.к. делали это в разное время. То есть частенько изобретали велосипед, не получая знаний от тех, кто уже делал эту задачу.
- Time to market в целом по фиче на всех платформах растягивался на многие месяцы.
- Скорость работы по новым фичам снижалась, так как постоянно оставались определенные хвосты по старым задачам.
После очередного обсуждения на тему «вы опять там с API накосячили», мы решили сделать кросс-функциональные команды или фича-тимы.
Команда кросс-функциональна, если в команде есть все компетенции, чтобы реализовать фичу на всех клиентских платформах разом. При этом крайне важно, чтобы члены такой команды физически сидели вместе, в одном кабинете. Желательно, чтобы в такой команде было побольше T-shaped людей, которые прокачаны в чем-то одном, но могут и готовы помогать своим товарищам на других направлениях.
Поначалу у ребят были сомнения по поводу идеи кросс-функциональных команд. Основные их опасения были на счет того, что они будут сидеть далеко от остальных компонентных команд и будут оторваны от их работы. Однако сомнения развеялись почти сразу после того, как мы стали работать по-новому. Уже никто не хотел покидать новую команду.
На небольшой ретроспективе после пары месяцев работы кросс-функциональной команды ребята сами отметили следующие плюсы:
- Коммуникации стали существенно короче. Достаточно повернуть голову в сторону коллеги и договориться сразу. Раньше такого обсуждения могло и не возникать, были недосказанности.
- Ребята стали развиваться в смежных областях. Кто-то в тестировании, кто-то в бэкенде, кто-то в авто-тестах.
- API по новым фичам согласовывалось одновременно всеми платформами и на старте фич.
- Существенно упростилась и ускорилась отладка проблем. Мобильному разработчику и бэкендеру достаточно совместно воспроизвести проблему и изучить логи.
- Тестирование начинается раньше: когда есть пусть и не до конца готовая задача, ее можно тестировать одновременно как со стороны API, так и со стороны клиентского приложения.
- Команда фокусируется на задаче, улучшается погружение в контекст, так как все занимаются одной задачей.
- Оказалось, что нужно меньше митингов, и остается больше времени на работу.
- Ребята стали предлагать кроссплатформенные решения, что стало экономить время. Например, кроссплатформенный эмулятор API.
- У членов команды уравниваются знания о продукте и знание различных нюансов работы.
- Унифицируются решения. Если раньше даже iOS и Android команды могли делать фичу по-разному, то теперь перестали изобретать велосипеды.
- Сократился time to market фичи: на все 3 клиентские платформы функционал выходит одновременно (почти).
- Возрос командный дух и мотивация команды.
- Ребята поняли, что оказывается нужно учиться договариваться об общих решениях (например, об API), а не перепихивать проблему на другую команду.
Не обошлось и без минусов:
- Периодически возникают перекосы по загрузке членов фича-тимы. Например, фронтенд может делать фичу в разы быстрее бэкенда. В условиях, когда фронтендер не готов (или пока не готов) переквалифицироваться в тестировщика или бекендера, он вынужден брать другие задачи из бэклога.
- Меньше связь с компонентными командами в рамках своей компетенции. Раньше архитектурные решения на какой-то одной платформе обсуждались сразу. Теперь необходимы отдельные воркшопы для таких задач.
- Необходимость быть T-shaped замедляет сотрудников на первых порах. Требуется время, чтобы разобраться в смежных компетенциях.
Что мы также отметили, поработав в концепции фича-тимов?
- Прежде всего это, что не все сотрудники готовы к такого рода работе: много договариваться, быть T-shaped. Надеюсь это временная проблема.
- Также осталась необходимость в компонентных командах (пусть и в меньших составах), которые отвечают за «корневые» архитектурные решения на платформе, финальную интеграцию, а также решают задачи, не требующие зависимости от других платформ.
- Необходим так называемый «налог на бэклог». Это когда фича-тима делает не только фичи, но и до 20% времени уделяет прочим небольшим улучшениям и багофиксу. Такая практика необходима, чтобы у фича-тимов не возникало соблазна делать задачи «спустя рукава», если они будут уверены, что их ошибки им не вернутся. Это также необходимо, чтобы решение багов не было уделом или повинностью компонентных команд.
- Чтобы не отрываться от других команд и работать на общее дело, члены фича-тимов продолжают участвовать в перекрестном ревью кода, в проработке долгосрочных архитектурных решений, в регрессе приложений перед выпуском, в наполнении базы автотестов.
Теперь я ни за что не откажусь от работы с кросс-функциональными командами. Они доказали и продолжают доказывать свою эффективность. Если вы работаете только с компонентными командами, советую вам пересмотреть свой подход. Посмотрите еще в сторону примеров от Spotify.
Фото pixabay.com
0 коммент.:
Post a Comment