Яндекс - это ж наш главный IT-гигант. Флагман. Компания, на которую все равняются. И они публикуют вакансию Product Owner, в которой НИ ОДНОГО требования, соответствующего реальной роли PO в Scrum.

Спойлер: Яндекс ищет не Product Owner, а Product Manager, CPO, стратега, координатора и аналитика в одном флаконе - Господа Бога! За одну зарплату.

Разбираем по косточкам:

«Развитие экосистемных инициатив — от поиска проблемы и проработки решения до запуска, оценки результата и дальнейшего развития». Какой нахер поиск проблем.. чьих проблем? На каком уровне проработка решения? Системная, бизнесовая, какая? Бля, это просто набор каких-то слов. Это вообще звучит, как прийти и сделай нам полностью бизнес.

«Проработка новых пользовательских сценариев... проектировать новые кросс-продуктовые сценарии... проверять гипотезы». Это как сантехника позвать крышу перестилать.. причем тут вообще Scrum и в частности PO?

«Координация кросс-командной разработки: договариваться с командами... формировать требования, синхронизировать действия участников». Типа есть команда распиздяев, которые не хотят работать, а нужен погоняло, который придет и будет их уговаривать работать? В Scrum есть Scrum-митинги.. где все участники собираются и определют, что включать в следующий спринт. Вообще не нужно ничего синхронизировать и координировать.

«Развитие стратегии экосистемы: участвовать в формировании стратегии развития, искать новые направления роста». В Яндекс вообще знают, что такое стратегия, как она разрабатывается и сколько ресурсов для этого нужно? Это задача высшего уровня и доступная только выскококлассным спецам с многолетним опытом. Некоторые стратегия разрабатываются годами сотнями сотрудников. А тут тип офисный планктон им должен развиваться из своей ямы.

А что говорит Scrum Guide?

Product Owner отвечает за максимизацию ценности продукта и за эффективное управление Product Backlog. Т.е. PO просто причесывает и приоритезирует бэклог. Притом приоритезирует даже не он, а заказчик, который и определяет что ценно, что нет. Всё. Никакой стратегии, никакого поиска гипотез, никакой координации команд. Product Owner - владелец бэклога.

Что это значит?

Яндекс, будучи крупнейшим IT-гигантом в России, либо нанимает некомпетентных HR-специалистов, которые не знают разницы между PO, PM и CPO, либо сознательно вводит в заблуждение соискателей, надеясь найти «универсального солдата» за одну зарплату, либо не понимает основ Scrum, несмотря на то, что заявляет о себе как о технологическом лидере.

Какой бы вариант ни был верным, это позор для компании такого уровня.

Почему это важно?

Потому что когда Яндекс публикует такую вакансию, другие компании смотрят на это и думают: «Ага, Яндекс так делает - значит, так правильно». И начинают копировать. В итоге кандидаты не понимают, чего от них хотят, нанятые «PO» выгорают через полгода, потому что на них вешают работу трех человек, а профессия Product Owner обесценивается.

Как думаете? Яндекс - это эталон или они тоже скатились в «найми человека-оркестра»? Может, у них есть какой-то свой «особый» Scrum, о котором мы не знаем?

Обратите внимение, что вакансия от Питерского офиса Яндекс. Походу, просто СПБ - это большая деревня, в которой Scrum еще не читали.

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

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

В такой ситуации, если у нас есть запас декомпозированных требований, это даёт следующие преимущества:

• Во-первых, мы не ограничиваем себя в выборе задач для спринта (можем работать только с теми задачами, которые уже декомпозированы).

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

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

Два основных подхода к декомпозиции.

Существует два базовых подхода к декомпозиции крупных задач на пользовательские истории — «горизонтальное» и «вертикальное» разбиение:

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

• С другой стороны, «вертикальный» подход к декомпозиции акцентирует внимание на выделении более мелких задач, функций и особенностей, так что каждая пользовательская история может быть реализована и завершена независимо от других. В этом случае в процессе разработки могут участвовать различные роли, а также задействоваться несколько модулей и систем, обеспечивая большую гибкость и скорость в реализации функционала. Пример вертикальной декомозиции из саб-тасков:

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

• В рамках «вертикальной» декомпозиции каждая конечная пользовательская история обладает явной ценностью для бизнеса, что упрощает процесс сравнения и определения приоритетов таких задач.

