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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.10.2015, 09:31   #61  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Bobkov Посмотреть сообщение
... то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера.
Вопрос в том возможно ли такое на первоначальном этапе.
Общие документы целеполагающего характера никто не отрицает в методологиях. А вот подробные...

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

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

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

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.
В итоге приходим к тому что по факту имеем необходимость частого общения с пользователями, на что и нацелена agile методология
Старый 15.10.2015, 12:10   #65  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Тут ещё надо иметь в виду, что зачастую требование пользователя звучит как "сделайте как в Экселе/1С/итд"(с) Т.е. требуемая функциональность имеется, но выглядит иначе. А у пользователя срабатывает инстинкт "выглядит не так, значит не то". Ведь в принципе главбуху должно быть всё равно, как выглядит план счетов - главное, чтобы он был.
__________________
С уважением,
Вячеслав
Старый 15.10.2015, 13:11   #66  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А классика отвергает общение с пользователями? Я вот очень плохо отношусь, когда команда не сидит у клиента и не общается с пользователями. Исключения делаем на очень удаленных проектах, и то периодичность присутствия все равно ритмична на всех стадиях, даже разработки. Ну и современные средства общения - наше все.
__________________
Ivanhoe as is..
Старый 15.10.2015, 13:58   #67  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А классика отвергает общение с пользователями?
Скажем так: на этом не заостряется внимание + нет общих подходов с правами и обязанностями пользователей системы на разных этапах (т.е. никаких свиней и куриц к примеру).
Старый 19.10.2015, 17:38   #68  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А классика отвергает общение с пользователями?
Водопад скорее - "Мы сделаем то-то за год и миллион долларов, если что-то в процессе меняется, давайте дополнительно денег и времени"

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

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


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

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

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

Постараюсь в данной прадигме объяснить разницу между методологиями внедрения 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
 
2,129 / 915 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от 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), Васыо (1).
Старый 08.06.2017, 10:36   #75  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
+
agile может себе позволить специалист уровня архитектора, а никак не программиста.
Старый 08.06.2017, 11:32   #76  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
По поводу того, кому подходит и что надо освоить можно погуглить "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, время: 05:35.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.