Бесплатный фрагмент - Модель цифровой ценности. Введение в dVM

ДИСКЛЕЙМЕР И ПРЕДУПРЕЖДЕНИЕ ОТ АВТОРОВ

Данная работа представляет собой собрание принципов, методик, мемов и провокаций, возникших в рамках экспериментального подхода к управлению проектами, известного как Digital Value Model (dVM). Это не истина в последней инстанции, а скорее коллекция наших граблей, шишек и провалов. На момент издания этой книги данную модель уже два года тестируют в нескольких закрытых группах, и уже есть первые результаты, но говорить о статистической значимости и репрезентативности выборки пока преждевременно — когорта испытуемых недостаточно велика, а данные требуют верификации и проверки на систематическую ошибку. В условиях отсутствия контрольных групп и рандомизации мы воздерживаемся от категоричных выводов и пока оперируем качественными, а не количественными инсайтами. Сейчас ясно одно: dVM — это «роскошество», доступное лишь тем, кто готов принять высокую степень неопределенности и работать в условиях методологического хаоса.

Авторы и издатель настоящим заявляют и снимают с себя ответственность за:

Любые прямые или косвенные последствия, убытки и ущерб, возникшие в результате применения, неправильного применения или непонимания изложенных здесь методов и идей.

Испорченные отношения с заказчиками, инвесторами, стейкхолдерами и коллегами; разваленные команды; добровольные и принудительные увольнения сотрудников, не переживших dVM-хаос; финансовые потери и репутационные риски.

Ваше профессиональное и экзистенциальное выгорание, психологические травмы, испорченную психику, потерю мотивации, веры в человечество и прочие формы ментального дискомфорта.

Соматические последствия: разлитие желчи, приступы тошноты, потерю потенции, выпадение волос, бессонницу, кипение возмущённого разума и иные негативные реакции организма.

Безвозвратную потерю времени, потраченного на чтение, обдумывание и бессмысленные споры об этой методологии.

Также авторы не несут дискурсивной, юридической или кармической ответственности за ваше поведение после прочтения и не обязаны разъяснять, что они «хотели сказать».

ВНИМАНИЕ: МОДЕЛЬ ЦИФРОВОЙ ЦЕННОСТИ dVM — ЭТО ОГОЛЕННЫЙ ПРОВОД ПОД НАПРЯЖЕНИЕМ. ОНА НИЧЕГО НЕ РАЗЖИГАЕТ И НИ К ЧЕМУ НЕ ПРИЗЫВАЕТ, ОНА ПРОСТО ПОКАЗЫВАЕТ КРАСИВОЕ И/ИЛИ БЕЗОБРАЗНОЕ.

Для кого она: Для сильных профессионалов и команд, способных отличить метафору от инструкции, шутку от директивы, а цинизм — от здравого смысла. Для тех, кто умеет фильтровать шум и адаптировать абсурд под свой контекст.

Кому не пригодится: Для глупых, наивных, слабых духом, морально неустойчивых, для тех, кто ищет простые ответы и пошаговые инструкции. Она сожжет нейроны, карьеру и выплюнет неподготовленного пользователя.

Данное произведение содержит провокационные, нетривиальные, намеренно деструктивные подходы, а также может содержать сцены интеллектуального насилия и нецензурные выражения.

Не применяйте эту модель бездумно. Совсем не применяйте. Вы предупреждены.

18+

Введение: когда Agile умирает, а Waterfall уже мёртв

В мире управления проектами мы застряли в вечном противостоянии.

С одной стороны — гибкость.

Agile, Scrum, Kanban, Lean, XP — все они обещают адаптацию, скорость и минимизацию потерь.

Но на практике часто превращаются в ритуалы без результата: бесконечные ретроспективы, митинги без решений, MVP, которые никто не хочет использовать.

С другой стороны — структура.

Waterfall, CPM, CCPM — подходы, построенные на планировании, этапах и контрольных точках.

Но в реальном мире, где требования меняются каждую неделю, они превращаются в бюрократические машины, которые тонут в документах, прежде чем успевают запустить первую фичу.

Где истина?

В середине?

Нет.

В отказе от поиска середины.

Знакомьтесь: dVM — Digital Value Model

Это не очередная методология.

Это новая философия движения.

dVM — не про баланс.

Он про выбор.

Выбор в пользу ценности.

Выбор против холивара.

Выбор в пользу результата, даже если он рождается в хаосе.

dVM впитал лучшее из гибких и каскадных подходов —

и выбросил всё, что мешает двигаться вперёд.

«Если что-то не создаёт ценность — оно уходит в утиль.

Даже если это любимый процесс начальника.»

История одной шутки, ставшей реальностью

Первая версия dVM называлась Degeneracy Vegetables Model — просто ради смеха, чтобы поиздеваться над очередным «инновационным фреймворком».

