Коллеги, не подскажете, где можно почитать более-менее связно про специфику управления требованиями для портфеля проектов, основанных на общей технологической платформе?

Поясню. Компания разрабатывает некий фреймворк (платформу, прототип, программный шаблон), который используется в нескольких прикладных проектах. Фреймворк удобен тем, что содержит в готовом виде некоторые "часто запрашиваемые фичи" из определенной предметной области. Поэтому реализация прикладного проекта выглядит так: берем фреймворк, докручиваем/модифицируем его под конкретного функционального заказчика, и вуаля.

Проблему с т.зр. управления требованиями представляет то, что фреймворк, как и прикладные проекты на его основе, - живые системы, которая постоянно развиваются. Каждый проект ведется своей проектной командой, со своими аналитиками, разработчиками и т.п. У фреймворка - своя отдельная проектная команда: аналитики, разработчики и прочее. В каждом проекте управление требованиями в каком-то виде ведется: зафиксированы требования заказчиков в прикладных проектах, существуют формулировки требований, относящихся к функционалу фреймворка. Есть потребность этот комплекс как-то увязать между собой и управлять с учетом зависимостей между проектами.

Можно выделить очень много вопросов, которые хотелось бы решать, приведу только примеры. 1. В прикладном проекте заявлено требование заказчика - сделать Х. Кто будет реализовывать это требование - команда фреймворка (с тем, чтобы Х вошло в функции платформы) или команда прикладного проекта? 2. Со стороны прикладного проекта П1 заявлено пожелание модифицировать фичу платформы Y. На какие характеристики прикладных систем в проектах П2, П3 и т.д. это может повлиять? 3. Во фреймворке есть фича Z, а в прикладном проекте мы ее докручиваем до Z*. Правильно иметь в прикладном проекте формулировку требований Z* или Z*-Z? Ну и т.п.
 
Изобретать велосипеды мы сами мастаки, но все равно буду признателен и за частные отзывы. Но вопрос вообще про то, не знает ли кто, где можно ознакомиться с мнением великих по данной теме.

Можно выделить очень много вопросов, которые хотелось бы решать, приведу только примеры. 1. В прикладном проекте заявлено требование заказчика - сделать Х. Кто будет реализовывать это требование - команда фреймворка (с тем, чтобы Х вошло в функции платформы) или команда прикладного проекта? 2. Со стороны прикладного проекта П1 заявлено пожелание модифицировать фичу платформы Y. На какие характеристики прикладных систем в проектах П2, П3 и т.д. это может повлиять? 3. Во фреймворке есть фича Z, а в прикладном проекте мы ее докручиваем до Z*. Правильно иметь в прикладном проекте формулировку требований Z* или Z*-Z? Ну и т.п.

1. Отнесение реализуемого функционала к "платформенной" или к индивидуально настраиваемой части ИМХО относится к компетенции архитектора, архитектуре. Обсуждать эти вопросы в контексте управления проектами (планирование состава и графика работ, выбор архитектуры решения и пр.) стоит, когда уже артикулировано выделены варианты архитектурных решений (например, вариант 1 - с реализацией функционала целиком индивидуально только под данного заказачика, не трогая платформы. Вариант 2 - реализуем фичи 1, 2,3 доработкой платформы, 4,5,6 - индивидуально под заказчика). И выбор между вариантами принимать по критерию стоимости/сроки, а также сложности сопровождения продукта, после поставки его заказчику.
2. Возможность доработки функционала платформы под один проекта без создания проблем для другого проекта на этой же платформе можно обсуждать опять же только применительно к конкретной архитектуре платформы и архитектуры решений проектов 1 и 2.
3. Формулировка требований в прикладном проекте: если это требования Заказчика (ТЗ?) - неизбежно будут описаны требования к системе в целом (как то, что реализуются "платформой", так и то, что реализуется доработкой под Заказчика). Требования для разработчиков (скорее, уже описание проектного решения - техпроект) может ограничиваться описанием собственно дорабатываемого под данного Заказчика функционала (предполагая, что все команды разработчиков хорошо знают функционал "платформы") .

ИМХО основная проблема - не сколько создание, сколько сопровождение (поддержка) функционала нескольких похожих, но разных систем, после того как они поставлены заказчикам. Лучше всего, если в "платформу" включается только функционал, заведомо общий для всех проектов, например, реализующий требования законодательства или общеотраслевых нормативных актов. Или ориентироваться на распространение коробочного решения реализующего "лучшие практики", минимизируя изменения "платформенного" функционала.

2 Михаил Курбасов: Вам нужно решение "как организационно управлять требованиями" или "какие технические/программные средства использовать"?

