3 формата: как договориться о требованиях
Я в рамках проекта «Амбассадоры компании Т1» провожу исследование: какой формат контента удобнее для рабочих задач. Сегодня на примере вечной темы «Согласование требований бизнеса и разработки» смотрю три разные упаковки.
Одна тема — три формата.
🎓 Формат 1. Обучающий (видео-разбор) Что это: Короткий урок на 7 минут «Техника согласования через Принцип ONE THING». Внутри: Правило «Одно главное число» (ROI / срок / юзабилити — что в приоритете). Пример конфликта и его снятие через цифру. Результат: Человек перестает спорить «как правильно» и начинает задавать вопрос «что важнее для денег сейчас».
🧰 Формат 2. Гайд или инструмент (PDF-шаблон) Что это: Заполняемый шаблон на 2 страницы для встречи по требованиям. Внутри: 1. Блок «Что хочет бизнес (выгода)» vs «Что может разработка (ограничения)». 2. Матрица «Стоимость vs Скорость vs Качество». Результат: Вместо хаоса есть документ, где обе стороны видят компромиссы до начала спринта.
📊 Формат 3. Механика вовлечения (опрос в Stories) Что это: Короткий интерактивный опрос в историях. Внутри: 5 реальных фраз из переписок («это просто кнопка добавить», «давайте сначала аналитику, потом код»). Нужно выбрать: «Прав бизнес» или «Прав разработчик». Результат: Человек за минуту видит свои слепые зоны в коммуникации и получает подсказку, как перевести претензию в требование.
❗️Какой формат оказался самым сильным? Я считаю, что гайд - самый рабочий инструмент. На практике он дает четкое понимание структуры и остается чек-листом, который всегда под рукой. Знание из видео выветривается, опрос в сторис дает инсайд, но не систему, а заполняемый шаблон лежит в заметках и работает каждый раз, когда начинается спор.
❓Спрашиваю вас как часть исследования: А какой формат вы считаете наиболее удобным для рабочих задач: обучающий, гайд или опрос в сторис? —.___.—
И заодно: какая фраза от бизнеса или разработки бесит вас сильнее всего? 👇
· 27.04
Как архитектор который сидит между бизнесом и разработчиками — добавлю четвёртый формат который работает лучше всех трёх: Architecture Decision Record (ADR).
Одна страница: контекст проблемы, рассмотренные варианты, принятое решение и почему, последствия. Бизнес видит что их требования учтены, разработчики понимают почему не взяли "более очевидный" вариант, новый человек в команде за 5 минут вкурсе.
Главное преимущество перед видео или слайдами: ADR хранится в git рядом с кодом. Через год никто не ищет "а почему мы выбрали вот это" в Confluence — ответ в репозитории.
ответить
коммент удалён
· 28.04
Спасибо, вы точно подметили главную слабость трёх форматов из моего поста: все они живут вне контекста команды и кода. ADR у вас вшит в процесс. И отдельное спасибо за «бизнес видит, что их требования учтены» - это часто забываемая сторона архитектурных решений. Сильнее любых форматов это место хранения👌🏼 У вас ADR заводятся на каждую задачку или только на спорные моменты?
ответить
ответ удалён