Документ обсуждает работу аналитиков в контексте заказной разработки, акцентируя внимание на важности четкой формулировки требований и активного взаимодействия с заказчиком. Рассматриваются проблемы, связанные с 'расплывчатыми' и противоречивыми требованиями, а также предлагаются итеративные подходы, обеспечивающие быструю обратную связь и минимизацию доработок. Основная цель заключается в оптимизации процессов для достижения удовлетворительных результатов для заказчика в разумные сроки.

1. Аналитик как золотоискатель:
работа с требованиями при
заказной разработке
Наталия Григораш
ведущий аналитик,
компания Custis

2. О компании

3. О чем поговорим сегодня
Требования при заказной разработке:
• Особенности
• Цели
• Сложности и как их обойти
• Итеративный подход

4. Работа с требованиями

5. Требования и заказная разработка
Основной вопрос :
что нужно
заказчику?

6. Аналитик как золотоискатель

7. Грамотная работа с требованиями

8. Как работать с требованиями?

9. Сначала определим цели
• заказчик получает то,
что ему,
действительно,
необходимо
(что еще?)
• постановка задач для
разработчиков
• минимизация
количества доработок
• разумные сроки
реализации

10. Проблемы при работе с требованиями

11. Проблемы при работе с требованиями
• «расплывчатые» требования
• излишняя детализация задач, поступающих от
заказчика
• «как не поломать то, что уже работает хорошо»
• неверные предположения, «мы думали, а
оказалось…»
• противоречивые требования
• ожидаемые сроки разработки превышают те, что
необходимы заказчику

12. Проблемы при работе с требованиями
как их обойти?

13. «Расплывчатые» требования
• нет четкой формулировки
задачи
• недостаточно ясно изложены
цели
• много «белых пятен»
• в формулировке требований
много сравнений («хотим как
там»), которые не дают
полной картины того, что
необходимо

14. «Расплывчатые» требования:
как добиться четкости?

15. «Расплывчатые» требования:
• добраться до непосредственных
пользователей будущего функционала,
раскрыть предполагаемые сценарии
использования
• «заполнение пробелов» на основе знаний о
бизнес-процессах заказчика, на основе уже
работающего функционала
• несколько «точек» обратной связи (первичные
требования, раннее тестирование,
«макетный» вариант)
как добиться четкости?

16. Избыточность информации:
Излишняя детализация задач,
поступающих от заказчика
(«лишние детали в
конструкторе»)

17. Избыточность информации:
• много допустимых вариантов
– какой выбрать?
• детали, которые сказываются
на сроках или сложно
совместимы с уже
реализованным
функционалом

18. Избыточность информации:
как отсеять лишнее
и не потерять нужное?

19. Избыточность информации:
как отсеять лишнее
и не потерять нужное?
понять, кем и для чего будет
использоваться будущий функционал
отделить наиболее важную часть
функционала от деталей
отдать пользователям
и получить отзывы
разобраться с деталями
(доработать, отказаться от них,
вынести в отдельный функционал)

20. «Как не поломать то, что уже работает»

21. «Как не поломать то, что уже работает»
• найти решение, которое минимально меняет уже
работающий функционал, надстройка вместо
переделки
• анализ того, что может быть затронуто
(в т. ч. подключение разработчиков, общение с
командами смежных систем)
• раннее тестирование, в т. ч. пользователями
• постепенный переход к новому (сначала
реализуется сама возможность, затем поэтапно
переключаемся на новое и отказываемся от
старого) –> минимизация риска

22. Неверные предположения
«мы думали, а
оказалось…» (((((

23. Неверные предположения: последствия
• срок разработки превысил ожидаемый
• сделали, как хотел заказчик, но в итоге оказалось не
то, что ему реально было нужно
• заказчика не устраивают какие-либо параметры,
которые изначально не предусмотрели (скорость
работы, связь с другими системами)
• небольшая доработка выросла в переделку
значительной части системы
• возникли срочные непредвиденные доработки для
доведения до рабочего состояния
• пользователям недоступны все возможности
функционала или не предусмотрены все нужные
сценарии

24. Неверные предположения: причины
• заказчик указал не все сценарии
• функционал разработан с учетом того, что будет
запущен в эксплуатацию другой функционал или
стороннее ПО, а второе отложилось
• предоставлены ошибочные данные об объеме
данных

25. Неверные предположения: как избежать?
• выяснить у заказчика, что может повлиять в
будущем (переход на новую систему и др.)
• предварительное нагрузочное тестирование на
раннем этапе разработки
• ранний фидбэк, передать «макетный» вариант
или минимальный рабочий вариант
• найти «точки риска» и путь, при котором
возможные доработки будут минимальны

26. Противоречивые требования
входящие требования
• противоречат уже
работающему функционалу
• противоречат друг другу
• «ломают» устоявшийся
бизнес-процесс

27. Противоречивые требования:
• доработка уже работающего
функционала или корректировка
бизнес-процесса под новый
функционал (не всегда
возможно)
• поиск альтернативного пути,
который решит потребности
заказчика
• компромиссное решение
(выделить детали, от которых
можно отказаться)
как найти выход?

28. А что со сроками реализации?

29. А что со сроками реализации?
заказчик: «хочу
за такой срок»

30. А что со сроками реализации?
• отсеивание не очень критичных доработок,
которые «ударяют по срокам»
• определение оптимальной последовательности
выполнения задач
• расстановка приоритетов
• при необходимости реализовать альтернативный
быстрый вариант, позже перейти на более
правильный вариант

31. Еще: итеративный поход
Какие преимущества для
заказной разработки?

32. Итеративный поход
быстрые релизы (раз в 2 недели)
быстрая обратная связь ,
быстрая реакция на запросы заказчика

33. Итеративный поход
можно первую версию отдать раньше,
доработки реализовать позже
пользователи могут раньше начать
использовать функционал,
выигрыш по срокам

34. Итеративный поход
уточнение требований
в процессе разработки
гибкость при работе с требованиями,
уменьшение риска того,
что заказчик получит не то,
что ему было реально необходимо

35. Итеративный поход
Вывод:
для заказной разработки
итеративность естественна

36. К чему стремимся в итоге?
• исчерпывающая формулировка
задач для разработчиков
• точная оценка затрат,
запланированных для решения
каждой задачи
• минимизация возможных
доработок после передачи
заказчику реализованного
функционала
• и, главное, оправдание ожиданий
заказчика в разумные сроки.

38. Наталия Григораш
ngrigorash@custis.ru