Продолжаем обсуждать вопрос масштабирования организаций, начатый в прошлом посте. Итак, что делать, если размер команды разработки в разы превышает допустимый для линейного масштабирования или организация занимается разработкой различных продуктов? Нужно делить организацию на части. Эти части называют по-разному: трайбы, стримы, департаменты, продуктовые группы… Давайте остановимся на коротком названии трайб для удобства. Выделение трайбов - очень непростая задача, особенно в больших и запутанных организациях. Начать стоит с формализации основных потоков ценности (value streams) для клиентов организации. Фактически, вся разработка должна существовать для доставки ценности по этим потокам. Конкретные приложения, системы и сервисы - это лишь каналы для доставки. Вот ключевые критерии для выделения трайбов: - Каждый трайб должен покрывать целиком (end to end) один или несколько потоков ценности. Это позволяет бизнесу максимально эффективно экспериментировать и управлять приоритетами. - В трайбе должны быть специалисты по всему задействованному технологическому стеку. Для legacy систем возможны исключения, но необходимо реализовывать специальные подходы для использования internal open source стратегии. - Зависимости между трайбами должны быть минимальными. Это позволяет добиться лучшей предсказуемости и фокуса в разработке, избегая постоянного бардака в приоритетах. Также, у бизнеса появляется возможность независимого масштабирования трайба под свои цели и бюджеты. Идеального мира не существует, поэтому всегда будут перекосы. Например, если раньше организация строила команды вокруг разработки легаси систем, то разделить их по трайбам будет очень нетривиальной задачей. Возможно, на переходной период лучше будет их оставить в качестве компонентных сервисных команд, обслуживающих все трайбы. А потом уже потихоньку двигаться к целевой структуре. Давайте рассмотрим пример не очень удачного разделения на трайбы и к чему оно приводит. Представим, что у большой финтех компании выделили такие трайбы: Cards для карточных продуктов, Payments для платежей и Mobile для клиентских мобильных приложений. И вот, у бизнеса из Cards трайба возникает идея нового карточного продукта, частью которого являются льготные платежи. Для реализации им нужно поставить задачу в Payments трайб, а также в Mobile трайб для добавления поддержки нового продукта в мобильном клиенте. И начинаются все те же игры с приоритетами, ведь у Payments и Mobile трайбов наверняка есть свои бэклоги с не менее приоритетными задачами и целями. Вдобавок, в Cards трайбе нет специалистов по мобильной разработке, поэтому они полагаются на решения Mobile трайба, который не так сильно погружён в домен карточных продуктов. Это может привести к плохому UX для пользователей. От бизнеса будет требоваться точная постановка задач для оценок и включения в бэклог. А это, в свою очередь, закрывает возможность для экспериментов для бизнеса. В результате, снова страдают конечные пользователи. Через некоторое время находится кто-то, предлагающий попробовать SAFe для управления всем этим бардаком зависимостей. Ведь в соседней энтерпрайз организации «внедрили SAFe и все довольны». Это лишь вопрос времени. Вуаля, и организация снова вернулась в мир водопадной разработки, только с Agile привкусом… В следующем посте я отвечу на ваши вопросы и набросы по данной теме. :) #менеджмент #разработка #масштабирование