Форум Сообщества Аналитиков

×


Как оценить внедрение СУТ? ROI (Return on Investment)(Прочитано 30152 раз)
Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

Сейчас используем JIRA + Confluence + SVN.
Требования в виде вордовских файлов хранятся в свн.
По требованиям ставятся задачи в JIRA.
При изменении требований/появлении новых ставятся новые задачи в JIRA, в т.е. на доработку ТЗ/документации.
Confluence используем как дополнительный, справочный материал.
« Последнее редактирование: 14 Июня 2013, 00:55:41 от Trigger »



Re: Как оценить внедрение СУТ? Ответ #1 : 13 Июня 2013, 13:46:53
сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:30:53 от pmle »
Ставлю крестики на ноликах © pmle



Re: Как оценить внедрение СУТ? Ответ #2 : 13 Июня 2013, 16:11:14
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.
Ой, как хорошо, наконец-то с кого-то это стали требовать...
Внедрение СУТ ничем не отличается от внедрения другой программы автоматизации или разработки софта на начальном этапе. Поэтому я также рекомендовал бы начать с ЗЛ и проблем.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Как оценить внедрение СУТ? Ответ #3 : 13 Июня 2013, 16:45:49
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

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

Вот так и оцените: было - стало (разница). В этом вообще говоря смысл постановки задачи - не выдвигай непроверяемые требования (см. библию папы нашего Вигерса).



Re: Как оценить внедрение СУТ? Ответ #4 : 13 Июня 2013, 18:26:30
ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

  • Какие задачи выбрать для измерения? Они должны быть идентичны.
  • На ком проводить измерения? Должны быть одни и те же люди.
  • Как определить погрешность?
  • Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)
pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.


Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:
  • Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
  • Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
  • Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
  • Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
  • При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.

p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?

p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?
« Последнее редактирование: 13 Июня 2013, 18:43:41 от Trigger »



Re: Как оценить внедрение СУТ? Ответ #5 : 13 Июня 2013, 21:04:36
Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Что-то я не понял перехода — только задумались, а уже надо делать пилотный проект.
Как так? Те, кто задумались, чего ожидают от неё? В чём и почему думают она поможет?



Re: Как оценить внедрение СУТ? Ответ #6 : 13 Июня 2013, 21:19:41
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
Вы хотите автоматизировать процесс или операции?
Если процесс, то у процесса можно определить его показатели.
У вас процесс УТ уже есть? Зачем он нужен?
Как вы меряете его эффективность сейчас?
Если не меряете, то зачем асфальтировать дороги, по которым ходят коровы?

Подсказки:
Время согласования требований — это показатель процесса разработки требований, а не управления.
Количество согласований — тоже.

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

Денежные потери, возникшие в результате ошибочных решений о рамках релизов и итераций — вполе себе показатель процесса управления требований.



Re: Как оценить внедрение СУТ? Ответ #7 : 14 Июня 2013, 12:45:25
ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

  • Какие задачи выбрать для измерения? Они должны быть идентичны.
  • На ком проводить измерения? Должны быть одни и те же люди.
  • Как определить погрешность?
  • Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)

Эээ, а почему вы задаете эти вопросы на форуме, а не самим себе? ) Вы же инициатор внедрения - значит, вы знаете, какие именно параметры вас не устраивают в текущем состоянии. Если вы не знаете, тогда зачем вам что-то внедрять?



Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

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

Управление требованиями затрагивает все процессы, связанные с разработкой ПО, и каждый из них нужно оценивать. С требованиями работают, как минимум:
- аналитики, которые их разрабатывают;
- руководители проектов (собственно, управление требованиями - это их задача);
- разработчики, которые их реализуют;
- тестировщики, которые проверяют реализацию.

У всех этих людей свои процессы, а у каждого процесса свои показатели.

В первую очередь внедрение СУТ должно сказаться на качестве. Здесь есть где развернуться с показателями, потому что в области оценки качества их изобретено много. Наверняка у вас какие-то уже есть.

Конечно, для оценки хочется взять цифры "до" и "после" и сравнить. Но на практике, во-первых, чтобы иметь цифры "до", нужно, чтобы какая-то статистика уже была. Если у вас есть какие-то верхнеуровневые показатели, полученные от взаимодействия с заказчиком (количество запросов на изменения, рекламаций на неправильно реализованные или нереализованные требования и т. п.), то имеет смысл их использовать.

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

