Проводить ресерчи или выкатывать изменения? Может все сразу? Любому продукту хотелось бы катить только те изменения, которые дают прирост в метриках. Ведь кому нравится работать в стол или тестировать фигню? Когда я приходил на новые места работы, продукты стремились проверять как можно больше гипотез. Много внимания уделялось их количеству, а также скорости доставки изменений в продакшн. B меньшей степени – качеству самих гипотез. Пословица «семь раз отмерь – один раз отрежь» дает хороший ответ, как повысить качество проверяемых гипотез – нужно хорошенько подумать перед тем, как что-то сделать. Т. е. нужно начать вкладываться в продуктовые исследования. И многие в компании это понимали – слова важности ресерчей со стабильной периодичностью звучали на встречах. Да вот только сами гипотезы продолжали падать в беклог по большей части на основе экспертного мнения руководства. Продуктовый Roadmap всегда оказывался важнее потенциальных ресерчей. На своем опыте я перепробовал разные варианты решения этой проблемы. Например, выделять часть ресурса команды каждый спринт, или даже отдельные спринты продуктовых команды на ресерчи. Действительно работал только один вариант – отдельная продуктовая discovery команда на пару к delivery, обе работающие в синергии по методологии Dual Agile Track. Discovery команда занималась поиском точек роста, оценкой плеч и прощупыванием реальности возможностей с помощью быстрых АБ. Она выступала «светом» для delivery команды. Delivery же команда занималась выкатыванием новых изменений (также через АБ) в продакшн качестве. В основе изменений лежали артефакты Discovery команды. Да, держать отдельную Discovery команду кажется дорогим удовольствием. Но взамен вы получаете постоянный поток качественных гипотез и минимизацию затрат на тесты с низким потенциалом. Как итог – быстрый рост метрик и довольные команды с разделенными обязанностями.