|
![]() |
#1 |
Участник
|
Цитата:
Цитата:
Если вспомнить цитату, с которой я возобновил бурчание, то вот она. Цитата:
Сообщение от Belugin
На одном из проектов делал доработку, чтобы заводилась запись наименьшей гранулярности
Но он был поставлен в такие условия, когда ему приходится решать не задачи пользователей, а некую "универсальную задачу", которая, скорее всего, имеет очень отдаленное отношение к реальным задачам пользователей (Я более чем уверен, что пользователи не знали и не понимали термин "гранулярность" и тем более не понимали что такое "запись наименьшей гранулярности"). Из той же оперы темы про 50 универсальных галочек на форме, про универсальные построители, про "произвольные" алгоритмы и прочие. Главный признак - решается не проблема пользователей, а создается некий "универсальный" механизм. Вторичные признаки: 1. разработчик надеется, что пользователь сможет настроить этот универсальный механизм 2. разработчик не дает средств отладки для универсального механизма 3. разработчик совершенно не думает, есть ли в принципе у пользователя информация для работы с универсальным механизмом! Про первое и второе понятно, я надеюсь. Поясню третий пункт. Дело в том, что во время работы, универсальный механизм может потребовать ввода информации, которой у данного пользователя в данный момент просто нет. Либо информация появится позже, либо информация будет у другого пользователя и передать ее нельзя по соображениям безопасности. пример бездумного "программисткого подхода" (извините за использование этого дурацкого термина) - это реализация ГТД в локализованной Аксапте. Универсальный механизм ввода складской аналитики требует, чтобы ГТД ввели в момент физического прихода. Но в момент физического прихода сопроводительные документы могут отсутствовать (приехала фура, документы не у водителя, а у экспедитора или идут по почте). Как вводить ГТД? Не вводить ее нельзя. Давать людям правку складской аналитики? Вы знаете к каким катастрофическим последствиям может привести эта хакерская функция. В результате использования универсального механизма, отломан красивый механизм работы с неотфактурованными поставками для импортных товаров. Это пример того, что информация может отсутствовать в момент работы с универсальным механизмом. Но это еще не все. На том же ГТД можно пронаблюдать пример принципиального отсутствия информации у пользователя. Итак, ГТД. ИНВЕНТАРИЗАЦИЯ. По документам должно быть 5шт товара1 с ГТД1 + 10шт товара1 с ГТД2. НО кладовщик абсолютно ничего не знает о ГТД. Кладовщик посчитал и обнаружил, что фактически товара1 всего лишь 14штук. ГТД практически никогда не указывается на самой упаковке. Как кладовщик должен ввести информацию о складской аналитике ГТД????!! Информацией о ГТД обладают бухгалтера. Но ведь не передашь им документ инвентаризации. И не будешь бухов звать на проведение инвентаризации (нафига им такая матответственность, им и своей хватает). Т.е. инвентаризацию с ГТД надо было бы разбить на несколько фаз - 1) пересчет количества, 2) проставление нескладских признаков. Но разработчик решил использовать "универсальный механизм". В результате, горе разработчик своим подходом убил инвентаризацию товаров с ГТД и напрочь лишил смысла объект СКЛАДСКАЯ аналитика. А ведь нам обещают в новой локализованной версии прибавить еще три "складские" аналитики, в которых кладовщики ни ухом, ни рылом. Цитата:
Сообщение от Zabr
![]() Нужно огораживать не программистов от пользователей и не пользователей от программистов, а не[достаточно]квалифицированных сотрудников от других сотрудников в вопросах, не относящихся к их компентенции; а одних не[достаточно]квалифицированных сотрудников от других не[достаточно]квалифицированных сотрудников - в особенности
![]() Во-первых, как же будут неквалифицированные обучаться? Во-вторых, по прежнему непонятно что же надо делать, после того как огородили. ![]() Мне кажется, что лучше сформулировать следующим образом: 1. Надо разбираться в предметной области и решать реальные задачи пользователей, а не ваять универсальные механизмы. 2. Универсальные механизмы можно создавать, только четко понимая, что они потребуют гораздо больших усилий и времени, чем специализированные. Руководители проектов, коллеги: как только вы задумали сделать универсальный механизм и оценили время на его разработку, то тут же умножайте это время на 10. Дополнительное время потребуется для того, чтобы ваш универсальный механизм действительно решал задачи пользователей и был удобен пользователям. |
|
|
За это сообщение автора поблагодарили: Kabardian (2). |
![]() |
#2 |
Участник
|
Цитата:
Сообщение от mazzy
![]() Руководители проектов, коллеги: как только вы задумали сделать универсальный механизм и оценили время на его разработку, то тут же умножайте это время на 10. Дополнительное время потребуется для того, чтобы ваш универсальный механизм действительно решал задачи пользователей и был удобен пользователям.
![]() |
|
![]() |
#3 |
Administrator
|
согласен с предыдущим оратором
очень часто на проектах встречается IF "Location Code" = 'ОФИС' THEN... (сииньким выделено текстовое значение, которое в любой момент может быть изменено в настройке) быстро? быстро! работает? работает! клиент доволен? а как же!!! можно не создавать универсальные механизмы, но надо немного мыслить системно... по поводу консультанты vs программисты я лет 5 назад статью написал. тезисы следующие: 1. для оптимизации использования ресурсов переход зоны ответственности от одних к другим является ТЗ (своеобразная точка). 2. не существует консультантов (без навыка программирования в конкретной системе), способных создать ТЗ, не вызывающее дополнительных вопросов программиста 3. не существует программистов, способных исключительно по ТЗ (если в нем не приведены тексты конкретных функций и места и параметры их вызова - а зачем тогда вообще нужны программисты?) создать решение, без дополнительных консультаций (как минимум вопрос "а почему не сделать так? так быстрее"). 4. каждая консультация программиста и консультанта = потеря времени = потеря эффективности = потеря ДЕНЕГ в итоге для всех. вывод парадоксален. в целях увеличения ПРИБЫЛЬНОСТИ проектов надо забыть про п.1 (оптимизацию использования ресурсов) и вместо ТОЧКИ передачи информации (ТЗ) сделать ОТРЕЗОК передачи информации. другими словами, конс должен понимать, что можно запрограммировать, а что нет (или чрезвычайно сложно), должен понимать ГДЕ это будет программироваться, в ключевых местах или на периферии, как это скажется на общей работоспособности решения, следовательно конс должен быть кодером. кодер, в свою очередь, должен быть осведомлен о нюансах бизнес процесса заказчика, о калейдоскопе предложенных ему альтернативных вариантов решения (с обоснованием отказа), т.е. кодер должен быть консом. только тогда они понимают друг друга не с первого, так со второго раза, и решение получается жизнеспособным в кратчайшее время. Последний раз редактировалось Sancho; 17.05.2009 в 01:11. |
|
![]() |
#4 |
Administrator
|
блин!
![]() Ruff Дмитрий Ерин выразил те же самые мысли по-другому и 2 года назад тут: Cтоит ли программистов огораживать консультантами от пользователей? |
|
![]() |
#5 |
Участник
|
В целях увеличения прибыльности проектов ключевые пользователи должны быть кодерами и сисадминами.
__________________
![]() |
|
|
![]() |
||||
Тема | Ответов | |||
Вспомогательный класс для импорта из Excel через ADO | 80 | |||
Чтение из ini-файла | 1 | |||
Несколько вопросов по AXAPTE | 53 |
|