Аналитик какзолотоискатель: работа с

требованиямипри заказной разработке

Наталия Григорашведущий аналитик,

компания Custis

О компании

О чем поговорим сегодня

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

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

Требования и заказная разработка

Основной вопрос :

что нужно заказчику?

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

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

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

Сначала определим цели

• заказчик получает то, что ему, действительно, необходимо

(что еще?)

• постановка задач для разработчиков

• минимизация количества доработок

• разумные сроки реализации

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

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

• «расплывчатые» требования• излишняя детализация задач, поступающих от

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

оказалось…»• противоречивые требования• ожидаемые сроки разработки превышают те, что

необходимы заказчику

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

?как их обойти

« » Расплывчатые требования

• нет четкой формулировки задачи

• недостаточно ясно изложены цели

• много «белых пятен»• в формулировке требований

много сравнений («хотим как там»), которые не дают полной картины того, что необходимо

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

« » :Расплывчатые требования

• добраться до непосредственных пользователей будущего функционала, раскрыть предполагаемые сценарии использования

• «заполнение пробелов» на основе знаний о бизнес-процессах заказчика, на основе уже работающего функционала

• несколько «точек» обратной связи (первичные требования, раннее тестирование, «макетный» вариант)

?как добиться четкости

:Избыточность информации

Излишняя детализация задач, поступающих от заказчика («лишние детали в

конструкторе»)

:Избыточность информации

• много допустимых вариантов – какой выбрать?

• детали, которые сказываются на сроках или сложно совместимы с уже реализованным функционалом

:Избыточность информации как отсеять лишнее

?и не потерять нужное

?

:Избыточность информации как отсеять лишнее

?и не потерять нужное понять, кем и для чего будет

использоваться будущий функционал отделить наиболее важную часть

функционала от деталей

отдать пользователям и получить отзывы

разобраться с деталями (доработать, отказаться от них, вынести в отдельный функционал)

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

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

• найти решение, которое минимально меняет уже работающий функционал, надстройка вместо переделки

• анализ того, что может быть затронуто (в т. ч. подключение разработчиков, общение с командами смежных систем)

• раннее тестирование, в т. ч. пользователями• постепенный переход к новому (сначала

реализуется сама возможность, затем поэтапно переключаемся на новое и отказываемся от старого) –> минимизация риска

Неверные предположения

«мы думали, а оказалось…» (((((

: Неверные предположенияпоследствия• срок разработки превысил ожидаемый• сделали, как хотел заказчик, но в итоге оказалось не то,

что ему реально было нужно• заказчика не устраивают какие-либо параметры,

которые изначально не предусмотрели (скорость работы, связь с другими системами)

• небольшая доработка выросла в переделку значительной части системы

• возникли срочные непредвиденные доработки для доведения до рабочего состояния

• пользователям недоступны все возможности функционала или не предусмотрены все нужные сценарии

: Неверные предположения причины

• заказчик указал не все сценарии • функционал разработан с учетом того, что будет

запущен в эксплуатацию другой функционал или стороннее ПО, а второе отложилось

• предоставлены ошибочные данные об объеме данных

: Неверные предположения как?избежать

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

• предварительное нагрузочное тестирование на раннем этапе разработки

• ранний фидбэк, передать «макетный» вариант или минимальный рабочий вариант

• найти «точки риска» и путь, при котором возможные доработки будут минимальны

Противоречивые требования

входящие требования• противоречат уже

работающему функционалу • противоречат друг другу• «ломают» устоявшийся

бизнес-процесс

Противоречивые требования:

• доработка уже работающего функционала или корректировка бизнес-процесса под новый функционал (не всегда возможно)

• поиск альтернативного пути, который решит потребности заказчика

• компромиссное решение (выделить детали, от которых можно отказаться)

?как найти выход

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

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

заказчик: «хочу

за такой срок»

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

• отсеивание не очень критичных доработок, которые «ударяют по срокам»

• определение оптимальной последовательности выполнения задач

• расстановка приоритетов• при необходимости реализовать альтернативный

быстрый вариант, позже перейти на более правильный вариант

: Еще итеративный поход

Какие преимущества для заказной разработки?

Итеративный поход

быстрые релизы (раз в 2 недели)

быстрая обратная связь , быстрая реакция на запросы заказчика

Итеративный поход

можно первую версию отдать раньше, доработки реализовать позже

пользователи могут раньше начать использовать функционал,

выигрыш по срокам

Итеративный поход

уточнение требований в процессе разработки

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

Итеративный поход

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

?К чему стремимся в итоге

• исчерпывающая формулировка задач для разработчиков

• точная оценка затрат, запланированных для решения каждой задачи

• минимизация возможных доработок после передачи заказчику реализованного функционала

• и, главное, оправдание ожиданий заказчика в разумные сроки.

Спасибо

?ВопросыНаталия Григорашngrigorash@custis.ru