Ты предлагаешь "оставить психбольницу в руках пациентов"?

[sukhanchik]

Цитата:

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

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

А можно поинтересоваться (в профессиональном плане) - в чем стоит надругательство над заказчиком?
Я в своей жизни встречался с двумя типами внедрений.
1) Натянем бизнес на систему. Т.е. внедрим штатную АХ с минимальным кол-вом модификаций. В этом случае заказчик либо привыкает к системе, либо ищет "более дружелюбный" продукт. Но и тут система "неисполосована".
2) Натянем систему на бизнес. Т.е. внедрим "свое" решение, написанное условно сбоку от штатного функционала, но при этом вполне удовлетворяющее заказчика (по кр. мере на этапе внедрения). В этом случае заказчик через некоторое время "с удивлением" узнает, что от АХ у него имеется один логотип . Но в тоже время - обычно переписанная система более дружелюбна, нежели штатная - в связи с этим все недовольство сводится к зависимости от одного партнера, а уж никак не к АХ.

Понятно - что есть различные промежуточные варианты. Вот поэтому и хочется поинтересоваться.

[gl00mie]

Цитата:

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

внедрим "свое" решение, написанное условно сбоку от штатного функционала, но при этом вполне удовлетворяющее заказчика

Из моего скромного опыта, "условно сбоку" можно реализовать разве что какие-то модули, которые либо недоразвиты, либо просто отсутствуют в стандартном приложении. Когда же штатные модули "натягиваются" на бизнес, то они зачастую тут и там "ломаются", отчего отсекаются возможности использовать штатный функционал для решения многих задач, которые возникнут на проекте потом, уже в ходе пром. эксплуатации. Плюс многие вещи либо не реализуются вовсе, либо реализуются "локально", не вписываясь должным образом в стандартный функционал. Классический, думаю, пример - проверка целостности данных: много кто дописывает свои проверки? Или инициализация дополнительных полей на таблицах: много кто кастомизирует AxD-классы? В лучшем случае код добавят в modifiedField() на таблице, а то и вовсе на форму обработчик повесят - см. ту же локализацию.

[Мартынов Дмитрий]

Цитата:

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

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

Когда я увидел первый такой проект (где все дописано сбоку), я подумал - "ну повезло же Заказчику встретить идиота, когда на рынке полно толковых консультантов". Но чем дальше, тем больше. В результате нормальные проекты, где функциональность используется на 100% (из той которую можно использовать) + к этому есть некоторое количество модификаций (в основном связанных с исправлением неадекватной русской локализации), можно пересчитать по пальцам и это те проекты, которые делали те, кого вы здесь хорошо знаете...

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

Цитата:

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

В общем - не бойтесь модификаций, бойтесь дурных модификаций.

Правильно! НО НЕ научно все это как то.... Всяк другого мнит уродом......

[sukhanchik]

Цитата:

Сообщение от Мартынов Дмитрий

язык х++ очень прост и программировать на нем гораздо интересней чем читать горы документации.

А еще аргумент в пользу x++ состоит в том, что вся та документация, которая была и есть на систему бывает не отражает реалии.
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию.

[ZornFire]

Цитата:

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

А еще аргумент в пользу x++ состоит в том, что вся та документация, которая была и есть на систему бывает не отражает реалии.
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию.

это только по отчётности, но без понимания бухгалтерских принципов хотябы, лезть и кодить не имеет смысла, разве нет?

[sukhanchik]

Цитата:

Сообщение от mr.ZF

это только по отчётности, но без понимания бухгалтерских принципов хотябы, лезть и кодить не имеет смысла

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

[Мартынов Дмитрий]

Цитата:

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

А еще аргумент в пользу x++ состоит в том, что вся та документация, которая была и есть на систему бывает не отражает реалии.
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию.

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

[xan]

Добрый день, коллеги.

Нашу версию мы изложили в колонке: Вредные мысли от Алана Купера

С уважением, Александр Дублин.

[egorych]

Цитата:

Сообщение от Мартынов Дмитрий

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

ГыГы! Где эти горы? Что читать - Еременко, еще что? Где хотя бы краткое описание так называемого API - invent-чего-то-там, ledger-чего-то-там и т.п.
Не у всех есть возможность поработать в партнере МС, соответственно далеко не все знают как с этим работать! Да и в партнерах тоже, видимо, учат не очень - нам, например, "прилепили" (по другому не скажешь) свою трансляцию заказов/закупок и др. при наличии стандартной!!!
Вот отсюда и бардель в модификациях!

[fed]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Плюс многие вещи либо не реализуются вовсе, либо реализуются "локально", не вписываясь должным образом в стандартный функционал. Классический, думаю, пример - проверка целостности данных: много кто дописывает свои проверки? Или инициализация дополнительных полей на таблицах: много кто кастомизирует AxD-классы? В лучшем случае код добавят в modifiedField() на таблице, а то и вовсе на форму обработчик повесят - см. ту же локализацию.

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

Цитата:

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

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

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

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

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

[Vadik]

Цитата:

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

Согласен. Но с другой стороны - партнер - не вендор - у него нет цели учесть ситуации на все случаи жизни, при том, что в данном случае нужно решить один конкретный частный случай за ограниченное кол-во денег (времени)

