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

[mazzy]

**** тема выделена отсюда Блокировка номеклатуры при инвентаризации ****

Цитата:

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

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

программистский подход
см. Про программистский подход, программистское мышление и стереотипы
и Cтоит ли программистов огораживать консультантами от пользователей?

[belugin]

Цитата:

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

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

Я собственно и был огорожен - идея была не моя

[egorych]

Цитата:

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

программистский подход

Ну да, консультантсуий подход подразумевает заставить юзера заводить все вручную тыщ для 20 номенклатур и для 10 складов.

[mazzy]

Цитата:

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

Ну да, консультантсуий подход подразумевает заставить юзера заводить все вручную тыщ для 20 номенклатур и для 10 складов.

Это не консультантский подход. Это... даже не знаю что...

[aidsua]

Цитата:

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

Это не консультантский подход. Это... даже не знаю что...

В стиле "Работать, негры!!"

[egorych]

Цитата:

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

Это не консультантский подход. Это... даже не знаю что...

Можно тогда попросить изложить консультанский? Или то, что указано выше

Цитата:

...Тут должен быть недюжий интеллект ...

и есть он? Ну так фактически это и есть предложение сделать вручную. Т.к. запрограммировать "недюжий интеллект" ну-у-у, скажем так, почти невозможно.

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

[mazzy]

Цитата:

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

Можно тогда попросить изложить консультанский?

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

Т.е. консультант - это прежде всего ПЕРЕВОДЧИК

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

Я вроде неоднократно высказывался на эту тему, поищите.

См. также Бизнес-аналитик VS Консультант
Когда нужен системный аналитик на проекте?
работа в консалтинге vs. на клиенте

а также уже упоминаемая тема Cтоит ли программистов огораживать консультантами от пользователей?

[mazzy]

Цитата:

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

Т.к. запрограммировать "недюжий интеллект" ну-у-у, скажем так, почти невозможно.

Если делать универсальную шнягу - то да. (Поэтому такого и нет в Аксапте)
Если делать то, что нужно конкретным пользователям - как правило реализуется достаточно просто.

[fed]

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

[Vals]

Цитата:

Т.е. консультант - это прежде всего ПЕРЕВОДЧИК

Угу, иногда такого напереводят - волосы дыбом становятся
Наверно интернет-переводчиком переводят

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

Это наблюдается на большинстве проектов.

Как бы мы ни рассуждали - всё упирается в квалификацию консультанта, архитектора, программиста.

[mazzy]

и снова возвращаемся к теме
Cтоит ли программистов огораживать консультантами от пользователей?

[Zabr]

Не в том разрезе смотрите. Пока разговор идет о консультантах и программистах, так и будет хождение по кругу. Правильнее, имхо, говорить о квалифицированных и не[достаточно]квалифицированных сотрудниках. Квалифицированных в широком смысле слова - не только хорошо понимающих свою профессию, но и умеющих общаться, и с коллегами, и с пользователями, и главное - понимающих, с кем и как можно говорить, а с кем как нельзя. Думаю, что не только я неоднократно видел как программисты или сотрудники ИТ пытаются говорить с пользователями не на том языке, то есть не задумываясь о том, в теме ли вообще пользователь, понимает ли он используемую терминологию (как формальную, так и неформальную) и т.п.

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

[mazzy]

Цитата:

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

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

Может быть

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

[Vals]

Цитата:

Т.е. инвентаризацию с ГТД надо было бы разбить на несколько фаз - 1) пересчет количества, 2) проставление нескладских признаков

А меченую пробовал приспособить для этого дела?

[mazzy]

Цитата:

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

А меченую пробовал приспособить для этого дела?

Блин, vals... ну, подумай же.

Повторю пример:
по системе: товар1, гтд1 - 5 шт; товар1, гтд2 - 10шт
по факту: товар1, гтд? - 14 шт

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

[Vals]

Цитата:

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

Сам же написал - тебе нужно два этапа:

Цитата:

1) пересчет количества, 2) проставление нескладских признаков

1- Меченая (ГТД пустой)
2 - Журнал инвентаризации

[mazzy]

[sukhanchik]

Ну кстати, если уж приводить пример со складской аналитикой - то мысль с одной стороны я считаю правильной, но с другой стороны - сам пример не очень корректен.
Дело в том, что складская аналитика (в отличие от финансовой) не является "универсальной" (т.е. ее некорректно будет представлять массивом и работать с ней как с массивом, а не по отдельности) по своему определению. Да, 90% свойств у складских аналитик совпадают. Но есть и 10% отличий.
Взять бы ту же галочку "Контроль серийных номеров". Или идеологию заказа на перемещения, где одна аналитика "Склад" становится важнее остальных.

Резюме: ГТД очень похожа на складскую аналитику и при минимуме усилий был достигнут максимальный эффект. Другое дело - что да, есть "недодумки", которые опять-таки можно было решить "в индивидуальном порядке", сделав ГТД тоже "особенной" аналитикой. Но это не сделали.

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

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

[mazzy]

Цитата:

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

Да, 90% свойств у складских аналитик совпадают. Но есть и 10% отличий.
...
Другое дело - что да, есть "недодумки", которые опять-таки можно было решить "в индивидуальном порядке", сделав ГТД тоже "особенной" аналитикой. Но это не сделали.

Тема не про складскую аналитику, а про консультантский/программистский подход.

Цитата:

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

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

[Geo]

Цитата:

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

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

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