Столкнулся с проблемой убедить начальство\заказчика\маму\папу ... в том, что нормально выстроенный Процесс Управления Требованиями (ПУТ) это действительно нужно. Или как говорят небезызвестные нам консультанты -- what is the value of requirements management process?

Попытался сформулировать преимущества и риски, которые дает выстроенный ПУТ, но и они не дали результата. Давайте вместе подумаем, что можно придумать еще и переформулировать что есть.

4.   Преимущества внедрения процесса и средства Управления  Требованиями.
Ниже описаны все преимущества дающие внедрение процесса и средств Управления Требований.
4.1.   Внедрение регламентов по управлению требованиями позволит уменьшить время, требуемое на процесс анализа и всю разработку ПО в целом.
4.2.   Применение внедряемых техник сбора, анализа и документирования требований позволит разрабатывать ПО, наиболее полно отвечающее всем требованиям Заказчика. Что в итоге позволит сократить время разработки ПО
4.3.   Правильная организация требований позволит использовать требования и разработанные решения вторично, что сильно сократит время разработки .
4.4.   Полное описание требований и правильная их организация позволит более точно планировать разработку ПО.
4.5.   Полная база знаний (требования) ПО позволит делать более правильные стратегические решения по совершенствованию существующего ПО, разработки нового или интеграции ПО, имеющегося в наличии.
4.6.   Организация доступа, сохранности и версионности требований с помощью СУТ позволит уменьшить время разработки ПО и избежать ситуации работы с неактуальными требованиями. Кроме того, будет всегда известно – кто и по какой причине сделал изменения в требованиях, что увеличит контроль над процессом анализа.
4.7.   Совершенствование процессов целеполагания позволит разрабатывать ПО, которое будет помогать конечному Заказчику в достижении бизнес цели и автоматизировать наиболее необходимые и трудоемкие задачи.
4.8.   Правильное документирование и организация требований позволит легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект.
4.9.   Правильное документирование и организация требований позволит улучшить качество требований, чтобы они стали более понятные, однозначные и тестируемые. Что в конечном итоге повысит качество создаваемого ПО.
4.10.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и конечными Заказчиками. Что в итоге уменьшит время, требуемое на согласование требований.
4.11.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и всеми членами команды разработки (Архитекторы, Разработчики и Тестировщики). Что в итоге позволит уменьшить время разработки и повысит качество ПО.
4.12.   Организация трассировки позволит понять – как одно требование влияет на другие и обнаружить ситуацию, когда требования определены не полностью. Данное преимущество позволит уменьшить время, требуемое на изменение требований, и описывать требования наиболее полно.
4.13.   Визуализация требований (моделирование) позволяется облегчить процесс понимания требований в целом и в деталях.
4.14.   СУТ позволит оптимально распределить права и обязанности между всеми задействованными лицами в проекте и обеспечит работу множества участников над многими проектами.

5.   Риски внедрения процесса Управления Требованиями.
Ниже представлен список возможных рисков при внедрении процесса Управления Требований. Данных рисков можно избежать, если правильно выстроить предлагаемый процесс.
5.1.   Требования должны быть известны всем участникам проекта
5.2.   В процесс анализа не должно быть вложено слишком много усилий
5.3.   Не следует быть через чур формальным с требованиями и спецификациями
5.4.   Не следует быть слишком не формальным
5.5.   Требования не должны быть слишком длинные и скучные для всех заинтересованных лиц, участвующих в процессе создания ПО

З.Ы. Следующим шагом должен быть описанный регламент УТ.

Проблема в том, что мы (я) не можем сказать количественные показатели оптимизации при внедрении ПУТ, т.е. не можем сказать точно, что время разработки снизится на столько, затраты уменьшаться на столько и т.д. Т.е. результат нельзя пощупать. Или можно???

Цена ошибки при выявлении некорректных требований на стадии их формализации и анализа в 200 раз ниже чем ошибка, обнаруженая в коде.

Эд,

Ну прямо слоган Может сделать данную фразу девизом сайта???

По делу - т.е. ты можешь гарантировать, что время разработки уменьшиться в 200 раз или кол-во ошибок уменьшится в 200 раз?? Т.е. после того как мы перейдем от того, что ТЗ писали как хотят и где хотят, в нормальный процесс, то мы в 200 (или меньше - цифра) снизим издержки??
Данный факт не убедит потенциального заказчика. Ну пишут они ща как-то ТЗ, а ты приходишь и говоришь - в 200 раз. А он - за счет чего??

Можно еще здесь посмотреть http://cmcons.ru/articles/upravlenie_trebovanijami_instrument_ibm_rational_r/rol_protsessa_upravlenija_trebovanijami_pri_razrabotke_slozhnykh_programmnykh_sistem_praktika_primenenija_metodologii_ibm_rup_i_instrumenta_ibm_rational_requisitepro/
И другие статьи с этого сайта. Новичков правда больше пропагандирует процесс управления конфигурациями, но у него хорошая подборка аргументов, проанализировав их, можно и на требования переложить

