AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.10.2015, 09:31   #61  
axm2013 is offline
axm2013
Banned
 
668 / 62 (0) ++++
Регистрация: 04.12.2013
Цитата:
Сообщение от Bobkov Посмотреть сообщение
... то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера.
Вопрос в том возможно ли такое на первоначальном этапе.
Общие документы целеполагающего характера никто не отрицает в методологиях. А вот подробные...

В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"
Старый 15.10.2015, 10:25   #62  
gl00mie is offline
gl00mie
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Most Valuable Professional
 
3,468 / 4365 (152) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от Bobkov Посмотреть сообщение
Позволю себе выразить мнение, что причина тут не в организации "консалтинг" или "внутренний проект", а в мотивации исполнителя.
Очень тонко подмечено
Цитата:
Сообщение от Bobkov Посмотреть сообщение
В общих чертах, это выглядит так:
- Если сотрудник сидит на окладе или подрядчик на таймшитах, то они оба будут заинтересованы в том чтобы поменьше писать документов, а побольше удовлетворять пользователей.
- А если сотруднику обещана большая премия за результат или подрядчик привлечен на фикс-прайс, то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера.
В переводе на русский, если сотрудник заинтересован в результате, то он документирует работу по проекту ("получите, распишитесь"), а если в самом процессе безотносительно результата, то концентрируется на удовлетворении хотелок пользователей ("чего изволите?")
Цитата:
Сообщение от axm2013 Посмотреть сообщение
В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости.
В переводе на русский: консультанты не разбирались в бизнесе заказчика.
Старый 15.10.2015, 11:07   #63  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
КОРУС Консалтинг
 
3,469 / 1646 (61) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"
А вот это уже вопрос к методологии. Если вы возлагаете ответственность на ключевых - их нужно сначала обучить системе, подходам к проектированию, той же методологии - на этих проектах была такая задача выполнена?

Показы, я так понимаю, после реализации. Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками? Это очень сложно делать если вы пишите космос - ну так не надо тогда Акс внедрять. Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.
__________________
Ivanhoe as is..
Старый 15.10.2015, 11:45   #64  
axm2013 is offline
axm2013
Banned
 
668 / 62 (0) ++++
Регистрация: 04.12.2013
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А вот это уже вопрос к методологии. Если вы возлагаете ответственность на ключевых - их нужно сначала обучить системе, подходам к проектированию, той же методологии - на этих проектах была такая задача выполнена?
Начнем с того что естественно представление о системе у пользователей было, но для полноценного понимания ключевой пользователь должен выйти на уровень среднего консультанта имхо (так в общем то и происходит но со временем). В ином случае он полагается на консультанта, который априоре не знает всех тонкостей, считающихся порой само собой разумеющимися для ключевого. При этом отмечу что ключевые пользователи порой тоже могут и не знать определенных ньюансов которые решаются уровнем ниже.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками?
Ровно так и делали и выяснялось порой что не учтены определенные ньюансы серъезно влияющие на дальнейших ход всей разработки.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.
В итоге приходим к тому что по факту имеем необходимость частого общения с пользователями, на что и нацелена agile методология
Старый 15.10.2015, 12:10   #65  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,251 / 247 (11) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Тут ещё надо иметь в виду, что зачастую требование пользователя звучит как "сделайте как в Экселе/1С/итд"(с) Т.е. требуемая функциональность имеется, но выглядит иначе. А у пользователя срабатывает инстинкт "выглядит не так, значит не то". Ведь в принципе главбуху должно быть всё равно, как выглядит план счетов - главное, чтобы он был.
__________________
С уважением,
Вячеслав
Старый 15.10.2015, 13:11   #66  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
КОРУС Консалтинг
 
3,469 / 1646 (61) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А классика отвергает общение с пользователями? Я вот очень плохо отношусь, когда команда не сидит у клиента и не общается с пользователями. Исключения делаем на очень удаленных проектах, и то периодичность присутствия все равно ритмична на всех стадиях, даже разработки. Ну и современные средства общения - наше все.
__________________
Ivanhoe as is..
Старый 15.10.2015, 13:58   #67  
axm2013 is offline
axm2013
Banned
 
668 / 62 (0) ++++
Регистрация: 04.12.2013
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А классика отвергает общение с пользователями?
Скажем так: на этом не заостряется внимание + нет общих подходов с правами и обязанностями пользователей системы на разных этапах (т.е. никаких свиней и куриц к примеру).
Старый 19.10.2015, 17:38   #68  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,869 / 1984 (74) ++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А классика отвергает общение с пользователями?
Водопад скорее - "Мы сделаем то-то за год и миллион долларов, если что-то в процессе меняется, давайте дополнительно денег и времени"

Agile скорее "Мы за месяц решим вам наиболее важную проблему а дальше посмотрим что будет самое важное"

Типа изменения - по-умолчанию


