Почему разрабы мы все факапим сроки? Посвящается всем разрабам и продактам
Причина №1 – у нас искажено системное мышление, из-за чего мы видим код продукт мир как цепочку причинно-следственных связей и параметров:
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образом улучшить нарушить работу Системы, лучше посмотреть, как она себя ведёт.
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️
Причина №1 – у нас искажено системное мышление, из-за чего мы видим код продукт мир как цепочку причинно-следственных связей и параметров:
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
И наименее очевидная часть Системы, её функция и Цель, часто является наиболее важным фактором, определяющим само поведение Системы.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образом улучшить нарушить работу Системы, лучше посмотреть, как она себя ведёт.
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️