Scrum (Agile) and CRM development

[fed]

Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать...

[Ivanhoe]

Поддержу. В опросе стоило бы явно прописать MS CRM, а не весь Dynamics.

[Daniil]

Цитата:

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

Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать...

вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.

[fed]

Цитата:

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

вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.

Для справки - ASAP основан на идее, что вместо того чтобы делать детальное исследование бизнес-процессов до внедрения и дизайн процессов после внедрения, мы просто берем некие типовые бизнес-процессы и настраиваем систему под них (не запариваясь о том что у заказчика сейчас и как он будет менять свой бизнес под новые бизнес-процессы). Я не буду обсуждать этот подход в деталях (коротко говоря - это такой большевизм от внедрения). Могу только сказать что НИ МАЛЕЙШЕГО отношения к Agile этот подход не имеет. Вполне себе классический водопад, просто из него убрали стадию изучения реального заказчика и заменили на библиотеку сферических заказчиков в вакууме..

[Daniil]

Цитата:

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

Для справки - ASAP основан на идее, что вместо того чтобы делать детальное исследование бизнес-процессов до внедрения и дизайн процессов после внедрения, мы просто берем некие типовые бизнес-процессы и настраиваем систему под них (не запариваясь о том что у заказчика сейчас и как он будет менять свой бизнес под новые бизнес-процессы). Я не буду обсуждать этот подход в деталях (коротко говоря - это такой большевизм от внедрения). Могу только сказать что НИ МАЛЕЙШЕГО отношения к Agile этот подход не имеет. Вполне себе классический водопад, просто из него убрали стадию изучения реального заказчика и заменили на библиотеку сферических заказчиков в вакууме..

да, сори, это я дезинформировался по поводу ASAP .
это я впечатлился примером одного успешного крупного проекта по SAP-там использовали многие принципы Agile. и заодно говорили про ASAP. вот я и прикрутил его втихаря )).
тем не менее, в этом проекте во всю использовали некоторые принципы SCRUM: команда, один Product owner, спринты+релиз план.

даже еще прикольнее: они управляли одновременно несколькими проектами ASAP при помощи спринтов, составляя релиз-план (хотя я не знаю, возможно в ASAP положено и так использовать спринты, но тем не менее - это одна из фишек SCRUM).

[mnt_dx]

А я подумал, что в опросе под Microsoft Dynamics подразумевается именно АХ.

[S.Kuskov]

Цитата:

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

P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо".

ТОП-100 Аджайл книг всех времен (на конец 2013 года)

Даже не представлял себе что их столько

[fed]

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

[AlexeyS]

Цитата:

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

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

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

[komar]

Цитата:

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

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

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

А где не сформулировать инструкцию - формулируется ритуал.

[S.Kuskov]

«Хочешь разбогатеть – придумай свою религию». (С) Рон Хаббард

[mnt_dx]

А может скрам подходит для поддержки большого АХ решения?

[Daniil]

Цитата:

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

А может скрам подходит для поддержки большого АХ решения?

в принципе может, если группировать куски хотелок в более-менее объемные и логичные блоки работ (Юзер Стори). но это вряд-ли получится, т.к. в поддержке более высокая степень неопределенности- не знаешь что вылезет завтра или через час.
Для поддержки более подходит Kanban. как раз такой пример применения Kanban в поддержке описывается в книге "SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ":

"
Я сам из разработчиков, так что о сути технической поддержки я знал мало.
Но я не собирался
"ворваться и всѐ поменять".
Мне нужен был менее
конфликтный
подход, который бы, тем не менее,
научил нас нужному, убрал бы ненужное, и при этом был бы лѐгок в изучении.
Были рассмотрены следующие кандидаты:
1. Scrum – хорошо отработанный и проверенный подход для команд разработчиков.
2. Kanban – новый и непроверенный подход, который зато хорошо ложился на принципы Lean, которых нам как раз и не хватало.
После бесед с менеджерами, принципы Kanbanа и Lean показались хорошими ответами на вопросы, которые нас мучили.
С их точки зрения спринты нам не очень подходили, так как приоритеты
менялись каждый день.
Таким образом, логичной отправной точкой был выбран
Kanban, несмотря
даже на то, что никто из нас не знал, что же это за зверь
"

[komar]

Цитата:

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

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

Нас бросала молодость на Кронштадтский лёд,
Нас водила молодость в сабельный поход.
Если б не бросали нас головой об лёд,
То и не пошли бы мы в сабельный поход...

Но, с другой стороны, будет о чём вспомнить на свалке

Цитата:

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

тем не менее, в этом проекте во всю использовали некоторые принципы SCRUM: команда, один Product owner, спринты+релиз план.
даже еще прикольнее: они управляли одновременно несколькими проектами ASAP при помощи спринтов, составляя релиз-план (хотя я не знаю, возможно в ASAP положено и так использовать спринты, но тем не менее - это одна из фишек SCRUM).

Ну и каша...Страшно далеки они от народа...

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

[vaavr]

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

[AlexeyS]

Цитата:

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

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

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

[komar]

В буквальной трактовке внедрять твёрдый предмет легче

[vaavr]

Цитата:

В буквальной трактовке внедрять твёрдый предмет легче

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

[komar]

У меня внедрение с менее экзотическими действиями ассоциируется. Впрочем, не будем уходить от темы