Про консультантский подход

[Sancho]

согласен с предыдущим оратором
очень часто на проектах встречается

IF "Location Code" = 'ОФИС' THEN...
(сииньким выделено текстовое значение, которое в любой момент может быть изменено в настройке)

быстро? быстро!
работает? работает!
клиент доволен? а как же!!!

можно не создавать универсальные механизмы, но надо немного мыслить системно...

по поводу консультанты vs программисты я лет 5 назад статью написал.
тезисы следующие:
1. для оптимизации использования ресурсов переход зоны ответственности от одних к другим является ТЗ (своеобразная точка).
2. не существует консультантов (без навыка программирования в конкретной системе), способных создать ТЗ, не вызывающее дополнительных вопросов программиста
3. не существует программистов, способных исключительно по ТЗ (если в нем не приведены тексты конкретных функций и места и параметры их вызова - а зачем тогда вообще нужны программисты?) создать решение, без дополнительных консультаций (как минимум вопрос "а почему не сделать так? так быстрее").
4. каждая консультация программиста и консультанта = потеря времени = потеря эффективности = потеря ДЕНЕГ в итоге для всех.

вывод парадоксален.
в целях увеличения ПРИБЫЛЬНОСТИ проектов надо забыть про п.1 (оптимизацию использования ресурсов) и вместо ТОЧКИ передачи информации (ТЗ) сделать ОТРЕЗОК передачи информации.
другими словами, конс должен понимать, что можно запрограммировать, а что нет (или чрезвычайно сложно), должен понимать ГДЕ это будет программироваться, в ключевых местах или на периферии, как это скажется на общей работоспособности решения, следовательно конс должен быть кодером.

кодер, в свою очередь, должен быть осведомлен о нюансах бизнес процесса заказчика, о калейдоскопе предложенных ему альтернативных вариантов решения (с обоснованием отказа), т.е. кодер должен быть консом.

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

[Sancho]

блин!

Ruff
Дмитрий Ерин

выразил те же самые мысли по-другому и 2 года назад тут: Cтоит ли программистов огораживать консультантами от пользователей?

[ppson]

Цитата:

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

в целях увеличения ПРИБЫЛЬНОСТИ проектов ... конс должен быть кодером.

В целях увеличения прибыльности проектов ключевые пользователи должны быть кодерами и сисадминами.

[Ivanhoe]

Хм, а про архитекторов все забыли? Или на практике никогда у вас не было такой роли?
В примерах, так или иначе, эта роль отдается на откуп или консу, или программеру, или пополам между ними.

Мне кажется, эффективнее выделить эту роль явно:
1. Конс пишет описание решения с точки зрения пользовательского интерфейса откуда запускается, как выдглядит, что получается в итоге. Пишет методику тестирования. В общем случае толковому консу достаточно хороших знаний предметной области и хороших знаний Аксапты (чтобы не строить заново велосипед).
2. Архитектор продумывает оптимизацию, структуру данных, классов и т.п. Фиксирует в задании программисту эту архитектуру.
3. Программист программирует.

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

[glibs]

Я чего-то считал, что архитектор скорее контролирует РЕШЕНИЕ в целом. Т.е. координирует в первую очередь работу консультантов, в меньшей степени разработчиков. Чтобы функционал консультантов был совместимым друг с другом, сочетался как-то. Дополнительной задачей может быть непроектная — универсализация кастомизаций на проекте, чтобы их можно было использовать у других.

Вот слайд из презентаци по еще ONTARGET.

Архитектор бизнес-решений
-----------------

Функции:
- Отвечает за процесс Дизайна решения
- Контроль качества создаваемого решения
- Координирует работу аналитиков и функциональных консультантов

Профиль:
- Ведущий аналитик, имеющий опыт работы
- Знание предметной области

[Волчара]

Цитата:

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

Я чего-то считал, что архитектор скорее контролирует РЕШЕНИЕ в целом....

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

Ну это так к слову.... Мне понравилась идея с аналитикой:

