Много документов Разработка не будет читать

Много документов Разработка не будет читать 100 вопросов зададут

9.80M

Похожие презентации:

ТРПО. Лекция 2. Введение в инженерию требований

Программная инженерия

Методы и средства проектирования ПО. Введение

Спецификация требований к программному обеспечению. Лекция 19

Rational Unified Process (RUP). Рациональный унифицированный процесс (Rational Unified Process, RUP)

Разработка программного решения в пакете Excel для проектного планирования в форме диаграмм Ганта

Тестирование документации и требований. Часть 1

Автоматизированные системы, интенсивно использующие ПО

Гибкая методология разработки программного обеспечения AGILE

Классификация требований. Тема 6

Документируй_это_Как_артефакты_аналитика_становятся_топливом_для

1. Документируй это

Как артефакты аналитика становятся топливом
для проекта, а не бюрократией

2. О спикере

Владимир
Бурмистров
Главный системный аналитик
ИТ-Холдинг Т1, проект Dion
+ Порядок в документации
+ Ускорился за счет ИИ
+ 18 лет в IT, все ещё не выгорел
+ Умею пользоваться поиском
+ Преподаватель и автор курсов

3. Кто сталкивался с плохой документацией?

4. Какая должна быть документация?

Ожидания от аналитика

5. Кто читал?

6. Кто читал?

«Требования должны быть
достаточно хорошими, чтобы
разработка могла продолжаться с
приемлемым уровнем риска»
6

7. Вигерс фигни не скажет

«Требования должны быть
достаточно хорошими, чтобы
разработка могла продолжаться с
приемлемым уровнем риска»
«Ошибки, допущенные на этапе
проектирования — это самые
болезненные ошибки, потому что
для их исправления требуется
перезапуск всего
производственного процесса»
7

8. Жизненный цикл проекта

9. Жизненный цикл проекта

Новая инициатива
9

10. Жизненный цикл проекта

Новая инициатива
10
SC

11. Жизненный цикл проекта

Новая инициатива
11
SC
BRS

12. Жизненный цикл проекта

Новая инициатива
12
SC
BRS
SRS

13. Жизненный цикл проекта

Новая инициатива
13
SC
BRS
SRS
Разработка

14. Жизненный цикл проекта

Новая инициатива
Новая инициатива
Большая задача
Мы собрались делать
что-то глобальное и не
очень
14
SC
BRS
SRS
Разработка

15. Жизненный цикл проекта

Solution Concept
Новая инициатива
SC
Большая задача
Верхнеуровневое
решение
Мы собрались делать
что-то глобальное и не
очень
15
Подготовка к
декомпозиции,
разделение на
участников
BRS
SRS
Разработка

16. Жизненный цикл проекта

17. Жизненный цикл проекта

Solution Concept
Новая инициатива
SC
Большая задача
Верхнеуровневое
решение
Мы собрались делать
что-то глобальное и не
очень
BRS
Подготовка к
декомпозиции,
разделение на
участников
Для кого: PO, Архитекторы, Технические лиды, Команды
Когда писать:
✅ Всегда при новой крупной инициативе
✅ Вовлечены несколько команд
✅ Сложная/кросс-функциональная фича
⚠ По ситуации для технических задач
17
SRS
Разработка

18. Жизненный цикл проекта

Solution Concept
Новая инициатива
SC
Большая задача
Верхнеуровневое
решение
Мы собрались делать
что-то глобальное и не
очень
BRS
SRS
Разработка
Чек-лист успеха:
• Цели и бизнес-контекст (зачем это всё?)
• Краткое описание решения
• HLA (High Level Architecture): диаграммы C1 и
Для кого: PO, Архитекторы, Технические лиды, Команды
C2
• Список требований (User Stories/Use Cases) —
Когда писать:
не детализация!
✅ Всегда при новой крупной инициативе
• Ограничения и допущения решения
✅ Вовлечены несколько команд
• ADR (Architecture Decision Records) — по
✅ Сложная/кросс-функциональная фича
необходимости
⚠ По ситуации для технических задач
18
Подготовка к
декомпозиции,
разделение на
участников

