Конфликты Требований

Конфликты Требований (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- Обратные Разработки.

Текст

Конфликты Требований

Как требования к будущему продукту, так и требования к его разработке олицетворяют согласие заказчика оплачивать решение каких-то проблем или удовлетворение каких-то бизнес-потребностей. Деньги стоят за разработкой и ещё большие деньги могут стоять за разработанным продуктом.

Нельзя сказать, что процесс создания требований -- это всегда борьба за получение наибольшего куска от имеющегося пирога. Однако, как любая делёжка денег, работа над требованиями всегда несёт в себе потенциал для конфликтов.

Отношения между заказчиком и подрядчиком могут выйти из-под контроля, если стороны не определили рамки сотрудничества. Это касается как всего проекта, так и разработки требований. Хотя обе стороны обычно зантересованы в успехе и, часто, продолжении сотрудничества, у сторон всегда есть почва для разногласий.

Объём работ по требованиям обычно невозможно определить. Фиксированная сумма за разработку требований провоцирует бесконтрольное раздувание объёмов.

Вот обычный сценарий провального проекта. Чтобы получить заказ, подрядчик предложил бесплатную разработку требований. Когда выяснилось, что разработка затягивается и расходы растут, подрядчик решил начать работу по незаконченным требованиям. Когда готовое изделие принесли заказчику, тот восклицает что-то типа: "Да это же чёрное! Я заказывал жёлтое! Мне чёрное не нужно!"

Почасовая ставка за разработку требований -- это, пожалуй, лучшая практика. Для привлечения заказчика, подрядчик может теоретически предложить бесплатную разработку, но в договоре тогда необходимо оговорить часовой предел бесплатных работ.

Управление требованиями или Планирование! Давайте сначала рассмотрим важность анализа заинтересованных сторон и управления заинтересованными сторонами. Вы начинаете объяснять концепцию наличия разных типов заинтересованных сторон, которые вовлечены в проект, и что каждый играет свою роль. Вы пытаетесь охватить метод анализа заинтересованных сторон, называемый моделью RACI, и я думаю, что, возможно, столкнулся с этим несколько лет назад в другой роли. Я вижу, что взаимодействие с заинтересованными сторонами и анализ являются очень важной частью бизнес-анализа, и принимаю это во внимание в общем смысле. Опять же, мне пришлось бы оставить понимание техник и различных аспектов и подходов к построению отношений на другой день.

А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, :

Варианты

разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).

Следующее лектио -- Учёт в Требованиях

Термины

Требования, Эпические продукты, SSOT