Какая методология лучше в случае "Сначала сделайте, а мы посмотрим"

[R.Safianov]

Цитата:

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

Оформили список дополнительных функциональных требований.
Отдали пользователям на проверку и утверждение, а они заявили: "Мы читать не любим. Вы сначала сделайте, а мы потом посмотрим и скажем ответ."

Смешно?

Заказчик смеется? И правильно делает.

Пошло бы легче, если бы вы:
1) Состряпали список процессов и их шаги.
2) Разобрать отчетность, которую планируется получать из системы.
3) Показать как процесс отражается в системе.
4) Показать места плановых модификаций и показать зачем они нужны.
5) Собрать от них требования по расхождениям. С поименными источниками требований.
6) Запустить процедуру утверждения требований. На этом шаге все будут биться за реализацию именно своих требований. А от каких-то есть шанс избавится навсегда.

Как правило требования собранные таким подходом позволяют перевести процесс из творческой в рабочую плоскость. Но этот подход требует от консультантов демонстрировать очень высокие знания системы.

[fed]

Цитата:

Сообщение от R.Safianov

Заказчик смеется? И правильно делает.

Пошло бы легче, если бы вы:
1) Состряпали список процессов и их шаги.
2) Разобрать отчетность, которую планируется получать из системы.
3) Показать как процесс отражается в системе.
4) Показать места плановых модификаций и показать зачем они нужны.
5) Собрать от них требования по расхождениям. С поименными источниками требований.
6) Запустить процедуру утверждения требований. На этом шаге все будут биться за реализацию именно своих требований. А от каких-то есть шанс избавится навсегда.

Как правило требования собранные таким подходом позволяют перевести процесс из творческой в рабочую плоскость. Но этот подход требует от консультантов демонстрировать очень высокие знания системы.

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

[R.Safianov]

Цитата:

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

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

Я бы сказал так. Заказчик хочет:
1) Купить систему, заплатив за нее один раз понятных денег.
2) Иметь систему, которую можно легко настроить, как угодно. Мы же не знаем сейчас процессов.
3) В процессе выявления процессов система должна становится еще быстрее. Мы ведь конкретизируем чего хотим.
4) Система должна уметь сама дополнять данные задним числом. Типа добавили разрез и все данные поменялись. Вах!!!
5) И если вот нам совсем захочется какой-то экзотики, то внедренец должен подорваться и совсем за маленькие деньги сделать такую уникальную штуку (как вообще мир до сих пор может жить без такой штуки. Вообще-то за клевую идею внедренец должен доплатить).

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

[macklakov]

Цитата:

Сообщение от R.Safianov

2) Иметь систему, которую можно легко настроить, как угодно. Мы же не знаем сейчас процессов.

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