19. Жизненный цикл проекта

Solution Concept
Новая инициатива
SC
Большая задача
Верхнеуровневое
решение
Мы собрались делать
что-то глобальное и не
очень
BRS
SRS
Разработка
Чек-лист успеха:
• Цели и бизнес-контекст (зачем это всё?)
• Краткое описание решения
• HLA (High Level Architecture): диаграммы C1 и
Для кого: PO, Архитекторы, Технические лиды, Команды
C2
• Список требований (User Stories/Use Cases) —
Когда писать:
не детализация!
✅ Всегда при новой крупной инициативе
• Ограничения и допущения решения
✅ Вовлечены несколько команд
• ADR (Architecture Decision Records) — по
✅ Сложная/кросс-функциональная фича
необходимости
⚠ По ситуации для технических задач
19
Подготовка к
декомпозиции,
разделение на
участников
https://rutube.ru/video/6898265cb67b9012b5d7efe6a328bae9/

20. Жизненный цикл проекта

21. Жизненный цикл проекта

22. Жизненный цикл проекта

23. Жизненный цикл проекта

Business Requirements Specification
Новая инициатива
SC
BRS
Большая задача
Верхнеуровневое
решение
Как это для
пользователя
Подготовка к
декомпозиции,
разделение на
участников
Что рисовать дизайну,
корнер кейсы
Мы собрались делать
что-то глобальное и не
очень
SRS
Разработка
Чек-лист успеха:
• Глоссарий (все термины определены)
• User Story в формате: As [role], I want
[action], So that [benefit]
Для кого: PO, Команда разработки, Тестировщики, Дизайнеры
• Проблематика: AS IS / TO BE
• Acceptance Criteria в формате
Given/When/Then
Когда писать:
• Анализ конкурентов (опционально)
✅ Всегда, если это пользовательская фича
• Нефункциональные требования:
❌ Не нужен для чисто технических задач
• Требования к UI (ссылка на макеты)
• Требования к производительности
• Требования к безопасности
23

24. Жизненный цикл проекта

25. Жизненный цикл проекта

Software Requirements Specification
Новая инициатива
SC
BRS
SRS
Большая задача
Верхнеуровневое
решение
Как это для
пользователя
Подготовка к
декомпозиции,
разделение на
участников
Что рисовать дизайну,
корнер кейсы
Что нужно
сделать
разработчику?
Мы собрались делать
что-то глобальное и не
очень
Для кого: РАЗРАБОТЧИКИ (главные потребители!)
Когда писать:
✅ ВСЕГДА
25
Техничка
Разработка

26. Жизненный цикл проекта

Software Requirements Specification
Новая инициатива
SC
BRS
SRS
Большая задача
Верхнеуровневое
решение
Как это для
пользователя
Подготовка к
декомпозиции,
разделение на
участников
Что рисовать дизайну,
корнер кейсы
Что нужно
сделать
разработчику?
Мы собрались делать
что-то глобальное и не
очень
Техничка
Для кого: РАЗРАБОТЧИКИ (главные потребители!)
Когда писать:
✅ ВСЕГДА
Золотое правило:
Всегда начинайте SRS с КРАТКОГО ОПИСАНИЯ РЕШЕНИЯ (3-5
предложений)!
Без него разработчик смотрит на 50 страниц спеки и думает «ой бл*...»
26
Разработка

27. Жизненный цикл проекта

