![]() |
#21 |
Участник
|
А я подумал, что в опросе под Microsoft Dynamics подразумевается именно АХ.
|
|
![]() |
#22 |
Участник
|
Цитата:
Сообщение от fed
![]() Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать... для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте. так что ERP подкоряется потихоньку под Agile тоже )) мир динамичен. подходы меняются. |
|
![]() |
#23 |
Moderator
|
Цитата:
Сообщение от Daniil
![]() вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте. так что ERP подкоряется потихоньку под Agile тоже )) мир динамичен. подходы меняются. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
![]() |
#24 |
Шаман форума
|
Цитата:
Сообщение от Daniil
![]() С бюджетом верно заметили. Но тут в двух словах не ответишь. Очень хорошо отвечает на подобные вопросы Майк Кон в одной из своих книг. Тут просто совсем иной принцип. Найду в книге - напишу. Тут целая философия, честное слово. Но она работает! Потому что заказчик получает то что хочет. Но, как правильно Вы заметили идеальная картина - это "гибкий" бюджет. ![]() В случае разработки сторонним консультантом для отдельного от него заказчика встаёт таки вопрос бюджета. То есть консультанту интересно получить с проекта прибыль, а не сидеть годами на зарплате сочиняя формочки с овальными кнопками. Посему выгоднее всего для консультанта напяливание всем подряд типового решения для типовых задач. В экономической теории это известно как "эффект масштаба" - то есть гибкость системы сознательно ограничивается во имя тиражируемости. С коробочными системами это - наилучший для консультанта вариант, так как ему (консультанту) полагается покрывать постоянные издержки, а также одновременно ваять для нескольких заказчиков. Альтернативный подход - выдача клиенту технологии для in-house разработки, при которой вполне подходит и описанный Вами подход. P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо". Рисков как-то меньше. И, кстати, книжка - вещь безусловно тиражируемая, там так и написано - мол, тираж такой-то. А представьте, если бы писатель под каждого читателя отдельную книжку писал - одному подлиннее, другому покороче, третьему сюжет подправить, четвёртому на другой язык перевести и оглавление поудобнее... небось не так весело было бы методологу ![]()
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
|
За это сообщение автора поблагодарили: Ivanhoe (5), gl00mie (2), Player1 (1), handy-comp (2). |
![]() |
#25 |
Участник
|
Тут главное на первом месяце уволить директора по IT, который допустил такой подход.
|
|
![]() |
#26 |
Участник
|
Не везде есть директора IT, где-то простой начальник отдела, или даже бюро. А заму который курирует It-отдел глубоко пофиг как эти парни в свитерах делают работу, лишь бы бухи не ворчали и производственники не ругались.
Последний раз редактировалось Player1; 19.11.2013 в 10:29. Причина: очепятка |
|
![]() |
#27 |
Шаман форума
|
Цитата:
И ещё. Наверное, не нужно смешивать такие разные штуки, как разработка тиражного продукта (который затем расставляется пользователям as-is), и доработку продукта под конкретный проект под задачу, сформулированную как "нарисуй мне кунгуру". То есть при разработке Майкрософтом хоть Динамикса, хоть операционной системы весь "скрам-и-аджайл" - по сути, междусобойчик разработчиков. То есть никто в здравом уме никогда не понесёт при разработке Windows или Ax никакие "ежедневные шплинты" дяде Пете из Выхино. И даже партнёрам Динамикса система достанется "как получилось" - а дальше делайте с ней, что хотите. Запросы конечного пользователя в лучшем случае поступят один раз - на входе. Тему же завели о применении подобных подходов с лепкой системы на ходу именно на внедрении фирмой-консультантом конечному пользователю, прямо перед "чел овнером от заказчика в ежедневных стенд-апах" - так при таком подходе либо сроки и бюджет изначально резиновые, либо команда получит под плановый срок сдачи "круглосуточный стенд-ап", "ночной фон-колл" и прочие "мозговые штормы", которые хорошее проектное управление должно как бы минимизировать.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#28 |
Участник
|
Цитата:
Даже не представлял себе что их столько ![]() |
|
![]() |
#29 |
Moderator
|
Вообще методология часто приобретает характер религии для программистов - со своей обрадностью (типа 10-минутных стенд-ап митингов), терминологией, отцами церкви и их трудами, бродячими проповедниками и тп. То есть - возможно сами авторы методологии к этому результату и не стремились, но в руках последователей их идеи приняли характер первобытной религии типа шаманизма.
Последний раз редактировалось fed; 20.11.2013 в 11:34. |
|
![]() |
#30 |
Участник
|
«Хочешь разбогатеть – придумай свою религию». (С) Рон Хаббард
|
|
![]() |
#31 |
Участник
|
Цитата:
Сообщение от komar
![]() Наверное, не нужно смешивать такие разные штуки, как разработка тиражного продукта и доработку продукта под конкретный проект под задачу. То есть при разработке Майкрософтом хоть Динамикса, хоть операционной системы весь "скрам-и-аджайл" - по сути, междусобойчик разработчиков. То есть никто в здравом уме никогда не понесёт при разработке Windows или Ax никакие "ежедневные шплинты" дяде Пете из Выхино. И даже партнёрам Динамикса система достанется "как получилось" - а дальше делайте с ней, что хотите. Запросы конечного пользователя в лучшем случае поступят один раз - на входе.
Цитата:
Управление проектами происходит по-разному на разных уровнях масштаба и абстракции. Есть уровень команды или отдельной функции (около 10 человек), уровень проекта (от 50 до 5000 человек, работающих над определенным релизом) и уровень продукта (несколько релизов, которыми управляют менеджеры). Методы гибкой разработки прекрасно работают на уровне команды, формальные методы прекрасно работают на уровне проекта, а методы долгосрочного стратегического планирования прекрасно работают на уровне продукта. Однако, люди редко работают одновременно на нескольких уровнях; на самом деле, обычно проходят годы, прежде чем отдельный человек переходит от работы на одном уровне к работе на другом. Из-за этого люди думают, что методы, эффективные на одном уровне, должны быть применены и к другим, что зачастую приводит к трагическим последствиям. Мораль такова: небольшие слаженные группы работают иначе, нежели масштабные распределенные организации, поэтому выбирайте подход, соответствующий конкретной ситуации.
Последний раз редактировалось gl00mie; 20.11.2013 в 14:08. Причина: стилистика |
|
![]() |
#32 |
Участник
|
А может скрам подходит для поддержки большого АХ решения?
|
|
![]() |
#33 |
Участник
|
Цитата:
Сообщение от fed
![]() Вообще методология часто приобретает характер религии для программистов - со своей обрадностью (типа 10-минутных стенд-ап митингов), терминологией, отцами церкви и их трудами, бродячими проповедниками и тп. То есть - возможно сами авторы методологии к этому результату и не стремились, но в руках последователей их идеи приняли характер первобытной религии типа шаманизма.
Вообще идеализация чего-то - это от недостатка опыта и знаний. Под разные задачи нужны разные методологии |
|
![]() |
#34 |
Шаман форума
|
Цитата:
Есть такая мысль, что программирование вообще куда ближе к искусству, чем к сборочному производству. А картину по методологии не очень-то нарисуешь. То есть критерий готовго результата - конечно есть. А вот пошаговую инструкцию для дрессированной обезьяны по достижению этого результата - поди придумай... А где не сформулировать инструкцию - формулируется ритуал.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#35 |
Участник
|
По моему мнению вся суета вокруг "гибких" методологий проекта основана на предположении, что этот подход поможет решить проблему не адекватного заказчика. Может в каких-то конкретных случаях и удастся, но далеко не всегда, особенно в проектах внедрения ERP - систем.
Вообще в последнее время термин "внедрение" часто понимается в его буквальной трактовке, как "достижение результата при преодолении сопротивления окружающей среды". При таком подходе становится понятным интерес к гибким методологиям. |
|
![]() |
#36 |
Шаман форума
|
В буквальной трактовке внедрять твёрдый предмет легче
![]()
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#37 |
Участник
|
Цитата:
В буквальной трактовке внедрять твёрдый предмет легче
|
|
![]() |
#38 |
Шаман форума
|
У меня внедрение с менее экзотическими действиями ассоциируется. Впрочем, не будем уходить от темы
![]()
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#39 |
Участник
|
Цитата:
Сообщение от vaavr
![]() По моему мнению вся суета вокруг "гибких" методологий проекта основана на предположении, что этот подход поможет решить проблему не адекватного заказчика. Может в каких-то конкретных случаях и удастся, но далеко не всегда, особенно в проектах внедрения ERP - систем.
Вообще в последнее время термин "внедрение" часто понимается в его буквальной трактовке, как "достижение результата при преодолении сопротивления окружающей среды". При таком подходе становится понятным интерес к гибким методологиям. а набор формальных правил и следование им дает если и не эффективный результат, то по меньшей мере ощущение контроля процесса, что уже немало ![]() |
|
![]() |
#40 |
Участник
|
в принципе может, если группировать куски хотелок в более-менее объемные и логичные блоки работ (Юзер Стори). но это вряд-ли получится, т.к. в поддержке более высокая степень неопределенности- не знаешь что вылезет завтра или через час.
Для поддержки более подходит Kanban. как раз такой пример применения Kanban в поддержке описывается в книге "SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ": " Я сам из разработчиков, так что о сути технической поддержки я знал мало. Но я не собирался "ворваться и всѐ поменять". Мне нужен был менее конфликтный подход, который бы, тем не менее, научил нас нужному, убрал бы ненужное, и при этом был бы лѐгок в изучении. Были рассмотрены следующие кандидаты: 1. Scrum – хорошо отработанный и проверенный подход для команд разработчиков. 2. Kanban – новый и непроверенный подход, который зато хорошо ложился на принципы Lean, которых нам как раз и не хватало. После бесед с менеджерами, принципы Kanbanа и Lean показались хорошими ответами на вопросы, которые нас мучили. С их точки зрения спринты нам не очень подходили, так как приоритеты менялись каждый день. Таким образом, логичной отправной точкой был выбран Kanban, несмотря даже на то, что никто из нас не знал, что же это за зверь " |
|