☀️ RFC начинается с "зачем", а не с "как"
Пользователь создает запрос на изменение: "Добавьте галочку". Кажется просто - но это уже готовое решение. А действительно ли нужна именно галочка?
🤷♂️ Почему "сразу делать" опасно
• Ненужные изменения ломают типовую методологию 1С.
• Каждый "быстрый фикс" усложняет поддержку и увеличивает техдолг.
• Пользователь остается недоволен: получил кнопку, а задача все равно не решена.
📝 Мини-чек-лист первого соприкосновения с RFC
• Слушаем боль, не решение. Записываем проблему словами бизнеса.
• "5 почему". Выясняем корневую потребность.
• Проверяем существующую методологию. Ищем готовую возможность "из коробки", чтобы не изобретать велосипед.
• Сравниваем варианты. Обучение, консультация, настройка, код.
• Формализуем пользу. Если остается код - считаем экономию/выручку.
• Документируем вывод. Решение + обоснование в карточке RFC.
💡Не путайте функциональные требования с проектными решениями
🛑"Добавьте табличную часть Источники финансирования" - это проектное решение, указание что и как сделать.
✅"Система должна позволять выбирать несколько источников финансирования для одного проекта" - это функциональное требование, описание что должна уметь система, без навязывания конкретного способа реализации.
☝️Cначала формулируем что и зачем, а как (справочник, табличная часть, кнопка) оставляем команде архитекторов и аналитиков.
🤝 Выгоды подхода
• Партнерство вместо "сделайте". Мы не отказываем, а вместе формулируем цель и предлагаем выгодный путь.
• Экспертиза защищает архитектуру. Команда ИТ берет ответственность за техрешение, сохраняя чистоту кода и снижая техдолг.
• Быстрее к результату. Без лишней разработки time-to-market сокращается, релизы становятся стабильнее.
• ROI на каждой правке. Показываем экономию и рост выручки до начала работ.
• Рост T-shape-команды. Вопросы "почему" прокачивают кросс-компетенции внутри ИТ и бизнеса.
🖐 Ваша команда уже спрашивает "почему" перед тем, как обещать срок реализации?
#RFC #Requirements #ProductManagement #Value #ChangeManagement #CIO
