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

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

2.  Заказная разработка
 Новый продукт,
а не внедрение/доработка
 Fixed-Price/Fixed-Scope
 Waterfall/Single Iteration
 Проблемы с процессом
не рассматриваются
Калугин Александр 2

3. Заказчик: Не реализован определенный функционал,
который мы считаем в scope проекта.
Подрядчик: Требуемое изменение рассматривается outside
the scope, но явных подтверждений этой точки зрения нет
Калугин Александр 3

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

5.  Негативные тесты (включая работу
в некорректном окружении)
 Проблемы совместимости
 Performance/Security issues
 Наработки на отказ под нагрузкой
 Обработка полукорректного ввода
 «Не так как у аналогов»
 Не понимание ограничений технологии
и т п.
Претензии по основным workflows – редко.
Даже без модификаций продукт достигает
основной бизнес-цели
Калугин Александр 5

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

7.  Конфликт. Не в пользу
заказчика – «портит карму».
 В пользу заказчика – down
the rabbit hole.
 Сложно сделать, так как
такие запросы приходят поздно
 Часто запросы идут поперек архитектуры.
 Может быть очень важным для успеха продукта
Не имеет хорошего решения. Лучше не
доводить до такой проблемы.
Калугин Александр 7

8. Что хотел заказчик Что понял разработчик
Какой должен Как понято и
быть продукт реализовано
Спецификация
Калугин Александр 8

9. Минное поле
Минное поле требований архитектуры
•всѐ спросить нельзя объяснять
•необходимы правила заказчику
игры/принципы чтобы он мог
•говорить на языке говорить на
заказчика одном языке
Common Vision
Калугин Александр 9

10. Профилактика:
 До начала проекта
(Pre-sale)
 По ходу проекта
(manufacturing)
Лечение:
 Коммуникация по
проблеме, completion
Калугин Александр 10

11. Требования
Что? - + Как?
СНАРУЖИ
ВНУТРИ
Границы Архитектура
Приоритеты Workflows
ЧЕГО НЕТ ЧТО ЕСТЬ
ДО НАЧАЛА В ПРОЦЕССЕ
Калугин Александр 11

12.  Отказ от требований
 Приоритеты
 Границы
 Дихотомии
Калугин Александр 12

13. Цель: Избежать превращения пожеланий в ограничения.
Коммуницируем с заказчиком предположения в виде:
1. Нет других требований к шифрованию/дешифрованию
пользовательских данных
2. Нет явных требований к поведению UI контролов – при
портировании
3. Нет явных требований по количеству обрабатываемых
запросов/объеме пользовательских данных. Система
должна обеспечивать корректную стабильную работу
без потерь пользовательских данных.
Калугин Александр 13

14. Цель: выяснить относительные приоритеты
различных аспектов работы системы.
Критерий Рейтинг
Удобный, интуитивно понятный пользовательский
интерфейс, время отклика.
Защищенность пользовательских данных
Дизайн/Красивый пользовательский интерфейс
Расширяемость
Отказоустойчивость
Сохранность пользовательских данных
Сохранение общей базы кода (при портировании)
и т.д.
Калугин Александр 14

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

16. Написание спецификации подрядчиком – это не доп.
затраты, а контратака и страх полис
 рассказать всѐ своими словами
– меньше возможность поняли
неправильно – если заказчик
утверждает
 есть возможность
«разминировать архитектуру»
-- рассказать о «ребрах
жесткости»
 возможно ограничить
негативные тесты,
сформулировав acceptance
tests.
 выставить ожидания о
неинтуитивных видах функционала
Калугин Александр 16

17. Архитектура всегда влияет на продукт. Если
заказчик не готов понимать саму
архитектуру, он в состоянии понять ее
последствия
Примеры:
 AJAX или перезагрузка страницы
 Синхронная или асинхронная обработка
 Реализация конкретного требования или
создания framework-а для серии аналогичных?
Калугин Александр 17

18. Ядро Спека
 Участие в review
Б
Л  Внести изменения по
А
Г Feature #1 Review #1 ходу – без изменения
О
П
Feature #2  Видеть прогресс – лучше
Р Review #2
И
Я
продукт
Feature #3 Review #3 
Т
Н В случае если нет спеки
О Feature #4
Review #4 или Review – не
продолжать
Debug
Калугин Александр 18

19. Часто у заказчика небольшое количество хотелок.
Если эти желания удовлетворяются –
настроение улучшается.
Если потребности выявлены
достаточно рано –
не обязательно
следует увеличение
стоимости.
Калугин Александр 19

20.  Общего решения – нет
 Баги надо признавать
 Детальная разборка –
билет в один конец
 Если изменение критично
для бизнес-цели, то
– конструктивного
диалога не получится.
Калугин Александр 20

21.  Попытаться понять суть и истоки запроса,
выяснить не достигается ли цель в рамках
существующей функциональности.
 Предложить альтернативу менее
сложную в реализации
 Объяснить негативные
последствия
реализации --
несоответствие
выявленным правилам.
Калугин Александр 21

22.  При реализации запроса – может быть
покрыт corner case, но может быть стать
хуже для проекта в целом.
 Реализация запроса может требовать
удаления из проекта
других изменений
к оригинальному scope, реализованных
запрошенных на более
ранних этапах.
Калугин Александр 22

23.  Реализация запроса может
усложнить basic workflow.
 Изменение может быть
вне запросов других
представителей
заказчика.
Калугин Александр 23

24. Спасибо за внимание!
Калугин Александр
info@pmarcor.com
24