Software Requirements Specification
Чек-лист успеха:
• Краткое описание
3 API, 2
Новая инициатива
SC
BRS
SRS решения (что меняем:
Разработка
таблицы, 1 новый сервис)ё
• Таблица изменений
Большая задача
Верхнеуровневое
Как это для
Что нужноBE/FE
• Диаграммы:сделать
решение
пользователя
Мы собрались делать
разработчику?
что-то глобальное и не
• C2 (если
изменяется архитектура)
Подготовка к
Что рисовать дизайну,
очень
декомпозиции,
корнер кейсы
Техничка
• Sequence
diagrams (сценарии взаимодействия)
разделение на
• Логическая модель данных (ER-диаграммы, если
участников
изменяется БД)
Для кого: РАЗРАБОТЧИКИ (главные потребители!)
• Описание методов:
REST/gRPC/WSS/Kafka/GraphQL…
Когда писать:
• Маппинг макетов UI и вызовов API
✅ ВСЕГДА
• Нефункциональные требования:
Золотое правило:
• Производительность
Всегда начинайте SRS с КРАТКОГО ОПИСАНИЯ РЕШЕНИЯ
(3-5
• Аудит
предложений)!
• Информационная безопасность
Без него разработчик смотрит на 50 страниц спеки и думает
«ой бл*...» метрики
• Продуктовые
27

28. Жизненный цикл проекта

29. Жизненный цикл проекта

Разработка
Новая инициатива
SC
BRS
SRS
Разработка
Большая задача
Верхнеуровневое
решение
Как это для
пользователя
Мы все
Подготовка к
декомпозиции,
разделение на
участников
Что рисовать дизайну,
корнер кейсы
Что нужно
сделать
разработчику?
Мы собрались делать
что-то глобальное и не
очень
29
Техничка
Придут конечно
разрабы,
тестировщики… ну или
сделать для них
созвон

30. Много документов

31. Много документов Разработка не будет читать

32. Много документов Разработка не будет читать 100 вопросов зададут

33. Много документов Разработка не будет читать 100 вопросов зададут

34. Много документов Разработка не будет читать 100 вопросов зададут

35. Много документов Разработка не будет читать 100 вопросов зададут

36. RACI МАТРИЦА ДЛЯ АРТЕФАКТОВ

RACI — это:
- R (Responsible) — Исполнитель
- A (Accountable) — Ответственный за результат
- C (Consulted) — Консультант
- I (Informed) — Информируемый
36

37. RACI МАТРИЦА ДЛЯ АРТЕФАКТОВ

RACI — это:
- R (Responsible) — Исполнитель
- A (Accountable) — Ответственный за результат
- C (Consulted) — Консультант
- I (Informed) — Информируемый
37

38. Конфликтные зоны

39. Конфликтные зоны

Аналитик vs
Разработчик
Где заканчивается
анализ и начинается
разработка?
39

40. Конфликтные зоны

Аналитик vs
Разработчик
Где заканчивается
анализ и начинается
разработка?
40
PBR (Product
Backlog Refinement)
Последний момент влияния
разработчиков на решение

41. Конфликтные зоны

«Слишком
детально» vs
«Недостаточно
информации»
41

42. Конфликтные зоны

«Слишком
детально» vs
«Недостаточно
информации»
42
Общение с
командой
Обратная связь от целевой
аудитории, адаптация
шаблона под команду

43. ADR

44. ADR

Зачем:
• Через 2 месяца вы НЕ вспомните, почему выбрали это решение
• Через 6 месяцев будете думать: «Господи, я точно был в трезвом уме?»
• Новые участники команды смогут понять контекст
Пример:
ADR-001: Выбор PostgreSQL как БД для календаря
Контекст: Нужна БД с поддержкой JSON, часовых поясов, ACID
Решение: PostgreSQL
Альтернативы: MongoDB (нет ACID), MySQL (слабая поддержка
JSON)
Последствия:
+ Надежность
+ timezone
- Сложнее горизонтальное масштабирование
44

45. СЕКРЕТНОЕ ОРУЖИЕ

46. СЕКРЕТНОЕ ОРУЖИЕ

ИИ
46

47. СЕКРЕТНОЕ ОРУЖИЕ

ИИ
ИИ = ассистент, НЕ замена
47

48. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
48
Генерация User Stories

49. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
Генерация User Stories
Ты — опытный бизнес-аналитик. Создай детализированную User Story на основе следующего контекста.
Контекст:
• Продукт: Система управления календарем.
• Проблема: События на целый день (например, "День рождения", "Отпуск") при просмотре из разных часовых поясов могут смещаться на
предыдущий или следующий день, что вызывает путаницу.
• Роли: Администратор (управляет настройками системы), Обычный пользователь (создает и просматривает события).
Задача:
Представь результат в строгом формате:
1. User Story:
• ID:** US-CAL-001
• Название: Корректное отображение полнодневных событий в любом часовом поясе
• Формула: As a [роль], I want to [действие], so that [цель/польза].
2. Предусловия (Preconditions): Какие условия должны быть истинны до начала сценария? (2-3 пункта)
3. Критерии приемки (Acceptance Criteria) в формате Gherkin (Given/When/Then):
• Опиши 1-20 сценариев, охватывающих:
• Создание полнодневного события.
• Просмотр этого события из того же часового пояса.
• Просмотр этого события из другого часового пояса (например, UTC-5 и UTC+8).
• Учти, что полнодневное событие должно привязываться к календарной дате, а не к 24-часовому интервалу.
• Обязательно охвати сложные сценарии формата:
• Пользователь в NY (UTC-4) создает событие "День рождения" на 10 сентября.
• Пользователь в Лондоне (UTC+1) просматривает календарь на 10 сентября и должен видеть это событие.
• Пользователь в Токио (UTC+9) просматривает календарь на 10 сентября и тоже должен видеть это событие.
4. Открытые вопросы (Open Questions):
• Сформулируй 0-5 уточняющих вопроса по контексту, которые ты бы задал продукт-менеджеру для уточнения требований.
(Например, о хранении дат на сервере, формате вывода даты и т.д.)
Если какая-либо часть контекста неясна, смоделируй наиболее логичное предположение и укажи его в разделе "Предположения».
Если не хватает информации, подумай и уточни у меня.
49

50. СЕКРЕТНОЕ ОРУЖИЕ

51. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
• Генерация User Stories
• Генерация диаграмм (PlantUML)
51

52. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
• Генерация User Stories
• Генерация диаграмм (PlantUML)
• Генерация глоссария
52

53. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
• Генерация User Stories
• Генерация диаграмм (PlantUML)
• Генерация глоссария
• Улучшение AC
• Уточнения прошлых генераций
53

54. СЕКРЕТНОЕ ОРУЖИЕ

ИИ, чем поможет?
• Генерация User Stories
• Генерация диаграмм (PlantUML)
• Генерация глоссария
• Улучшение AC
• Уточнения прошлых генераций
• Генерация API на основе конкурентов
54

55. СЕКРЕТНОЕ ОРУЖИЕ

56.

7 правил хороших документов
Здравый смысл важнее процесса
56

57.

7 правил хороших документов
Здравый смысл важнее процесса
Шаблоны = чек-лист
57

58.

7 правил хороших документов
Здравый смысл важнее процесса
Шаблоны = чек-лист
58
Целевая аудитория
определяет детализацию

59.

7 правил хороших документов
Здравый смысл важнее процесса
Шаблоны = чек-лист
Целевая аудитория
определяет детализацию
Краткое описание
решения — золотое
правило SRS
59

60.

7 правил хороших документов
Здравый смысл важнее процесса
Шаблоны = чек-лист
Целевая аудитория
определяет детализацию
Краткое описание
решения — золотое
правило SRS
Версионность и
история изменений
60

61.

7 правил хороших документов
Здравый смысл важнее процесса
Шаблоны = чек-лист
Целевая аудитория
определяет детализацию
Краткое описание
решения — золотое
правило SRS
Связь документов между
собой
Версионность и
история изменений
61

62. 63. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
1
63

64. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
64
2

65. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
65
Собрать обратную
связь
2
3

66. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
66
Собрать обратную
связь
2
Адаптировать
3
4

67. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
67
Собрать обратную
связь
2
Адаптировать
3
Показать ценность
4
5

68. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
Важно
100%
Всем сначала будет больно
68
Собрать обратную
связь
2
Адаптировать
3
Показать ценность
4
5

69. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
Собрать обратную
связь
2
Адаптировать
3
Важно
100%
Всем сначала будет больно
69
Потом адаптируете все под команду
Показать ценность
4
5

70. ВНЕДРЕНИЕ В КОМАНДЕ

5 шагов успешного внедрения
Создать шаблоны
Провести воркшоп
1
Собрать обратную
связь
2
Адаптировать
3
Показать ценность
4
Важно
100%
Всем сначала будет больно
70
Потом адаптируете все под команду
Всем станет нормально
5

71.

Мгновенного результата не будет!
71

72. Как понять, что процесс работает?

73. Как понять, что процесс работает?

Количество вопросов
Сократилось
73

74. Как понять, что процесс работает?

Количество багов на
задачу
Меньше
Количество вопросов
Сократилось
74

75. Как понять, что процесс работает?

Количество багов на
задачу
Скорость онбординга
новых участников
Меньше
Быстрая как никогда
Количество вопросов
Сократилось
75

76. Как понять, что процесс работает?

Количество багов на
задачу
Скорость разработки (не
падает!)
Скорость онбординга
новых участников
Меньше
Даже растет
Быстрая как никогда
Количество вопросов
Сократилось
76

77. Как понять, что процесс работает?

Количество багов на
задачу
Время на
переделки/доработки
Скорость разработки (не
падает!)
Скорость онбординга
новых участников
Меньше
Сократилось
Даже растет
Быстрая как никогда
Количество вопросов
Сократилось
77

78. Как понять, что процесс работает?

78
Количество багов на
задачу
Время на
переделки/доработки
Скорость разработки (не
падает!)
Скорость онбординга
новых участников
Меньше
Сократилось
Даже растет
Быстрая как никогда
Количество вопросов
Мозги
Сократилось
Целы и даже иногда отдыхают

79. Метрики

Качественные метрики:
• Опросы удовлетворенности команды
• Отзывы разработчиков: «Всё понятно», «Спасибо за спеку»
• Уменьшение количества вопросов «А что тут имелось в виду?»
НЕ метрики:
❌ Количество страниц в документе (больше ≠ лучше)
❌ Время на написание документа (быстро ≠ плохо)
79

80. ЗАКЛЮЧЕНИЕ

Артефакты = топливо, когда:
- У каждого есть целевая
аудитория (RACI)
- Они решают реальные
проблемы команды
- Заполняются разумно
(здравый смысл > догма)
80
ИИ = ускоритель, но НЕ
замена:
- User Stories, диаграммы,
глоссарий
- Человек контролирует
качество и точность
- Промпты важны — учитесь
их писать
Делать БОЛЬШЕ, писать МЕНЬШЕ:
- Один хороший документ > три
посредственных
- Шаблон = чек-лист, а не
повинность
- Документы для людей, а не для
процесса

81. ЗАКЛЮЧЕНИЕ

Документы ≠ Бюрократия
Документы = Актив (когда они ДЛЯ людей)
Артефакты = топливо, когда:
- У каждого есть целевая
аудитория (RACI)
- Они решают реальные
проблемы команды
- Заполняются разумно
(здравый смысл > догма)
81
ИИ = ускоритель, но НЕ
замена:
- User Stories, диаграммы,
глоссарий
- Человек контролирует
качество и точность
- Промпты важны — учитесь
их писать
Делать БОЛЬШЕ, писать МЕНЬШЕ:
- Один хороший документ > три
посредственных
- Шаблон = чек-лист, а не
повинность
- Документы для людей, а не для
процесса

82. О спикере

Владимир
Бурмистров
Главный системный аналитик
ИТ-Холдинг Т1, проект Dion
+ https://t.me/CrazyElephant_note
+ https://t.me/CrazyElephant

83.

84.

Спасибо
за внимание

English Русский Правила