Возможно, я тычусь пальцем в небо, но есть такая тема, что управлять требованиями на долгоживущих продуктовых разработках далеко не то же самое, что управление на заказных разработках.

Почему? - спросите Вы. Причин может быть несколько. Вот одна из них.
Заказная разработка типично имеет одного заказчика, на то она и заказная. Следовательно весь набор требований идет точечно. Этот набор может быть противоречив, взаимокомпенсироваться или наоборот усиливать эффект. Тут искусство управления требованиями направлено на получение в конце концов полной, компромиссной, непротиворечивой спецификации, экономичного использования информации, заключенной в ней. Идеально, если все начинается с нуля, в условиях наличия специалистов и опыта. При этом есть мнение, что именно под такое управление требованиями существуют и развитые методики, методологии, инструменты и т.п.

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

Я бы назвал такую ситуацию как отраслевое решение. Сначала некая компания сумела придумать и организовала свое решение. Заложила платформу развития и научилась использовать это решение для ведение своего бизнеса. Потом в какой-то счастливый момент, компания поделилась своим решением (понятно не бесплатно) с кем-то еще из своей ниши. И так шаг за шагом, некое решение превратилось в специализированный отраслевой продукт. Разработчики этого продукта пытаются сделать продукт достаточно универсальным, ведь ведение бизнеса даже в одной отрасли может быть весьма разнообразным. В итоге могут формироваться очень противоречивые пожелания, причем отследить, понять и предсказать, что в результате реализации это может потребовать иногда просто героических усилий и магической изворотливости, заранее часто не удается.
При этом следует учесть исторические условия развития продукта, если в начале не видели большой потребности в качественной фиксации и грамотном управлении требований, то впоследствии это стало большой проблемой. Пытаться восстановить требования - практически непосильная и экономически невыгодная задача? Начать систематическую фиксацию требований и решений по новым задачам - так же неэффективно, так как все задачи вырастают из старых и чисто с нуля мало, что начинается.

Нельзя сказать, что ничего не делается в этом направлении: задачи документируются в виде wiki статей, электронных документов, работ в системах управления проектами. Существует постоянная передача и накопления информации и знаний внутри команды через опыт, общение, обсуждение, понимание основ бизнеса, контекста. Может этого и достаточно?

Эдуард, как ни странно, но я сейчас косвенно столкнулся с подобной задачей (управление требованиями в долгоиграющем заказном проекте) и не могу для себя определить, как лучше-то сделать. СУТ не используем, но есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.

На данный момент начал лишь систематизировать всю документацию на длительном проекте, в котором принимаю участие (вся документация - множество ТЗ на выполнение определённых задач по разработке новой функциональности). Мною была написана единая инструкция по управлению документами, а также создан реестр документации по этому проекту. Инструкция, реестр и прочие полезные документы лежат в одном месте, все участники проектной команды могут ими коллективно пользоваться и править в случае необходимости. Шаг в оптимизации работы команды сделан. С чего-то нужно ведь начинать

Кстати, думаю в ближайшее время поделиться этим опытом организации и написать развернутый пост в своём блоге.

Возможно и достаточно.
Иногда просто времени не хватает , отследить все в долгом проекте.
Может быть проще, если такое возможно, разбить по модулям или функционалу. И уже там описывать.
И все равно отраслевое решение для каждого свое.

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

Это скорее вопрос ведения компетенции по проекту. Если хочется оторвать компетенцию от команды и участников проекта, то можно вводить дополнительные инструменты. Только надо учитывать, что накладные в таком случае на работу появляются  и достаточно большие, поскольку необходимо отслеживать связные требования, устанавливать связи и все такое прочее.
Из собственного опыта: мы ситуацию с противоречивыми требованиями решали введением итераций разработки (версий). Версия должна быть обозрима, но при этом достаточно длительна для удобства разработчиков. Длительность версии определяется исходя из набора требований-изменений, которые могут быть оценены на непротиворечивость и реализуемость.
Процедура планирования включала два этапа:
1. Выбор из всего набора нереализованных требований самых важных и необходимых. При этом все требования фиксировались в беспрерывном режиме, а отсечение дубликатов и откровенно лишних происходило на этом этапе.
2. Оценка для реализации на совместимость и возможность принципиальной реализации. Здесь же появлялись и оценивались сроки.

Эдуард, ты сильно затронул тему, которую я заявил на ЛАФ'12
Если есть желание, то можем обсудить или объединить усилия, я тебе вышлю свои наработки на выходных.

Эдуард, ты сильно затронул тему, которую я заявил на ЛАФ'12
Если есть желание, то можем обсудить или объединить усилия, я тебе вышлю свои наработки на выходных.

Извини, я не хотел Высылай было бы интересно обсудить.

