☀️ RFC начинается с "зачем", а не с "как"

Пользователь создает запрос на изменение: "Добавьте галочку". Кажется просто - но это уже готовое решение. А действительно ли нужна именно галочка?

🤷‍♂️ Почему "сразу делать" опасно • Ненужные изменения ломают типовую методологию 1С. • Каждый "быстрый фикс" усложняет поддержку и увеличивает техдолг. • Пользователь остается недоволен: получил кнопку, а задача все равно не решена.

📝 Мини-чек-лист первого соприкосновения с RFC • Слушаем боль, не решение. Записываем проблему словами бизнеса. • "5 почему". Выясняем корневую потребность. • Проверяем существующую методологию. Ищем готовую возможность "из коробки", чтобы не изобретать велосипед. • Сравниваем варианты. Обучение, консультация, настройка, код. • Формализуем пользу. Если остается код - считаем экономию/выручку. • Документируем вывод. Решение + обоснование в карточке RFC.

💡Не путайте функциональные требования с проектными решениями 🛑"Добавьте табличную часть Источники финансирования" - это проектное решение, указание что и как сделать. ✅"Система должна позволять выбирать несколько источников финансирования для одного проекта" - это функциональное требование, описание что должна уметь система, без навязывания конкретного способа реализации. ☝️Cначала формулируем что и зачем, а как (справочник, табличная часть, кнопка) оставляем команде архитекторов и аналитиков.

🤝 Выгоды подхода • Партнерство вместо "сделайте". Мы не отказываем, а вместе формулируем цель и предлагаем выгодный путь. • Экспертиза защищает архитектуру. Команда ИТ берет ответственность за техрешение, сохраняя чистоту кода и снижая техдолг. • Быстрее к результату. Без лишней разработки time-to-market сокращается, релизы становятся стабильнее. • ROI на каждой правке. Показываем экономию и рост выручки до начала работ. • Рост T-shape-команды. Вопросы "почему" прокачивают кросс-компетенции внутри ИТ и бизнеса.

🖐 Ваша команда уже спрашивает "почему" перед тем, как обещать срок реализации?