Вот еще, кстати, нашел:
Achieving ROI with Rational Requirements Management Tools
или ее перевод:
Эффективность от внедрения в финансовом выражении. Часть 1: Окупаемость инвестиций при использовании инструментов Rational для управления требованиями

Эд,

Ну прямо слоган Может сделать данную фразу девизом сайта???

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

По делу - т.е. ты можешь гарантировать, что время разработки уменьшиться в 200 раз или кол-во ошибок уменьшится в 200 раз?? Т.е. после того как мы перейдем от того, что ТЗ писали как хотят и где хотят, в нормальный процесс, то мы в 200 (или меньше - цифра) снизим издержки??
Данный факт не убедит потенциального заказчика. Ну пишут они ща как-то ТЗ, а ты приходишь и говоришь - в 200 раз. А он - за счет чего??

Нет я говорил о цене стоимости ошибки
Цена ошибки и затраты на ее выявление и устранения в 200 раз меньше чем на стадии кодирования, т.е. если не управлять и сопровождать требования, то веротяность ошибки крайне высока как и цена ее устранения.
Говорить же о том что количество ошибок уменьшится в 200 раз - совершенно нельзя

Эд,

Ну это понятно. Я просто так уж для смеха сказал про 200 раз. Эти 200 надо умножить на вероятность возникновения ошибки и м.б. на что-то еще. В общем математика не для слабых умов и главное не доказуемо и не факт, что достижимо.

Мне нужны количественные показатели уменьшения издержек, увеличения скорости разработки, еще чего-то, чтобы это было осязаемо. Пока что тут осязаемо только одно - затраты на внедрения ПУТ.

Саша, для тог чтобы сделать это осязаемым, нужно четко выделить критерии и сопоставить им количественные характеристики.
1 Скажем - время ввода в курс дела нового работника
2 время затрачиваемое на проверку требований рецензентом до и после
3. процент выялвения ошибко при обычном рецензировании и с СУТ
4. время подготовки отчетов по требованиям и т.п.

Для начал нужно выделить все наиболее часто осуществляемые операции. Оценить времязатраты до и после

естествено есть качественные моменты - но они как раз должны идти от качеств самих требований

Нужно добавить еще один момент -- требования по сути это scope проекта. Когда scope неясно очерчен, то не понятно где заканчивается проект, что чревато особенно при fixed price ...
А вообще забавная ситуация -- многие ИТ-руководители не могут посчитать бизнес-value от ИТ у себя в компании, но требуют этого от своих поставщиков тулов и услуг :-). А вообще, считать экономический эффект от внедрения процессов можно только если у компании вообще есть статистические данные -- например то же распределение дефектов ПО по их причинам, средняя стоимость одного дефекта ... и вообще как эта компания измеряет качество и какие заданные параметры качества ПО у нее есть. Если компания не задумывается об измерении качества ПО, не задумывается о метриках своей работы как таковых (т.е. говорим что у компании низкий уровень зрелости), то скоре всего ей не нужно улучшать процессы в принципе. А если в компании сидит 5 программистов и нет ни одного аналитика, то разработчикам бесполезно предлагать работу с требованиями. Максимум, что им можно предложить, так это использовать bag tracker.

Для начал нужно выделить все наиболее часто осуществляемые операции. Оценить времязатраты до и после

Супер, это как?? Т.е. приходишь к заказчику и говоришь, давай я вам внедрю ПУТ, выделим ключевые показатели, и померим до и после и посмотрим что получится???
А вообще ключевые показатели надо выделить. Этим и займусь на днях.

Супер, это как?? Т.е. приходишь к заказчику и говоришь, давай я вам внедрю ПУТ, выделим ключевые показатели, и померим до и после и посмотрим что получится???
А вообще ключевые показатели надо выделить. Этим и займусь на днях.

А причем тут заказчик? Ему то это вообще зачем? Или я чего-то не понял

Юра,

Еще бы не плохо если бы ты сказал эти "мерительные" показатели, или сказал бы где почитать ...

А причем тут заказчик? Ему то это вообще зачем? Или я чего-то не понял

Заказчик в данном случае - руководство компании (внешней или внутренний), где ты собираешься внедрять ПУТ, т.е. сама компания является разработчиком софта, а ты типа модный консультант.

т.е. сама компания является разработчиком софта, а ты типа модный консультант.

ААААА, хм ну тут наверное нужно иметь чутье менеджера по продажам, ну и написать парочку диссертаций или может купить какой-нить аналитический обзор на тему. Хотя ясно - что нужно как-то оценить внедрение и подсчитать прибыль, где-то на просторах рунета я видел статью, как раз посвященную именно твоей проблеме. Там писалось о том, как некая компания проводила внедрение СУТа и вообще ставлиа процесс разработки и делилась опытом того как это делать быстро - вернее рекламировала что умеет делать это быстро и четко, там же описывались пробемы, риски и способы их избежать - но не помню