Многие CIO еще не перешли от софтверных/прикладных проектов к мышлению, ориентированному на продукт. Глобальный руководитель отдела технологических решений и предпродаж Persistent Systems Ананд Кришнан рассказывает на портале InformationWeek как это сделать.

Проведенное в 2018 г. исследование Gartner показало, что 85% организаций приняли или планируют принять модель, ориентированную на продукт, причем большинство из них уже используют ее по меньшей мере для выполнения 40% своей работы. Эта тенденция продолжает ускоряться, и ожидается, что в 2022 г. этот показатель вырастет до 80%.

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

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

1. Начинайте с «почему», а не с «как»

Эта концепция должна стать опорой вашей бизнес-стратегии. Модели разработки продуктов, ориентированные на клиента, направлены на устранение болевой точки на рынке, а не на само ПО. Если вы начинаете составлять свой стратегический план с вопроса: «Как нам решить эту проблему?», вы обсуждаете решение, тем самым ограничивая свои действия несколькими вариантами. Когда вы сосредоточитесь на том, почему вы разрабатываете приложение, вы сможете определить приоритеты, уточнить цели и подвести основание для построения стратегии.

2. Овладейте проблемой, а не технологией

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

3. Код — это пассив, функциональность — актив

Сложный код сам по себе не имеет ценности. Даже самый сложный код бесполезен, если за ним не стоит сильная команда. По мере формирования организации, подумайте о том, как код может быть наиболее полезен в качестве инструмента для достижения ваших целей, ориентированных на клиента. Следующее поколение разработчиков ПО и бизнес-профессионалов может извлечь пользу из решений типа Low-code/No-code как части вашей модернизированной модели. Более простой код легче в понимании и его легче поддерживать. И снова небольшой сдвиг позволит вашим командам быть гибкими. В этом случае глубокие технические знания не всегда необходимы для достижения ваших целей.

4. Измеряйте то, что важно, а не результаты

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

5. Применяйте итерации и осуществляйте непрерывную доставку

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

6. Фокусируйтесь на новых каналах, рынках и моделях распространения

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