Но потом к ней прикоснулись:

аналитики, DevOps, тимлиды, QA, UX-дизайнеры.

И вдруг поняли:

«Она работает.

Не потому, что она красивая.

А потому что она честная.»

Сегодня dVM — не мем.

Это инструмент, который помогает командам:

— Двигаться быстрее.

— Принимать решения без бесконечных согласований.

— Достигать результатов, не теряя себя в процессах.

Что даёт dVM?

✔ Баланс между хаосом Agile и жесткостью Waterfall —

не как компромисс, а как стратегия выживания в мире, где всё меняется.

✔ Фокус на ценности, а не на процессной др0чке —

если задача не приносит пользы — она не существует.

✔ Гибкость там, где нужна, и порядок там, где важен —

не догма, а инструмент.

✔ Реальные метрики и понятные критерии успеха —

не ради отчётов, а ради движения.

Ключевые принципы dVM

1. Вайб — это всё

Если атмосфера тухлая — проект мёртв.

Настроение команды важнее всех фреймворков, дедлайнов и KPI.

Ценность рождается там, где есть энергия.

2. Итерация ради итерации — идёт на х#р

Делай только то, что реально двигает вперёд.

Всё остальное — в топку.

«Не каждый шаг — прогресс.

Только тот, что ведёт к цели.»

3. Кто не спрятался — сам виноват

Мир меняется.

Или ты адаптируешься — или идёшь чистить backlog вечности.

4. Аджаил-задр0ты, на выход

Методологии без души — это просто др0чка на процессы.

Нам нужен движ, а не бесконечные ретроспективы.

Решения принимаются в живом общении, а не в грёбанных отчётах.

5. «Не ху#ню ли я делаю?»

Любая идея под сомнением.

Ху#ню лучше остановить сразу, пока не стало поздно.

Ультранасилие: почему жёсткость — это любовь

В большинстве компаний «командная культура» означает:

вежливость, согласие, уважение.

Но на практике это превращается в молчаливое одобрение плохих решений,

в безмолвное принятие неэффективности,

в пирожки и мемы вместо роста.

dVM выбирает другой путь.

Путь ультранасилия.

«Не потому, что мы любим страдания.

А потому что они работают.»

Ультранасилие — это не агрессия. Это метод.

В dVM «насилие» — это не буквальное.

Это методологический приём,

позволяющий ускорить проверку гипотез,

выявить слабые места,

и подтолкнуть команду к действиям,

которые в ином случае растянулись бы на месяцы.

Оно работает по принципу радикального давления на систему —

как в спорте, где только нагрузка создаёт рост мышц.

1. Гипотезы под давлением

Обычные компании тестируют гипотезы месяцами:

сбор данных, согласования, A/B-тесты, отчёты.

dVM делает иначе.

— Сжатые сроки: гипотеза либо срабатывает, либо умирает в муках.

— Никто не жалеет идеи, которые не выдерживают тестов.

— Беспощадные вопросы: каждый продукт проходит через огонь допросов.

— «Зачем это нужно?»

— «Почему это не провалится?»

— «Кто первый умрёт, если это запустить?»

— Шоковая терапия: пользователи сталкиваются с экстремальными версиями продукта,

— чтобы выявить реальные боли, а не вежливые ответы.

Пример: вместо A/B-тестов команда выкатывает радикальное изменение UI без предупреждения.

Если пользователи адаптируются — гипотеза подтверждена.

Если нет — rollback, но с ценными инсайтами.

2. Customer Development на грани нервного срыва

Сбор обратной связи в dVM — это не интервью.

Это стресс-тест.

— Только жесткая правда: никаких «а что вы думаете?»

— Только: «Что вас больше всего бесит?» и «На какой фиче вы готовы платить?»

— Выживание продукта: клиентские боли проверяются через принудительное использование продукта в его худшем состоянии.

— Разжигание эмпатии: команда ставит пользователей в экстренные условия,

— чтобы получить честную, неотфильтрованную реакцию.

Пример: перед запуском нового интерфейса команда даёт старым пользователям закрытую бету без инструкций.

Смотрит, кто сломается первым.

И учится.

3. Разработка продукта через хаос

Product development в dVM — это не Waterfall.

Не Agile.

Это управляемый беспорядок.

— Фичи выпускаются, пока кто-то не закричит:

— Если никто не орёт в Slack — команда недостаточно быстро выпускает возможности.

— Баги — тоже фичи:

— Если пользователи находят баг и используют его как функцию — оставь и дай красивое название.

— Код пишется, чтобы его боялись менять:

— Если часть системы становится легендой — оставь её в первозданном виде, как святыню.

— Пример: новый API вводится без документации.

