Управление изменениями в реальной практике(Прочитано 33196 раз)
Может быть оффтоп, но в приложении регламент работ по управлению изменениями в реальном проекте.
И это работает...
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



bas,
наше с Вами видение вопросов, оказывается, различается.
Раз уж Вы прокомментировали мои тезисы, то и мне для сопоставления придется.

1. Противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния.
Я здесь скорее имел в виду ситуации, когда команда разработки дает оценку "по верхней границе", закладывая риски, организационные нестыковки, большие объемы тестирования и т.п.  А менеджер/сейл понимает, что продать заказчику это изменение "задорого" невозможно, и даже попытка выкатить озвученную "производством" оценку может спровоцировать большие разборки. Ситуация обостряется, если идет поток изменений, и проблема несоответствия оценок "производства" ожиданиям заказчика носит системный характер. Т.е. тут возникает ситуация внутренних переговоров, предшествующих собственно переговорам с заказчиком. Эту отдельную тему можно тоже во многих красках расписывать, учитывая разницу (как правило) в мотивации исполнителей и менеджеров/сейлов.

2. Формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний.
Может, "делать отдельные Договора на разные этапы проекта" и лучше, только неочевидно, что заказчик будет в таком виде это подписывать. Во многих случаях играется конкурс на проект целиком, и компания-исполнитель, выигравшая конкурс, не может в договоре уменьшить объем обязательств по сравнению с тем, что зафиксировано в условиях конкурса.
Я здесь скорее имел в виду аспекты:
 - если у заказчика фиксированный бюджет, и он не располагает возможностью привлекать дополнительные деньги, то есть ли смысл ему счета за изменения выставлять?
 - если у вас есть чейндж-реквест на 100$, согласованный менеджером проекта со стороны заказчика, но в вашем договоре нет пункта об оплате дополнительных работ, вы будете запускать на согласование дополнительное соглашение на эту сумму?
 - что надо написать в договоре, чтобы зарезервировать бюджет под будущие изменения, но при этом заказчик был бы также заинтересован в наличии такой строки в бюджете, а не был бы напуган, что с него заранее берут деньги за будущие ошибки исполнителей?
Ну и т.п.

3. Методы "сужения" или "расширения" потока замечаний и запросов на изменение.
Тут проще примеры привести.
Кейс 1. Вы делаете коробочный продукт. Внедряете на группе альфа-тестеров. Их замечания вам крайне важны для понимания, что улучшать в продукте, как его развивать. Вы заинтересованы в том, чтобы собрать как можно больше замечаний, вы будете искать пути, как облегчить для пользователей выдачу вам замечаний и запросов.
Кейс 2. Вы делаете программный продукт под заказ в условиях крайне ограниченного бюджета и для заказчика, перспективы дальнейшей работы с которым совершенно неочевидны. Думаю, Вы будете заинтересованы в том, чтобы максимально уменьшить поток замечаний, и всякие "хотелки" отсечь еще на этапе сбора, чтобы они и до регистрации, по возможности, не доходили.
Какие существуют еще ситуации, в которых надо канал сбора запросов на изменения расширять или сужать? Какими методами его можно расширять или сужать?

4. Зависимость решений по изменениям от фазы проекта.
Тезис "чем раньше проект, тем гибкость ближе, чем старше проект, тем гибкость ниже" не исчерпывает ответ на данный вопрос. Часто я сталкивался с ситуациями, когда пользователи, пока не начинали реально работать с системой (после предварительных демонстраций, например), выдавали замечания весьма поверхностного характера, но весьма радикальные по форме ("пока они это не исправят, я с этим работать не буду!"). Когда же начиналась реальная эксплуатация системы (хотя бы опытная), то замечания становились более глубокие, и степень радикальности формы выдачи значительно снижалась (пользователи понимали, что если руководство подписало приказ о начале ОЭ, то деваться им некуда - работать в системе придется - и просто бузить бессмысленно). При этом оказывалось, что многие из тех замечаний, которые пользователи генерировали до начала эксплуатации, позже признавались ими как неправильные, или, по крайней мере, как незначащие.
Поэтому то, что гибкость проекта на начальных фазах высока - это, конечно, да. Но это совсем не означает, что только по этой причине надо вносить как можно больше изменений сразу же на этих начальных фазах.

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



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

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

Но про остальные стороны УИзм тоже не думать нельзя....



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