Самый очевидный профит от внедрения СУТ получит менеджер проекта (условное название, в разных компаниях это могут быть разные роли), которому управление требованиями даёт в руки множество новых показателей для оценки и управления, например:
- готовности продукта (процент реализованных требований - правда, при условии, что вам удастся полностью покрыть разрабатываемую функциональность документированными требованиями);
- протестированности продукта (процент выполненных тестов - в дополнение к предыдущему условию нужно, чтобы тест-кейсы тоже разрабатывались по требованиям, а не "сами по себе");
- временные оценки на разработку и тестирование - начнут работать после набора более-менее адекватной статистики по оценочной и реальной трудоёмкости работ по разработке, реализации и тестированию требований.

Но все эти показатели будут адекватными реальности только если действительно удастся внедрить управление требованиями во все перечисленные процессы. Все эти люди должны начать действительно использовать СУТ в своей работе.
« Последнее редактирование: 16 Июня 2013, 20:13:47 от greesha »
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

  • Какие задачи выбрать для измерения? Они должны быть идентичны.
  • На ком проводить измерения? Должны быть одни и те же люди.
  • Как определить погрешность?
  • Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)
pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.


Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:
  • Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
  • Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
  • Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
  • Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
  • При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.

p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?

p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?

1. СУТ не предназначена для управления задачами, она позволяет создавать (точнее фиксировать) и эффективно управлять требованиями (и их изменениями)
2. Преимущества СУТ в т.ч. лежат в: возможности проведения анализа влияния (матрицы трассировки требований), быстрая генерация формальной документации требований (с учетом версионирования требований), контроль изменений требований (кто, когда и почему изменил), возможность коллективной работы над требованиями (но это можно решить и с использованием SharePpoint, например). Другой вопрос, как у вас поставлен процесс разработки и управления требованиями ... некоторые преимущества ценны будут для вас, а некоторые - нет. Кроме этого, не следует исключать такой аспект, как повышение уровня зрелости процессов разработки ПО в целом, с использованием СУТ. Как оценить - можно посмотреть посмотреть на ту же goals/practices в CMMI (REQM)
3. Согласовывать имеет смысл не отдельные требования, а требования к конкретному релизу (в совокупности). Это делать проще (согласовать документ и получить по нему замечания). Не думаю, что вы заставите заказчиков использовать СУТ для этого ... хотя бывают исключения.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:31:00 от pmle »
Ставлю крестики на ноликах © pmle



Юрий, не могу согласиться.
Управлять задачами в СУТ очень удобно. Иллюстрации и пояснения здесь: http://edu.reqcenter.pro/?p=4206

Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:31:05 от pmle »
Ставлю крестики на ноликах © pmle



Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).

TFS - это действительно полноценная СУТ. С управлением требованиями там всё в порядке. ALM Rangers вон целую книгу написали про управление требованиями в TFS http://vsartfsreguide.codeplex.com/

Вот с разработкой требований в TFS не очень, но это решается. Ира Сурова на ЛАФ будет рассказывать, как они скрестили TFS и Enterprise Architecht. Кроме того, ходят упорные слухи, что TFS будет интегрироваться с Borland CaliberRM.

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



более того, скажу вам по секрету, что IBM нашли способ поженить TFS и RRC(rational requisite composer) из их платформы Jazz :)
Штатные средства трассирования TFS - это выгрузка айтемов в excel. как говорится, на безрыбье и рак рыба, но это полный треш.

Для себя я нарисовал такую картину СУТ+TFS:
По факту получаются независимые подсистемы ALM: в СУТ аналитики формализуют, создают и управляют требованиями и делают постановку задачи архитектуре или сразу разработчику(в зависимости от ролей и принятого техпроцесса), а архитекторы, разработчики и тестирование ведут управление заданием уже в TFS. Таким образом аналитик выступает в роли заказчика для архитектуры и разработки(в ролевой модели проекта).

По сабжу,
мы, когда ROI на внедрение СУТ подготавливали у нас отбив стоимости продукта внедрения был 3 года с 30% приростом производительности.
по расчёту ROI в интернете полно информации + Юрий хороший пост написал
« Последнее редактирование: 18 Июня 2013, 18:33:08 от Мухо »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19