Тема навеяна сообщением Виталия Григораша о выпуске им журнала для аналитиков с подборкой на тему "Изменения требований".

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

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

Как обстоит с этим дело у вас в проектах?

Михаил, вот как Вы сказали: делать это изменение вы все равно будете. Причем это внутренняя корпоративная политика разработчика. Удовлетворить заказчика максимально. Правда анизотропный такой подход. Только для группы заказчиков

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

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

У нас на проекте принимают решение о  изменении руководители проекта. Ченж-реквесты, поступившие от заказчика фильтруются. Если "фича" действительно нужная, то приходится вносить изменения, которые влияют пусть и не на всю систему, но на отдельные модули очень сильно. Был случай, когда во время разработки поменялись законы. Пришлось полностью переделать целый модуль, причем все это в рамках ограниченных сроков и бюджета.
А вот различного рода "бантики" обычно замораживают до лучших времен. Т.е. требование есть, но скоуп у него проставлен на конечные релизы. Сейчас у нас также все требования касающиеся GUI идут низким приоритетом и в первую очередь пытаемся успеть завершить всю функциональность к поставке системы.
На счет "не знаем зачем" - это суровая правда. Дело в том, что из 10 аналитиков, требованиями управляем я (процентов на 10%), ведущий аналитик (%40) и ведущий архитектор (%50). Остальные аналитики, не совсем понимали, зачем о каждом изменении и пожелании заказчика сообщать всем. Они просто применяли запрос и вносили изменния в спеку. До разработчиков это доносилось не сразу и было очень много разногласий. Так как система большая и сроки ограничены, менеджеры не успевали отслеживать все изменения. Пришлось объяснять, внедрять жесткий процесс, заставлять его соблюдать...
Зато сейчас у нас стало меньше проблем, обо всех изменениях в требованиях сообщается ведущему аналитику, он принимает решение принимать или нет, ставит приоритеты и скоуп.
Аналитики вносят изменения в доки и оповещают ответственных программистов...

Виталий, правильно ли я Вас понял, что для вас основным критерием принятия решения является "нужность" изменения?
Т.е., допустим вам заказчик говорит: "хочу A, B, C". Вы говорите: А - не нужно, B - бантик, а вот С - "действительно нужная" фича, делаем.
А на основании чего? Как вы заказчику мотивируете, что его запросы A и B вы посчитали ерундой и отклонили?

Виталий, правильно ли я Вас понял, что для вас основным критерием принятия решения является "нужность" изменения?
Т.е., допустим вам заказчик говорит: "хочу A, B, C". Вы говорите: А - не нужно, B - бантик, а вот С - "действительно нужная" фича, делаем.
А на основании чего? Как вы заказчику мотивируете, что его запросы A и B вы посчитали ерундой и отклонили?

К сожалению я этим не занимаюсь, поэтому всех деталей работы с заказчиком я рассказать не могу. Думаю здесь вступает в силу закон "Учись говорить нет". Можно всегда объяснить, что менее важное требование можно отложить до лучших времен и сделать акцент на более важных моментах. Думаю это зависит от конкретного заказчика. Бывают "самодуры", которые бантики считаю наиболее важной фичей, чем например построение отчетов, аутентификация и тп. Можно объяснить, например, что сейчас вы сможете решать свои проблемы без данной функции, а в дальнейшем (в сл. релизах) мы обязательно это сделаем. Думаю заказчик, то же не будет рисковать тем, что у него появиться бантик, но не будет работать основная функциональность.
Преподаватель на курсах по аналитике (он сейчас ПМ), рассказывал, что прямо обрезал заказчика и говорил, что новое требование выпадает из скоупа, и что для его реализации мы либо:
1. Увеличиваем бюджет и сроки
2. Либо делаем все требования, но не отвечаем за качество, не только нового, но и остальных.

На самом деле я не совсем понял проблему у автора топика, поэтому отвечаю как могу

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

