Доклад Екатерины Герт на конференции Analyst Days-6 www.analystdays.com

1. Екатерина Герт
Ведущий аналитик
Москва, 2017 г.
ВСЕ ГРАНИ
РЕЦЕНЗИРОВАНИЯ
ТРЕБОВАНИЙ

2. /342
• Более 7 лет работы аналитиком
• Первый документ с требованиями переписывала 5 раз
• Рецензировала работы стажеров, опытных аналитиков и 1
очень известного бизнес-аналитика
ЕКАТЕРИНА ГЕРТ

3. /343
ЧТО ПРОИСХОДИТ С ТРЕБОВАНИЯМИ ПОСЛЕ ТОГО, КАК
ОНИ БЫЛИ РАЗРАБОТАНЫ?
Сразу отправляю на согласование Заказчику
Сразу передаю разработчикам
Происходит проверка требований другими
членами проектной команды
Другое

4. /344
ИСТОРИЯ ПРО КОРАБЛЬ И СУДНО
Корабль или судно?
Какая разница?

5. /345
ЧТО ДАЕТ РЕЦЕНЗИРОВАНИЕ ТРЕБОВАНИЙ
• 60% ошибок после рецензирования проектных артефактов
• 60% ошибок находится после тестирования ПО
• 90% - 99% ошибок можно найти при помощи обоих методов
По данным из Handbook of Technical Reviews, Gerald Weinberg, 4th edition

6. /346
ПРОБЛЕМА №1. НЕТ ЕДИНОГО ТЕРМИНА
Review (ревью)
Рецензирование требований
Тестирование требований
Technical review (техническое ревью)
Другое

7. /347
ЧТО ГОВОРЯТ УЧЕБНИКИ О ТЕРМИНЕ
Рецензирование – действия,
предпринимаемые одним или несколькими
лицами для исследования продукта с целью
обнаружить дефекты и улучшить возможности
Требования к разработке программного обеспечения,
Карл Вигерс, 3-е издание

8. /348
ЧТО МЫ ДУМАЕМ, КОГДА ГОВОРИМ О ТЕРМИНЕ
Проверить на
соответствие
«шаблону»
Проверить на
наличие ошибок
стилистики,
орфографии,
грамматики
Качество
требований
«по Вигерсу»

9. /349
ВЫВОД №1
Убедитесь, что рецензент и автор документа
одинаково понимают, каким должен быть
результат

10. /3410
ПРОБЛЕМА №2. УЗКАЯ СФЕРА ПРИМЕНЕНИЯ
Проверить на
соответствие
шаблону
Проверить на
орфографию и
пунктуацию
Проверить
качество каждого
требования «по
Вигерсу»

11. /3411
ИСТОРИЯ ПРО 100 КОММЕНТАРИЕВ

12. /3412
Формальное рецензирование:
• Группа экспертов;
• Очное обсуждение;
• Результат доступен всем
ВИДЫ РЕЦЕНЗИРОВАНИЯ
Неформальное рецензирование:
• 1-2 человека;
• Каждый оценивает самостоятельно;
• Результат обсуждается тет-а-тет

13. /3413
• Создание документа с предсказуемым качеством
ВОЗМОЖНОСТИ РЕЦЕНЗИРОВАНИЯ
• Обучение автора документа
• Распространять знания среди проектной команды

14. /3414
• Используйте возможности рецензирования на 100%
• Обучайте коллег
• Делитесь знаниями
ВЫВОД №2

15. /3415
ПОЧЕМУ У ВАС НЕ ИСПОЛЬЗУЕТСЯ ПРОВЕРКА ТРЕБОВАНИЙ
ДРУГИМИ УЧАСТНИКАМИ ПРОЕКТНОЙ КОМАНДЫ?
Нет времени
Нет людей с равными компетенциями
Никому это не нужно
Если решение требует проверки другими участниками проектной команды, то эти
вопросы решаются в процессе разработки требований
Нет, в процессе
В каждой команде 1 аналитик. После согласования требований с заказчиком, они
обсуждаются с прочими членами проектной команды. После этого возможны
дополнения, но на общий состав это не влияет
Аналитики достаточно квалифицированные
Дефицит ресурсов в рамках текущих задач команды

16. /3416
ПРОБЛЕМА №3. НЕВЕРНОЕ ПОНИМАНИЕ ПРОЦЕССА
РЕЦЕНЗИРОВАНИЯ
Зачем на это
тратить время?
У меня и так
все отлично!
Рецензирование
– это трудно…

17. /3417
КАК БОРОТЬСЯ С ОТСУТСТВИЕМ ВРЕМЕНИ?
Что делать, если
времени нет?
Выделить самые
приоритетные
части
Разбить артефакт
на части с учетом
приоритета

