Если вы работаете в разработке ПО, особенно в продуктовых командах, то, скорее всего, слышали о HADI-циклах. HADI часто воспринимают как инструмент менеджеров и аналитиков: A/B-тесты, конверсии, метрики.
Но HADI — это не про маркетинг. Это способ принимать решения осознанно, проверяя предположения через данные. Это универсальный цикл принятия решений, основанный на проверке предположений и гипотез. HADI — это система мышления для любого, кто хочет принимать решение на основе данных, а не интуиции или установок «так принято».
🔍 В чем заключается HADI
HADI — это фреймворк, который основывается на идеях методологий Lean Startup и Agile. Он упаковывает их философию в простую и практичную форму:
- 🎯 Hypothesis (Гипотеза): «Если мы сделаем X, то получим Y, потому что Z».
- ⚡ Action (Действие): Реализуем X минимальными усилиями.
- 📊 Data (Данные): Собираем данные и метрики, чтобы оценить результат Y.
- 💡 Insight (Вывод): Анализируем данные и понимаем, была ли гипотеза верна. Что мы узнали? Что делать дальше?
Цель HADI — не просто делать, а делать с осмыслением: проверять, работает ли реализованное решение, и учиться на результатах.
💻 Хорошо, но зачем это разработчикам, архитекторам и т.д.?
Инженерные решения — это тоже гипотезы. Код ради кода без понимания его бизнес-ценности — это слепое искусство. Современная разработка — это принятие решений, каждое из которых имеет последствия.
Любое наше инженерное решение — это по сути гипотеза.
🧪 Примеры инженерных гипотез:
Пример 1:
- Гипотеза: Если заменить библиотеку X на более современную и легковесную Y, то мы уменьшим время сборки проекта на 15% и повысим стабильность runtime, потому что в Y меньше известных багов.
- Действие: Заменяем библиотеку в одном из не самых критичных сервисов.
- Данные: Замеряем время сборки до и после. Мониторим количество инцидентов в модуле в течение некоторого времени.
- Вывод: Сборка действительно ускорилась на 10%, но появляются новые ошибки при определенных условиях. Решение: откатываемся и ищем другую библиотеку или исправляем баг. Мы не тратим много времени на полный рефакторинг, чтобы узнать это.
Пример 2:
- Гипотеза: Если переписать некоторые сервисы с Java на Rust, мы получим прирост производительности до 50% и уменьшим объем памяти, необходимый для приложения, в 2 или даже 3 раза.
- Действие: Переписываем один самый маленький микросервис или часть функциональности на Rust, важно, чтобы это не заняло много времени.
- Данные: После релиза сервиса снимаем метрики использования памяти и время ответов.
- Вывод: Получили незначительный прирост производительности (около 20%), значительно уменьшили объем занимаемой памяти (на 60%). Но потребовалось значительно больше времени для реализации задачи. Решение: попробуем применять техники оптимизации для Java-приложений, чтобы уменьшить объем потребляемой памяти.
Ключевая мысль
HADI — это научный метод в разработке. Вы формируете предположение, ставите эксперимент, проверяете его на основе данных и получаете знания.
Начните думать о задачах как о гипотезах. Такой подход меняет все:
- 🛡️ Снижает риски: Вы не тратите много времени на сомнительные изменения.
- 🤝 Создает общий язык: Разработчики и менеджеры говорят на одном языке — языке измеримых результатов.
- 📈 Обосновывает ваши решения: Вместо «мне кажется, это будет лучше» вы говорите: «Мы проверили, и это дало вот такой измеримый результат».
HADI — это способ быть инженером-исследователем, который своими действиями генерирует ценность и знание для бизнеса.
Подпишись на мой канал в telegram
#HADI #agile #engineering #development