Empower vs. Restrict

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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