• Учитывая, что в решении задач, организованных по «вертикальному» принципу, участвуют специалисты с разными ролями, они легче могут выявить потенциальные проблемы, зависимости и риски, которые могут возникнуть в ходе выполнения работы.

Техники декомпозиции требований

Способ 1: Этапное разбиение бизнес-процессов

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

• Вход в личный кабинет

• Просмотр товаров в «корзине»

• Формирование счета

• Отправка счета на почту

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

Способ 2: Разделение на позитивные и негативные сценарии

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

• Позитивный сценарий: пользователь авторизуется и успешно совершает покупку.

• Негативный сценарий 1: попытка покупки без авторизации.

• Негативный сценарий 2: недостаточно средств на счете для завершения транзакции.

• Негативный сценарий 3: блокировка учетной записи после нескольких неверных попыток ввода пароля.

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

Способ 3: Разбиение по правилам и условиям

В отличие от предыдущего метода, здесь акцент делается не на этапах, а на логических ветках процесса, основанных на различных правилах. Например, для функции покупки можно выделить правила, такие как:

• Минимальная сумма покупки.

• Дополнительные варианты оплаты при превышении определенной суммы.

• Автоматическая отмена заказа через 2 дня без оплаты.

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

Способ 4: Разделение по типам операций

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

• Create: добавление нового продукта.

• Read: просмотр описания продукта.

• Update: редактирование информации о продукте.

• Delete: удаление товара из магазина.

Такое разбиение позволяет четко определить необходимые операции и их приоритеты.

Способ 5: Декомпозиция по платформам и ОС

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

• Персональные компьютеры

• Планшеты

• Смартфоны

• Разные операционные системы: Windows, iOS, Android.

Такой подход помогает определить приоритетные направления разработки.

Способ 6: Разделение по типам данных и параметрам

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

• Поиск по наименованию товара.

• Поиск по номеру товара.

• Поиск с использованием регулярных выражений.

Эта декомпозиция позволяет четко определить допустимые параметры и легко управлять требованиями.

Способ 7: Разделение по ролям и правам доступа

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

• Владелец: создание и удаление товаров.

• Администратор: редактирование описаний и работа с клиентами.

• Клиент: просмотр и покупка товаров.

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

Способ 8: Декомпозиция по тестовым сценариям

Этот метод разбивает функциональность на основе тест-кейсов, которые необходимо проверить для проверки успешности работы функций. Например, для функции добавления товара в «корзину» могут быть выделены следующие тестовые сценарии:

• Товар доступен для покупки.

• Товар зарезервирован другим пользователем.

• Товара нет в наличии.

Такой подход позволяет объединить различные техники декомпозиции и формирует ясные задачи для разработки и тестирования.

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

Преимущества Декомпозиции задач:

• Улучшает понимание: Разделение крупных задач (или историй пользователей) на более мелкие позволяет команде лучше понять, что именно требуется сделать. Мелкие задачи легче осмысливать и обсуждать.

• Лучшая оценка: Команда может более точно оценить время и усилия, необходимые для выполнения мелких задач, что улучшает планирование и управление ресурсами (Гарантирует отличный Митинг Планирования используется числами Фибоначчи или последовательность T-Shirt Sizes ).

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

• Увеличение прозрачности: Когда задачи разбиты на более мелкие части, становится легче отслеживать прогресс и выявлять проблемы на ранних этапах. Это позволяет команде быстро реагировать на изменения.

• Повышение гибкости: В Scrum часто происходят изменения в требованиях, и декомпозиция задач позволяет команде более гибко реагировать на эти изменения, адаптируя свои планы и приоритеты.

• Улучшение качества: Мелкие задачи позволяют команде сосредоточиться на качестве выполнения каждой отдельной части. Это может привести к более высокому качеству конечного продукта.

• Стимулирование сотрудничества: Декомпозиция задач может содействовать более активному сотрудничеству внутри команды, так как участники могут работать над различными частями одной задачи одновременно.

• Постепенная интеграция: Разделение задач на более мелкие части позволяет команде поэтапно интегрировать и тестировать функциональность, что уменьшает риски и улучшает стабильность.

Я надеюсь, что данная информация вам пригодилась! Если у вас есть вопросы или пожелания, оставляйте комментарии. Буду рад помочь вам с личными советами по IT, бизнес-анализу, Scrum или управлению проектами!

Надеюсь, будет полезно.