Цитата:

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

..... надо разделять аналитику и функционал. Т.е. "в идеале" - складская аналитика не должна нести на себе функциональность и должна быть массивом как финансовая аналитика. А вот функционал должен жить отдельно.....

Функционал работает - аналитика не нужна. Но перед подготовкой отчетности все срочно начинают колдовать над аналитикой

[sukhanchik]

Цитата:

Сообщение от Волчара

Функционал работает - аналитика не нужна. Но перед подготовкой отчетности все срочно начинают колдовать над аналитикой

Ну дык - это и говорит о том, что аналитика д.б. везде. И что самое важное - что она нужна исключительно для отчетов - т.е. не нести функциональную нагрузку. А колдовать начинают - т.к. как я сказал - "в идеале". Склады могут при внедрении специально выделять. А в заказах на перемещение они и так выделены.
А в случае финаналитики - колдовство иногда вырастает в автоматическое создание аналитики, равное какому-либо справочнику (клиентов к примеру или еще как).

[Ivanhoe]

Цитата:

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

Я чего-то считал, что архитектор скорее контролирует РЕШЕНИЕ в целом. Т.е. координирует в первую очередь работу консультантов, в меньшей степени разработчиков. ...

Архитектор бизнес-решений
-----------------

Функции:
- Отвечает за процесс Дизайна решения
- Контроль качества создаваемого решения
- Координирует работу аналитиков и функциональных консультантов

Это Архитектор бизнес-решений. Как видно из описания и Ваших коментариев - это именно продвинутый консультант. Я речь вел про системного (технического) архитектора. Насколько я понимаю, в классической разработке софта, есть именно технический архитектор, а последнее звено - программисты-кодеры, которые реализуют конкретное архитектурное решение.

P.S. На своей практике встречал мало программистов, которые реально могли разработать эффективную архитектуру с точки зрения кода.

[Волчара]

Цитата:

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

P.S. На своей практике встречал мало программистов, которые реально могли разработать эффективную архитектуру с точки зрения кода.

В те времена когда БЭСМ 6 была признана лучшей машиной в Европе - у нас существовала своя школа программирования. Программы писались на бумаге с помощью карандаша и ластика, причиной конечно было, то что потом программу надо было переносить на перфокарты.... Однако карандаш и ластик дали толчок ряду методов, например методу отложенного программирования и другим...

Сейчас все эти инструменты в забытии - подавляющее большинство (почти все) программисты самоучки. Возможность мгновенной проверки кода конечно оказалась полезным инструментом позволяющим получить быстрый результат, однако школа системного программирования полностью утрачена...

[Vadik]

Цитата:

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

аналитика д.б. везде. И что самое важное - что она нужна исключительно для отчетов - т.е. не нести функциональную нагрузку

Складские аналитики нужны только для отчетов - я все верно понял ?

[Волчара]

sukhanchik предложил новую архитектуру системы, возможно совершенно НОВОЙ системы!
В этой архитектуре аналитики будут нужны только для отчетности: и это концептуальное изменение
Можно сказать, что это концептуальная основа новой системы. А Вы Vadik видимо решили что мы говорим про Аксапту....

[sukhanchik]

Ладно, все закругляюсь.... умолкаю и иду работать....
Курилка ж все же. Готов взять свои слова обратно - чтобы не разводить длинный флейм А курить - вредно

[denny]

Цитата:

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

P.S. На своей практике встречал мало программистов, которые реально могли разработать эффективную архитектуру с точки зрения кода.

Вот мне интересно - откуда же тогда вырастают системные архитекторы
Или вы про совмещение должностей?

[Ivanhoe]

Цитата:

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

Вот мне интересно - откуда же тогда вырастают системные архитекторы
Или вы про совмещение должностей?

Путей много может быть. Понятно, что это зависит от человека, его возможностей и желаний. Как программист может стать архитектором, так и консультант.

Возможно и совмещение - я же про роль на проекте говорю, а не должность.

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