Генеалогия понятий: Discovery and Delivery

Действительно, существует распространенный троп о разделении процессов на деливери и дискавери, который, впрочем, является в некотором смысле новоделом и достаточно свежим явлением. Marty Cagan начал использовать термин «discovery» для процесса поиска того, что именно нужно строить. В 2007 году он полностью закрепил его в своей книге Inspired - вот как он описывает в своих мемуарах - и взял из долгих процессов RnD бигфармы и медицины

Я уже много лет собирался написать эту статью, но поскольку она в основном историческая, всегда находились более срочные темы. Однако время от времени мне пишут люди, которые пытаются выяснить происхождение этого термина. А во время пандемии, по какой-то причине, такие вопросы стали приходить заметно чаще.
Сначала давайте проясним: сама концепция product discovery существует столько же, сколько и программное обеспечение, и уж точно гораздо дольше, чем я занимаюсь этой сферой.
У нас всегда было (и, скорее всего, всегда будет) две фундаментальные проблемы в разработке ПО:

Нужно понять, какой продукт нужно создать (правильный продукт).
Нужно правильно его построить.

Я всегда интересовался обеими проблемами, но считаю, что первая — значительно сложнее. Именно в ней происходит большинство инноваций, поэтому я уделяю ей основное внимание.
Примерно с 2005 года я начал экспериментировать с термином «discovery» (открытие/исследование) для процесса поиска того, что именно нужно строить. А в 2007 году я решил полностью перейти на этот термин. С тех пор первую проблему я называю discovery, а вторую — delivery (доставка/реализация).
В 2007 году я работал над первым изданием книги INSPIRED, и приближался срок сдачи в печать. Мне нужно было окончательно решить, какой термин использовать.
В то время практически все продуктовые менеджеры говорили о «сборе и определении требований» (gathering and defining requirements). Я же считал это одним из главных причин такого большого количества провальных продуктов. Для меня подход «определение требований» был не просто ошибочным, а ещё и высокомерным.
Я видел, что в сильных командах продукты рождаются в результате настоящего сотрудничества инженеров, дизайнеров и продакт-менеджеров. А не потому, что продакт-менеджер заявляет: «Вот требования, теперь идите и спроектируйте это, и постройте».
Поэтому мне нужен был термин, который вызывал бы в головах продакт-менеджеров и команд совершенно другую картину. Я хотел, чтобы они сохраняли открытый ум, понимали, чего они не могут знать, и честно признавали то, чего не знают.
Я хотел подчеркнуть, что отличные продукты получаются, когда продуктовая команда, дизайн и инженерия вместе работают над достижением результата, а не просто «спускают требования вниз по цепочке» и отгружают «выход».
Я хотел, чтобы они думали в терминах «мы должны разобраться, как решить проблему, которую нам поставили», а не «мы должны продиктовать требования к фиче, которую нам велели построить».
Термин «discovery» я взял из фармацевтической отрасли — так там называется процесс поиска и разработки жизнеспособного лекарства. В отличие от индустрии ПО, фармацевты сразу признают высокий риск. Они изначально ожидают, что многие (если не большинство) из разрабатываемых препаратов в итоге не окажутся достаточно безопасными и эффективными, чтобы их производить, распространять и продавать.

Позже Cagan перешёл к формулировкам Continuous Discovery + Continuous Delivery, чтобы подчеркнуть, что это не фазы, а постоянные параллельные процессы. Не думаю, что имеет смысл повторять критику подхода (я, например, вижу много "но"), просто интересно, что было прообразом и как фармацевтическая реальность исследований десятилетий, трансформировалась в культ быстрых тестов

Полезное из Figma Communy

Apple добавили новые шаблоны на своей странице в Figma Communy

Ссылка

#materials_nd

🧰 Neumorphism UI Kit — здесь вы можете найти готовые UI-элементы, выполненные в стиле неоморфизма

Dezzigners

📖Spring Boot 3.0 Cookbook
🖋Puig Felip Miguel 2024

Разбирайтесь со сложностями современных веб-приложений, используя шаблоны облачного проектирования Spring Boot для создания масштабируемых и устойчивых приложений.

💾 Скачать книгу

Daily Coding #книги #Spring | Канал в Max