Преодолеваем барьеры внутреннего продукта для внешнего рынка Часть 1

После анализа блокеров, которые мешают внутренним продуктам покорить рынок, самое время поговорить о шагах, которые помогут их преодолеть.

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

По-грамотному, KPI по рыночному развитию должны быть у всех, начиная от разработчиков и заканчивая акционерами. При этом уровень KPI должен быть значимым, а не 10%.

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

Места для реализации рыночного бэклога не будет никогда, если его не прибить гвоздями в протоколах с участием C-level, приводя аргументы вот отсюда (читай – через угрозы, шантаж и манипуляции).

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

Лучшие практики SAFe говорят про 4 ключевых квоты на следующие активности в команде разработки:

Рекомендации по квотированию могут различаться в зависимости от ситуации. Например, некоторые спринты могут быть стабилизационными – для повышения качества продукта, или технологическими – для закрытия технического долга или миграции на новые технологии, которые улучшат соответствие НФТ или продуктивность разработчиков. В целом мы рекомендуем придерживаться пропорции 30/40/20/10.

Конечно, квоты – это тактический инструмент с элементами «торга» между CPO (продуктовым лидером) и CTO (техническим лидером), который может регулироваться в зависимости от стадии жизненного цикла продукта.

Но нужно договориться о базовых квотах, на которые CTO сможет опереться, чтобы никто не мог это подвинуть, поскольку часто у СТО «отнимают» квоты по техническому долгу. А если бы не отнимали, может, техдолг и не появлялся бы.

Это самая важная часть, про которую скоро поговорим отдельно. Пока даём ключевое.

• Рыночный бэклог даст прирост 30-40% к бэклогу ключевого заказчика по функциональности. Закладывайте это в бюджет.

• Требования по ИБ от внешних заказчиков будут отличаться от ваших требований также на 30-40%. Сразу готовьтесь, как минимум, к аудиту SDLC, как максимум, к сертификации во ФСТЭК.

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

• Собрать требования по рыночному бэклогу можно только в «полях»: нужно будет провести несколько десятков встреч (мы рекомендуем 30-50) с живыми клиентами, затем агрегировать и приоритизировать запросы по частотности.

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

Продолжение – на следующей неделе.

🚀 Подпишитесь на наш TG-канал «Корпорация делает софт», чтобы не пропустить всю самую пользу и практику.