Sef.by'2011 Минное поле требований

Минное поле требований

в fixed-price проектеКалугин Александр, PhD, PMP

http://pmarcor.com/

http://pmarcor.com/

Калугин Александр 2

Disclaimer Заказная разработка Новый продукт,

а не внедрение/доработка Fixed-Price/Fixed-Scope Waterfall/Single Iteration

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


Суть проблемы:Заказчик: Не реализован определенный функционал,

который мы считаем в scope проекта.Подрядчик: Требуемое изменение рассматривается

outside the scope, но явных подтверждений этой точки зрения нет


Bona fide


Распространенные виды

Негативные тесты (включая работув некорректном окружении)

Проблемы совместимости Performance/Security issues Наработки на отказ под нагрузкой Обработка полукорректного ввода «Не так как у аналогов» Не понимание ограничений технологиии т п.

Претензии по основным workflows – редко. Даже без модификаций продукт достигает

основной бизнес-цели


Почему проблема? Конфликт. Не в пользу

заказчика – «портит карму». В пользу заказчика – down

the rabbit hole.

Сложно сделать, так как такие запросы приходят поздно

Часто запросы идут поперек архитектуры. Может быть очень важным для успеха продукта

Не имеет хорошего решения. Лучше не доводить до такой проблемы.


Суть проблемы: Требования и коммуникация

Спецификация

Что хотел заказчик

Какой должен быть продукт

Что понял разработчик

Как понято и реализовано


Суть проблемы: Минные поля

Common Vision

Минное поле требований

•всё спросить нельзя•необходимы правила игры/принципы •говорить на языке заказчика

Минное поле архитектуры

объяснять заказчику чтобы он мог говорить на одном языке


Как быть с минным полем?Профилактика: До начала проекта

(Pre-sale) По ходу проекта

(manufacturing)

Лечение: Коммуникация по

проблеме, completion


Профилактика в Pre-Sale

+-

Требования

СН

АР

УЖ

И

ВН

УТР

ИЧто? Как?

ГраницыПриоритеты

ЧЕГО НЕТДО НАЧАЛА

АрхитектураWorkflows

ЧТО ЕСТЬВ ПРОЦЕССЕ


До начала: Детали Отказ от требований Приоритеты Границы Дихотомии


До начала: Отказ от требованийЦель: Избежать превращения пожеланий в ограничения.

Коммуницируем с заказчиком предположения в виде:

1. Нет других требований к шифрованию/дешифрованию пользовательских данных

2. Нет явных требований к поведению UI контролов – при портировании

3. Нет явных требований по количеству обрабатываемых запросов/объеме пользовательских данных. Система должна обеспечивать корректную стабильную работу без потерь пользовательских данных.


До начала: Приоритезация

Цель: выяснить относительные приоритеты

различных аспектов работы системы.Критерий Рейтинг

Удобный, интуитивно понятный пользовательский интерфейс, время отклика.

Защищенность пользовательских данных

Дизайн/Красивый пользовательский интерфейс

Расширяемость

Отказоустойчивость

Сохранность пользовательских данных

Сохранение общей базы кода (при портировании)и т.д.


В производстве. Цели

_• Доспечить. Область ‘+’• Найти минное поле как можно раньше• «Разминировать» архитектуру• Уменьшить желание заказчика вносить

изменения


В производстве. ДоспекНаписание спецификации подрядчиком – это не доп. затраты, а

контратака и страх полис рассказать всё своими словами

– меньше возможность поняли неправильно – если заказчик утверждает

есть возможность «разминировать архитектуру» -- рассказать о «ребрах жесткости»

возможно ограничить негативные тесты, сформулировав acceptance tests.

выставить ожидания о неинтуитивных видах функционала


Об архитектуре:

Архитектура всегда влияет на продукт. Если заказчик не готов понимать саму архитектуру, он в состоянии понять ее последствия

Примеры: AJAX или перезагрузка страницы Синхронная или асинхронная обработка Реализация конкретного требования или

создания framework-а для серии аналогичных?


Сжатие времени Участие в review Внести изменения по

ходу – без изменения Видеть прогресс –

лучше продукт В случае если нет спеки

или Review – не продолжать

Ядро Спека

Feature #1

Feature #2

Feature #3

Feature #4

Debug

Review #1

Review #2

Review #3

Review #4

БЛАГОПРИЯТНО


Уменьшение желания. Gold-PlatingЧасто у заказчика небольшое количество

хотелок. Если эти желания удовлетворяются – настроение улучшается.

Если потребности выявлены достаточно рано – не обязательно следует увеличение стоимости.


Если ситуация возникла Общего решения – нет Баги надо признавать Детальная разборка –

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

для бизнес-цели, то – конструктивногодиалога не получится.


По-хорошему Попытаться понять суть и истоки запроса,

выяснить не достигается ли цель в рамках существующей функциональности.

Предложить альтернативу менеесложную в реализации

Объяснить негативные последствия реализации -- несоответствие выявленным правилам.


Прочие доводы При реализации запроса – может быть

покрыт corner case, но может быть стать хуже для проекта в целом.

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

ранних этапах.


Прочие доводы Реализация запроса может

усложнить basic workflow. Изменение может быть

вне запросов других представителей заказчика.

24

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

Калугин Александр[email protected]

mailto:[email protected]

Sef.by'2011 Минное поле требований

Documents

Transcript of Sef.by'2011 Минное поле требований