А при достижении некой критической массы "частных случаев" они переименовываются в Решение

[xan]

Добрый день, коллеги.

Не сразу заметил эту ветку обсуждения (как человек некурящий, в курилку хожу редко).

Прочитав Ваши комментарии я немного засомневался, все ли читали оригинал ("Психбольница в руках пациентов")?
Если нет, то рекомендую, особенно для консультантов-ассов по разработке, менеджеров проектов и фрилансеров.

С уважением, Александр Дублин.

P.S. После прочтения книги просьба вернуться к своим собственным комментариям и их прокомментировать :-)

P.P.S. Георгий ты куда, точнее кем, уходишь?

[Vals]

Цитата:

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

А можно поинтересоваться (в профессиональном плане) - в чем стоит надругательство над заказчиком?

Всё, о чём уже говорилось:
- Повторное программирование аналога стандартной функциональности
- Программирование функций которые не работают или генерят ошибки
- Невозможность использования других модулей системы, кроме тех, которые доработаны. (так как разорваны все связи)
- Невозможность использования стандартных настроек, так как доработки о них не знают
и т.д.
Причём такие перлы чуть ли не на каждом проекте по экспертизе.

[Atar]

Цитата:

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

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

Простите, а как насчёт документации по проекту (я имею ввиду эти ваши аудируемые проекты):
- Разве в требованиях клиента "чуть ли не на каждом проекте " указано что то отличное от того, что реализовано?
- Разве в дизайне решения (ТД, ТЗ и пр.) не указаны ограничения и написано (опять) не то, что реализовано?
Вот пример:
Разве не во благо экономии времени/денег не выполнялась, ну, к примеру, доработка налоговых проводок при выполнении связанной модификации в проекте внедрения, изначально ориентированном исключительно на логистический контур?

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

Да и причём тут документация! А как же здравый смысл? А как же "не умножать сущности"?
Как то очень огульно Вы хаете. Следовать Вашим советам - значит бесполезно раздуть кратно бюджеты внедрений, получив в результате "красивую" систему. Только стоит ли оно того?

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

Всегда есть баланс следования методологии/Best Practice и затрат.

[sukhanchik]

Цитата:

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

Всё, о чём уже говорилось:
- Повторное программирование аналога стандартной функциональности
- Программирование функций которые не работают или генерят ошибки
- Невозможность использования других модулей системы, кроме тех, которые доработаны. (так как разорваны все связи)
- Невозможность использования стандартных настроек, так как доработки о них не знают
и т.д.

Цитата:

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

Как то очень огульно Вы хаете. Следовать Вашим советам - значит бесполезно раздуть кратно бюджеты внедрений, получив в результате "красивую" систему. Только стоит ли оно того?
...
Всегда есть баланс следования методологии/Best Practice и затрат.

Как тут уже говорилось - заказчику иногда нужен бизнес-консалтинг, а не ИТ-консалтинг.
Так вот - вполне себе нередки случаи, когда сначала заказчик отклоняется от бизнес-процессов, заложенных в систему, а потом к ним приходит. Только за это время уже написаны и оплачены тонны кода. И, конечно, всем выгодно ругать все прошлое.
Любое программирование так или иначе будет оставлять в себе куски кода, "которые не работают или генерят ошибки". Как говорится - код с течением времени "протухает". Это кстати хорошо заметно в АХ 2009, если сравнивать ее с АХ 3. Взяли - что-то поменяли глобальное - вылезли проблемы с формами (к примеру). А о них никто не задумался. Аудиторы приходят и видят кучу функций, "которые не работают или генерят ошибки". И каждый прав по своему.

Другие модули. Опять-таки - если изначально не планировать их к использованию - это одно. Если планировать - это другое.
Пример. Была модификация "Разноска по складу", кочующая из проекта в проект у внедренцев. Решили локализаторы ее реализовать. В результате учета всех моментов в системе - реализовался функционал профилей учета. Я не берусь судить за всех внедренцев - но у некоторых - эта модификация была на порядок проще существующего функционала профилей учета. Но, конечно - она не учитывала те или иные моменты. И, возможно, где-то наступала на горло существующему функционалу. Но если сравнивать эти 2 варианта реализации - то вариант, реализованный в рамках локализации может быть неподъемным для бюджета внедрения (будем считать, что реализация от МС является эталонной по качеству, а также что локализация учитывает все стандартные настройки и не ломает нигде буржуйский функционал ).

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

Другое дело - что можно и палку перегнуть (и такие примеры есть - вспомним перекресточное решение - когда многое чего было реализовано параллельно).

А вот найти "золотую середину"... достаточно сложно. Наверное поэтому при аудите приглашают независимо несколько аудиторов для составления картины из нескольких независимых отчетов

[Vals]

Цитата:

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

Как то очень огульно Вы хаете. Следовать Вашим советам - значит бесполезно раздуть кратно бюджеты внедрений, получив в результате "красивую" систему. Только стоит ли оно того?

1. Не огульно, а совершенно конкретные примеры.
2. Бюджеты раздувает не аудит