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

[AXcons]

Цитата:

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

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

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

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

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