Александр Калугин Минное поле требований в fixed price...
DESCRIPTION
Александр Калугин Минное поле требований в fixed price проектеTRANSCRIPT
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.
Изменение может быть вне запросов других представителей заказчика.