Это примерно как в семейной жизни обсуждать, как будем уборку делать. Я цветы полью, а ты - пыль протри, и так легко и быстро всю уборку завершим. - Э, а кто будет пылесосить? полы мыть? мусор выносить? - А мы не знаем.... мы этого никогда не делаем... это кто-то другой делает.... мы всегда только цветы поливаем...
Ну нелепо же.
« Последнее редактирование: 18 Февраля 2009, 10:13:39 от Михаил Курбасов »



и рука сама тянется к тяжелому предмету...

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

В результате ощущаешь себя работающим в заведении для душевнобольных.

В принципе, по описанию так оно и есть. :)

На фиг тогда процесс, если его никто не будет соблюдать?...

Такой футбол процесс нам не нужен. Значит, нужен другой процесс. Вы сами чётко обозначили ключевую проблему, которую нужно решать:

Просто было бы странно заставлять делать что-то того, кто в этом не разбирается, или за что ответственность несет кто-то другой.
greesha.ru

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



Попытался подытожить дискуссию в статье Как бороться с Изменениями Требований?!.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Картинка в статье суперская, респект!



Картинка в статье суперская, респект!
Это спасибо Виталию, он опубликовал ее в статье из первого номера журнала AnalyzeIT
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Ну типа шуточное название. Ведь всех заботит именно борьба с ними ..
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



А у нас всё завязано на деньги, и потому довольно просто.

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

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

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

Некоторые "поблажки" в бесплатной и достаточно оперативной доработке делаем трём особо лояльным компаниям, на которых производим бета-тестирование новых продуктов.
« Последнее редактирование: 31 Мая 2009, 23:37:17 от AlexTheRaven »



-- но в приложении регламент работ по управлению изменениями в реальном проекте.
на проекте (немецком где мы Субподрядчик) у нас так
 - немцы присылают CR аналитики задают ворпосы по ним через базу вопросов в Лотусе - офицальная штука позволяющая отбиваться потом от лишних хотелок
(типа подтвердите что вас правильно поняли то и то)
немцы меняют CR согласно нашим замечаниям
затем аналитики оценивают свой обхем работы на изменение (создание) юз-кейсов (ворд.файл по шаблону RUP) тестеры оценивают свой девелоперы свой
эстимация заслыается немцам и если они согласны то потверждают
если вдруг нет  (такое бывает) то я точно не помню как работа аналитика по CR
оценивается - скорей всего это где то прописана в SoW (statemnet of work)
заключаещееся на каждый год с заказчиком
проект большой и плановый - т.е измеения вносятся в след. релиз
при подтверждении аналитики меняют юзкейсы в ворде - девелоперы кодят тестеры тесят (наши и немцы)
все это увязнао в лотусе через спец. базы CR ,UC, Implementation и Test
есть еще TCR (Technical) к-е не всегда проходят через аналитиков
ну типа помнетяь SQL запрос (не меняя его логики) для оптимизации
ну или срочно что-нибудь с продакшн зафиксить



<...>
есть еще TCR (Technical) к-е не всегда проходят через аналитиков
ну типа помнетяь SQL запрос (не меняя его логики) для оптимизации
ну или срочно что-нибудь с продакшн зафиксить
Конечно, можно сказать, что такова жизнь и никуда не деться, но весьма неприятно, когда в системе вдруг обнаруживается косой-кривой кусок функциональности "сбоку", который зачем-то нужно описать в требованиях пост-фактум, со всей кривизной, как реализовали. Потом, когда задают вопрос: "кто написал эти требования", приходится краснеть, хотя ты тут вроде бы и ни при чём.

А срочные фиксы в продакшн - это вообще песня, когда вдруг всё "отваливается", или у Заказчика начинает жить версия с доработками "из палки и верёвки", которую ни в коем случае нельзя обновлять, иначе всё разлетится.

IMHO лучше пользоваться требованиями с высоким приоритетом. Это, кстати, даёт возможность проверять: а на каком основании ведутся эти работы, а так ли высок приоритет, а кто за эти доработки платит и окупают ли они себя? Т.к. возможны варианты, когда менеджеры клиентов повышают прибыльность своих продаж за счёт неучтённой работы отделов разработки и внедрения.
« Последнее редактирование: 07 Июня 2009, 22:05:54 от AlexTheRaven »



Чтобы освоить искусство управления изменениями, можно пройти дистанционные курсы по управлению изменениями http://veulearning.com/courses/kouching-i-mentorstvo/




 

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