Просмотр сообщений
1381
Системный Анализ и Требования / Управление требованиями на долгоживущем проекте
« : 16 Февраля 2012, 23:38:30 »
Возможно, я тычусь пальцем в небо, но есть такая тема, что управлять требованиями на долгоживущих продуктовых разработках далеко не то же самое, что управление на заказных разработках.
Почему? - спросите Вы. Причин может быть несколько. Вот одна из них.
Заказная разработка типично имеет одного заказчика, на то она и заказная. Следовательно весь набор требований идет точечно. Этот набор может быть противоречив, взаимокомпенсироваться или наоборот усиливать эффект. Тут искусство управления требованиями направлено на получение в конце концов полной, компромиссной, непротиворечивой спецификации, экономичного использования информации, заключенной в ней. Идеально, если все начинается с нуля, в условиях наличия специалистов и опыта. При этом есть мнение, что именно под такое управление требованиями существуют и развитые методики, методологии, инструменты и т.п.
Продуктовая разработка отличается тем, что либо заказчиков много, и разработчик берет на себя смелость интеграции разнородных требований, либо он просто предлагает и диктует свое видение продукта, а уже покупатель оценивает качество такого видение рублем. Я в первую очередь хочу обратить внимание на такой продукт, который вряд ли будет продаваться как пирожки, кроме того помимо ценности самого продукта, важна и ценность послепродажной перманентной поддержки.
Я бы назвал такую ситуацию как отраслевое решение. Сначала некая компания сумела придумать и организовала свое решение. Заложила платформу развития и научилась использовать это решение для ведение своего бизнеса. Потом в какой-то счастливый момент, компания поделилась своим решением (понятно не бесплатно) с кем-то еще из своей ниши. И так шаг за шагом, некое решение превратилось в специализированный отраслевой продукт. Разработчики этого продукта пытаются сделать продукт достаточно универсальным, ведь ведение бизнеса даже в одной отрасли может быть весьма разнообразным. В итоге могут формироваться очень противоречивые пожелания, причем отследить, понять и предсказать, что в результате реализации это может потребовать иногда просто героических усилий и магической изворотливости, заранее часто не удается.
При этом следует учесть исторические условия развития продукта, если в начале не видели большой потребности в качественной фиксации и грамотном управлении требований, то впоследствии это стало большой проблемой. Пытаться восстановить требования - практически непосильная и экономически невыгодная задача? Начать систематическую фиксацию требований и решений по новым задачам - так же неэффективно, так как все задачи вырастают из старых и чисто с нуля мало, что начинается.
Нельзя сказать, что ничего не делается в этом направлении: задачи документируются в виде wiki статей, электронных документов, работ в системах управления проектами. Существует постоянная передача и накопления информации и знаний внутри команды через опыт, общение, обсуждение, понимание основ бизнеса, контекста. Может этого и достаточно?
Почему? - спросите Вы. Причин может быть несколько. Вот одна из них.
Заказная разработка типично имеет одного заказчика, на то она и заказная. Следовательно весь набор требований идет точечно. Этот набор может быть противоречив, взаимокомпенсироваться или наоборот усиливать эффект. Тут искусство управления требованиями направлено на получение в конце концов полной, компромиссной, непротиворечивой спецификации, экономичного использования информации, заключенной в ней. Идеально, если все начинается с нуля, в условиях наличия специалистов и опыта. При этом есть мнение, что именно под такое управление требованиями существуют и развитые методики, методологии, инструменты и т.п.
Продуктовая разработка отличается тем, что либо заказчиков много, и разработчик берет на себя смелость интеграции разнородных требований, либо он просто предлагает и диктует свое видение продукта, а уже покупатель оценивает качество такого видение рублем. Я в первую очередь хочу обратить внимание на такой продукт, который вряд ли будет продаваться как пирожки, кроме того помимо ценности самого продукта, важна и ценность послепродажной перманентной поддержки.
Я бы назвал такую ситуацию как отраслевое решение. Сначала некая компания сумела придумать и организовала свое решение. Заложила платформу развития и научилась использовать это решение для ведение своего бизнеса. Потом в какой-то счастливый момент, компания поделилась своим решением (понятно не бесплатно) с кем-то еще из своей ниши. И так шаг за шагом, некое решение превратилось в специализированный отраслевой продукт. Разработчики этого продукта пытаются сделать продукт достаточно универсальным, ведь ведение бизнеса даже в одной отрасли может быть весьма разнообразным. В итоге могут формироваться очень противоречивые пожелания, причем отследить, понять и предсказать, что в результате реализации это может потребовать иногда просто героических усилий и магической изворотливости, заранее часто не удается.
При этом следует учесть исторические условия развития продукта, если в начале не видели большой потребности в качественной фиксации и грамотном управлении требований, то впоследствии это стало большой проблемой. Пытаться восстановить требования - практически непосильная и экономически невыгодная задача? Начать систематическую фиксацию требований и решений по новым задачам - так же неэффективно, так как все задачи вырастают из старых и чисто с нуля мало, что начинается.
Нельзя сказать, что ничего не делается в этом направлении: задачи документируются в виде wiki статей, электронных документов, работ в системах управления проектами. Существует постоянная передача и накопления информации и знаний внутри команды через опыт, общение, обсуждение, понимание основ бизнеса, контекста. Может этого и достаточно?
так уж и называйте это не ЛАФ, а Тусовочкой, зачем народ дезинформировать?