Хм..
1. А почему не надо делать расчеты? Чтобы уменьшить объем работы?
2. Если вы одновременно аналитик и ПМ, то вы возможно и в курсе "политических причин". В случае если вы обычный аналитик, то не вам принимать решать - будет ли данное требование реализовано или нет. Вы делаете заключение и передаете его ПМ-у, который уже решает сам или по согласованию с руководством.

Т.е., допустим вам заказчик говорит: "хочу A, B, C". Вы говорите: А - не нужно, B - бантик, а вот С - "действительно нужная" фича, делаем.
А на основании чего? Как вы заказчику мотивируете, что его запросы A и B вы посчитали ерундой и отклонили?

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

Михаил,

Очень нужный и своевременный вопрос. Как раз сегодня про него рассказывал ...
Действительно, если гуру Анализа говорят, что изменения неизбежны (и это в т.ч. индикатор вовлеченности и заинтересованности ЗЛ) и что нельзя сильно сопротивляться им, то зачем ими управлять!?

А вот зачем (+ к Виталию):
1. Если требования попадают в единый реестр, то их можно приоритизировать и делать наиболее важные, НЕ забывая об остальных. В этом случае легче разговаривать с Заказчиком и говорить ему, что мы ничего не забываем, а делаем сейчас наиболее важные, потом займемся и остальными. А остальные со временем могут сами отмереть или станут не такие важные как при звонке
2. Позволяет глубже проанализировать проблему, а не сразу реализовывать ее. Бывали случаи, что нужно внести изменения в отчет, а этот отчет использовался только для формирования другого, так не лучше убрать вообще первичный отчет и сразу формировать второй?!
3. Не хвататься сразу за реализацию, а накопить их и делать их скопом для одного куска и делать, так дешевле
4. Разговаривать с Заказчиком об разделении рисков между Разработчиком и Заказчиком, например 50% на 50% при появлении новых требований и возможно убедить Заказчика заплатить за фичи не входящие в скоуп. Это еще вопрос к хорошей проработке Концепции.
5. Позволяет провести Анализ ошибок, кто виноват - Аналитик, что не выявил требования или Пользователь, который хочет совершенно новую фичу. Может пересмотреть квалификацию Аналитика.
6. Если одно и тоже требования часто меняется, то есть смысл задуматься - а в чем проблема, Аналитик дурак или у Заказчика бардак (не устоялся БП), а как известно автоматизация бардака - это автоматизированный бардак. Может отложить это требование?!
7. Изменять первичные требования, а не иметь кучу ченьж реквестов и не понятно что же должна делать ИС
8. Оповещать всех участников проекта об изменении
9. Не делать одно и тоже  (например от разных Пользователей) - дважды.
10. А если у нас идет разработка коробочного ПО и оно еще кастомизируется (дорабатывается) под каждого конкретного Клиента, то все вышеперечисленные проблемы можно умножить на 10

З.Ы. У меня в практике был известен случай когда два программиста делали один и тот же (похожие) запрос на изменение и почему-то в разных кусках ИС

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

Как я понял, наиболее массово-распространенный способ управления изменениями выглядит примерно так, как описал bas:

требования попадают в единый реестр ... их можно приоритизировать и делать наиболее важные

Я ничего против такого подхода не имею, сам так делал много раз. Но для него имхо ни чейндж-реквесты, ни анализ влияния (в терминах сроков/стоимости) не нужны.

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

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

Как я понял, наиболее массово-распространенный способ управления изменениями выглядит примерно так, как описал bas:

требования попадают в единый реестр ... их можно приоритизировать и делать наиболее важные

Я ничего против такого подхода не имею, сам так делал много раз. Но для него имхо ни чейндж-реквесты, ни анализ влияния (в терминах сроков/стоимости) не нужны.

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

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

