Александр Калугин Минное поле требований в fixed price...

Калугин Александр, PhD, PMPhttp://pmarcor.com/

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

Заказная разработка

Новый продукт, а не внедрение/доработка

Fixed-Price/Fixed-Scope

Waterfall/Single Iteration

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

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

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

Подрядчик: Требуемое изменение рассматривается outside the scope, но явных подтверждений этой точки зрения нет

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

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

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

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

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

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

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

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

Конфликт. Не в пользу заказчика – «портит карму».

В пользу заказчика – down the rabbit hole.

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

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

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

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

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

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

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

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

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

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

Common Vision

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

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

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

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

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

Профилактика:

До начала проекта (Pre-sale)

По ходу проекта (manufacturing)

Лечение:

Коммуникация по проблеме, completion

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

+-

Требования

СН

АРУ

ЖИ

ВН

УТ

РИЧто? Как?

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

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

Архитектура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Калугин Александр

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

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

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

Общего решения – нет

Баги надо признавать

Детальная разборка –билет в один конец

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

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

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

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

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

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

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

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

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

Реализация запроса может усложнить basic workflow.

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

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

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

info@pmarcor.com

24