Методология глазами клиента и партнера

[komar]

Цитата:

Сообщение от AXcons

...технологии внедрения на рынке грамотной нет. ....

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

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

[KiselevSA]

(вставлю свои пять копеек)
Основной свой опыт с AX получил на клиенте и, глядя с той колокольни, на эту дискуссию, могу сказать: две, нет, три основные проблемы взаимоотношений клиент/консалтинг на проекте - это отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий); отсутствие прикладника со стороны консалтинга; идиотская приверженность некоторых представителей клиента к «рюшечкам» и нежелание тратить оставшиеся нервы специалистами консалтинга на борьбу с рюшечками.
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом. Очень часто альбом процессов и альбом документов при разработке выливается в следующее закидывание помидорами: «- Вы не сказали, что это нужно (или что нужно учесть это и это). - А вы не спросили об этом.» Да чтобы спросить, надо знать, о чем спрашивать.
Специалисты клиента забывают или не хотят (иногда и специально) раскрывать все «секреты»: «Вот не скажу, может и останемся в знакомой среде». Высшее руководство, заинтересованное в переходе на новую систему, спрашивать, за редким исключением, бесполезно, ибо они нарисуют сферического коня в вакууме, свою розовую мечту, далекую от истины. Итоговый документ превращается в декларацию о намерениях с легким абрисом «болевых точек». И это не устраивает обе стороны: «Плохой консалтинг, забыли … (список на n листах)»; «Проблемный клиент, список дополнительных работ на n листах без расширения бюджета». Хорошо, если у консалтинговой компании есть уже опыт в выбранной сфере автоматизации. Уже наступали на грабли и знают, что надо не забыть спросить. Мелкие отличия сильно не скажутся. А если нет? Вот тут и начинается игра в русскую рулетку, а всего-то надо одного толмача, который не будет относиться к рискам проекта.

[George Nordic]

Коллеги, по следам дивной темы По мотивам общения с Майкрософтом решил скопировать часть интересных высказываний в эту отдельную ветку. Мне кажется, что пост KiselevSA очень верно раскрывает суть, почему методология ведения проекта из руководсва "как сделать то, что хочет Заказчик в срок и с минимальными рисками" превращается в талмуд "как учесть все закидоны клиента и защитится от "вы этого не учли, вы того не учли, а вот еще это и это сделайте в рамках текущего проекта" - то, о чем пишет Дмитрий.

С Уважением,
Георгий

[komar]

Цитата:

Сообщение от KiselevSA

Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом.

Да, очень правильно было бы задумываться о том, что система должна работать Не галки должны быть проставлены и не отчёты должны быть нарисованы, а именно "система должна работать" А "система" - это, как правило, не только и не столько программа... Вот об этом методология вендора никогда и не скажет - потому, что для производителя программы система = программа. А это не так.

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

Сферические же в вакууме методологии управления проектами существуют для успешного проведения задницеприкрывательных мероприятий, и со своей задачей справляются на все 100%. Задачи "система должна работать" здесь тоже нет в помине.

[Vals]

О да, напишите в ТЗ "Система должна работать" и главное, подпишите это у заказчика.

Такое у нас было только с клиентами с которыми 100% взаимопонимание + доверие + взаимное обучение друг-друга.
И с отраслевыми клиентами, когда из узкой специализации отрасли не спрыгнешь, потому что всё регламентировано бизнесом. При этом необходимо присутствие отработанного отраслевого решения.

[KiselevSA]

Цитата:

Сообщение от komar

Да, очень правильно было бы задумываться о том, что система должна работать Не галки должны быть проставлены и не отчёты должны быть нарисованы, а именно "система должна работать" А "система" - это, как правило, не только и не столько программа... Вот об этом методология вендора никогда и не скажет - потому, что для производителя программы система = программа. А это не так.

Отчасти не соглашусь, ибо методология вендора рассчитана на 100% совпадение всех входных условий: формирование команд заказчика и исполнителя, назначение ключевых фигур. опыт специалистов и, обратите внимание, достаточно подробного описания БП хотя бы ASIS. Ну, т.е., когда все шестеренки в механизме есть, правильно смазаны и не имеют "сломанных", точнее лишних, зубов. Для западного менталитета, успех корпорации прежде всего, такой подход будет рабочим, а вот перенос его на российскую действительность страдает на все две (или даже четыре) ноги.

[Vals]

Цитата:

Сообщение от komar