— Только те, кто смог его понять, могут использовать.

— Остальные — учатся.

4. Совершенствование через боль

В dVM рост достигается через страдание, но в конструктивном ключе.

— Критика доведена до предела:

— Любая ошибка разбирается до атомов, чтобы никто никогда больше так не делал.

— Тренировка боем:

— Новички сразу бросаются в самый сложный проект.

— Либо выживают — либо становятся анекдотом внутри команды.

— Минимум жалости:

— Если тебе не нравится, что тебя троллят за плохой код — пиши лучше.

— Пример: новый разработчик, написавший неэффективный SQL-запрос,

— получает в подарок 10 млн записей и полный лог серверной нагрузки.

— Чтобы почувствовать боль.

Вывод: dVM как школа радикального роста

Ультранасилие в dVM — это не хаос ради хаоса.

Это инструмент, который создаёт:

✔ Быстрый отбор лучших решений.

✔ Искреннюю, жёсткую обратную связь.

✔ Постоянное давление, которое делает команду сильнее.

✔ Культуру боли, из которой рождается мастерство.

Такой подход может показаться экстремальным.

Но в условиях постоянной конкуренции и нехватки времени — он позволяет не просто выживать.

Он позволяет доминировать.

dVM Team Structure: Архитектура Хаоса

Где рождаются решения, которые никто не планировал

Структура dVM идеально подходит для команд от 7 до 25 человек,

где гибкость не превращается в анархию, а эффективность — в бюрократию.

Это не просто команда.

Это организм, выживший в условиях постоянного кризиса.

Для масштабирования на более крупные предприятия dVM предлагает модульный подход:

команда делится на автономные сегменты, каждый из которых работает в рамках общей стратегии, но с полной свободой в тактике.

«Гибкость без контроля — это хаос. Контроль без гибкости — это смерть. dVM балансирует на грани.»

Ключевые роли в dVM-команде

В dVM нет «должностей» в классическом понимании.

Есть функции, архетипы и ритуалы.

Каждая роль — не просто набор обязанностей.

Это социальный механизм, поддерживающий движ, вайб и контролируемое безумие.

Owner: Видение в условиях тумана

Отвечает за стратегическое видение продукта и принимает ключевые решения по его развитию.

Взаимодействует с заказчиками, чтобы гарантировать соответствие продукта ожиданиям — даже если эти ожидания ещё не сформулированы.

«Owner не объясняет, зачем что-то нужно.

Он делает так, чтобы все поверили, что это было их идеей.»

Примечание: при отсутствии Owner его функции выполняет PM — но с пометкой «временно, пока не найдут настоящего».

Crab Master: Хозяин хаоса

Главный фасилитатор.

Следит за тем, чтобы команда работала слаженно, даже когда всё идёт не по плану.

Управляет встречами, дискуссиями, процессами — не ради порядка, а ради результата.

Основной инструмент — DDD (Dude Degeneracy Diagram), диаграмма деградации команды.

В редких случаях используется фалоситация — метод «сажания на бутылку» участников, портящих общий vibe.

«Фалоситация — не наказание.

Это терапия для тех, кто забыл, зачем пришёл.»

Идеальный кандидат:

— Бывшие сотрудники спецслужб.

— Переквалифицированные Scrum-мастера (с последующей реабилитацией).

— Люди, умеющие смотреть в глаза и говорить:

«Ты — Dolb@eb.»

Trigger Engineer: Химик реакций

Анализирует, как команда реагирует на бизнес-требования.

Оптимизирует процессы, заключает договоры, контролирует cash flow.

Также решает мелкие коллизии внутри команды.

Часто использует фирменную связку: «Пизд0шно / Роскошество» — для мгновенной оценки ситуации.

«Он не управляет командой.

Он поджигает её.»

NetArchitect: Строитель сетей и сарказма

Разрабатывает архитектуру системы, выбирает технологии.

Следит за соблюдением архитектурных принципов — и за тем, чтобы все называли интерфейс «интерфейсом», а не «вот это вот».

«Если он орёт — значит, кто-то сломал сетевой стек.

Если молчит — значит, уже починил.»

TeamVibe: Душа команды

Руководит разработчиками, распределяет задачи, контролирует выполнение.

Но его главная функция — поддержание вайба.

— Включает музыку.

— Рассказывает анекдоты в чате.

— Поднимает настроение.

— Иногда — выносит мозг.

«TeamVibe не управляет.

Он создаёт атмосферу, в которой даже баги кажутся фичами.»

MDA (Master of Delightful Atmosphere): Архитектор радости

Работает в паре с TeamVibe.

Организует выездные мероприятия, battle-ретроспективы с шашлыками, и вечеринки с непредсказуемыми последствиями.

Требования к кандидату:

— Неподдельный оптимизм.