Конечной последней инстанцией в определении именно важности не может быть ни Аналитик ни МП со стороны Исполнителя (как внутреннего так и внешнего), а должен быть ИМЕННО Заказчик! А вот уже Аналитику нужно понять - почему этот Запрос на изменение важен Заказчику с помощью последнего. Если Аналитик не понимает - значит либо он дурак, либо Запрос действительно не очень важный и тогда надо говорить с людьми принимающими решение. Если последние говорят, что это важно, то все-таки Аналитик дурак (если Заказчик адекватный), п.ч. он не понимает действительных потребностей Заказчика. Тут же опять встает вопрос о качественной проработке Проблем Заказчика, путей их решения и вообще Целей разработки, т.е. Концепции ПО. Если на этом этапе схалтурили, то "убийственных" требований не избежать. Опять же итеративность разработки нам поможет: сделали часть - сразу показали, если что-то не так, то можем изменить курс.
Если же мы говорим о подряде, то во-первых всегда закладывается определеный бюджет на такого рода Риски, а во вторых нужно тут уже договариваться с Заказчиком и желательно заранее о разделении рисков\стоимости Разработки м\у Заказчиком и Исполнителем.
Т.е. в определении важности\нужности изменений складывается не только из одного фактора, он многогранен (ошибки Исполнителей, ошибки Заказчиков, внешние влияния и т.д.). И серебренной пули здесь нет.

З.Ы. надеюсь понял вопрос

Хотел написать небольшую статью по "Управлению изменениями Требований" ,чтобы подитожить этот топик и первый выпуск журнала AnalyzeIT.
Ответы на какие вопросы Вы бы хотели увидеть в этой статье?

Вот тут еще кое какие мысли по управлению изменениями требований:
http://vingrad.ru/blogs/ida/2008/12/10/analiz-izmeneniy/

Если заказчик соглашается со всем перечисленным, начинаем работу.

В исходном посте я приводил как раз кейс, когда заказчик НЕ соглашается со всем перечисленным, но, тем не менее, изменения в производство запускаются.
Причина - жесткость заказчика в том, что он не подпишет акты до тех пор, пока данное изменение не будет внесено.
Наверное, нужно уточнить - являются ли дальнейшие процессы сложных переговоров с заказчиком (кто заплатит за изменения, действительно ли так сразу и подразумевалось, а сделали неверно, действительно ли накосячили при анализе, можно ли уменьшить сроки/стоимость и т.п.) обязательным элементом процесса управления изменениями?
Насколько я понял коллег, у них этого часто нет. А можно ли считать процесс управления изменениями полноценным, если такой элемент переговорного процесса с заказчиком отсутствует?

Михаил,

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

bas, я согласен с замечаниями.

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

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

Попытаюсь раскрыть выше обозначенные вопросы.

- противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния;

А вот тут как раз подключаются два фактора:
1. Цели проекта, т.е. принимаем решение, которое удовлетворяет Целям проекта. Как раз к вопросу о нужности Концепции и хорошей ее проработки
2. Лидер\куратор проекта или группы ЗЛ, который решает, что удовлетворяем "производство" например или требование конкретного ЗЛ.

- формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний;

Тут наверное лучше делать отдельные Договора на разные этапы проекта:
1. Написание Концепции
2. Проработка первой фазы Требований - ТЗ1
3. Разработка\тестирование\внедрение ТЗ1
4. Проработка второй фазы ТЗ - ТЗ2
5. Разработка\тестирование\внедрение ТЗ2
6. и т.д.

- методы "сужения" или "расширения" потока замечаний и запросов на изменение;

ИМХО корелирует с "определение приоритетов изменений", "ведение переговоров с заказчиком", "политические причины" и "формат договорных отношений"

- зависимость решений по изменениям от фазы проекта

Ну тут ИМХО очевидно - чем раньше проект, тем гибкость ближе, чем старше проект, тем гибкость ниже

и др.

Если задашь еще вопросы, то попытаемся ответить.