AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Результаты опроса: Empower vs. Restrict
Empower 2 15.38%
Restrict 11 84.62%
Голосовавшие: 13. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.11.2017, 12:32   #1  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,568 / 2100 (78) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Empower vs. Restrict
Вот эта тема настроила меня на философский лад и рефлексию. На текущих проектах, которые ведутся в основном Microsoft Consulting Services, я сражаюсь с подходом многих коллег дать пользователям инструменты во всей полноте, а там пусть сами разбираются; в конце проверяем все и сразу, и показываем большой красный крест если что не так. Как раз в понедельник руководитель IT одного подразделения Glencore жаловался на издержки этого подхода, когда разгребание заказов на хранение, введенных задним числом до вступления в действие цены и контракта заняло 3 месяца, а разработка жесткого корсета с эвристикой и проверками на каждом шаге процесса - еще 3 месяца.

Апофеоз такого подхода к дизайну в стандартном приложении - это счет на покупку pending invoice: мы даем пользователю форму, он заполняет все данные, отправляет в workflow, проходит через все инстанции, чтобы в конце автоматическая разноска сказала: "нет счета ГК". Характерно, что Reset в distribution на этот момент уже не работает, и единственный вариант - это пересоздать строку счета, по сути ввести его заново.

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

Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?
За это сообщение автора поблагодарили: Ivanhoe (2).
Старый 20.11.2017, 10:28   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,186 / 4023 (139) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я по этому поводу всегда говорю: Если бы клиент был вменяемый, он бы сам внедрял, а не нас звал.
Если гайки на внедрении были чрезмерно закручены, то их в последствии достаточно легко отпустить. Обратный процесс - намного сложнее.
За это сообщение автора поблагодарили: belugin (5), Ivanhoe (1).
Старый 20.11.2017, 10:46   #3  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,591 / 1855 (69) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Считаю, что вся гибкость стандарта нужна для выбора оптимального решения задачи при внедрении. Пересмотр настроек и гибкости возможен в рамках нормального развития запущенного проекта.

А оставлять Аксапту (да и любую ERP) открытым конструктором типа Excel - не несет никаких плюсов, кроме минусов.
__________________
Ivanhoe as is..
Старый 20.11.2017, 13:25   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,500 / 4483 (157) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
На текущих проектах, которые ведутся в основном Microsoft Consulting Services, я сражаюсь с подходом многих коллег дать пользователям инструменты во всей полноте, а там пусть сами разбираются; в конце проверяем все и сразу, и показываем большой красный крест если что не так.
Очень похоже на работу фиговых фреймворков, которые позволяют разработать кучу интересных вещей, а потом в итоге ничего не работает.
Цитата:
Сообщение от EVGL Посмотреть сообщение
Апофеоз такого подхода к дизайну в стандартном приложении - это счет на покупку pending invoice: мы даем пользователю форму, он заполняет все данные, отправляет в workflow, проходит через все инстанции, чтобы в конце автоматическая разноска сказала: "нет счета ГК". Характерно, что Reset в distribution на этот момент уже не работает, и единственный вариант - это пересоздать строку счета, по сути ввести его заново.
Помнится, давным давно появилось такое понятие, как pit of success (применительно к API, главным образом): такой подход к разработке фреймворка или системы, при котором их пользователь будет "автоматически" двигаться в нужном направлении и достигать своих целей, как бы катиться со склона, а не окажется вынужден пробираться вперед так, будто идет по минному полю.

Цитата:
Сообщение от EVGL Посмотреть сообщение
Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?
Тут важно уточнить, чье именно мнение спрашивается:
  • с точки зрения, к примеру, разработчика/консультанта, несколько лет проработавшего в режиме DevOps, разумеется, лучше жесткий корсет + по возможности настройки его жесткости, регулируемые специально обученными людьми с головой на плечах.
  • с точки зрения какого-нить продажника лучше куча классных фич, которые можно показать на пресейле, и плевать, что их реализация дырява, как дуршлаг, а их поддержка после внедрения превратится в ночной кошмар.
Позволю себе привести вольный перевод заметки по ссылке выше касаемо pit of success:
Цитата:
По мере усложения системы "окружающий ландшафт" обычно становится хуже, а не лучше, и это вполне объяснимо: новые части системы, как правило, основаны на уже существующих частях. И если, допустим, часть существующего "ландшафта" испещрена ухабами, то при добавлении нового функционала люди, естественно, скопируют их, создав ЕЩЕ БОЛЬШЕ ухабов, в которые смогут попасть пользователи.
Вскоре может сложиться ситуация, когда для любого продвижения вперед потребуются очень сложные руководства и тому подобное. Шагните влево, избегайте острых шипов, не сломайте лодыжки в одной из этих ям, проберитесь через вершины двух холмов, не разбейтесь о возможные препятствия на пути и, возможно, если вам повезет, вы сможете заявить о своей победе.
Теперь вы можете попробовать повысить эффективность вашей организации либо за счет обучения всех сотрудников этим правилам (полагаю, это не помешает, некоторые правила могут быть весьма полезными), либо за счет улучшения ландшафта. Измените форму некоторых из тех холмов так, чтобы люди с большей вероятностью двигались в правильном направлении. Переместите конечную точку маршрута туда, куда будет проще добраться. И, наконец, разравняйте уже эти ухабы, чтобы в новом функционале люди перестали их копировать!
Если следовать этому пути, то через какое-то время у вас будет все больше и больше пользователей, которые автоматически идут правильными путями и достигают успеха. Они могут даже не знать, что это - благодаря вам, они просто внезапно начнут достигать успеха, делая простые и очевидные вещи, словно скатываясь вниз со склона.
За это сообщение автора поблагодарили: mazzy (2), Ivanhoe (2).
Старый 20.11.2017, 17:53   #5  
kashperuk is offline
kashperuk
Senior SDE, Dynamics AX
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,353 / 2048 (77) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
В Extensibility проекте мы исходим как раз из "корсета" - то есть открываем только те возможности, которые кто-то конкретно запросил. Это позволит там расслабить ограничения позже. Обратный подход не подходит, так как он бы ломал backward compatibility

Да и вообще:
https://en.wikipedia.org/wiki/Fail-fast
За это сообщение автора поблагодарили: Ivanhoe (1).
Старый 20.11.2017, 18:05   #6  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,748 / 575 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от EVGL Посмотреть сообщение
Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?
3) 1 но при этом отвечать только за описанные и согласованные сценарии.
И клиенту гибко и партнеру тепло.
За это сообщение автора поблагодарили: sukhanchik (2).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Restrict access to group form control in the grid Blog bot DAX Blogs 0 17.10.2016 23:11
dynamicsaxhints: How to restrict view datasource fields Blog bot DAX Blogs 0 22.03.2016 09:11
atinkerersnotebook: Use Filters To Restrict Sellable Products To Customers Blog bot DAX Blogs 0 07.07.2014 20:16
atinkerersnotebook: Restrict Field Access By Security Role Blog bot DAX Blogs 0 15.04.2014 15:11
atinkerersnotebook: Restrict User Access To Certain Companies Through Roles Blog bot DAX Blogs 0 11.04.2014 14:11
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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