18. /3418
У МЕНЯ РАБОТАЮТ САМЫЕ КЛАССНЫЕ АНАЛИТИКИ, ЗАЧЕМ
МНЕ ЭТО?
У меня работают
самые классные
аналитики!
Если аналитики такие
классные, то это
займет 5 минут и
поможет избежать
ошибок
Люди не идеальны и
ошибаются

19. /3419
ВСЕ И ТАК ПОНЯТНО, ЗАЧЕМ МНЕ РЕЦЕНЗИРОВАНИЕ?
Все и так понятно.
Зачем мне
рецензирование?
Важно, чтобы было
понятно всем
участникам
Неоднозначные
формулировки могут
создать трудности при
разработке, внедрении
и сопровождении
Если все
понятно, то
это займет 5
минут

20. /3420
НЕТ ЛЮДЕЙ, КОТОРЫЕ СПОСОБНЫ ПРОВОДИТЬ
РЕЦЕНЗИРОВАНИЕ
У меня нет людей,
которые могут
проводить
рецензирование
Хотя бы 1
способный
должен быть
Используйте
рецензирование
как инструмент
обучения, чтобы
появились новые
рецензенты

21. /3421
МОЖНО ВНЕСТИ ИЗМЕНЕНИЯ ПОСЛЕ СОГЛАСОВАНИЯ С
ЗАКАЗЧИКОМ/ ПЕРЕДАЧИ В РАЗРАБОТКУ
Можно внести
изменения после
согласования с
заказчиком
Это может привести
к повышению
стоимости решения
Это может
испортить вашу
репутацию в
глазах заказчика
Заказчик может
отказаться от
исправления
требований

22. /3422
• Рецензировать можно небольшие блоки требований
• Проверьте, что требованиями разными участниками команды воспринимаются
одинаково
• Прекрасные требования рецензируются за 5 минут
ВЫВОД №3

23. /3423
Ведущий аналитик
КОГО МОЖНО ПРИВЛЕКАТЬ К РЕЦЕНЗИРОВАНИЮ
Ведущий разработчик
Архитектор
Ведущий тестировщик
Другое
А еще…. Коллеги из смежных проектов, Внедренцы, Заказчик, Эксперт

24. /3424
1. Сформировать список рецензентов
2. Разослать рецензентам материалы и согласовать срок встречи
3. Организовать встречу рецензентов
4. Принять решение о качестве артефакта
5. Зафиксировать результаты
КАК ПРОВОДИТЬ ФОРМАЛЬНОЕ РЕЦЕНЗИРОВАНИЕ?

25. /3425
• Собрать команду
• Привлечь экспертов
• Пройтись по требованиям и снять вопросы
GROOMING МИТИНГ

26. /3426
• Выбрать коллег для рецензирования
• Попросить коллег провести оценку работы
• Собрать результаты и обсудить их при необходимости
КАК ПРОВОДИТЬ НЕФОРМАЛЬНОЕ РЕЦЕНЗИРОВАНИЕ

27. /3427
• Быть готовым к проведению рецензирования
• Следить за используемыми фразами
• Один позитивный – один негативный комментарий
• Обнаруживать проблемы, но не решать их
• Результат формального рецензирования должен быть публичным
РЕКОМЕНДАЦИИ ДЛЯ РЕЦЕНЗЕНТОВ

28. /3428
• Письменно в виде комментариев или реестра замечаний
• Устно обсудить все открытые вопросы
• Подвести итог письменно, чтобы зафиксировать основные моменты, открытые
вопросы и договоренности
• Лучше сочетать устный и письменный вариант
ФОРМА ОБРАТНОЙ СВЯЗИ

29. /3429
• Внимательно изучить результаты рецензии
• Обращать внимание на суть, отсеивать эмоции
• Непонятное сразу обсуждать
• Если не согласны, то прокомментировать и обсудить возражения
РЕКОМЕНДАЦИИ ДЛЯ АВТОРОВ

30. /3430
Заказчику нужно работающее решение, а не пачка идеально
написанных бумаг
ИТОГИ

31. /3431
• Чтобы развивать решение
• Чтобы поддерживать разрабатываемы продукт
• Чтобы согласовать свои обязательства с Заказчиком
АРТЕФАКТЫ НУЖНЫ ПРОЕКТНОЙ КОМАНДЕ

32. /32
• Handbook of Technical Reviews, Fourth Edition Gerald M. Weinberg
• Карл Вигерс «Требования к программному обеспечению»
• Результаты опроса в сообществе
• Личный опыт
МАТЕРИАЛЫ ДЛЯ ДОКЛАДА

33. СПАСИБО ЗА
ВНИМАНИЕ!
Екатерина Герт
Ведущий аналитик
Департамента информационных технологий
111033, Москва, ул. Волочаевская, д.5, к.1
Т: (495) 974 2274 # 6412 | Ф: (495) 974 2277
E-mail: EGert@croc.ru
croc.ru