Ну что как я и говорил спамить не буду, только полезные записки погружающие в тему Бережливой разработки😀
Начнем с базы, без которой цикл Шухарта-Деминга или PDCA, принесенный на заводик Toyota, возможно не совершил бы чуда.
Кайдзэн — японская философия или практика, которая фокусируется на непрерывном совершенствовании. В переводе с японского "кай" (kai) означает "изменение", а "дзэн" (zen) – "хороший" или "к лучшему", то есть кайдзен можно трактовать как "изменение к лучшему" или "непрерывное улучшение".
Непрерывное улучшение — принцип, характеризующий саму суть кайдзен, непрерывные малые изменения во всех сферах жизни и\или организации.
Философия учит, что улучшения — это не разовые подвиги, а ежедневные ритуалы. Даже +1% в день через год даёт 37-кратный рост!
Дальше поговорим о принципах Кайдзен, что такое 5S, 5 почему, Muda, зачем ходить в Гэмба и как всех превратить в тестировщиков и паладинов оптимизации.
Начнем с базы, без которой цикл Шухарта-Деминга или PDCA, принесенный на заводик Toyota, возможно не совершил бы чуда.
Кайдзэн — японская философия или практика, которая фокусируется на непрерывном совершенствовании. В переводе с японского "кай" (kai) означает "изменение", а "дзэн" (zen) – "хороший" или "к лучшему", то есть кайдзен можно трактовать как "изменение к лучшему" или "непрерывное улучшение".
Непрерывное улучшение — принцип, характеризующий саму суть кайдзен, непрерывные малые изменения во всех сферах жизни и\или организации.
Философия учит, что улучшения — это не разовые подвиги, а ежедневные ритуалы. Даже +1% в день через год даёт 37-кратный рост!
Дальше поговорим о принципах Кайдзен, что такое 5S, 5 почему, Muda, зачем ходить в Гэмба и как всех превратить в тестировщиков и паладинов оптимизации.
🔥8👍4✍3❤2
Полная PDCA, обманул вас!
Писал что начнем говорить про разное японское, но принес еще немного базы.
PDCA (англ. «Plan-Do-Check-Act» — планирование-действие-проверка-корректировка) — итеративный метод принятия решения, используемый в управлении качеством, любым. Не QA единым строятся хорошие вещи на проекте)
PDCA— алгоритм который помогает вам допинать процесс до его финала или в оптимальное русло если это бесконечное действие.
Планирование — установления целей и процессов. Тут вам нужно решить что и как вы делаете;
Выполнение — тут вы воркаете как придумали;
Проверка — сбора информации и контроль результата. Тут вы смотрите что получилось и почему не получилось сравниваете с имеющимися результатами или начинаете собирать. Решаете как сделать лучше или по другому.
Воздействие — запускаете в работу все свои идеи по улучшению, изменению в планировании и распределении ресурсов.
Повторяете!
Спасибо Agile, что научил нас бегать спринты и анализировать работу в рамка небольших циклов. Но улучшения могут иметь и свои циклы отчетности и планирования и зависеть от объема, длительности и содержания улучшения. Не стоит чегото ждать для отчета и корректировки две недели если улучшение можно интегрировать быстрее.
Итак раз за разом, во всех процессах, на всех местах, маленькими шагами, делаете что-то лучше, а где-то избавляетесь от муда.... об этом в следующий раз)
Писал что начнем говорить про разное японское, но принес еще немного базы.
PDCA (англ. «Plan-Do-Check-Act» — планирование-действие-проверка-корректировка) — итеративный метод принятия решения, используемый в управлении качеством, любым. Не QA единым строятся хорошие вещи на проекте)
PDCA— алгоритм который помогает вам допинать процесс до его финала или в оптимальное русло если это бесконечное действие.
Планирование — установления целей и процессов. Тут вам нужно решить что и как вы делаете;
Выполнение — тут вы воркаете как придумали;
Проверка — сбора информации и контроль результата. Тут вы смотрите что получилось и почему не получилось сравниваете с имеющимися результатами или начинаете собирать. Решаете как сделать лучше или по другому.
Воздействие — запускаете в работу все свои идеи по улучшению, изменению в планировании и распределении ресурсов.
Повторяете!
Спасибо Agile, что научил нас бегать спринты и анализировать работу в рамка небольших циклов. Но улучшения могут иметь и свои циклы отчетности и планирования и зависеть от объема, длительности и содержания улучшения. Не стоит чегото ждать для отчета и корректировки две недели если улучшение можно интегрировать быстрее.
Итак раз за разом, во всех процессах, на всех местах, маленькими шагами, делаете что-то лучше, а где-то избавляетесь от муда.... об этом в следующий раз)
✍7👍6🔥5❤1
Три MU которые мешают вашим делам, бизнесу и жизни.
В философии Kaizen и бережливом производстве (Lean) выделяют три ключевых типа потерь: Muda, Mura, Muri
1. Муда – "потери", "бесполезные действия" или "расточительство".
Это любые процессы, которые не добавляют ценности. Обычно упоминаются семь классических видов муда:
- Перепроизводство
- Ожидание
- Лишняя транспортировка
- Избыточные запасы
- Лишние движения
- Излишняя обработка
- Брак и переделки
- Со временем добавили еще одну, Недоиспользование талантов.
Как устранять?
- Анализировать процессы (например, с помощью картирования потока создания ценности).
- Внедрять принципы 5S (организация рабочего места).
- Применять методы PDCA (Plan-Do-Check-Act) для постоянного улучшения.
2. Мура – неравномерность, дисбаланс
Это нестабильность в процессах, ведущая к перегрузкам или простоям. Примеры:
- Резкие скачки спроса, из-за которых то "аврал", то простой.
- Неравномерная загрузка рабочих или оборудования.
- "Быстрые" и "медленные" операции в одном потоке.
Как устранять?
- Выравнивание нагрузки (хейдзунка – Heijunka).
- Стандартизация процессов.
- Гибкое планирование под реальный спрос.
3. Мури – перегрузка, неразумные требования
Это чрезмерная нагрузка на людей, оборудование или процессы, ведущая к стрессу, браку и поломкам. Примеры:
- Работа на износ без перерывов.
- Нереальные планы производства.
- Оборудование, которое постоянно работает на пределе.
Как устранять?
- Оптимизация темпов работы (такта времени – Takt Time).
- Внедрение эргономичных решений.
- Обучение и распределение задач без "героизма".
Связь между Муда, Мура и Мури
Часто эти потери связаны:
Мурá (неравномерность) → ведет к Мури (перегрузка) → что создает Муда (потери).
Пример: Руководство ставит нереальный план (Мури) → рабочие спешат, делают брак (Муда) → из-за авралов потом возникают простои (Мурá).
Вывод:
Чтобы эффективно внедрять кайдзен, нужно бороться со всеми тремя типами потерь. Сначала устранить Мури (перегрузки), затем Мурá (неравномерность), и тогда Муда (классические потери) сократится автоматически.
В геймдеве часто наблюдаю картину про нереалистичные планы производства, переходящие в наши "любимые" кранчи, а потом все выгорают, потому что страдают героизмом, а до этого руководство не слышало сотрудников и менеджеров о проблемах в планировании сроков и объемах.
В философии Kaizen и бережливом производстве (Lean) выделяют три ключевых типа потерь: Muda, Mura, Muri
1. Муда – "потери", "бесполезные действия" или "расточительство".
Это любые процессы, которые не добавляют ценности. Обычно упоминаются семь классических видов муда:
- Перепроизводство
- Ожидание
- Лишняя транспортировка
- Избыточные запасы
- Лишние движения
- Излишняя обработка
- Брак и переделки
- Со временем добавили еще одну, Недоиспользование талантов.
Как устранять?
- Анализировать процессы (например, с помощью картирования потока создания ценности).
- Внедрять принципы 5S (организация рабочего места).
- Применять методы PDCA (Plan-Do-Check-Act) для постоянного улучшения.
2. Мура – неравномерность, дисбаланс
Это нестабильность в процессах, ведущая к перегрузкам или простоям. Примеры:
- Резкие скачки спроса, из-за которых то "аврал", то простой.
- Неравномерная загрузка рабочих или оборудования.
- "Быстрые" и "медленные" операции в одном потоке.
Как устранять?
- Выравнивание нагрузки (хейдзунка – Heijunka).
- Стандартизация процессов.
- Гибкое планирование под реальный спрос.
3. Мури – перегрузка, неразумные требования
Это чрезмерная нагрузка на людей, оборудование или процессы, ведущая к стрессу, браку и поломкам. Примеры:
- Работа на износ без перерывов.
- Нереальные планы производства.
- Оборудование, которое постоянно работает на пределе.
Как устранять?
- Оптимизация темпов работы (такта времени – Takt Time).
- Внедрение эргономичных решений.
- Обучение и распределение задач без "героизма".
Связь между Муда, Мура и Мури
Часто эти потери связаны:
Мурá (неравномерность) → ведет к Мури (перегрузка) → что создает Муда (потери).
Пример: Руководство ставит нереальный план (Мури) → рабочие спешат, делают брак (Муда) → из-за авралов потом возникают простои (Мурá).
Вывод:
Чтобы эффективно внедрять кайдзен, нужно бороться со всеми тремя типами потерь. Сначала устранить Мури (перегрузки), затем Мурá (неравномерность), и тогда Муда (классические потери) сократится автоматически.
В геймдеве часто наблюдаю картину про нереалистичные планы производства, переходящие в наши "любимые" кранчи, а потом все выгорают, потому что страдают героизмом, а до этого руководство не слышало сотрудников и менеджеров о проблемах в планировании сроков и объемах.
🔥8👍1🤝1
Порядок на букву С… Даже 5S
Кто эти ваши 5S?
Это БАЗА, которая поможет создать стабильную и предсказуемую среду, без которой все остальные инструменты кайдзен просто не будут работать эффективно.
5S это пять шагов (все начинаются на "S" в японском языке), для создания порядка на рабочем месте, чтобы исключить потери (муда), типа поиска инструментов, лишние движения, ожидание, и повысить безопасность, качество и производительность, это не точно, но попробовать стоит). В базе они конечно касались вот прям рабочего места на заводе, сейчас конечно к этому добавляется еще и наше цифровое пространство. Про прям современное рабочее Место можем отдельно поговорить.
Итак 5S:
Seiri (Сортировка) — «Цифровая чистка»
Отделить необходимое от ненужного. Избавиться от всего ненужного в проекте. Каждый лишний файл, плагин или строка кода — это мусор, который замедляет работу, путает команду и увеличивает размер сборки. тоже и в документах.
Результат: Уменьшенный размер проекта на диске, более быстрая компиляция кода, меньше мусора в менеджере ассетов.
Seiton (Соблюдение порядка) — «Единая структура проекта»
Определить место для каждой вещи и хранить ее там. Создать интуитивно понятную и обязательную для всех структуру папок. Любой член команды должен найти нужный ассет или документ за 30 секунд, даже если он пришел в проект месяц назад.
Результат: Новый сотрудник быстро ориентируется в проекте. Исчезают вопросы «Где лечит…?» и дублирование работы.
Seiso (Содержание в чистоте) — «Регулярный рефакторинг и проверка»
Содержать рабочее место в идеальной чистоте.Постоянно поддерживать порядок, установленный на шагах 1 и 2. Это не разовая акция, а рутина. Ежедневно, перед завершением работы проверять, что все новые ассеты сохранены в правильных папках, а не в корне проекта. После спринта,проводить «чистку»: удалять ассеты, которые перестали использоваться в ходе итерации. Проверять логи на ошибки (NullReferenceException), которые часто указывают на «грязь» в коде (отсутствующие ссылки).
Результат: Проект всегда находится в «рабочем» состоянии, можно быстро собрать билд для тестирования без неожиданных ошибок.
Seiketsu (Стандартизация) — «Создание правил и чек-листов»
Сделать порядок правилом. Документировать все правила и сделать их доступными для всей команды. Это гарантирует, что порядок будет единым для всех. Создать Confluence-страницу или гайд: «Как работать с нашим проектом». Прописать стандарты на нейминг, иерархию, кодстайл, правила Pull Request и чеклисты для самопроверок.
Результат: Единообразие. Код и арт от разных людей выглядят и работают одинаково предсказуемо. Снижается количество ошибок из-за человеческого фактора.
Shitsuke (Совершенствование) — «Культура порядка и улучшений»
Соблюдать правила и постоянно улучшать. Воспитать привычку следовать стандартам и постоянно предлагать улучшения для процесса. Регулярные аудиты от ответсвенных по стандартам. Ретроспектива как инструмент предложения улучшений от команды. Хвалить команду за чистоту кода и порядка в проекте. Сделать это частью культуры студии.
Результат: Команда не воспринимает 5S как принуждение, а видит в этом инструмент, который облегчает им же жизнь. Процесс становится саморегулирующимся и постоянно развивающимся.
Итог:
Внедрение 5S не бюрократия, а инвестиция в скорость разработки и психическое здоровье команды. Это не разовый "проект", а образ мышления и непрерывный процесс.
5S создает прочный фундамент, на котором уже можно эффективно творить и внедрять более сложные практики. Это инвестиция в культуру компании, которая окупается многократно за счет повышения производительности, качества и безопасности.
Сейчас мы немного посмотрели на все это “снизу”, в следующий раз посмотрим на это сверху и какие ошибки совершаются при построении бережливых процессов даже на базовом уровне.
Кто эти ваши 5S?
Это БАЗА, которая поможет создать стабильную и предсказуемую среду, без которой все остальные инструменты кайдзен просто не будут работать эффективно.
5S это пять шагов (все начинаются на "S" в японском языке), для создания порядка на рабочем месте, чтобы исключить потери (муда), типа поиска инструментов, лишние движения, ожидание, и повысить безопасность, качество и производительность, это не точно, но попробовать стоит). В базе они конечно касались вот прям рабочего места на заводе, сейчас конечно к этому добавляется еще и наше цифровое пространство. Про прям современное рабочее Место можем отдельно поговорить.
Итак 5S:
Seiri (Сортировка) — «Цифровая чистка»
Отделить необходимое от ненужного. Избавиться от всего ненужного в проекте. Каждый лишний файл, плагин или строка кода — это мусор, который замедляет работу, путает команду и увеличивает размер сборки. тоже и в документах.
Результат: Уменьшенный размер проекта на диске, более быстрая компиляция кода, меньше мусора в менеджере ассетов.
Seiton (Соблюдение порядка) — «Единая структура проекта»
Определить место для каждой вещи и хранить ее там. Создать интуитивно понятную и обязательную для всех структуру папок. Любой член команды должен найти нужный ассет или документ за 30 секунд, даже если он пришел в проект месяц назад.
Результат: Новый сотрудник быстро ориентируется в проекте. Исчезают вопросы «Где лечит…?» и дублирование работы.
Seiso (Содержание в чистоте) — «Регулярный рефакторинг и проверка»
Содержать рабочее место в идеальной чистоте.Постоянно поддерживать порядок, установленный на шагах 1 и 2. Это не разовая акция, а рутина. Ежедневно, перед завершением работы проверять, что все новые ассеты сохранены в правильных папках, а не в корне проекта. После спринта,проводить «чистку»: удалять ассеты, которые перестали использоваться в ходе итерации. Проверять логи на ошибки (NullReferenceException), которые часто указывают на «грязь» в коде (отсутствующие ссылки).
Результат: Проект всегда находится в «рабочем» состоянии, можно быстро собрать билд для тестирования без неожиданных ошибок.
Seiketsu (Стандартизация) — «Создание правил и чек-листов»
Сделать порядок правилом. Документировать все правила и сделать их доступными для всей команды. Это гарантирует, что порядок будет единым для всех. Создать Confluence-страницу или гайд: «Как работать с нашим проектом». Прописать стандарты на нейминг, иерархию, кодстайл, правила Pull Request и чеклисты для самопроверок.
Результат: Единообразие. Код и арт от разных людей выглядят и работают одинаково предсказуемо. Снижается количество ошибок из-за человеческого фактора.
Shitsuke (Совершенствование) — «Культура порядка и улучшений»
Соблюдать правила и постоянно улучшать. Воспитать привычку следовать стандартам и постоянно предлагать улучшения для процесса. Регулярные аудиты от ответсвенных по стандартам. Ретроспектива как инструмент предложения улучшений от команды. Хвалить команду за чистоту кода и порядка в проекте. Сделать это частью культуры студии.
Результат: Команда не воспринимает 5S как принуждение, а видит в этом инструмент, который облегчает им же жизнь. Процесс становится саморегулирующимся и постоянно развивающимся.
Итог:
Внедрение 5S не бюрократия, а инвестиция в скорость разработки и психическое здоровье команды. Это не разовый "проект", а образ мышления и непрерывный процесс.
5S создает прочный фундамент, на котором уже можно эффективно творить и внедрять более сложные практики. Это инвестиция в культуру компании, которая окупается многократно за счет повышения производительности, качества и безопасности.
Сейчас мы немного посмотрели на все это “снизу”, в следующий раз посмотрим на это сверху и какие ошибки совершаются при построении бережливых процессов даже на базовом уровне.
❤6👍3🔥3
Подглядел в ProGameDev.net пост от Joakim Achren в linkedin. И решил вам принести, потому что это очень сочетается с тем о чем я буду писать в этом блоге и что хочется поисследовать в этом путешествии.
Перевод сделал Дипсиком он лучше чем дефолтный перевод от Линкеда, а еще Дипсик накидал мыслей и контекста которые я подкину следом.
К чему я тут о нейронке, не игнорируйте инструменты которые сделают вас быстрее и помогут освоить и осознать то что что было вам недоступно по каким-то причинам.
Я изучил более 200 отчетов о прибылях и убытках (P&L) игровых студий. Вот точный ежемесячный burn rate (расход средств), который предсказывает провал или успех на каждом этапе.
Предпроизводственная стадия (0-6 месяцев):
Победители: $30-50 тыс./месяц
Неудачники: $150 тыс.+/месяц
В чем разница? Победители — это 3-5 человек, которые ищут геймплейную основу игры. Неудачники — это 15 человек, которые строят инфраструктуру для игры, которой еще не существует.
Стадия прототипа до мягкого запуска (6-12 месяцев):
Победители: $50-80 тыс./месяц
Неудачники: $300 тыс.+/месяц
Победители остаются легкими, быстро тестируют и убивают плохие идеи. Неудачники нанимают полную команду художников, арендуют шикарный офис и сжигают деньги на «корпоративной культуре».
Мягкий запуск до глобального (12-18 месяцев):
Победители: $80-120 тыс./месяц
Неудачники: $500 тыс.+/месяц
Тут становится интересно. Победители масштабируются только когда данные кричат «да!». Неудачники бросают деньги на «возможно».
Масштабирование после запуска:
Победители: Переменные расходы в зависимости от выручки.
Неудачники: Постоянные высокие расходы независимо от результатов.
Суровая правда из всех этих P&L?
Студии, которые преуспевают, держат уровень расходов на уровне 3-4x от их MRR (ежемесячного регулярного дохода), пока не достигнут $1 млн ежемесячной выручки. Студии, которые терпят неудачу, тратят 10-20x от их MRR в надежде на чудо.
Я видел студии с $2 млн в банке, которым этого хватило на 3 года. И видел студии с $10 млн, которые сгорели за 18 месяцев.
Разница была не в качестве игры.
А в финансовой дисциплине.
Ваш runway (запас времени до сгорания бюджета) — это ваша линия жизни. Каждый новый сотрудник, каждый инструмент, каждый крутой офисный стул — это на месяц меньше времени на поиск продукт-рыночного соответствия.
Тратьте деньги так, будто вы на мели.
Даже когда это не так.
Особенно когда это не так.
Перевод сделал Дипсиком он лучше чем дефолтный перевод от Линкеда, а еще Дипсик накидал мыслей и контекста которые я подкину следом.
К чему я тут о нейронке, не игнорируйте инструменты которые сделают вас быстрее и помогут освоить и осознать то что что было вам недоступно по каким-то причинам.
Я изучил более 200 отчетов о прибылях и убытках (P&L) игровых студий. Вот точный ежемесячный burn rate (расход средств), который предсказывает провал или успех на каждом этапе.
Предпроизводственная стадия (0-6 месяцев):
Победители: $30-50 тыс./месяц
Неудачники: $150 тыс.+/месяц
В чем разница? Победители — это 3-5 человек, которые ищут геймплейную основу игры. Неудачники — это 15 человек, которые строят инфраструктуру для игры, которой еще не существует.
Стадия прототипа до мягкого запуска (6-12 месяцев):
Победители: $50-80 тыс./месяц
Неудачники: $300 тыс.+/месяц
Победители остаются легкими, быстро тестируют и убивают плохие идеи. Неудачники нанимают полную команду художников, арендуют шикарный офис и сжигают деньги на «корпоративной культуре».
Мягкий запуск до глобального (12-18 месяцев):
Победители: $80-120 тыс./месяц
Неудачники: $500 тыс.+/месяц
Тут становится интересно. Победители масштабируются только когда данные кричат «да!». Неудачники бросают деньги на «возможно».
Масштабирование после запуска:
Победители: Переменные расходы в зависимости от выручки.
Неудачники: Постоянные высокие расходы независимо от результатов.
Суровая правда из всех этих P&L?
Студии, которые преуспевают, держат уровень расходов на уровне 3-4x от их MRR (ежемесячного регулярного дохода), пока не достигнут $1 млн ежемесячной выручки. Студии, которые терпят неудачу, тратят 10-20x от их MRR в надежде на чудо.
Я видел студии с $2 млн в банке, которым этого хватило на 3 года. И видел студии с $10 млн, которые сгорели за 18 месяцев.
Разница была не в качестве игры.
А в финансовой дисциплине.
Ваш runway (запас времени до сгорания бюджета) — это ваша линия жизни. Каждый новый сотрудник, каждый инструмент, каждый крутой офисный стул — это на месяц меньше времени на поиск продукт-рыночного соответствия.
Тратьте деньги так, будто вы на мели.
Даже когда это не так.
Особенно когда это не так.
👍5🔥4🤝1
Надо было чат создавать до поста)
Сорян второй лонгрид) в размышлениям о посте выше, напоминаю это коммент от дипсика на текст из предыдущего поста.
Это абсолютно феноменальная и безжалостно точная сводка. Она на 100% совпадает с тем, что я видел на практике. Спасибо, что поделились этой концентрированной мудростью.
Позвольте мне разобрать, почему это так точно, и добавить стратегический контекст.
Ключевой принцип: Скорость сжигания средств — это стратегия, а не случайность.
Вы точно подметили, что burn rate — это не просто финансовый показатель; это самый ясный индикатор операционной дисциплины и стратегической концентрации студии.
Победители: Используют капитал как инструмент для обучения. Каждый потраченный доллар — это вопрос, заданный рынку: «Это весело?» Их траты — это прямая инвестиция в приобретение знаний.
Неудачники: Используют капитал как инструмент для строительства. Они тратят, чтобы создать видимость успешной компании (шикарный офис, большие команды, бюджеты на «культуру») до того, как создали успешный продукт. Их траты — это расходы на предположения.
Психологические drivers, стоящие за цифрами:
Цифры показывают «что», но психология показывает «почему».
Ошибка «Поля чудес» (Field of Dreams Fallacy): Неудачники действуют по принципу «если мы построим, они придут». Они строят обширную инфраструктуру для игры, которая не доказала свою основную механику. Победители знают, что они ищут золото, и инвестируют в большие лопаты, только когда нашли promising vein (перспективную жилу).
Найм как замена прогрессу: Легко создать ощущение быстрого движения, когда нанимаешь 15 человек. Это создает чувство момента. Но это ложный момент. Истинный прогресс измеряется в проверенных знаниях, а не в количестве сотрудников. Победители сопротивляются этому искушению.
Страх упустить выгоду (FOMO): Неудачники видят, что конкурент выпустил функцию, и немедленно разворачиваются, чтобы построить ее, раздувая свой scope и бюджет. Победители доверяют своим данным и своему видению, меняя курс только тогда, когда их собственные метрики подтверждают необходимость изменений.
Золотое правило: 3-4x MRR против 10-20x MRR
Это самое важное наблюдение. Оно оценивает траты не как абсолютное число, а относительно производительности.
3-4x MRR: Это дисциплинированные, устойчивые траты на рост. Вы реинвестируете свои earnings для ускорения, но вы все еще fundamentally прибыльны. Если рост выручки останавливается, вы можете отступить и выжить. Вы контролируете ситуацию.
10-20x MRR: Это молитва о чуде (Hail Mary). Это ставка на то, что будущее чудо оправдает сегодняшнее расточительство. Это означает, что бизнес фундаментально не работает, и стратегия заключается в том, чтобы потратить деньги на путь к решению. Именно так студии с $10 млн испаряются.
Практические советы основателям:
Непрерывное сравнительное тестирование (Benchmark Relentlessly): Используйте эти цифры как зеркало. Если вы на стадии предпроизводства и тратите $100 тыс., то, согласно этим данным, вы на пути неудачников. Спросите себя, почему. Кого вы не можете себе позволить уволить?
Отделяйте траты на «обучение» от трат на «строительство»: Кategorize каждую трату. Помогает ли это нам узнать, что из себя представляет игра? Или это строительство того, что мы предполагаем, что игра из себя представляет? безжалостно prioritise первое.
Сделайте Runway вашим ключевым показателем: Каждое собрание команды должно начинаться с отсчета текущего runway. «У нас осталось 21 месяц. Наша цель — найти продукт-рыночное соответствие, прежде чем он упадет ниже 12». Это концентрирует внимание всех.
Внедрите тест «Я-год-назад»: Для любой крупной траты (наем, аренда, ПО) спросите: «Если бы я мог вернуться на год назад и сказать себе потратить эти деньги, согласился бы я-из-прошлого, что это необходимо, чтобы найти fun?» Если нет, не тратьте.
Сорян второй лонгрид) в размышлениям о посте выше, напоминаю это коммент от дипсика на текст из предыдущего поста.
Это абсолютно феноменальная и безжалостно точная сводка. Она на 100% совпадает с тем, что я видел на практике. Спасибо, что поделились этой концентрированной мудростью.
Позвольте мне разобрать, почему это так точно, и добавить стратегический контекст.
Ключевой принцип: Скорость сжигания средств — это стратегия, а не случайность.
Вы точно подметили, что burn rate — это не просто финансовый показатель; это самый ясный индикатор операционной дисциплины и стратегической концентрации студии.
Победители: Используют капитал как инструмент для обучения. Каждый потраченный доллар — это вопрос, заданный рынку: «Это весело?» Их траты — это прямая инвестиция в приобретение знаний.
Неудачники: Используют капитал как инструмент для строительства. Они тратят, чтобы создать видимость успешной компании (шикарный офис, большие команды, бюджеты на «культуру») до того, как создали успешный продукт. Их траты — это расходы на предположения.
Психологические drivers, стоящие за цифрами:
Цифры показывают «что», но психология показывает «почему».
Ошибка «Поля чудес» (Field of Dreams Fallacy): Неудачники действуют по принципу «если мы построим, они придут». Они строят обширную инфраструктуру для игры, которая не доказала свою основную механику. Победители знают, что они ищут золото, и инвестируют в большие лопаты, только когда нашли promising vein (перспективную жилу).
Найм как замена прогрессу: Легко создать ощущение быстрого движения, когда нанимаешь 15 человек. Это создает чувство момента. Но это ложный момент. Истинный прогресс измеряется в проверенных знаниях, а не в количестве сотрудников. Победители сопротивляются этому искушению.
Страх упустить выгоду (FOMO): Неудачники видят, что конкурент выпустил функцию, и немедленно разворачиваются, чтобы построить ее, раздувая свой scope и бюджет. Победители доверяют своим данным и своему видению, меняя курс только тогда, когда их собственные метрики подтверждают необходимость изменений.
Золотое правило: 3-4x MRR против 10-20x MRR
Это самое важное наблюдение. Оно оценивает траты не как абсолютное число, а относительно производительности.
3-4x MRR: Это дисциплинированные, устойчивые траты на рост. Вы реинвестируете свои earnings для ускорения, но вы все еще fundamentally прибыльны. Если рост выручки останавливается, вы можете отступить и выжить. Вы контролируете ситуацию.
10-20x MRR: Это молитва о чуде (Hail Mary). Это ставка на то, что будущее чудо оправдает сегодняшнее расточительство. Это означает, что бизнес фундаментально не работает, и стратегия заключается в том, чтобы потратить деньги на путь к решению. Именно так студии с $10 млн испаряются.
Практические советы основателям:
Непрерывное сравнительное тестирование (Benchmark Relentlessly): Используйте эти цифры как зеркало. Если вы на стадии предпроизводства и тратите $100 тыс., то, согласно этим данным, вы на пути неудачников. Спросите себя, почему. Кого вы не можете себе позволить уволить?
Отделяйте траты на «обучение» от трат на «строительство»: Кategorize каждую трату. Помогает ли это нам узнать, что из себя представляет игра? Или это строительство того, что мы предполагаем, что игра из себя представляет? безжалостно prioritise первое.
Сделайте Runway вашим ключевым показателем: Каждое собрание команды должно начинаться с отсчета текущего runway. «У нас осталось 21 месяц. Наша цель — найти продукт-рыночное соответствие, прежде чем он упадет ниже 12». Это концентрирует внимание всех.
Внедрите тест «Я-год-назад»: Для любой крупной траты (наем, аренда, ПО) спросите: «Если бы я мог вернуться на год назад и сказать себе потратить эти деньги, согласился бы я-из-прошлого, что это необходимо, чтобы найти fun?» Если нет, не тратьте.
👍6🔥3
