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

[slava09]

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

Смешно?

[kashperuk]

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

[galka]

Цитата:

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

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

Смешно?

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

[Nick]

Цитата:

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

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

Смешно?

Нет!
Если Заказчик финансирует такой способ работ - почему бы и нет?!
Как правило, при грамотной команде внедренцев проект даже и более рентабельным для клиента выходит...

[slava09]

Цитата:

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

Как правило, при грамотной команде внедренцев проект даже и более рентабельным для клиента выходит...

При грамотной команде внедренца, можно внедрить за 1 месяц SAP
Если команда, конечно, ОЧЕНЬ грамотная!

[glibs]

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

В смысле, мы сами себе выбираем заказчиков.

[slava09]

Цитата:

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

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

Если я смогу представить себе эту историю, то отвечу было ли мне смешно или нет

[DSPIC]

[ax_mct]

Цитата:

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

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

Смешно?

Это может называться Workshop или даже Proof Of Concept.
Вполне себе оправданно и часто именно так и нужно делать когда "иди туда не знаю куда но принеси то, что мне надо но я сам еще не знаю что точно мне надо".

[macklakov]

Цитата:

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

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

Смешно?

Хороший вам пользователь попался, честный и умный. С такими работать одно удовольствие.
Смысл большинства проектных документов тупо в том, чтобы переложить ответственность на заказчика. Все равно ведь ни заказчик, ни исполнитель не могут предусмотреть всех ньюансов и вариантов. А пользователи к тому же не понимают половину терминологии. Да и бизнес может поменяться в процессе внедрения. И технология может не заработать так, как описано в документации. В этом и кроется секрет такого высокого процента неудачных внедрений.
Получается натуральный АвтоВАЗ. Продукт от начала до конца делают, а потом начинают тестировать. В процессе изготовления неизбежно накапливается брак. Списать уже собранный автомобиль дорого, поэтому снижаются критерии качества.
Для сравнения, на заводах конкурентов, контроль качества непрерывный, поэтому брак выявляют и исправляют на стадиях когда это еще дешево сделать.
Попробуйте предложить клиенту одну из agile методологиий. Сейчас, к примеру, scrum в моде.
Будете планировать на 2 недели. И каждые 2 недели что-то работающее им в руки давать. На 2 недели планировать реально. А если кто и ошибется, то цена ошибки мнимальна. Т.к. каждые 2 недели делается разбор полетов, то буквально через месяц-другой качество заметно улучшается, а ошибки почти исчезают.

[Ivanhoe]

Проблема, как правило, не в методологии, а в том, что у заказчика обычно никто не хочет брать ответственность и обычно никто не хочет платить даже за "что-то сделанное за две недели".

Нет проблемы сделать и показать. Хоть по какой методологии. Есть проблема чтобы за это заплатить.

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

Agile - это хорошо, но не на практике в большом проекте ERP в России. На западе, при внедрении коробки (а это очень четкое понятие и со стороны внедренца и со стороны заказчика), это может быть хорошо и реально альтернатива классическому подходу.

[fed]

Agile вообще на больших проектах не работает. Ее хорошо использовать чтобы какие-нибудь пользовательские интерфейсы или печатные формочки на поздних стадиях проекта отлаживать. Гораздо интереснее бывает когда ты решения по настройке производства, например, принимаешь. Там чтобы последствия решения увидеть, надо запуститься и пару месяцев проработать. Никакой Agile в этих случаях не помогает.
Более того - в той же Турции такой огромный процент факапов на проектах как раз из за широкого применения agile. Сначала клиент через двухнедельные марафоны (или как оно там называется), тратит весь бюджет на какие-нить удобные формы для пользователя или отчетики, а потом после запуска выясняет, что ему основную финансовую отчетность толком не построить, сводное работает через одно место, себестоимость не считается и тп. А ему просто во время марафонов всего этого не показали (потому что за марафон не уложиться).

[Logger]

Цитата:

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

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

Интересно, а финдир, главбух и.т.п. участвовали в этих двухнедельных забегах ?
И если участвовали, то что им показывали ? Неужели они удовлетворились какими-то формочками, но не обеспокоились отчетностью, которую они на ЭТОМ будут готовить ?

[fed]

Цитата:

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

Интересно, а финдир, главбух и.т.п. участвовали в этих двухнедельных забегах ?
И если участвовали, то что им показывали ? Неужели они удовлетворились какими-то формочками, но не обеспокоились отчетностью, которую они на ЭТОМ будут готовить ?

Обычно они считают что все это доступно out-of-the-box в любой ERP. Поскольку вылизывание формочек - это типа отраслевая специфика. А отчеты и сводное - оно у всех есть. И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.
P.S. Ну и другая стандартная проблема - что топам некогда внедрением плотно заниматься, а тимлиды на местах (ака ключевые пользователи) обычно больше озабочены удобством ввода, чем глобальными задачами внедрения.

[ax_mct]

Цитата:

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

Обычно они считают что все это доступно out-of-the-box в любой ERP. Поскольку вылизывание формочек - это типа отраслевая специфика. А отчеты и сводное - оно у всех есть. И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.
P.S. Ну и другая стандартная проблема - что топам некогда внедрением плотно заниматься, а тимлиды на местах (ака ключевые пользователи) обычно больше озабочены удобством ввода, чем глобальными задачами внедрения.

Я бы добавил что например для британцев в принципе некомфортно и непонятно когда ты говоришь о ВОЗМОЖНЫХ и ПОТЕНЦИАЛЬНЫХ проблемах достаточно отдаленных и еще непонятных. Будет проблема - будем ее решать, чего парится заранее - примерно такой жизненный позитивизм. В этих условиях предупреждать о чем то глобальном - просто выглядеть чудаком. Не принято о плохом заранее говорить С одной стороны есть управление рисками но менталитет многое определяет. Наверное поэтому немцы считаются лучшими руководителями проектов

[ice]

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

[R.Safianov]

Цитата:

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

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

Смешно?

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

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

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

[macklakov]

Цитата:

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

И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.

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

[fed]

Цитата:

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

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

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

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

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

[R.Safianov]

Цитата:

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

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

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

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