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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Михаил Курбасов

Страницы: « 1 2 3 4 5 6 »
31
Есть тест, предлагаемый К.Вигерсом.
Англоязычный оригинал здесь:
http://processimpact.com/process_assets/reqs_self_assessment.doc
http://processimpact.com/process_assets/reqs_self_assessment.xls
Русский перевод есть в его книжке, см. Приложение А.

32
О Сайте и Форуме / Re: Новости Cайта
« : 19 Февраля 2009, 15:16:54 »
Статьи НЕ имеющие ценности
Может, такие и не надо публиковать?  ;)

Согласно Вашему определению, если я опубликую ссылку на статью, а в статье будет расказываться, как замечательно компания Х, предположим, рисует UML-диаграммы, и сопровождаться это будет соответствующим прайс-листом - то это не будет рекламой?!
Тогда это, конечно, мнение, действительно, "субъективное" и "Ваше личное"...

33
О Сайте и Форуме / Re: Новости Cайта
« : 19 Февраля 2009, 09:47:23 »
Мне кажется, не очень корректный вопрос - что для меня является рекламой.

Для меня рекламой является то же самое, что и для всех. Можно посмотреть определение в Википедии:
http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D0%B0
Реклама — информация, распространенная любым способом, в любой форме и с использованием любых средств, адресованная неопределенному кругу лиц и направленная на привлечение внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижение на рынке

Оттуда же см. определение скрытой рекламы:
Скрытой называется реклама, не обозначенная как таковая, размещённая под видом информационного, редакционного или авторского материала, закамуфлированная под личное сообщение, или иную нерекламную информацию

Мне кажется, это как раз то, о чем я написал. Мне представляется, что не надо размещать скрытую рекламу - надо ее маркировать как явную.

Можно еще обратиться к закону "О рекламе", если хотите. Пока я туда не лез - мне на этом уровне казалось достаточным понимания на уровне здравого смысла.
То, что Вы размещаете у себя на ресурсе рекламу - это понятно, и никто, собственно, не против. Но несколько удивительно, почему, размещая рекламу, Вы отказываетесь считать ее таковой...

34
О Сайте и Форуме / Re: Новости Cайта
« : 18 Февраля 2009, 20:49:18 »
Ну не знаю. Я ничего не имею против здоровой рекламы.
...
Если Вас это так напрягает, то можем подумать как сделать так, чтобы не напрягало.
Я не знаю, как разделить рекламу на "здоровую" и "нездоровую". Как сделать, чтобы не напрягало - я написал. Просто пометьте явно, что это реклама. В печатных СМИ можно увидеть, что есть просто статьи, а есть статьи "на правах рекламы". Как пример.

35
О Сайте и Форуме / Re: Новости Cайта
« : 18 Февраля 2009, 10:20:30 »
Мне кажется, что под видом новостей последнее время публикуется все больше и больше рекламы. Имхо, было бы корректнее по отношению к читателям сайта такие сообщения все-таки явно маркировать как "рекламу".

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

Это примерно как в семейной жизни обсуждать, как будем уборку делать. Я цветы полью, а ты - пыль протри, и так легко и быстро всю уборку завершим. - Э, а кто будет пылесосить? полы мыть? мусор выносить? - А мы не знаем.... мы этого никогда не делаем... это кто-то другой делает.... мы всегда только цветы поливаем...
Ну нелепо же.

37
назвал бухгалтера Анаша Петровна и сделал мне скриншоты
Напомнило.
Был у нас один субподрядчик, делал нам некий модуль для продукта по автоматизации работы судов. Ну и в документации понавствлял скриншотов, где можно было прочесть ФИО обвиняемых - все сплошь из нашей проектной команды, составы преступления - я уже всех не помню, но напротив моей фамилии значился "каннибализм". Ну и меры наказания так от души подобрали.
Такой вот юмор у ребят своеобразный....

А наши аналитики составляли справочник воинских званий. Ну и добавили (в тестовых целях, разумеется) всякую фигню. Перед отправкой клиентам тестовые воинские звания типа "гусар" и "111", разумеется, почистили. Но вычистили, как выяснилось, не все. Довольно быстро нам пользователи сообщили про наличие в списке званий "барабанщика". Барабанщика удалили, вроде все опять проверили. Спустя где-то пять (!!!) релизов обратили внимание, что живет у нас еще такой "церемониймейстер"... Затерялся в списке и живет...
P.S. По итогам этой истории мы сделали специальный регламент по ведению эталонных наборов справочников. Во избежание...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45
Сама по себе идея подобной "политинформации" для сотрудников мне кажется правильной и полезной. Рад за вас, что вы нашли в себе силы сделать первый шаг в этом направлении.
Что касается самого содержания журнала, то наличие в нем ТОЛЬКО отрывков известных книг немного разочаровало. Ну, т.е. по анонсу ожидалось нечто более "свое, выстраданное". Или, по крайней мере, хотя бы дополнение "классиков" какими-то словами о применении описанной теории в вашей реальной практике. Впрочем, подозреваю, что журналы, содержащие ваши ноу-хау или анализ реального состояния дел, вы бы не могли публиковать в интернете.
В любом случае, желаю вам удачи и чтобы ваше начинание не загнулось!

Поделитесь попозже, каков был фидбэк на ваше новшество? Со стороны коллег, руководства?

Страницы: « 1 2 3 4 5 6 »