Сферические же в вакууме методологии управления проектами существуют для успешного проведения задницеприкрывательных мероприятий, и со своей задачей справляются на все 100%. Задачи "система должна работать" здесь тоже нет в помине.

Поддерживаю. Даже лекция в МИРБИСе была на эту тему

Нарисуй картину
Студенты тоже говорили - нарисуй картину, я им изображал как Мог, а Мог был известным художником
http://www.e-xecutive.ru/blog/Vals/2855.php

[Bobkov]

Цитата:

Сообщение от Vals

О да, напишите в ТЗ "Система должна работать" и главное, подпишите это у заказчика.

Самое смешное, что именно это и нужно и заказчику, и исполнителю. В нормальном ТЗ должна быть определено, что понимается в рамках данного проекта под Системой и определены критерии приемки готовой Системы заказчиком. Когда-то мне повезло читать подготовленный Сергеем Мазуркиным проект договора на маленькую системку, и там в приложении по сути было именно такое ТЗ - что такое в данном случае "система" и что такое "работает". Было очень приятно читать

[fedka]

Цитата:

Сообщение от KiselevSA

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

Полностью согласен!
Но вот по рюшечкам - я считаю что на начальном проекте они также важны - дабы мотивировать сотрудников заказчика. Нужен "бизнес аналитик" и эксперты в деятельности организаций. Экспертов то и надо мотивировать - а люди за ними потянутся.

[AXcons]

Цитата:

Сообщение от KiselevSA

(вставлю свои пять копеек)
Основной свой опыт с AX получил на клиенте и, глядя с той колокольни, на эту дискуссию, могу сказать: две, нет, три основные проблемы взаимоотношений клиент/консалтинг на проекте - это отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий); отсутствие прикладника со стороны консалтинга; идиотская приверженность некоторых представителей клиента к «рюшечкам» и нежелание тратить оставшиеся нервы специалистами консалтинга на борьбу с рюшечками.
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом. Очень часто альбом процессов и альбом документов при разработке выливается в следующее закидывание помидорами: «- Вы не сказали, что это нужно (или что нужно учесть это и это). - А вы не спросили об этом.» Да чтобы спросить, надо знать, о чем спрашивать.
Специалисты клиента забывают или не хотят (иногда и специально) раскрывать все «секреты»: «Вот не скажу, может и останемся в знакомой среде». Высшее руководство, заинтересованное в переходе на новую систему, спрашивать, за редким исключением, бесполезно, ибо они нарисуют сферического коня в вакууме, свою розовую мечту, далекую от истины. Итоговый документ превращается в декларацию о намерениях с легким абрисом «болевых точек». И это не устраивает обе стороны: «Плохой консалтинг, забыли … (список на n листах)»; «Проблемный клиент, список дополнительных работ на n листах без расширения бюджета». Хорошо, если у консалтинговой компании есть уже опыт в выбранной сфере автоматизации. Уже наступали на грабли и знают, что надо не забыть спросить. Мелкие отличия сильно не скажутся. А если нет? Вот тут и начинается игра в русскую рулетку, а всего-то надо одного толмача, который не будет относиться к рискам проекта.

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

Еще есть такой трюк (если все-таки бюджет надо как-то зафиксировать) - в бюджет закладывать специальную статью - дополнительные требования. И заложите хорошо там - 10-20% от всего бюджета на разработку. И тогда, если у вас возникла такая ситуация с требованиями - оп, а у вас под это есть бюджет.
У меня называлась такая статья "Мелкие доработки по требованиям пользователей". Но у меня неучтенных требований не было. Там действительно было на такие вещи, как доработка пользовательского интерфейса, и какие-то мелочи. Потому что мы тщательно обследование делали. Ну сначала было, конечно, первые года 3 работы в консалтинге. А потом уже нет. Никаких сюрпризов на запуске в эксплуатацию.

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

[miklenew]

Цитата:

Сообщение от AXcons

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

