doc/PM_BA/t_analysis_it_m1.md

119 lines
7.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Сегодня будем обсуждать и делиться советами, как собирать требования
https://t.me/analysis_it/1780
Сбор требований — это фундамент любого проекта. Ошибки на этом этапе приводят к переделкам, срыву сроков и недовольству заказчика. Расскажу по шагам, как делать это правильно, избегая типичных ловушек, исходя из своего опыта☝️
🚀 1. Подготовка: что сделать до встречи с заказчиком
✅ Поймите контекст проекта:
— Какие бизнес-цели преследует заказчик? (Пример: увеличить продажи на 30% через новый сайт).
— Кто ключевые стейкхолдеры? (руководитель, пользователи, IT-отдел).
— Изучите существующие документы: ТЗ, отчеты
— Проанализируйте и изучите конкурентов
✅ Составьте план интервью:
Лучше быть готовым, чем краснеть. Я заранее на лист бумаги выписывала цель проекта, главне вопросы, в зависимости от заказчиков (если их несколько)
— Определите, какие вопросы задать. Например:
«Какие проблемы решает этот проект?»
«Как вы видите успех через полгода после запуска?»
✅ Выберите инструменты:
Чаще всего я пользовалась листом бумаги
— Анкеты
— Шаблоны для документирования (Confluence, Excel)
— Доски (Miro для мозговых штурмов)…
——————
▶️ 2. Начало общения: как установить контакт
✅ Первые 10 минут — самые важные:
— Объясните свою роль: «Я помогу формализовать ваши идеи так, чтобы команда их правильно реализовала»
— Уточните формат работы: «Сейчас я задам несколько вопросов, а потом мы обсудим детали»
✅ Слушайте активно:
— Кивайте, повторяйте ключевые тезисы: «Правильно ли я понял, что основная проблема — долгая обработка заказов?».
— Задавайте открытые вопросы:
«Расскажите, как сейчас происходит процесс X»
— Переспросите, если что-то было непонятно
——————
🛠️ 3. Техники сбора требований
✅ User Stories (Пользовательские истории):
Формат: *«Как [роль], я хочу [действие], чтобы [цель]»*.
Пример: *«Как менеджер, я хочу фильтровать заказы по дате, чтобы быстро находить просроченные»*.
✅ Мозговой штурм:
Используйте Miro или доску. Фиксируйте все идеи, даже странные. Позже вместе с заказчиком отсортируйте их по приоритету
✅ Прототипы:
Набросайте схему интерфейса или бизнес-процесса. Часто заказчик не понимает текста, но сразу видит ошибки в визуальной схеме
——————
📌 4. Что обязательно уточнить
✅ Функциональные требования: Что система должна делать (например, «формировать отчет в PDF»)
✅ Нефункциональные требования:
— Производительность («загрузка страницы — не дольше 2 сек»)
— Безопасность («двухфакторная аутентификация»)
✅ Ограничения: Бюджет, сроки, законодательство («данные должны храниться в РФ»)
——————
⛔️ 5. Чего делать НЕЛЬЗЯ
❌ Додумывать за заказчика.
*Неверно:* «Вам, наверное, нужна интеграция с 1С
*Правильно:* «Какие системы должны быть подключены?»
❌ Игнорировать конфликты требований.
Если отдел продаж хочет «гибкую настройку цен», а бухгалтерия — «фиксированные правила», вынесите это на обсуждение. Сами не принимайте решений.
❌ Откладывать документирование.
Фиксируйте требования сразу в структурированном виде.
Можно использовать пример:
- Требование | Возможность отмены заказа
- Тип | Функциональное
- Приоритет | High
- Источник | Интервью с менеджером
——————
📝 6. Проверка и согласование
✅ Валидация требований:
Покажите заказчику документ и задайте вопросы:
*«Всё ли учтено? Нет ли противоречий?»*
✅ Используйте примеры:
«Представьте: пользователь пытается оформить заказ ночью. Как система должна реагировать?»
——————
Советы напоследок
- Говорите на языке заказчика. Избегайте технических терминов.
- Управляйте ожиданиями: Если требование невозможно, сразу скажите: «Это потребует 3 месяца работы. Есть ли бюджет?».
- Итеративность: Требования меняются. Регулярно возвращайтесь к ним и актуализируйте.
——————
Инструменты в помощь:
- Jira + Confluence — для документирования.
- Draw.io / Lucidchart — для диаграмм процессов.
- Balsamiq — для прототипов.
Главное — не бойтесь задавать «глупые» вопросы. Лучше уточнить сто раз, чем переделывать проект. Удачи! 🚀
Источник: @ba_and_sa
https://t.me/analysis_it/1779
Топ-материалов, которые вышли у нас в 2024 году📌