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