Чем мне нравится мышление разработчиков, дак это тем, что они всегда думают о связях между объектами в базах данных продукта и постоянно спрашивают тебя “А с чем ещё связана эта сущность?“.
Их лайфхак в том, что это помогает им избегать запутанности в архитектуре и логике кода между его сущностями и не перегружать их лишними запросами.
И я заметил, что продакт-менеджеру такой подход тоже сильно помогает.
Можно смотреть на эти же самые связи, но только с точки зрения пользовательского поведения и Customer Journey Map — потому что все объекты в коде/продукте это оцифрованные действия и результаты деятельности наших пользователей.
То есть просто смотрим на продукт как на живой процесс (с живыми участниками внутри), а не как на код с взаимосвязями.
Почаще задавайся вопросами:
— А с какими сущностями и механиками (пользователями и их процессами) связана эта фича/гипотеза;
— На какие ЕЩЁ сущности и механики МОЖЕТ повлиять та или иная гипотеза/фича/решение;
— Как сделать так, чтобы могла повлиять (раз уж ты думаешь или вы работаете над ней).
Часто, в попытке найти зависимости, открываются весьма нестандартные и мега-эффективные решения.
Их лайфхак в том, что это помогает им избегать запутанности в архитектуре и логике кода между его сущностями и не перегружать их лишними запросами.
И я заметил, что продакт-менеджеру такой подход тоже сильно помогает.
Можно смотреть на эти же самые связи, но только с точки зрения пользовательского поведения и Customer Journey Map — потому что все объекты в коде/продукте это оцифрованные действия и результаты деятельности наших пользователей.
То есть просто смотрим на продукт как на живой процесс (с живыми участниками внутри), а не как на код с взаимосвязями.
Почаще задавайся вопросами:
— А с какими сущностями и механиками (пользователями и их процессами) связана эта фича/гипотеза;
— На какие ЕЩЁ сущности и механики МОЖЕТ повлиять та или иная гипотеза/фича/решение;
— Как сделать так, чтобы могла повлиять (раз уж ты думаешь или вы работаете над ней).
Часто, в попытке найти зависимости, открываются весьма нестандартные и мега-эффективные решения.
10 comments
Log in to comment
Хотя бы условно что есть вот пользователь, он "владеет" такими сущностями, у каждой сущности такой-то набор параметров-данных, эти параметры можно матчить с другими сущностями с другими параметрами.
Костыли в коде часто являются следствием костылей в пользовательских процессах, описанных продактами и придуманных в полной уверенности, что им самое место в CJM и юзеры должны делать "именно так", потому что это "удобнее".