Перечитал несколько раз. Задался вопросом: Он реально имеет ввиду дословно то, что написал?
Прототип системы??? - ого. Может прототип процесса.
Дизайном заниматься на этапе прототипа?
Прототип нужен для ознакомления с стандартными возможностями и понимания чего нет и придётся делать самим. Какой тут дизайн? Можно конечно на этом этапе топтаться месяцы... Даже сталкивался раз с таким. Бред.
Конечному пользователю? Вот одна из бед аксапты. Давайте тысячу раз по кругу походим.
Как я делаю.
1) Делаю прототип процесса для себя. На пустой базе или демо, разные бывают варианты. Смотрю чё сходиться, чё не сходиться.
Чё не сходится, ищу ключевого пользователя. Сидим чешим репу.
Потому что бывали случаи, что мне казалось не логичным после разговора с пользователем оказывалось не лишённым логики.
Какой бы ни был процент покрытия типовыми средствами идём на следующий этап.
2) Ввод начальных данных. Доработка. Согласование с ключевым пользователем процесса. Дизайн и другие мелочи.
3) Руководство пользователя ->Обучение. Вот здесь уже конечный пользователь. Снова доработка дизайна, возможно изменение функционала. Но суть вся основная работа должна быть сделана до. Например с начальником отдела. У конечного пользователя должно быть ощущение, что его ставят перед фактом, что завтра он будет работать по этому процессу. Это будет не через месяц, два или год, а ближайшее время. Иначе начинается брожение мозгов, обсуждение каких то пустых вещей.
4) Запуск. Параллельно создание средств анализа. Исправление багов. Баньтики.
5) Поддержка.
Переходим к следующему отделу или следующему процессу.

[Raven Melancholic]

Попробую задать вопросы со стороны клиента.

Цитата:

То есть, бюджет на разработку определяется не в момент подписания договора, а по согласованному конкретному перечню доработок.

Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта.

Цитата:

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

А если не уложились в это отклонение?

Цитата:

Никаких сюрпризов на запуске в эксплуатацию

Что же это за компания?

Цитата:

Вот они когда систему видят, сразу понимают, что...

Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.

Цитата:

И заложите хорошо там - 10-20% от всего бюджета

В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Вы уверены, что оперируете реальными проектами, а не "сферическими конями в вакууме"?

[AXcons]

Цитата:

Сообщение от Raven Melancholic

Попробую задать вопросы со стороны клиента.

Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта.

А если не уложились в это отклонение?

Что же это за компания?

Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.

В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Вы уверены, что оперируете реальными проектами, а не "сферическими конями в вакууме"?

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

[AXcons]

Цитата:

Сообщение от miklenew

Перечитал несколько раз. Задался вопросом: Он реально имеет ввиду дословно то, что написал?
Прототип системы??? - ого. Может прототип процесса.
Дизайном заниматься на этапе прототипа?
Прототип нужен для ознакомления с стандартными возможностями и понимания чего нет и придётся делать самим. Какой тут дизайн? Можно конечно на этом этапе топтаться месяцы... Даже сталкивался раз с таким. Бред.
Конечному пользователю? Вот одна из бед аксапты. Давайте тысячу раз по кругу походим.
Как я делаю.
1) Делаю прототип процесса для себя. На пустой базе или демо, разные бывают варианты. Смотрю чё сходиться, чё не сходиться.
Чё не сходится, ищу ключевого пользователя. Сидим чешим репу.
Потому что бывали случаи, что мне казалось не логичным после разговора с пользователем оказывалось не лишённым логики.
Какой бы ни был процент покрытия типовыми средствами идём на следующий этап.
2) Ввод начальных данных. Доработка. Согласование с ключевым пользователем процесса. Дизайн и другие мелочи.
3) Руководство пользователя ->Обучение. Вот здесь уже конечный пользователь. Снова доработка дизайна, возможно изменение функционала. Но суть вся основная работа должна быть сделана до. Например с начальником отдела. У конечного пользователя должно быть ощущение, что его ставят перед фактом, что завтра он будет работать по этому процессу. Это будет не через месяц, два или год, а ближайшее время. Иначе начинается брожение мозгов, обсуждение каких то пустых вещей.
4) Запуск. Параллельно создание средств анализа. Исправление багов. Баньтики.
5) Поддержка.
Переходим к следующему отделу или следующему процессу.

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

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

[gl00mie]

Цитата:

Сообщение от AXcons

Цитата:

Сообщение от Raven Melancholic

Попробую задать вопросы со стороны клиента. Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.
В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта. А если не уложились в это отклонение?

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

Вы, наверно, какой-то секрет знаете С такими секретными сведениями - и отсиживаться на клиенте... "Оставайтесь! Будете гениальным механиком планеты" руководителем проектов

[AXcons]

Цитата:

Сообщение от gl00mie

Вы, наверно, какой-то секрет знаете С такими секретными сведениями - и отсиживаться на клиенте... "Оставайтесь! Будете гениальным механиком планеты" руководителем проектов

Кое-что знаю, да. Когда-нибудь, наверное, вернусь в консалтинг. А пока отдохну на клиенте