СУТ не используем, но есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.

У нас не прижилось, хотя сделали довольно обширную работу по фиксации требований.

Кстати, думаю в ближайшее время поделиться этим опытом организации и написать развернутый пост в своём блоге.

будет интересно почитать.

И все равно отраслевое решение для каждого свое.

В нашем случае оно единое. У нас система как ДНК или РНК (биологам виднее). Заложены все возможности. В определенной среде проявляются нужные свойства

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

Да вы правы:
Проект: с 1997 года
Контролируемый процесс релизов с 2007 года.
Количество релизов 20 (угадали)
Контролируемый процесс работы с требованиями с 2008
ну и далее по тексту примерно так же

Это скорее вопрос ведения компетенции по проекту. Если хочется оторвать компетенцию от команды и участников проекта, то можно вводить дополнительные инструменты. Только надо учитывать, что накладные в таком случае на работу появляются  и достаточно большие, поскольку необходимо отслеживать связные требования, устанавливать связи и все такое прочее.

Да, конечно, мы это понимаем.

Из собственного опыта: мы ситуацию с противоречивыми требованиями решали введением итераций разработки (версий). Версия должна быть обозрима, но при этом достаточно длительна для удобства разработчиков. Длительность версии определяется исходя из набора требований-изменений, которые могут быть оценены на непротиворечивость и реализуемость.
Процедура планирования включала два этапа:
1. Выбор из всего набора нереализованных требований самых важных и необходимых. При этом все требования фиксировались в беспрерывном режиме, а отсечение дубликатов и откровенно лишних происходило на этом этапе.
2. Оценка для реализации на совместимость и возможность принципиальной реализации. Здесь же появлялись и оценивались сроки.

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

есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.

У нас была попытка все требования положить в одну общую систему. Пробовали на эту роль все системы, использующиеся разными проектными командами: Sparx EA, MS TFS, SharePoint. В результате пока отказались от такой унификации, т.к. для каждого проекта используемая в настоящее время система в определенномо смысле оказалась "оптимальной", и команды не сочли  проигрыш в удобстве и необходимости перехода в дургую систему стоящим выигрыша от унификации СУТ, хотя с наличием плюсов от такой унификации все согласились.

Пробовали на эту роль все системы, использующиеся разными проектными командами: Sparx EA, MS TFS, SharePoint.

SharePoint пробовали именно как средство коллективной работы с проектной документацией? Правильно ли понимаю? Насколько я знаю, именно функционала управления требованиями в SharePoint нет.

На SharePoint достаточно легко делать кастомные списки, в которых удобно хранить требования и отслеживать их статусы и взаимосвязи. Не так круто, как в специализированном софте, но 80% участников процесса "управления требованиями" это устраивает. Поскольку у нас демократия, то 80% довольных побеждают 20% недовольных

Поскольку у нас демократия, то 80% довольных побеждают 20% недовольных

а я слышал, что при демократии должно быть наоборот. Мол демократия должна защищать меньшество, а большинство и так себя защитит

На SharePoint достаточно легко делать кастомные списки, в которых удобно хранить требования и отслеживать их статусы и взаимосвязи. Не так круто, как в специализированном софте, но 80% участников процесса "управления требованиями" это устраивает. Поскольку у нас демократия, то 80% довольных побеждают 20% недовольных

Можно ли привести примеры применения Sharepoint для этих целей? Лучше всего со скриншотами.

p.s. Мы используем SP как репозиторий документов, в т.ч. с возможностью совместного редактирования.

На SharePoint достаточно легко делать кастомные списки, в которых удобно хранить требования и отслеживать их статусы и взаимосвязи. Не так круто, как в специализированном софте, но 80% участников процесса "управления требованиями" это устраивает. Поскольку у нас демократия, то 80% довольных побеждают 20% недовольных

Понял. Но всё-таки был бы благодарен, если бы вы дополнительно привели пример. Сейчас я использую SharePoint на своём проекте только как хранилище документов.

Кстати, думаю в ближайшее время поделиться этим опытом организации и написать развернутый пост в своём блоге.

Как и обещал: http://it-analysis.blogspot.com/2012/02/blog-post.html

Сейчас я использую SharePoint на своём проекте только как хранилище документов.

В SharePoint есть такая конструкция, как список, это типа таблицы записей с полями разных типов. В частности, поле может быть гиперссылкой, в которой можно хранить ссылку, например, на требование более высокого уровня, или на DOC файл с BRS или SRS, хранящийся в библиотеке документов того же Share Point.
В общем то, в списке SharePoint  можно реализовать многое из того, что можно реализовать в Work Item TFS, кроме сложного workflow и многостраничных форм с полями хитрых типов.

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