За это сообщение автора поблагодарили: twilight (1).
Старый 20.10.2015, 09:51   #69  
AlexeyS is offline
AlexeyS
Участник
 
315 / 204 (7) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от pitersky Посмотреть сообщение
Тут ещё надо иметь в виду, что зачастую требование пользователя звучит как "сделайте как в Экселе/1С/итд"(с) Т.е. требуемая функциональность имеется, но выглядит иначе. А у пользователя срабатывает инстинкт "выглядит не так, значит не то". Ведь в принципе главбуху должно быть всё равно, как выглядит план счетов - главное, чтобы он был.
Это вопрос формы и содержания.
Привычная форма помогает быстрее понять содержание, именно поэтому у большинства важных типов документов существует регламентированная форма с отступами, шрифтами и прочим.

Купите клавиатуру с нестандартной раскладкой и попечатайте вслепую,
ведь в принципе вам должно быть все равно как выглядит клавиатура - главное, что все буквы и цифры есть
За это сообщение автора поблагодарили: Bobkov (1).
Старый 20.10.2015, 14:13   #70  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,251 / 247 (11) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
Купите клавиатуру с нестандартной раскладкой и попечатайте вслепую,
ведь в принципе вам должно быть все равно как выглядит клавиатура - главное, что все буквы и цифры есть
это понятно, что при переходе с абака или арифмометра на калькулятор я некоторое время буду считать медленнее, чем раньше. ну и что? всё равно такой переход оправдан в более-менее длинной перспективе
__________________
С уважением,
Вячеслав
Старый 18.01.2016, 17:44   #71  
axm2013 is offline
axm2013
Banned
 
668 / 62 (0) ++++
Регистрация: 04.12.2013
Даже до Грефа дошло
"Кто не освоит аgile сегодня, тем придется в текущих бизнес-процессах быть лузерами завтра"
Греф
http://www.vedomosti.ru/finance/arti...ormi-sberbanka
Старый 19.01.2016, 11:44   #72  
axm2013 is offline
axm2013
Banned
 
668 / 62 (0) ++++
Регистрация: 04.12.2013
PS кстати мысли Грефа довольно сильно определяют саму архитектуру решения (явно спер их откуда то).
Собственно все сводится к кучке отдельных независимых сервисов. В чем то перекликается с идеями принятыми в Гугле (один человек один сервис) судя по книжке о тестировании там.

Только при таком решении обеспечивается быстрое тестирование. В ДАХ 12 есть как понимаю какие то подвижки в этом направлении тоже. Надеюсь будет продолжение и в 7 ке.
Старый 07.06.2017, 18:21   #73  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,326 / 965 (41) +++++++
Регистрация: 17.12.2003
Адрес: Moscow
Подкину-ка еще на вентилятор - как раз статью написал.

Постараюсь в данной прадигме объяснить разницу между методологиями внедрения PMBOK и новомодным Agile.

Сразу скажу - я не против и того и того. Да хоть PrinceII - мне все равно. Больше методологий хороших и разных.Нет "хороших" и "плохих" методологий, каждая хороша для решения определенного класса задач или типа проектов. И настоящий РП должен уметь их комбинировать: например, PMBOK на этапе комплексной оценки проекта и глобального руководства проектом, и Scrum - для реализации конкретной функциональности покрытия As is-to be GAP.

И когда я слышу "только хордкор, только PMBOK"!! или "В жопу документацию, рефакторинг рулит, Аджайл - наше все!!" - мне становится страшновато. Да, я понимаю что PMBOK - очень перегружен рядом процедур по каждой фазе проекта, куча процедур и документов. И, действительно, зачастую подготовка проектной документации занимает очень много ресурсов, которые так необходимы на самом внедрении. Да, я понимаю Agile это тоже серьезная методология, а не "раз-раз и в продакшен". Но когда мне заявляют, что только он годится для настройки ERP, мне хочется привести следующую аналогию, когда Вам нужна электрика в новую квартиру:

PMBOK
- Анализ и дизайн:
Покажите план квартиры. А что вам нужно? А где будет спальня? А тумбочки будут? А какие? А розетки там какие? Как не нужны, а как вы будете телефон заряжать? А где телевизор? А какие кабели класть? Или лучше канал сделать? А домашний кинотеатр будет? А колонки сзади? А почему бы сразу аккустические провода в стены не убрать? Это что - кухня? А какая кухня будет, вы уже заказали? что значит потом - необходимо сначала заказать кухню, чтобы сделать розетки на высоте столешницы, и вывести силовые кабели под варочную панель, духовой шкаф и микроволновку. И так далее.
- Разработка и Тестирование:
Чертим схему, понимаем нагрузку, выбираем толщину кабелей и пакетники, не забываем УЗО, рисуем распределительный шкаф. Согласуем с заказчиком, объясняем что розетки двигать нельзя, подписываем у него. Сдаем схему на экспертизу, получаем разрешение и документы. Говорим заказчику сколько розеток и выключателей понадобится.
- Внедрение:
Нагоняем рабочих, они штробят стены и сверлят углубления под подрозетники. Приводим электриков, они монтируют разводку, точки и шкаф. Проверяем. Проветриваем дым, исправляем, проверяем еще раз.
- Сдача в эксплуатацию и Сопровождение:
Проверка вместе с заказчиком. Ответы на безумные вопросы в стиле "ой, мы другую спальню купили, а можно вот эти розетки передвинуть", апеллируя к подписанному заказчиком плану. Возможно, все-таки двигая розетки, но по двойному тарифу.

