Всем добрый день. Хотелось бы обсудить тему рисков, связанных с выяснением и разработкой требований. По опыту - фактически на любом проекте они "выстреливают".
Есть ли практические приемы приоретизации и оценки этих рисков Особенно интересует методы количественной оценки - т.е. как такие "субъективные" риски - например, недоступность стэйкхолдеров или противоречия между ними - как их оценить количественно в человекочасах?

Есть ли практические приемы приоретизации и оценки этих рисков Особенно интересует методы количественной оценки - т.е. как такие "субъективные" риски - например, недоступность стэйкхолдеров или противоречия между ними - как их оценить количественно в человекочасах?

Недоступость заинтересованных лиц (или сложность привлечения экспертов) можно оценивать по стоимости в рублях. В эту стоимость может входить зарплата эксперта (выраженная в часах), стоимость организации встречи (например стоимость перелета, стоимость проживания в гостинице).
Также можно изначально ввести вербальные оценка, аля
1. Сидит рядом/в одном здании/городе/ в другом  городе/другой стране
2. Доступен по почте/телефону/скайпу/для встречи....
3. Готов уделять N времени на работу с требованиями
4. тд

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

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

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

1. Исходная оценка трудоемкости на аналитическую фазу делались из предположения, что мы описываем бизнес процессы, а в итоге потребовалась детализация до функциональных требований, что вызывает необходимость дополнительных интервью и доработки документов;
2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;
3. Задержка рецензий согласующими (почти месяц с даты отправки);
4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика)
5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);

Сейчас стоит вопрос касательно того, как оценить (в часах работы нашего эксперта, т.е. нужна конкретная количественная оценка) прирост трудозатрат по каждому из пунктов.

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

Плохая работа аналитика. Либо аналитик вообще не привлекался для оценки трудозатрат (если продолжать в таком духе, эти риски у вас и дальше будут "выстреливать").
Мы его называли "нечеткими требованиями" и закладывали некоторый объем (20%, 30%, 50% - в зависимости от исходных данных) на их детализацию.

2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;
3. Задержка рецензий согласующими (почти месяц с даты отправки);
4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика)

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

5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);

См. п.1.
Рихтуйте аналитиков, иначе будете еще долго делать открытия

А Вам нужно сделать оценку уже свершившихся переработок или на будущее?

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

А что в договоре написано, надо сделать описания БП или функциональные требования? Если просят сделать больше, чем в договоре - оценивайте затраты и подписывайте допсоглашение за отдельные деньги. Если уже сделали бесплатно - значит вы это сделали бесплатно, какой смысл теперь оценивать затраты?

2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;

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

3. Задержка рецензий согласующими (почти месяц с даты отправки);
4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика)

Надо как в шахматах: передали документ заказчику - на его часах время пошло. Заказчик вернул документы: на ваших время пошло. Протоколы передачи надо подписывать. Если не было протоколов, то сейчас вряд ли чего добьетесь.

5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);

Ну так и хорошо: вслед за этим переработайте и расширьте калькуляцию за свои услуги.

Сейчас стоит вопрос касательно того, как оценить (в часах работы нашего эксперта, т.е. нужна конкретная количественная оценка) прирост трудозатрат по каждому из пунктов.

ИМХО, так же, как вы оценивали изначальные трудозатраты. Был один перечень работ - вы оценили затраты. Сейчас другой перечень - просто оценивайте теперь исходя из него.

А Вам нужно сделать оценку уже свершившихся переработок или на будущее?

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

Div, спасибо, согласна со всеми комментами. Да, прощелкали эти риски при оценке, теперь трудно что-то с этим поделать. Зато есть опыт на будущее
По поводу задержек обратной связи от Заказчика - да, есть проектный регламент (рецензия предоставляется в течение 2х бизнес-дней, комменты инкорпорируются тоже в течение 2х). Но на практике регламент невозможно исполнять - причем по объективным соображениям (например, если документ из 100 страниц, то на одно только вдумчивое прочтение требуется как минимум 1 БД. Если согласующих 5 человек, например, и они предоставляют консолидированный комментарий). Поэтому к регламенту есть много оговорок и оправданий, которые позволяют тянуть с рецензированием и согласованием. Все эти факторы невозможно (или очень трудно) заранее предусмотреть, описать и придумать на каждый из них адекватные policies.
По поводу формулировке в контракте - да, мы подписывались именно на описание бизнес-процессов, и это явно фигурирует в договоре. Сейчас это, по-видимому, единственная зацепка. Но тут явно развернется идеологический спор по поводу того, что считать описанием БП, а что функциональными требованиями - грань действительно иногда очень тонкая.


 

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

Изначально не верно определен scope проекта. Косяк не столько аналитика, сколько PM-а и продавца проекта.

2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;

Косяк PM-а ... аналитики тут не причем. Изначально с заказчиком не проговорили состав рабочей группы по проекту и не нарисовали RACI charts.

3. Задержка рецензий согласующими (почти месяц с даты отправки);
4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика)

Задача PM-а пинать заказчика. Косяк PM-а, в договоре не определены сроки согласования документов.

5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);

scope creep .. классическая проблема управления проектом. При чем тут аналитик?

Сейчас стоит вопрос касательно того, как оценить (в часах работы нашего эксперта, т.е. нужна конкретная количественная оценка) прирост трудозатрат по каждому из пунктов.

Как вариант, можно попробовать использовать применяемую в agile коллективную технику "poker cards", по оценке сложности (или сразу трудоемкости) реализации тех или иных фич. В некоторой модификации она вполне может быть применима для решения данной задачи.

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

А если уже случилось и переработка была сделана - в чем проблема оценить трудозатраты на переработку? Просто сели и посчитали по каждому БП...

По поводу формулировке в контракте - да, мы подписывались именно на описание бизнес-процессов, и это явно фигурирует в договоре. Сейчас это, по-видимому, единственная зацепка. Но тут явно развернется идеологический спор по поводу того, что считать описанием БП, а что функциональными требованиями - грань действительно иногда очень тонкая. 

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

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

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

Предлагаю свои 5 копеек:

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

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

2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;

В следующий раз пишите в уставе проекта роли/обязанности, включая согласующих лиц и ЛПР. Изменение устава - пересмотр границ, а значит, сроков и бюджета.

3. Задержка рецензий согласующими (почти месяц с даты отправки);

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

4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика) 

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

5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);

Это чистое расширение границ. Тут надо вам, действительно, ставить проектное управление.

Сейчас стоит вопрос касательно того, как оценить (в часах работы нашего эксперта, т.е. нужна конкретная количественная оценка) прирост трудозатрат по каждому из пунктов.

Если работы уже выполнены, то в чем проблема? В будущем надо заставить эксперта вести таймшит. Сейчас, пусть эксперт экспертно оценит, сколько куда потратил.


Вот. И еще: мои списки рисков в аналитических работах есть тут: http://boatmanshome.ru/cgi-bin/page.pl?21dev_005.page

При этом, если заказчик невменяем и откажется серьезно обсуждать устав, реалистичные графики и процедуры управления проектом - тут надо брать бутылку коньяка и ехать в баню с их самым главным ЛПР. А  бюджет проекта умножать на коэффициент, существенно превышающий 2.