Ответ
Мой подход основан на переводе бизнес-потребностей в технические спецификации. Я начинаю с выяснения основной боли и критериев успеха.
Фаза 1: Исследование контекста. Я задаю открытые вопросы, чтобы понять процесс:
«Расскажите, как сейчас выполняется задача X? Сколько времени это занимает? Что самое неудобное в текущем процессе?»
Фаза 2: Определение результата. Вместо обсуждения технологий, мы фокусируемся на результате:
«Если бы система работала идеально, что бы она делала для вас завтра? Опишите идеальный отчет или действие.»
Фаза 3: Конкретизация и прототипирование. Чтобы избежать недопонимания, я сразу создаю простой макет или схему. Например, для задачи по отчетности я могу набросать таблицу в Google Sheets с примерными данными и спросить: «Вот так мог бы выглядеть итоговый отчет? Эти столбцы и группировка вам подходят?»
Фаза 4: Декомпозиция и приоритизация. Я разбиваю общее пожелание на конкретные, проверяемые функции и вместе с заказчиком определяем MVP (Minimum Viable Product):
- Обязательно для первого релиза: Функция А (автоматический расчет ключевого показателя).
- Можно добавить позже: Функция Б (красивые графики в PDF).
Ключевой принцип: Я постоянно перефразирую услышанное и фиксирую договоренности письменно (например, в виде краткого технического задания или списка пользовательских историй в Jira), чтобы у обеих сторон была одна точка истины.