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

[mazzy]

Цитата:

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

Не в том разрезе смотрите. Пока разговор идет о консультантах и программистах, так и будет хождение по кругу.

Может быть

Цитата:

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

Правильнее, имхо, говорить о квалифицированных и не[достаточно]квалифицированных сотрудниках.

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

Цитата:

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

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

Ни на секунду не сомневаюсь, что Максим Белугин обладает достаточной квалификацией.
Но он был поставлен в такие условия, когда ему приходится решать не задачи пользователей, а некую "универсальную задачу", которая, скорее всего, имеет очень отдаленное отношение к реальным задачам пользователей (Я более чем уверен, что пользователи не знали и не понимали термин "гранулярность" и тем более не понимали что такое "запись наименьшей гранулярности").

Из той же оперы темы про 50 универсальных галочек на форме, про универсальные построители, про "произвольные" алгоритмы и прочие.

Главный признак - решается не проблема пользователей, а создается некий "универсальный" механизм.
Вторичные признаки:
1. разработчик надеется, что пользователь сможет настроить этот универсальный механизм
2. разработчик не дает средств отладки для универсального механизма
3. разработчик совершенно не думает, есть ли в принципе у пользователя информация для работы с универсальным механизмом!

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

пример бездумного "программисткого подхода" (извините за использование этого дурацкого термина) - это реализация ГТД в локализованной Аксапте.

Универсальный механизм ввода складской аналитики требует, чтобы ГТД ввели в момент физического прихода. Но в момент физического прихода сопроводительные документы могут отсутствовать (приехала фура, документы не у водителя, а у экспедитора или идут по почте). Как вводить ГТД? Не вводить ее нельзя. Давать людям правку складской аналитики? Вы знаете к каким катастрофическим последствиям может привести эта хакерская функция. В результате использования универсального механизма, отломан красивый механизм работы с неотфактурованными поставками для импортных товаров.

Это пример того, что информация может отсутствовать в момент работы с универсальным механизмом.

Но это еще не все. На том же ГТД можно пронаблюдать пример принципиального отсутствия информации у пользователя. Итак, ГТД. ИНВЕНТАРИЗАЦИЯ. По документам должно быть 5шт товара1 с ГТД1 + 10шт товара1 с ГТД2.

НО кладовщик абсолютно ничего не знает о ГТД. Кладовщик посчитал и обнаружил, что фактически товара1 всего лишь 14штук. ГТД практически никогда не указывается на самой упаковке. Как кладовщик должен ввести информацию о складской аналитике ГТД????!!

Информацией о ГТД обладают бухгалтера. Но ведь не передашь им документ инвентаризации. И не будешь бухов звать на проведение инвентаризации (нафига им такая матответственность, им и своей хватает). Т.е. инвентаризацию с ГТД надо было бы разбить на несколько фаз - 1) пересчет количества, 2) проставление нескладских признаков. Но разработчик решил использовать "универсальный механизм".

В результате, горе разработчик своим подходом убил инвентаризацию товаров с ГТД и напрочь лишил смысла объект СКЛАДСКАЯ аналитика.

А ведь нам обещают в новой локализованной версии прибавить еще три "складские" аналитики, в которых кладовщики ни ухом, ни рылом.

Цитата:

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

Нужно огораживать не программистов от пользователей и не пользователей от программистов, а не[достаточно]квалифицированных сотрудников от других сотрудников в вопросах, не относящихся к их компентенции; а одних не[достаточно]квалифицированных сотрудников от других не[достаточно]квалифицированных сотрудников - в особенности .

А чего огораживать?
Во-первых, как же будут неквалифицированные обучаться?
Во-вторых, по прежнему непонятно что же надо делать, после того как огородили.

Мне кажется, что лучше сформулировать следующим образом:
1. Надо разбираться в предметной области и решать реальные задачи пользователей, а не ваять универсальные механизмы.
2. Универсальные механизмы можно создавать, только четко понимая, что они потребуют гораздо больших усилий и времени, чем специализированные.

Руководители проектов, коллеги: как только вы задумали сделать универсальный механизм и оценили время на его разработку, то тут же умножайте это время на 10. Дополнительное время потребуется для того, чтобы ваш универсальный механизм действительно решал задачи пользователей и был удобен пользователям.

[Geo]

Цитата:

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

Руководители проектов, коллеги: как только вы задумали сделать универсальный механизм и оценили время на его разработку, то тут же умножайте это время на 10. Дополнительное время потребуется для того, чтобы ваш универсальный механизм действительно решал задачи пользователей и был удобен пользователям.

Имхо как раз наоборот: на практике куда чаще встречается полное пренебрежение универсальными механизмами. Ввиду чего на каждом проекте, из раза в раз, повторяются одни и те же доработки с минимальными изменениями. Из-за того, что менеджеров и консультантов зачастую не интересует, что будет потом, и они "экономят ресурсы" до каждой строчки ТЗ и кода.

[Sancho]

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

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

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

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

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

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

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

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

[Sancho]

блин!

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

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

[ppson]

Цитата:

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

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

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