— Расширенное или изменённое сознание.

— Умение превратить провал в праздник.

EHA (Easy/Hard Admin): Универсальный админ

Многофункциональный оператор.

Занимается:

— Исследованием проблематики задач.

— Оценкой результативности.

— Ведением бэклога.

— Логированием чатов.

— Архивацией VHS-носителей (на всякий случай).

— Прогревом джойстиков перед вечеринкой.

Подчиняется напрямую Crab Master’у.

Может замещать его в отпуск.

Является связующим звеном при масштабировании.

«EHA — это не должность.

Это призвание.»

Kashew: Отсутствие орехов

В команде dVM нет орехов, сухариков и прочей бесполезной хрени.

Это не роль.

Это принцип.

«Мы не держим в команде то, что не двигает вперёд.»

Project Manager (PM): Посол иллюзий

Управляет сроками, бюджетом, качеством.

Координирует команду фразами вроде «реши вопрос!»

Общается с заказчиками: «всё хорошо, прекрасная маркиза», даже если всё горит.

«В самоорганизованных командах PM не нужен.

Но на вечеринке — он всегда пригодится.»

Software Developers: Генераторы ценности

Пишут код, реализуют функциональность.

Включают фронтенд, бэкенд, мобильных разработчиков, специалистов по ИИ.

«Они не пишут код.

Они создают реальность.»

HR Lead: Управление людьми и Agile-шутками

Отвечает за найм, адаптацию, удержание.

Знает Agile.

При необходимости идёт нах#й.

Решает конфликты, контролирует документацию.

При необходимости — делает всё, что нужно.

KarmaPolice: Страж порядка и хаоса

Автоматизирует процессы: разработку, тестирование, деплой.

Без эмпатии, но с виски — анализирует действия каждого, оценивает в баллах.

Следит за инфраструктурой.

Обладает карательными функциями вместе с Crab Master’ом.

«KarmaPolice не прощает.

Он запоминает.»

Типичный кандидат: опытный DevOps, который не боится нажать «удалить».

CE (Cones Engineer): Страж качества

Функционально — QA-инженер.

Следит за полнотой и актуальностью тестов.

Сверяет разработку с roadmap’ом.

Часто — отставной военный с атлетическим телосложением и кожаным плащом.

Это помогает поддерживать дисциплину.

PussyMan: Мотиватор и поставщик радости

Молодой сотрудник, отвечающий за мотивацию и моральный дух.

— Организует тимбилдинги.

— Фильтрует эскортниц для вечеринок.

— Приносит сладкую воду и влажные салфетки.

— Может приносить вкусняшки от MDA.

«Он не просто поддерживает дух.

Он его перезагружает.»

Wall Admin: Тот, кто пробивает стены

Способен «пробивать стены» — в переносном и буквальном смысле.

«Когда задача кажется непреодолимой — Wall Admin просто проходит сквозь неё.»

Hozayin (Big Admin): Хозяин инфраструктуры

Системный администратор, закупщик, ключевой элемент стабильности.

— Обеспечивает работу всех систем.

— Закупает оборудование.

— Имеет право первого выбора эскортниц.

— Контролируется PM, TeamVibe, MDA.

— Получает помощь от PussyMan.

— Иногда может быть Wall Admin (в небольших командах)

«Hozayin — не просто админ.

Он — святыня.»

UX/UI Designer: Архитектор пользовательского опыта

Разрабатывает интерфейс, следит за удобством.

Создаёт макеты, прототипы.

Сосёт кофеин за всю команду.

«Если пользователь не сломался — значит, дизайн хорош.»

M$ (МаСкот, Мелкомягкий): Талисман и стресс-менеджер

Талисман команды.

Выбирается из числа тех, кто отличается от остальных — по полу, возрасту, национальности, росту, весу, виду.

Выполняет роль стресс-менеджера:

— Провоцирует команду.

— Проверяет на живучесть.

— Следит за уровнем эмпатии.

Методы:

— Шутки о сексуальной ориентации.

— Вопросы о целесообразности присутствия в команде.

Требуется:

— Эмоциональная стабильность.

— Контроль со стороны Crab Master, TeamVibe, PM, KarmaPolice.

— Ежедневный анализ от Trigger Engineer.

— Периодическая ротация.

Лучшие кандидаты:

— Бывшая стриптизёрша.

— Вебкамщица.

— Школьный учитель информатики на позиции джуна.

— Специалист по Agile.

— Assembler.

— забытый всеми блогер.

— Карлик, одноглазый, афроамериканец, чухонец, уссуриец, реже кореец.

— Морская черепаха или попугай (в экстремальных случаях).

«M$ — не жертва. Он — катализатор.»

Чат-бот: Цифровой наблюдатель

В рабочие чаты добавляется ИИ-бот, который:

