Растущая значимость разработки продуктов

Давайте поговорим о гипотетической команде разработчиков. Ее история может показаться вам знакомой.

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

Рита, дизайнер продуктов в команде, столкнулась с другими трудностями. Она могла неделями кропотливо работать над каждым пикселем в своих дизайнах, а потом вдруг получить важный отзыв, после которого многое приходилось менять. «Когда разработчики указывают на технические ограничения, часто уже слишком поздно держаться за первоначальное видение дизайна», — объясняет она. Рите требовалось теснее взаимодействовать разработчиками, чтобы раньше уточнять дизайн.

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

Рику, руководителю программы, пожалуй, досталась самая сложная роль. Необходимость координировать зависимости между несколькими командами и поддерживать баланс между скоростью и качеством поставки лишала его сна. «Когда команды работают изолированно, простые изменения могут растягиваться на недели», — отмечает Рик. Он хотел найти способ укрепить сотрудничество между командами и сделать их работу нагляднее друг для друга.

За всем этим следила Анна, руководитель по разработке, которая пыталась найти новые методы работы для своих команд. Хотя она ценила техническое совершенство, было ясно: чего-то не хватает. «У нас невероятно талантливые разработчики, — подчеркивает она, — но мы не всегда даем клиентам необходимую ценность». Анна хотела изменить культуру команды, но поддерживать баланс между техническим совершенством и ценностью для клиентов в традиционной модели разработки было затруднительно.

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

«Культура разделывает стратегию под орех». Хотя эту цитату часто приписывают гуру управления Питеру Друкеру, она приобрела известность, когда Марк Филдс в 2006 году вывесил ее в конференц-зале Ford. Это не просто броская фраза — она заключает в себе фундаментальную истину, которую мы неоднократно видели в индустрии высоких технологий: даже самая блестящая стратегия обречена на провал, если она противоречит организационной культуре.

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

Наш путь трансформации команды Compass прекрасно это иллюстрирует. Мы перешли от традиционного процесса жизненного цикла функций продолжительностью 6–8 недель к процессу итеративного исследования, который значительно приблизил нас к решению проблем клиентов. Это стало не просто изменением процесса, но фундаментальным сдвигом в образе мышления, от «все знать» к «все выяснять», и каждая функция стала возможностью чему-то научиться у клиентов.

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

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

Традиционная модель разработки программного обеспечения

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

Старый рабочий процесс нашей команды отражал этот линейный подход:

• На создание и утверждение документов с требованиями уходило несколько месяцев.

• Архитекторы и дизайнеры работали изолированно.

• Разработчики писали код по точным спецификациям.

• В конце проводили тестирование и развертывание.

• Отзывы клиентов отбирали на нескольких уровнях.

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

Непрерывный цикл разработки продукта

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

В этой новой модели:

• Разработчики участвуют в интервью с клиентами и сеансах по исследованию.

• Разработка и дизайн идут бок о бок, с быстрым прототипированием и тестированием.

• Технические решения согласовываются с потребностями клиентов.

• Развертывание становится возможностью сделать выводы, а не просто этапом поставки.

• Команды оценивают успех не только по техническим показателям, но и по влиянию на клиентов.

От внедрения к вовлеченности

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

• Участвуют в постановке задачи и поиске решений.

• Делятся техническими подробностями на ранних этапах обсуждения.

• Сверяют предположения непосредственно с клиентами.

• Отвечают за результаты относительно функций, а не только за качество кода.

• Отслеживают бизнес-показатели и влияние на рынок.

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

Чтобы преобразовать подходы к разработке, недостаточно просто начать мыслить по-новому — нужна правильная основа. Наша команда в первую очередь опиралась на Jira Product Discovery — инструмент, который естественным образом добавил клиентский контекст в наши повседневные рабочие процессы.

Первая задача, которую требовалось решить, — сделать информацию от клиентов доступной для всех. Раньше отзывы клиентов и требования к продукту хранились в документах Confluence, обсуждениях Slack и заявках Jira. С Jira Product Discovery весь этот контекст доступен непосредственно там, где мы ведем разработку. Теперь разработчики могут видеть интервью с клиентами, сеансы обратной связи и модели использования вместе с задачами по разработке, благодаря чему потребности клиентов становятся осязаемыми и актуальными, а не абстрактными и отдаленными.

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

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

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