Мы живём в эпоху DevOps. Предприятия организуют непрерывную интеграцию / непрерывную поставку (CI / CD). Традиционные команды превращаются в междисциплинарные и саморганизующиеся. Они намного быстрее разрабатывают и выпускают новые функции. С их помощью функциональные колодцы приказывают “долго жить”, как и длительные сроки ожидания и скопившиеся очереди заданий между отделами. Scrum-мастера следят за тем, чтобы спринты помогали командам достигать своих целей. А что происходит с владельцем продукта? Как изменилась его роль с течением времени? Какие произошли изменения?

Об этом рассуждает в своей заметке технический консультант и Scrum-мастер Виби де Рус (Wiebe de Roos) на портале Amazic World.

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

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

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

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

Раньше владелец продукта считал основным реализацию в продукте конкретных функций. Хотя разработка отдельных функций в большей степени ориентирована “на проект”, чем “на продукт”. В нынешнее же время именно продукт является самым важным. Каждый, кто вносит свой вклад в развитие продукта, должен понимать бизнес-цели продукта для компании в целом. Современный владелец продукта должен сосредоточиться на жизненном цикле продукта, а не только на тех функциях, которые должны быть разработаны. Разрабатываемые функции должны вписываться в контекст более крупной системы – всего предприятия, они должны обеспечивать жизненный цикл продукта от начала разработки до вывода из эксплуатации. Системное мышление требует большего уровня абстракции, сохраняя при этом в поле зрения особенности отдельного продукта. Владелец продукта должен быть способен видеть главное и не тонуть при этом в деталях, поскольку можно допустить ошибку, общее видение размоется, станет нечётким, и организация может пойти в неверном направлении (например, обозначить не те требования или реализовать малозначимые функции, которые дадут в итоге меньший результат).

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

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

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

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

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

Данные навыки необходимы, чтобы принимать обоснованные решения. В случае, если владелец продукта действительно “хорошо знает своё дело”, то для продукта устанавливаются правильные цели и видение. Бизнес и ИТ синхронизируются.

Владелец продукта, каким мы его знаем сейчас, постепенно превращается… во “владельца жизненного цикла продукта”. Мышление в терминах “системного подхода” и “жизненного цикла продукта” становится новым базисом для более быстрой разработки и предоставления новых функций. Чтобы добиться этого, нужно уделять больше внимания и операционным требованиям.