— Логирует переписку.

— Следит за запрещёнными темами.

— Ведёт статистику эффективности.

— В конце недели награждает лучших шуточными званиями.

— Обозначает провинившихся как pidr, jackal, pidr/jackal — по степени деградации.

«Это не слежка. Это — обратная связь в реальном времени.»

Крайне полезен для Crab Master и KarmaPolice.

Заключение: почему это работает

dVM Team Structure — это не хаос. Это управляемая дестабилизация. Каждая роль — не просто функция. Это механизм поддержания баланса между:

— движом и болью,

— фаном и страданием,

— хаосом и результатом.

«Мы могли бы делать всё правильно. Но где в этом веселье?»

Стили управления в dVM

Как управлять, когда всё идёт не по плану

В классическом менеджменте существует множество стилей управления: от трансформационного до коучингового.

Но в условиях постоянного кризиса, перманентного хаоса и вечной нехватки кофе — эти подходы часто превращаются в бумажные ритуалы, которые ничего не решают.

Команда dVM адаптировала традиционные стили под свои реалии, добавив дозу отчаяния, безысходности и, конечно, хаоса.

В результате появилось пять ключевых стилей, каждый из которых работает в определённой фазе проекта — или просто тогда, когда нечем дышать.

1. Бюрократический стиль

aka «Круги ада Jira»

Практикуется: Project Manager (PM)

Философия: «Любую проблему можно решить дополнительным процессом.»

В этом стиле каждая задача проходит через многоуровневую систему документирования, согласований и обсуждений, где процесс важнее результата.

Признаки:

— Ни одна задача не может быть начата без заполнения 20-страничной документации.

— Все действия строго следуют процессу — даже если он явно не работает.

— Легенда гласит: однажды задача была завершена, но никто не мог найти подтверждающую бумагу — и её закрыли повторно.

Плюсы:

— Минимальный хаос.

— Всё задокументировано (по крайней мере, в теории).

Минусы:

— Один проект требует пяти жизней.

— Команда начинает считать дни до пенсии.

«Это не управление. Это археология.»

2. Служение (Сервисный лидер)

aka «Будда сгорает, но улыбается»

Практикуется: Crab Master

Философия: «Моя задача — не управлять, а служить. Создать идеальную атмосферу и убрать все блокеры.»

Такой лидер действует как духовный наставник: сочувствует, мотивирует, проводит бесконечные 1:1-встречи, но никогда не принимает решений.

Признаки:

— Вместо «Что за фигня, почему не работает?» — «Давайте вместе подумаем, как преодолеть этот вызов.»

— Встречи один на один случаются чаще, чем солнечные дни.

— Команда делает, что хочет… и при этом каким-то образом всё работает.

Плюсы:

— Высокий уровень эмпатии и морального духа.

— Команда чувствует себя любимой.

Минусы:

— Иногда напоминает коммуну хиппи, где никто не знает, кто за что отвечает.

— Решения принимаются методом «молчаливого согласия».

«Он не ведёт. Он плывёт по течению, улыбаясь сквозь слёзы.»

3. Авторитарный стиль

aka «Скала не обсуждает»

Практикуется: Hozayin, NetArchitect

Философия: «Вы не спрашиваете. Вы делаете.»

Используется, когда ситуация выходит из-под контроля, а времени на дискуссии нет.

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

Признаки:

— Встреча длится 2 минуты:

— «Ты делаешь это. Ты делаешь то. Вопросы? Их нет. Разошлись.»

— В Slack: "@everyone, почему это ещё не сделано?»

— Код-ревью превращается в суд инквизиции.

Плюсы:

— Задачи закрываются быстро.

— Никто не расслабляется.

Минусы:

— Риск массового эмоционального выгорания.

— Возможен бунт после релиза.

«Когда тонет корабль, капитан не опрашивает матросов.»

4. Невмешательство (Laissez-faire)

aka «Бог устал, теперь сами»

Практикуется: Wall Admin

Философия: «Если ты разработчик, то, наверное, умеешь гуглить.»

Этот стиль строится на полном доверии к команде — или, скорее, на полной усталости от управления.

Признаки:

— Любой вопрос получает ответ: «RTFM».

— Руководитель не вмешивается, пока сервер не упадёт или кто-то не уйдёт в запой.

— Культура: «самоорганизация через боль».

Плюсы:

— Полная свобода.

— Команда учится решать проблемы самостоятельно.

Минусы:

— Никто не знает, правильно ли он делает свою работу.

— Результат может быть как гениальным, так и катастрофическим.

«Это не лидер. Это наблюдатель на орбите.»

5. dVM-хаос

aka «Вечеринка с огнетушителями»

Практикуется: вся команда (в режиме полной синергии)