2 Водолей. Скорее, нужен best practise, как в части организационных подходов, так и в части теххнических/программных средств. Т.е. как ВООБЩЕ можно управлять требованиями - и с организационной, и с программно-технической точек зрения нам понятно. Хотелось позаимствовать чужого опыта для описанного кейса.

не знаю уж в какой мере мой опыт является best practice, да и не отношу я себя к великим... хотя..... :о)))

ключевой принцип, по-моему, должен заключаться в разделении ответственности: группа, отвечающая за ядро, д.б. ответственна за ядро :о)) плюс совместимость с отдельными проектами (индивидуально или в комплексе), а проектные группы д.отвечать за реализацию своих, особенных требований.
также где нужно должны использоваться принципы единства архитектуры, централизации и унификации. централизоваться должны функции, выполняемые в интересах более чем одной п/г, при этом проектные решения должны быть [максимально] унифицированными.
впрочем принципов можно напридумывать довольно много. со временем они сложатся в стройную систему
 
если какое-то особенное требование затрагивает ядро, то вопрос должен рассматриваться совместно и в каждом случае должно приниматься обоснованное решение. также должна отслеживаться "последовательность линии", особенно в отношении каких-либо архитектурных решений.
 
для этого могу посоветовать организовать комитет по требованиям (все равно какое-то подобное собрание у Вас уже должно существовать стихийно), состоящий из представителей р/г отдельных проектов, ответственных за управление и контроль реализации требований, и из отвественных за управление и реализацию требований в ядре продукта. очевидно также вам нужно будет иметь систематизированное представление требований всего семейства продуктов (ответственность за него скорее за "ядерными" управляющими требованиями), критерии отнесения требований к ядру или продукту, четкие процедуры взаимодействия обоих подгрупп на всех этапах работы с требованиями и схема и базовые критерии принятия решения (чтобы было без обиды). процедуры работы с требованиями по сути остаются теми же, но содержательно усложняются, т.к. увеличивается количество участников, принимающих участие в процессе управления требований в целом.
также должна поддерживаться определенная ритмичность рассмотрения подобных вопросов, гарантирующая своевременность принятия подобных решений, т.к. иначе проектные группы, не дождавшись "ядерной" реакции по новым требованиям, начнут на себя брать то, что к ним не относится.

на ваши вопросы однозначных ответов сейчас дать нельзя, т.к. ситуации описаны довольно абстрактно, поэтом возможно и так и эдак решать в каждом конкретном случае, например:
1. если Х относится к ядру, но не используется в других проектах (т.е. один частный случай), то "ядерщики" могут взять на себя либо делегировать реализацию проектной группе с последующим контролем качества и интеграцией с основным продуктом
если используется в проектах, то ответственность на "ядерщиках"
если от частного случая переход к обширной практике, то "ядерщики" должны взять себе соответствующую фичу, забрав ее у соответствующей проектной группы. при этом должен контролироваться стандарт документирования.
в общем я бы назвал это "схемой, похожей на осьминога" :о)))
2. однозначно, что взаимозависимости должны контролироваться "ядерной" группой управления, т.к. одна проектная группа может ничего не знать о содержании работ другой п/г (хотя может и знать). при большом количестве проектов за счет этого достигается значительная экономия на ресурсах п/г, занимающихся перекрестной поддержкой друг друга. от этого нужно уходить вплоть до создание специальной централизованной группы при значительном росте количества проектов.
3. на уровне ТЗ для заказчика неважно, как и где будет реализовываться фича Z*, поэтому, не зная деталей, я бы предложил разделить ответственность: за Z отвечает "группа ядра", за довесок и за Z* в целом перед заказчиком - п/г

при желании подробности можно обсудить в личке.

насчет софта... предполагаю, что можно прикрутить Caliber RM или что-то подобное, т.к. он позволяет связывать требования разных групп/уровней. хотя "это было давно и неправда"...

P.S. Могу посоветовать заглянуть в книжку Фатрелла (Фатрелл, Шафер, Шафер Управление программными проектами). К тому же есть опыт разработки и поддержки платформ (у той же 1С - в свое время про это много писалось, как сейчас не в курсе)

На прошлой работе решали подобную задачу.

Способ был примерно такой, как его описывает Водолей.
Дополнительно могу порекомендовать только как можно более четко определить границы "ядра" и планировать его развитие заранее, что бы другие группы знали - что в нем будет и когда.

Но вопрос вообще про то, не знает ли кто, где можно ознакомиться с мнением великих по данной теме.

Насколько я помню, у Леффингуэла эта ситуация рассматривается.