Системный сдвиг

Услышал тут про интересную практику: когда бизнес-аналитики сопровождают разработку какой-то фичи до конца.

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

Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'

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

Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.

Звучит очень круто — для тех, кто стремится охватить весь процесс целиком, всё контролировать и связывать — от бизнес-целей до технических деталей.

Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.

Забавно почитать, как у программистов-"я-хочу-просто-писать-код-отстаньте-от-меня" через силу отрастают менеджерские, аналитические и продуктовые функции. Как в фильме ужасов, когда кого-то укусил монстр или кто-то что-то не то выпил. У БА-"я-хочу-просто-описывать-требования-отстаньте-от-меня" тоже что-то примерно такое же происходит. Сложно отращивать новые лапки и усики.

Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).

Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.

Как пишут на scrum.org:

Ответственность — обязательство выполнить задачу. Ответственность часто заключается в выполнении работы и создании ее результата.
Подотчетность — принятие на себя ответственности за результаты или итог работы. Готовность нести последствия и отвечать за сделанный выбор.

Ну и когда у тебя есть эта самая Accountability — ты не просто отмахиваешься "на моем участке всё сделано, это дальше разработчики всё не так поняли", а идёшь и добиваешься значимого результата. Не всем нужно, не все могут. Но в этом и рост.

❤27👍15🫡4🔥2🤔1

www.group-telegram.com/us/systemswing.com/725

4.17K viewsApr 25 at 07:08

Услышал тут про интересную практику: когда бизнес-аналитики сопровождают разработку какой-то фичи до конца.

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

Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'

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

Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.

Звучит очень круто — для тех, кто стремится охватить весь процесс целиком, всё контролировать и связывать — от бизнес-целей до технических деталей.

Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.

Забавно почитать, как у программистов-"я-хочу-просто-писать-код-отстаньте-от-меня" через силу отрастают менеджерские, аналитические и продуктовые функции. Как в фильме ужасов, когда кого-то укусил монстр или кто-то что-то не то выпил. У БА-"я-хочу-просто-описывать-требования-отстаньте-от-меня" тоже что-то примерно такое же происходит. Сложно отращивать новые лапки и усики.

Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).

Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.

Как пишут на scrum.org:

Ответственность — обязательство выполнить задачу. Ответственность часто заключается в выполнении работы и создании ее результата.
Подотчетность — принятие на себя ответственности за результаты или итог работы. Готовность нести последствия и отвечать за сделанный выбор.

BY Системный сдвиг