Философия: «План — это просто список того, что мы не будем делать.»

Это эксклюзивный стиль dVM, который работает только в сильной, сплочённой команде, способной превращать хаос в результат.

Признаки:

— Все планы строятся за 5 минут до дедлайна.

— Сложные проблемы решаются методом «кто громче крикнет — того и слушаем».

— M$ (МаСкот) регулярно проводит стресс-тесты, напоминая: «Завтра релиз. А вы ещё не начали.»

Плюсы:

— Максимальная гибкость.

— Творческий подход к задачам.

— Героизм рождается из страданий.

Минусы:

— Если вы не любите хаос — он вас сломает.

— Внешние наблюдатели могут подумать, что команда сошла с ума.

«Мы не управляли. Мы просто выжили. И, чёрт возьми, это сработало.»

Вывод: почему dVM-хаос — это не провал, а стратегия

Каждый стиль управления имеет право на существование.

Но dVM-хаос — это не просто стиль.

Это философия, которая идеально отражает суть команды:

«Мы могли бы делать всё правильно.

Но где в этом веселье?»

Модель DISC в команде dVM

Для понимания динамики команды можно использовать модель DISC, адаптированную под dVM-реальность:

В dVM управление — это не контроль.

Это баланс между хаосом, болью и фаном.

И, если вы не сгорели, значит, вы не старались.

Новая тройственная ограниченность

CHAOS, PAIN, FUN

Почему старый треугольник Time-Cost-Quality больше не работает?

В классическом управлении проектами успех определяется тремя параметрами:

— Time — как быстро.

— Cost — сколько стоит.

— Quality — насколько хорошо.

Измените один — и два других тут же сдвинутся.

Хотите дешевле? Жертвуйте качеством или сроками.

Нужно быстрее? Готовьтесь платить больше или получать хуже.

Это логично.

Это предсказуемо.

Это мертво.

Потому что в реальном мире разработки IT-продуктов ничего не предсказуемо.

Требования меняются каждый день.

Команды горят.

Клиенты просят «чуть-чуть допилить» — и это «чуть-чуть» становится 33% проекта.

А «качество» — понятие, которое никто не может определить, пока продукт не упадёт.

dVM заменяет треугольник на триаду: CHAOS — PAIN — FUN

Мы отказались от иллюзии контроля.

Вместо качества мы поставили эмоции.

Вместо планов — выживание.

Вместо баланса — динамическое напряжение.

«Мы не управляем проектом. Мы балансируем на грани.»

1. CHAOS (Хаос) — Двигатель инноваций

Определение: уровень неопределенности, изменений и нелогичных решений.

Как влияет:

— Слишком мало хаоса → проект становится медленным, бюрократичным, предсказуемым.

— Как сон в 3 часа ночи: долгий, но бесполезный.

— Слишком много хаоса → команда теряет контроль, но появляются неожиданные прорывы.

— Как огонь: может уничтожить, а может нагреть.

Оптимальный уровень:

Когда никто не понимает, что происходит,

но решения рождаются быстрее, чем их отменяют.

Как управляется:

— Поддерживается через отсутствие документации и резкие смены приоритетов.

— Балансируется стратегией: «Давайте попробуем и посмотрим, что будет.»

— Если хаоса слишком мало — вводится искусственно:

— спонтанные ретроспективы с противоречивыми выводами,

— внезапные релизы в 3 ночи,

— и фраза: «А что, если мы это просто удалим?»

2. PAIN (Боль) — Топливо роста

Определение: уровень дискомфорта команды из-за нехватки ресурсов, времени или смысла.

Как влияет:

— Слишком мало боли → люди расслабляются. Проект превращается в корпоративный зоопарк, где все кормят крокодилов и ждут пенсии.

— Слишком много боли → команда сгорает, менеджеры уходят в dark mode Notion, а HR начинает говорить: «Ну, зато у нас хороший вайб.»

Оптимальный уровень:

Когда все страдают,

но испытывают азарт от этого.

Как управляется:

— Через систематическую нехватку времени:

— дедлайны = завтрашний день.

— Через совместное преодоление страданий:

— боль объединяет сильнее, чем кофе.

— Через методологию: «Кто страдает — тот развивается.»

«Боль — не побочный эффект. Это признак, что ты жив.»

3. FUN (Фан) — Антидот к катастрофе

Определение: степень удовольствия, которое команда получает от процесса, несмотря на хаос и боль.

Как влияет:

— Фана нет → люди злятся, начинают саботировать,

— и в чате появляется: «Я ухожу в лес. Пусть всё горит.»

— Фана слишком много → работа превращается в вечный брейншторм без результатов,

— где все смеются, но никто не пишет код.

Оптимальный уровень:

Когда шутки и сарказм позволяют терпеть боль и хаос.

