Empower vs. Restrict

[EVGL]

Вот эта тема настроила меня на философский лад и рефлексию. На текущих проектах, которые ведутся в основном Microsoft Consulting Services, я сражаюсь с подходом многих коллег дать пользователям инструменты во всей полноте, а там пусть сами разбираются; в конце проверяем все и сразу, и показываем большой красный крест если что не так. Как раз в понедельник руководитель IT одного подразделения Glencore жаловался на издержки этого подхода, когда разгребание заказов на хранение, введенных задним числом до вступления в действие цены и контракта заняло 3 месяца, а разработка жесткого корсета с эвристикой и проверками на каждом шаге процесса - еще 3 месяца.

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

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

Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?

[fed]

Я по этому поводу всегда говорю: Если бы клиент был вменяемый, он бы сам внедрял, а не нас звал.
Если гайки на внедрении были чрезмерно закручены, то их в последствии достаточно легко отпустить. Обратный процесс - намного сложнее.

[Ivanhoe]

Считаю, что вся гибкость стандарта нужна для выбора оптимального решения задачи при внедрении. Пересмотр настроек и гибкости возможен в рамках нормального развития запущенного проекта.

А оставлять Аксапту (да и любую ERP) открытым конструктором типа Excel - не несет никаких плюсов, кроме минусов.

[gl00mie]

Цитата:

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

На текущих проектах, которые ведутся в основном Microsoft Consulting Services, я сражаюсь с подходом многих коллег дать пользователям инструменты во всей полноте, а там пусть сами разбираются; в конце проверяем все и сразу, и показываем большой красный крест если что не так.

Очень похоже на работу фиговых фреймворков, которые позволяют разработать кучу интересных вещей, а потом в итоге ничего не работает.

Цитата:

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

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

Помнится, давным давно появилось такое понятие, как pit of success (применительно к API, главным образом): такой подход к разработке фреймворка или системы, при котором их пользователь будет "автоматически" двигаться в нужном направлении и достигать своих целей, как бы катиться со склона, а не окажется вынужден пробираться вперед так, будто идет по минному полю.

Цитата:

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

Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?

Тут важно уточнить, чье именно мнение спрашивается:

• с точки зрения, к примеру, разработчика/консультанта, несколько лет проработавшего в режиме DevOps, разумеется, лучше жесткий корсет + по возможности настройки его жесткости, регулируемые специально обученными людьми с головой на плечах.
• с точки зрения какого-нить продажника лучше куча классных фич, которые можно показать на пресейле, и плевать, что их реализация дырява, как дуршлаг, а их поддержка после внедрения превратится в ночной кошмар.

Позволю себе привести вольный перевод заметки по ссылке выше касаемо pit of success:

Цитата:

По мере усложения системы "окружающий ландшафт" обычно становится хуже, а не лучше, и это вполне объяснимо: новые части системы, как правило, основаны на уже существующих частях. И если, допустим, часть существующего "ландшафта" испещрена ухабами, то при добавлении нового функционала люди, естественно, скопируют их, создав ЕЩЕ БОЛЬШЕ ухабов, в которые смогут попасть пользователи.
Вскоре может сложиться ситуация, когда для любого продвижения вперед потребуются очень сложные руководства и тому подобное. Шагните влево, избегайте острых шипов, не сломайте лодыжки в одной из этих ям, проберитесь через вершины двух холмов, не разбейтесь о возможные препятствия на пути и, возможно, если вам повезет, вы сможете заявить о своей победе.
Теперь вы можете попробовать повысить эффективность вашей организации либо за счет обучения всех сотрудников этим правилам (полагаю, это не помешает, некоторые правила могут быть весьма полезными), либо за счет улучшения ландшафта. Измените форму некоторых из тех холмов так, чтобы люди с большей вероятностью двигались в правильном направлении. Переместите конечную точку маршрута туда, куда будет проще добраться. И, наконец, разравняйте уже эти ухабы, чтобы в новом функционале люди перестали их копировать!
Если следовать этому пути, то через какое-то время у вас будет все больше и больше пользователей, которые автоматически идут правильными путями и достигают успеха. Они могут даже не знать, что это - благодаря вам, они просто внезапно начнут достигать успеха, делая простые и очевидные вещи, словно скатываясь вниз со склона.

[kashperuk]

В Extensibility проекте мы исходим как раз из "корсета" - то есть открываем только те возможности, которые кто-то конкретно запросил. Это позволит там расслабить ограничения позже. Обратный подход не подходит, так как он бы ломал backward compatibility

Да и вообще:
https://en.wikipedia.org/wiki/Fail-fast

[ax_mct]

Цитата:

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

Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?

3) 1 но при этом отвечать только за описанные и согласованные сценарии.
И клиенту гибко и партнеру тепло.