Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - страница 4

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

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

Каждый успешный продукт или фича в нем начинается с аналитики – глубокого исследования и проработки требований к продукту. В классических компаниях для этого существуют две ключевые роли: бизнес-аналитик и системный аналитик. Хотя иногда эти роли смешиваются, на практике они являются разными и требуют отдельной экспертизы и навыков. Поэтому для достижения максимальной эффективности от проработки требований рекомендуется формировать команду, состоящую из отдельных доменов бизнес-анализа и системного анализа.

Аналогичная ситуация наблюдается и в разработке. Фулстек-специалисты, обладая широким спектром знаний и навыков, часто имеют свои сильные и слабые стороны в одном из направлений разработки. Например, фулстек-разработчик может быть более компетентен в backend-разработке, нежели в frontend-разработке, или наоборот. Важно понимать, что каждый член команды имеет свои уникальные навыки и экспертизу, которые могут принести значительную пользу проекту.

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

– — – — – — – — – — – — – — – — – — – —

Кейс: системный и бизнес-аналитик в одном лице

Суть: нам довелось поработать с несколькими аналитиками, которые на тот момент не смогли однозначно идентифицировать себя в одной или другой области анализа. В чем выражалась некоторая неопределенность, разберемся подробнее. Бизнес-аналитик начинает свой путь с проработки новых или уже существующих бизнес-процессов, составляет схемы процесса, прокапывает детали и взаимосвязи. Результатом его работы должен стать оптимальный клиентский путь, который является максимально дешевым с точки зрения разработки для снижения time to market и в то же время решает ключевую бизнес-задачу с понятной ценностью для компании или клиента. Суть работы системного аналитика – имея понятный бизнес-процесс, наложить все это на системы и сервисы, описать взаимодействие систем, новые функции и модели данных, что уже после перейдет непосредственно в команду разработки.

Именно тут и кроется распыление активностей в аналитике. Если быстро перейти к проработке системной аналитики, не уделив должного внимания самому процессу, то впоследствии это превращается в ряд доработок после обсуждения с владельцем продукта или проведением внутреннего демо для бизнес-заказчика. А все потому, что не учтены специфические нюансы бизнеса и, как следствие, процесс, дальнейшее описание работы системы и ожидаемый после разработки результат являются ложными. К сожалению, такие вещи несут под собой не только double costs для команды и компании, но и сильно увеличивают time to market для критических для бизнеса фичей. А теперь представьте ситуацию: в Сибири появился новый логистический хаб, куда свозят товары крупнейшие поставщики из Китая или других стран. В ритейл-компаниях появляется задача оптимизации логистики до конечных клиентов, которая учитывает изменение маршрутов с учетом наличия ассортимента на новом складе. Если поддержку такой бизнес-фичи затянуть, то конкуренты, оптимизировав доставку раньше, смогут снизить цены на товары в своих интернет-магазинах и, как следствие, для тебя и твоей компании это будет потеря GMV