Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: Михаил Курбасов от 28 Января 2009, 21:16:22
-
Тема навеяна сообщением Виталия Григораша о выпуске им журнала для аналитиков (http://www.uml2.ru/forum/index.php?topic=1119.0) с подборкой на тему "Изменения требований".
Во вступлении автор пишет что-то вроде того, что "пишем много чейндж-реквестов, и не всем понятно, зачем". Ну, это, очевидно, юмор, а я хотел спросить серьезно.
У тех из вас, у кого поставлен процесс управления изменениями - вам всегда ли понятно, для чего пишутся чейндж-реквесты, ведется анализ влияния? Сталкиваетесь ли вы с ситуациями, когда вы в ходе проекта зафиксировали некий чейндж-реквест, провели анализ влияния, вывели, что "чтобы это реализовать, надо всю систему переписать заново, и стоить это будет мильон баксов" - а заказчик вам на это выражает что-то типа "а мне пофиг, я без этой хотелки акты все равно не подпишу". Ну, я утрирую, конечно, но проблема в том - всегда ли имеет смысл осложнять себе жизнь дополнительными оформлениями-расчетами, если делать это изменение вы все равно будете (по политическим причинам, например)?
Как обстоит с этим дело у вас в проектах?
-
Михаил, вот как Вы сказали: делать это изменение вы все равно будете. Причем это внутренняя корпоративная политика разработчика. Удовлетворить заказчика максимально. Правда анизотропный такой подход. Только для группы заказчиков :)
Связано это с текущей ситуацией. Поскольку мы предлагаем очень привлекательное решение по сравнению с аналогами. Но мы мало известны, потому пока стратегия на максимальное удовлетворение заказчика
Правда, если возникают переделки на мильон баков - это гигантский просчет архитекторов, либо сильно устаревшая архитектура.
-
У нас на проекте принимают решение о изменении руководители проекта. Ченж-реквесты, поступившие от заказчика фильтруются. Если "фича" действительно нужная, то приходится вносить изменения, которые влияют пусть и не на всю систему, но на отдельные модули очень сильно. Был случай, когда во время разработки поменялись законы. Пришлось полностью переделать целый модуль, причем все это в рамках ограниченных сроков и бюджета.
А вот различного рода "бантики" обычно замораживают до лучших времен. Т.е. требование есть, но скоуп у него проставлен на конечные релизы. Сейчас у нас также все требования касающиеся 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://www.uml2.ru/forum/index.php?topic=1119.0).
Ответы на какие вопросы Вы бы хотели увидеть в этой статье?
-
Вот тут еще кое какие мысли по управлению изменениями требований:
http://vingrad.ru/blogs/ida/2008/12/10/analiz-izmeneniy/
-
Если заказчик соглашается со всем перечисленным, начинаем работу.
В исходном посте я приводил как раз кейс, когда заказчик НЕ соглашается со всем перечисленным, но, тем не менее, изменения в производство запускаются.
Причина - жесткость заказчика в том, что он не подпишет акты до тех пор, пока данное изменение не будет внесено.
Наверное, нужно уточнить - являются ли дальнейшие процессы сложных переговоров с заказчиком (кто заплатит за изменения, действительно ли так сразу и подразумевалось, а сделали неверно, действительно ли накосячили при анализе, можно ли уменьшить сроки/стоимость и т.п.) обязательным элементом процесса управления изменениями?
Насколько я понял коллег, у них этого часто нет. А можно ли считать процесс управления изменениями полноценным, если такой элемент переговорного процесса с заказчиком отсутствует?
-
Михаил,
Всегда есть такой элемент - ведение сложных переговоров с заказчиком об изменениях. Просто когда он легче, когда сложнее, и это уже скорее задача Менеджера разрулить ситуацию, а не Аналитика. Методы разруливания я предлагал выше.
-
bas, я согласен с замечаниями.
Просто мне показалось, что обсуждение темы управления изменениями не должно сводиться к очередному цитированию классиков. Есть очень много открытых вопросов, часть из которых мы тут набросали:
- определение приоритетов изменений ("бантики" vs "реально нужные фичи");
- разделение полномочий между аналитиком и менеджером проекта в управлении изменениями;
- ведение переговоров с заказчиком;
- учет "политических причин" при принятии решений по изменениям.
Еще не касались таких тем, например, как:
- противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния;
- формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний;
- методы "сужения" или "расширения" потока замечаний и запросов на изменение;
- зависимость решений по изменениям от фазы проекта
и др.
Т.е. тему я назвал "Управление изменениями в реальной практике", чтобы подчеркнуть, что есть очень много практических аспектов этого вопроса, достаточно мало освещенных. Было бы здорово, если бы кто-то взялся за эту тему и раскрыл ее с учетом этих разнообразных практических ситуаций.
-
Попытаюсь раскрыть выше обозначенные вопросы.
- противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния;
А вот тут как раз подключаются два фактора:
1. Цели проекта, т.е. принимаем решение, которое удовлетворяет Целям проекта. Как раз к вопросу о нужности Концепции и хорошей ее проработки
2. Лидер\куратор проекта или группы ЗЛ, который решает, что удовлетворяем "производство" например или требование конкретного ЗЛ.
- формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний;
Тут наверное лучше делать отдельные Договора на разные этапы проекта:
1. Написание Концепции
2. Проработка первой фазы Требований - ТЗ1
3. Разработка\тестирование\внедрение ТЗ1
4. Проработка второй фазы ТЗ - ТЗ2
5. Разработка\тестирование\внедрение ТЗ2
6. и т.д.
- методы "сужения" или "расширения" потока замечаний и запросов на изменение;
ИМХО корелирует с "определение приоритетов изменений", "ведение переговоров с заказчиком", "политические причины" и "формат договорных отношений"
- зависимость решений по изменениям от фазы проекта
Ну тут ИМХО очевидно - чем раньше проект, тем гибкость ближе, чем старше проект, тем гибкость ниже
и др.
Если задашь еще вопросы, то попытаемся ответить.
-
Может быть оффтоп, но в приложении регламент работ по управлению изменениями в реальном проекте.
И это работает...
-
bas,
наше с Вами видение вопросов, оказывается, различается.
Раз уж Вы прокомментировали мои тезисы, то и мне для сопоставления придется.
1. Противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния.
Я здесь скорее имел в виду ситуации, когда команда разработки дает оценку "по верхней границе", закладывая риски, организационные нестыковки, большие объемы тестирования и т.п. А менеджер/сейл понимает, что продать заказчику это изменение "задорого" невозможно, и даже попытка выкатить озвученную "производством" оценку может спровоцировать большие разборки. Ситуация обостряется, если идет поток изменений, и проблема несоответствия оценок "производства" ожиданиям заказчика носит системный характер. Т.е. тут возникает ситуация внутренних переговоров, предшествующих собственно переговорам с заказчиком. Эту отдельную тему можно тоже во многих красках расписывать, учитывая разницу (как правило) в мотивации исполнителей и менеджеров/сейлов.
2. Формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний.
Может, "делать отдельные Договора на разные этапы проекта" и лучше, только неочевидно, что заказчик будет в таком виде это подписывать. Во многих случаях играется конкурс на проект целиком, и компания-исполнитель, выигравшая конкурс, не может в договоре уменьшить объем обязательств по сравнению с тем, что зафиксировано в условиях конкурса.
Я здесь скорее имел в виду аспекты:
- если у заказчика фиксированный бюджет, и он не располагает возможностью привлекать дополнительные деньги, то есть ли смысл ему счета за изменения выставлять?
- если у вас есть чейндж-реквест на 100$, согласованный менеджером проекта со стороны заказчика, но в вашем договоре нет пункта об оплате дополнительных работ, вы будете запускать на согласование дополнительное соглашение на эту сумму?
- что надо написать в договоре, чтобы зарезервировать бюджет под будущие изменения, но при этом заказчик был бы также заинтересован в наличии такой строки в бюджете, а не был бы напуган, что с него заранее берут деньги за будущие ошибки исполнителей?
Ну и т.п.
3. Методы "сужения" или "расширения" потока замечаний и запросов на изменение.
Тут проще примеры привести.
Кейс 1. Вы делаете коробочный продукт. Внедряете на группе альфа-тестеров. Их замечания вам крайне важны для понимания, что улучшать в продукте, как его развивать. Вы заинтересованы в том, чтобы собрать как можно больше замечаний, вы будете искать пути, как облегчить для пользователей выдачу вам замечаний и запросов.
Кейс 2. Вы делаете программный продукт под заказ в условиях крайне ограниченного бюджета и для заказчика, перспективы дальнейшей работы с которым совершенно неочевидны. Думаю, Вы будете заинтересованы в том, чтобы максимально уменьшить поток замечаний, и всякие "хотелки" отсечь еще на этапе сбора, чтобы они и до регистрации, по возможности, не доходили.
Какие существуют еще ситуации, в которых надо канал сбора запросов на изменения расширять или сужать? Какими методами его можно расширять или сужать?
4. Зависимость решений по изменениям от фазы проекта.
Тезис "чем раньше проект, тем гибкость ближе, чем старше проект, тем гибкость ниже" не исчерпывает ответ на данный вопрос. Часто я сталкивался с ситуациями, когда пользователи, пока не начинали реально работать с системой (после предварительных демонстраций, например), выдавали замечания весьма поверхностного характера, но весьма радикальные по форме ("пока они это не исправят, я с этим работать не буду!"). Когда же начиналась реальная эксплуатация системы (хотя бы опытная), то замечания становились более глубокие, и степень радикальности формы выдачи значительно снижалась (пользователи понимали, что если руководство подписало приказ о начале ОЭ, то деваться им некуда - работать в системе придется - и просто бузить бессмысленно). При этом оказывалось, что многие из тех замечаний, которые пользователи генерировали до начала эксплуатации, позже признавались ими как неправильные, или, по крайней мере, как незначащие.
Поэтому то, что гибкость проекта на начальных фазах высока - это, конечно, да. Но это совсем не означает, что только по этой причине надо вносить как можно больше изменений сразу же на этих начальных фазах.
В общем, тема, на мой взгляд, очень сложная и глубокая. Факторов, влияющих на решение, огромное количество. Их даже проанализировать сложно, не говоря уже о том, чтобы влиять на них. Поэтому я бы предостерег от упрощения ситуации. Классики, конечно, общую схему нам описали - фиксируем запрос, делаем анализ влияния, сообщаем оценку заказчику - и аллес гуд. Но в жизни столько вариаций.....
-
в приложении регламент работ по управлению изменениями в реальном проекте. И это работает...
Виталий, я не знаю потребностей вашего конкретного проекта. Вполне допускаю, что для вашего проекта такой регламент является абсолютно оптимальным.
Но, вообще, насколько я понял, документ описывает только процесс регистрации запросов на изменения и решений по ним....
Я вовсе не хочу сказать, что надо пытаться регламентировать все аспекты управления изменениями. Регламентировать надо тот процесс, для которого проблемой является отсутствие единообразия, и регламентация способна это решить. Вполне возможно, что в проекте Виталия такой стороной управления изменениями является как раз регистрация запросов.
Но про остальные стороны УИзм тоже не думать нельзя....
-
ida,
ну что делать - в реальной жизни и технические, и управленческие, и политические вопросы тесно переплетены. Нужно заниматься и теми, и другими.
Просто если мы хотим иметь представление о процессе в целом (в данном случае мы обсуждаем процесс "управление изменениями"), то надо говорить о всех его сторонах и об их взаимосвязи.
Делить - "вот это аналитики делают, а вот это не делают" - можно и нужно, но в контексте обсуждения распределения задач управления изменениями по ролям. А пока мы не установили более-менее полную номенклатуру необходимых действий, то обсуждать распределение, имхо, малоэффективно.
Это примерно как в семейной жизни обсуждать, как будем уборку делать. Я цветы полью, а ты - пыль протри, и так легко и быстро всю уборку завершим. - Э, а кто будет пылесосить? полы мыть? мусор выносить? - А мы не знаем.... мы этого никогда не делаем... это кто-то другой делает.... мы всегда только цветы поливаем...
Ну нелепо же.
-
и рука сама тянется к тяжелому предмету...
Один пообещал заказчику, что через неделю будет вот такая-то фича, другой об этом знать не знает - при этом планами проектами занимается этот другой.
В результате ощущаешь себя работающим в заведении для душевнобольных.
В принципе, по описанию так оно и есть. :)
На фиг тогда процесс, если его никто не будет соблюдать?...
Такой футбол процесс нам не нужен. Значит, нужен другой процесс. Вы сами чётко обозначили ключевую проблему, которую нужно решать:
Просто было бы странно заставлять делать что-то того, кто в этом не разбирается, или за что ответственность несет кто-то другой.
-
Попытался подытожить дискуссию в статье Как бороться с Изменениями Требований?! (http://bas4all.livejournal.com/23187.html).
-
Картинка в статье суперская, респект!
-
Картинка в статье суперская, респект!
Это спасибо Виталию, он опубликовал ее в статье из первого номера журнала AnalyzeIT (http://www.uml2.ru/forum/index.php?topic=1119.0)
-
Ну типа шуточное название. Ведь всех заботит именно борьба с ними ..
-
А у нас всё завязано на деньги, и потому довольно просто.
Во-первых, продавцы не торгуют фьючерсами. ТЗ на решение, которое они "продают", пишут на основании того ПО, которое уже есть. ТЗ с "фьючерсом" может появиться, только если прибыль от продажи решения более чем оправдывает доработку (или "фьючерс" соответствует стратегии развития продукта), а сама доработка является малорискованной (необходимый опыт есть, сроки - с запасом). Но вот если после подписания, в процессе установки или опытной эксплуатации, появляется ошибка (в т.ч. отсутствие заявленной функциональности), она устраняется с приоритетом "бросить всё кроме" - т.к. это ухудшает репутацию и мешает получить оставшиеся деньги.
Во-вторых, доработка не входит в поддержку. В поддержку входит исправление ошибок в существующей функциональности, и то сроки не фиксируются, а "ошибка" в документах для заказчика - это то, что действительно невозможно обойти. И то, формально, как только подписали акт перевода в промышленную эксплуатацию "без замечаний" - заказчик соглашается с тем, что ошибок ПО и проблем конфигурации в решении нет. "Бантики" делаются, только если (и пока) прибыль от продажи поддержки (или прогнозируемых менеджером клиента будущих продаж). Ну или если она вписывается в стратегию развития продукта, а заказчик сам её оплачивает.
Как таковых, "запросов на изменение" нет. Есть сообщения о проблемах заказчика, которые преобразуются в проблемы конфигурации (которые решают инженеры), ошибки ПО (для которых временные пути обхода ищут сначала инженеры, затем, если инженеры не смогли, подключаются разработчики и тестировщики, и которые исправляют разработчики), запросы на изменение конфигурации (за отдельные деньги делают инженеры) и бизнес-требования к ПО (которые реализуют разработчики, иногда за отдельные деньги).
Некоторые "поблажки" в бесплатной и достаточно оперативной доработке делаем трём особо лояльным компаниям, на которых производим бета-тестирование новых продуктов.
-
-- но в приложении регламент работ по управлению изменениями в реальном проекте.
на проекте (немецком где мы Субподрядчик) у нас так
- немцы присылают CR аналитики задают ворпосы по ним через базу вопросов в Лотусе - офицальная штука позволяющая отбиваться потом от лишних хотелок
(типа подтвердите что вас правильно поняли то и то)
немцы меняют CR согласно нашим замечаниям
затем аналитики оценивают свой обхем работы на изменение (создание) юз-кейсов (ворд.файл по шаблону RUP) тестеры оценивают свой девелоперы свой
эстимация заслыается немцам и если они согласны то потверждают
если вдруг нет (такое бывает) то я точно не помню как работа аналитика по CR
оценивается - скорей всего это где то прописана в SoW (statemnet of work)
заключаещееся на каждый год с заказчиком
проект большой и плановый - т.е измеения вносятся в след. релиз
при подтверждении аналитики меняют юзкейсы в ворде - девелоперы кодят тестеры тесят (наши и немцы)
все это увязнао в лотусе через спец. базы CR ,UC, Implementation и Test
есть еще TCR (Technical) к-е не всегда проходят через аналитиков
ну типа помнетяь SQL запрос (не меняя его логики) для оптимизации
ну или срочно что-нибудь с продакшн зафиксить
-
<...>
есть еще TCR (Technical) к-е не всегда проходят через аналитиков
ну типа помнетяь SQL запрос (не меняя его логики) для оптимизации
ну или срочно что-нибудь с продакшн зафиксить
Конечно, можно сказать, что такова жизнь и никуда не деться, но весьма неприятно, когда в системе вдруг обнаруживается косой-кривой кусок функциональности "сбоку", который зачем-то нужно описать в требованиях пост-фактум, со всей кривизной, как реализовали. Потом, когда задают вопрос: "кто написал эти требования", приходится краснеть, хотя ты тут вроде бы и ни при чём.
А срочные фиксы в продакшн - это вообще песня, когда вдруг всё "отваливается", или у Заказчика начинает жить версия с доработками "из палки и верёвки", которую ни в коем случае нельзя обновлять, иначе всё разлетится.
IMHO лучше пользоваться требованиями с высоким приоритетом. Это, кстати, даёт возможность проверять: а на каком основании ведутся эти работы, а так ли высок приоритет, а кто за эти доработки платит и окупают ли они себя? Т.к. возможны варианты, когда менеджеры клиентов повышают прибыльность своих продаж за счёт неучтённой работы отделов разработки и внедрения.
-
Чтобы освоить искусство управления изменениями, можно пройти дистанционные курсы по управлению изменениями http://veulearning.com/courses/kouching-i-mentorstvo/