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

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

http://pmarcor.com/

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

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

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

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

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

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

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

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

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

Bona fide

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

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

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

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

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

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

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

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

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

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

the rabbit hole.

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

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

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

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

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

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

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

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

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

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

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

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

Common Vision

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

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

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

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

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

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

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

(manufacturing)

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

проблеме, completion

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

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

+-

Требования

СН

АР

УЖ

И

ВН

УТР

ИЧто? Как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

изменения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядро Спека

Feature #1

Feature #2

Feature #3

Feature #4

Debug

Review #1

Review #2

Review #3

Review #4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24

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

Калугин Александрinfo@pmarcor.com