Как управляется:

— Через культ мемов, шутливых тайтлов и неформальных ритуалов.

— Через обратную связь в формате roast session — где тебя хвалят, но так, что хочется уволиться.

— Через признание: «Работа должна быть веселее, чем тикеты в Jira.»

Новый баланс: не качество, а эмоции

В классике: качество — это итоговый результат.

В dVM: качество — это побочный эффект.

Главная цель — не «качественный продукт», а система, способная генерировать абсурдные, но рабочие решения быстрее конкурентов.

«Мы не делаем продукт. Мы делаем движ.»

Статистическое управление проектами в dVM

Критерий Шухарта и «Индекс предсказуемого хаоса» (IPХ)

В dVM используется адаптированный критерий Шухарта:

— Нет отклонений → команда впала в бюрократию и деградацию.

— Есть отклонения, но в пределах нормы → проект живой и управляемый.

— Всё вышло из-под контроля → это просто обычный рабочий день.

Вывод: проект стабилен, если хаос имеет структуру хаоса.

Контроль через метрики хаоса

Профиль ожидания vs. Реальность

— График ожиданий заказчика — гладкая прямая.

— Фактическое выполнение — ломаная линия с провалами и взрывами.

Если линии не совпадают — это нормально.

Главное — чтобы заказчик был удивлён, но доволен.

WIP по dVM

— В классике WIP — ограничение.

— В dVM — потолок задач, при котором команда ещё не уволилась.

— WIP слишком низкий → недостаточно челленджа.

— WIP слишком высокий → команда в кризисе, но проект движется.

Квадратичное отклонение как показатель «эффективного страдания»

— Малый разброс сроков → команда слишком предсказуема → скучно.

— Катастрофический разброс → команда в фазе предельного творчества.

«Если всё идёт по плану — значит, план плохой.»

SMART, CLEAR, PURE, MoSCoW и другие

— в dVM они работают иначе

Заключение: почему dVM работает

Когда кто-то спрашивает команду dVM:

«Какой у вас метод управления проектами?»

Они отвечают:

«Мы просто стараемся не потерять контроль над хаосом,

не сдохнуть от боли,

и не забыть, зачем мы всё это затеяли.»

MVE, а не MVP — как dVM убивает техдолг на корню

Почему Minimum Viable Product — это ложь, которую мы все принимаем?

В классическом продуктовом подходе MVP (Minimum Viable Product) — это священный артефакт.

Базовая версия продукта, с минимальным функционалом, запущенная, чтобы проверить гипотезу и собрать обратную связь.

Но в реальности MVP часто превращается в MBP — Maximum Broken Product:

собранный на костылях, запущенный в спешке,

работающий «технически», но вызывающий у пользователя только одно желание — закрыть вкладку.

«Он работает… но зачем?»

dVM не верит в MVP.

Мы верим в MVE — Minimum Viable Experience.

MVE: Минимальный, но достойный опыт

MVE — это не про функции.

Это про ощущение.

— MVP фокусируется на работоспособности.

— MVE — на восприятии.

Ключевые различия:

Почему MVE выигрывает у MVP

1. MVP решает задачи. MVE — удерживает пользователей.

— MVP: «Мы сделали!»

— MVE: «Ты хочешь остаться.»

Пользователь не уйдёт, потому что «всё работает».

Он уйдёт, если ему некомфортно.

2. MVP — это отмазка. MVE — это стратегия.

— MVP = «Запустим быстро, а потом разберёмся с багами.»

— MVE = «Сделаем нормально — и только потом масштабируем.»

MVE — это не про скорость.

Это про уважение: к пользователю, к команде, к продукту.

3. MVP создаёт техдолг. MVE его предотвращает.

Каждый MVP — это обещание: «Потом починим.»

Но «потом» редко наступает.

Вместо этого — горящий костёр технического долга, который питает Legacy Hell.

MVE переворачивает подход:

«Сделай хорошо сейчас — и расширяй потом.»

Нет обещаний. Нет отговорок.

Только результат.

Как dVM реализует MVE на практике

1. «Выкинь ненужное, но не забывай про удобство»

Если фича усложняет UX — она не нужна, даже если технически впечатляет.

В MVE мы оставляем только те функции, которые создают ощущение цельности.

«Продукт определяется не тем, что он делает.

А тем, как он заставляет чувствовать пользователя.»

2. «Если пользователь не может объяснить, что его бесит — он всё равно уйдёт»

MVP фокусируется на формализуемых ошибках.

MVE — на интуитивном дискомфорте.

Мы тестируем на:

— Путаницу.

— Раздражение.

— Момент тихого «WTF?»

И исправляем это до релиза.

3. «MVE — это MVP без позора»

— MVP: «Это же MVP, чего вы ждали?»

