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

И еще целая куча кейсов.А гипотезы, mvp, обсуждения  и общение с заказчиком. - не обязательно customer development. Все таки cusdev подразумевает штуки вроде "выйди из офиса", "интервью с конечным пользователем" и т.п.

Несмотря на таких, кто будет действительно препятствовать касдеву найдутся и те, у кого это реальная боль. Вопрос в выборке - сколько человек действительно хочет?

Ну сколько человек в вашей организации хочет, чтобы приходя на работу им надо было отмечаться в какой-то системе, уходя на перерыв - тоже и не забыть остановить часы, когда уходишь с работы, иначе все твои часы за день "сгорят"?) Я был бы рад с ними пообщаться)

Есть разные организации и разные случаи. Я исхожу из

> занимаемся автоматизацией в рамках крупного холдинга

В крупных холдингах цели холдинга и людей, работающих в них могут очень сильно расходится + бюрократические ограничения

но я чисто про свой опыт, про другой было бы интересно послушать. но еще интересней было бы, если бы ТС сказал, какая у него конечная цель)

А то если  они для рынка хотят продукты делать - одно, для внутрей - другое, подходы изменить - третье, упростить разработку для бизнеса и повысить ее эффективность - четвертое

Спасибо. Да, такая проблема есть и наверное действительно не на всех системах получится найти последователей из конечных пользователей, но с другой стороны, если выхода у пользователя уже нет, то он может помочь и заинтересован в том, чтобы сделать хотя бы удобней для себя.

Мне кажется надо еще немного объяснить почему я задался этим вопрос и компания хочет быть ближе к пользователям:
1) Всё равно очень много систем, в которых заинтересованы пользователи. В основном это цифровизация ранее ручного и бумажного труда.
2) Заказчик часто ошибается, особенно в процессах согласования или в каких-то технических моментах. Из-за этого мы тратим месяцы на разработку, а после внедрения оказывается, что это должно работать не так.
3) Сотрудники - конечные пользователи, тоже имеют голос и они могут звонить, показывать недовольство, перегружать отдел поддержки. Хотя если бы с ними общались чаще, обучали лучше, выявляли конкретные проблемы, то мы полагаем, что таких проблем бы не было

Я думаю, если заходить в лоб, то и будет описанный эффект, но можно попробовать попрактиковать заходить на процессы, проблемы, ожидания и далее.
Наверное, у нас разные понимания методологии cusdev. Я всегда думал, что там про процесс создания от идеи до product market fit, а не только пойти и выйти на улицу. Куда тогда девать шаги develop и discovery, если «улица» уже пройдена?

Я пару лет назад заходил на ца с вопросом «представьте если бы был чат-бот, который решил бы все ваши проблемы». Примерно почти все мне сказали, что им это не надо.
В итоге через полгода начали исследовать иначе и в итоге пользуются и довольны:)

О, а что за чат-бот, который все проблемы решает? Мне такой надо 🙂

Что я понял на текущий момент: Customer development - это слишком много информации и это больше про B2C или даже про стартапы. Я сейчас про полные 4 шага (Customer discovery, customer validation, customer creation, company building). А вот про глубинное интервью, как про один из инструментов рассказать можно.

customer development может и должен быть и в состоявшемся бизнесе, не в стартапах дело

Есть еще Дизайн мышление - вроде бы это более применимо и про это можно рассказать проектному офису

Волшебный. И суть сообщения была в другом. Если у вашей ЦА не болит так, что они из кожи вон лезут и как-то прямо сейчас не пытаются решать эту боль, то спрашивать в лоб - не рациональная идея.
Поэтому если работников склада спросить со стороны «мы сейчас создаем то, что твои процессы сломает», то работники склада будут вас мешать, а если зайти к ним и спросить про процессы, про опыт, проблемы, но в русле твоей, не озвученной им цели, то почти никто палки в колеса вставлять не будет.

верно, это можно сделать и в рамках любой другой практики включая DDD.

Сейчас специально на всякий случай CS манифест открыл и убедился, что это все таки немного про другое

Там в манифесте прям черным по белому написаны вещи, которые могут противоречить устройству крупного концерна

Какие-то практики может можете порекомендовать, которые помогут в сборе фидбека от конечных пользователей, работе с ними.

В идеальном мире внутри компании должны быть продакты, которые генерят идеи, проверяют их на конечных пользователях, а потом это приносят заказчикам, чтобы согласовать под это бюджет и начать разработку

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