Agile
Так, братва, берем кучу проводов, розетки и лампочки. Будем сверлить там, куда укажет заказчик.

С Уважением,
Георгий
Старый 08.06.2017, 02:44   #74  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,898 / 781 (30) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от George Nordic Посмотреть сообщение
"В жопу документацию, рефакторинг рулит, Аджайл - наше все!!" - мне становится страшновато.
Старая песня о главном. Зачастую используется псевдо-agile, с целью не писать документации. В то время как раельно agile не исключает документации, просто она пишется зандим числом. Т.е. решение и дизайн задокументированы, но нет документации по забракованным прототипам и промежуточным итерациям. И если клиент за эту документацию готов платить.
В общем случае, сопровождающая документация крайне рекомендуется. Но если это разовая поделка, то документация это просто дополнительные издержки.
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Agile
Так, братва, берем кучу проводов, розетки и лампочки. Будем сверлить там, куда укажет заказчик.
Нет, Agile это: "Так ребята, наш клиент хочет освещение и розетки. Вот контакт клиента, вот контакт его жены, у них узнаете детали. Что делать вы лучше меня знаете. Если какие сложности, обращайтесь ко мне."
Это другой момент в agile, про который все норовят забыть. Agile это само-организующаяся команда. А это подразумевает что она состоит из высококлассных честолюбивых профессионалов. Это способ развязать руки звездным и дорогим экспертам, которые лучше менеджера знают что и как надо делать.
Если уж аналогии проводить, то члены agile команды это больше не электрики, а дизайнеры интерьера. Они не боятся эксперементировать и предлагать решения, о которых клиент и не догадывался. Есть десятки способов поставить свет. Можно сосредоточиться на энерго-сбережении, можно сделать рабочий свет, можно "сделать красиво", можно изменяющийся под настроение или погоду. А можно светом подчеркнуть статус клиента. К примеру стелаж с наградами или семейными реликвиями.
Т.е. типовой сценарий специалиста в agile это прототипирование. С помощь временных источников света создать приглушенный свет в гостинной и подсветить какой-то предмет в углу или на стене. И спросить клиента, как тому эффект. Тут же переместить в другое место и сравнить. И когда клиент проникнется и скажет:"вот оно!", тогда уже заниматься собственно прокладкой электрики. Если клиент захочет. В музеях и на выставках, к примеру, так и оставляют временные, переносные источники света. Просто провода с прохода убирают и все.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 08.06.2017 в 02:47.
За это сообщение автора поблагодарили: apanko (2), Sancho (2).
Старый 08.06.2017, 10:36   #75  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
 
135 / 91 (4) ++++
Регистрация: 11.01.2006
+
agile может себе позволить специалист уровня архитектора, а никак не программиста.
Старый 08.06.2017, 11:32   #76  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,869 / 1984 (74) ++++++++
Регистрация: 16.01.2004
Адрес: Москва
По поводу того, кому подходит и что надо освоить можно погуглить "Agile Maturity model" или залипнуть на вот эту схему
За это сообщение автора поблагодарили: ax_mct (2).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Вебинар "Qlik Sense: новые способы работы с информацией" 23 января 2015 года в 11.00 George Nordic Обучение 1 20.01.2015 10:29
rumicrosofterp: AX 2012 R3: Вебинар "Новые технологии управления проектами" Blog bot Microsoft и системы Microsoft Dynamics 4 02.12.2014 10:04
"МЕЛОМАН-MARWIN" создает единую систему управленческого учета по холдингу на базе Microsoft Dynamics AX с помощью готового решения "OmegaPlus: Бюджетирование и казначейство" N.Shmel Полезное по Microsoft Dynamics 0 29.07.2014 11:54
rumicrosofterp: AX 2012: Лабораторный класс "WHS Расширенное управление складом в AX 2012 R3. Новый модуль, новые возможности" Blog bot Microsoft и системы Microsoft Dynamics 2 16.05.2014 10:19
Мы ищем программиста AX 2009 Модули: "Расчеты с клиентами", "Производство", "Расчеты с поставщиками", "Управление запасами", "Основные средства", Москва MikhailK2 Рынок труда Microsoft Dynamics 0 11.12.2013 15:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:05.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.