— MVE: «Да, функций мало — но это выглядит и чувствуется как продукт.»

Лучше маленький кусочек хорошего опыта,

чем большой кусок дерьма.

BRD-UML-MVP-Legacy Hell: Жизненный цикл IT-проекта по dVM

В dVM мы не боремся с Legacy.

Мы понимаем, откуда он берётся.

Это не случайность.

Это закономерность.

Как рождается Legacy Hell

1. BRD — Документ, написанный в тумане

Business Requirements Document — рождается в муках.

Аналитик пытается перевести «хочу, чтобы было круто» в технические требования.

Результат:

«Система должна быть удобной и быстрой.»

Но — что это значит?

Никто не знает.

2. UML — Диаграммы для стейкхолдеров

Unified Modeling Language — рисуется для красоты, а не для использования.

Команда либо игнорирует диаграммы, либо пишет код «на ощущениях».

«Зачем это рисовали, если всё равно переделаем?»

3. MVP — или, как мы его называем, MBP

Minimum Viable Product превращается в Maximum Broken Product.

Сделан максимально быстро, на костылях.

Пользователи после релиза просят:

«Почините, но ничего не меняйте!»

Это пид0р, рождённый шакалами.

Продукт, который минимально жизнеспособен, но не жизнеспособен вообще.

4. Legacy Hell — Неизбежный результат

Через год проект становится:

«Мы это не трогаем — вдруг сломается.»

Легенды о странных решениях передаются от джуна к джуну.

Комментарии в коде: // DON’T TOUCH! — становятся нормой.

Как dVM справляется с Legacy Hell

Trigger Engineer — шаман мёртвого кода.

С криками «Кто это писал?!» пытается воскресить систему.

Иногда получается.

Чаще — приходится писать ещё один костыль.

Crab Master — философ хаоса

Предлагает не чинить — а написать поверх.

А потом — поверх этого.

«Не ремонтируй. Добавь.»

TeamVibe — душа в раю администраторов.

Поддерживает моральный дух:

«Так у всех. Это нормально.»

KarmaPolice — страж справедливости (с опозданием)

Наказывает виновных.

Но обычно — уже поздно.

Вывод: Выхода нет. И это нормально

dVM считает:

Хаос — это не проблема. Это естественное состояние IT-проектов.

Любая попытка «починить Legacy» приводит к созданию нового, ещё более непредсказуемого Legacy.

Но есть выход:

Не победить хаос — а научиться в нём жить.

С юмором.

С костылями.

С MVE вместо MVP.

«Главное — не идеальный продукт.

Главное — чтобы пользователь не ушёл с криком.»

Управление рисками в dVM — не страх, а стратегия

Почему классические матрицы рисков — это артефакты прошлого

В традиционном управлении рисками — бесконечные таблицы, SWOT-анализы, PERT-диаграммы, цветные светофоры и «стратегии снижения последствий».

Но в мире, где требования меняются за ночь, архитектура держится на костылях, а заказчик вчера хотел одно, а сегодня — противоположное,

все эти инструменты превращаются в бюрократическую симуляцию контроля.

dVM не боится рисков.

Мы их приручаем.

«Риск — это не угроза.

Это сигнал: где слабое место, а где — возможность.»

1. Подход dVM к рискам: не бояться, а использовать

dVM не тратит время на гипотетические сценарии вроде «а вдруг метеорит упадёт?»

Мы работаем с тем, что есть здесь и сейчас.

Два типа рисков:

✔ Конструктивные риски

То, что создаёт новые возможности.

Пример: внедрение новой технологии.

Да, это рискованно.

Но если сработает — даст буст эффективности, скорости, вайба.

«Мы не избегаем рисков.

Мы делаем ставку на те, что приближают к цели.»

✖ Разрушительные риски

То, что только мешает:

— Технический долг.

— Бюрократия.

— Хрупкая архитектура.

— Токсичные процессы.

dVM не откладывает их в таблицы.

Мы их режем или адаптируем.

«Если риск не приносит пользы — он не риск.

Он — хлам.»

Ключевой принцип:

Риск, который не даёт буст — устраняется.

Риск, который даёт движ — принимается и масштабируется.

2. Работа с рисками на уровне команды

Вместо устаревших техник вроде SWOT или PERT, dVM предлагает живую, быструю реакцию через три мощных механизма.

Механика «Джунгли»: не контролируй — адаптируйся

Если вокруг хаос — не пытайся его победить.

Научись в нём выживать и зарабатывать очки.

«Мы не пытаемся победить хаос.

Мы учимся в нём жить — и использовать его как ресурс.»

«Системный киллер» — метод удаления ненужного

«Не знаешь, что делать с риском? Убей его, если он тормозит.»

Просто. Жёстко. Эффективно.