я учусь на бизнесе (к счастью, последние пару недель – сейчас автор плотно пишет диплом
) и мне буквально все 4 года втирали разные фреймворки. всё это время я думала, что это какая-то теоретизированная чушь, которой в принципе пользуются только на университетских проектах. в общем-то такое мнение довольно широко распространено и уже чуть ли не считается за святую истину...но всё больше, работая в Еде, к тому же в довольно новом и только формировавшемся во время моего прихода направлении (напомню: retention & курьерский опыт), убеждаюсь в том, что команды в итоге приходят к фреймворкам, даже если начинали в хаосе и собственных придумках. просто чем более зрелая и опытная команда, тем больше у нее насмотренность этих фреймворков, и большее их количество у нее получается адаптировать под свою работу. при этом работа только по фреймворкам не исключает креативности; все фреймворки – это только база для организации процесса/продукта, а наполнение его контентом остается за командой.
за последнее время мы не раз обращались к разным фреймворкам в работе, и каждый раз это можно красиво подать на защите проекта, как что-то, что круто сработало у какой-то еще компании, и обосновать этим свой подход. например, чисто продуктовые всем известные фреймворки типа выявления и создания метрики aha-moment юзали в стриме закрепляемости новичков, hook cycle – для создания у пользователя привычки использования своего продукта (когда-нибудь расскажу здесь чуть-чуть подробнее про сам проект, stay tuned
). это из более изощренного, что нечасто встретишь. я уже молчу про jtbd, которым вполне может обосновываться необходимость фичи, и cjmки, которыми вообще пишутся тикетыследующий пост хочу сделать по теме диплома (ну пусть от него хоть какая-то польза будет) – преисполнилась за полгода в теме прогнозирования спроса и планирования курьерских ресурсов в e-grocery, чучуть поделюсь!
@seniorPMintern
