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

[AXcons]

Цитата:

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

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

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

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

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

[miklenew]

Цитата:

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

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

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

[AXcons]

Цитата:

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

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

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

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