|
17.01.2006, 12:20 | #1 |
Участник
|
Цитата:
Цитата:
Цитата:
Своего конечно Но нужно конечно прогнозировать, как результат труда заказчика скажется на своем результате и во время предупреждать, если что-то не так. Все это мое сугубо личное имхо. В целом согласен с Игорем Манном. |
|
18.01.2006, 01:45 | #2 |
Участник
|
Цитата:
На мой взгляд, консультанта на предприятие приглашают тогда, когда выполняются три условия: 1) задача для заказчика новая; 2) предметная область - сложная; 3) задача имеет разовый характер. Если задача не новая, то ее на предприятии кто-то уже делал, ему и поручат сделать еще раз. Если предметная область простая, то назначат кого-нибудь из имеющихся сотрудников и ему поручат "разобраться и доложить". Если задача имеет повторяющийся характер, то возьмут нового человека в штат, желательно имеющего опыт решения таких задач, и поручат ему. Предлагаю эту мою мысль обсудить (желательно, конструктивно :-) |
|
18.01.2006, 12:51 | #3 |
Участник
|
По моему Вы немного путаете понятия. Стандарты и идеи - это разные вещи. Стандарт нам говорит, например, что за этапом анаиз должен следовать этап дизайн, но что именно будет написано в дизайне, и как в этом документе буду решены те или иные задачи будет зависеть от конкретного человека. Один опишет, что это нужно сделать настройками, другой - попытается разработать новый функционал, а третий посмотрит на все это и спросит у заказчика "А вам это надо?" и предложит изменить бизнес-процесс, чтобы "красиво" уложить его в существующий функционал. И никаких вам противоречий со стандартами. И, по моему, вообще Закзчику, если его задача решена, наплевать, соответствует-ли ее решение стандартам или нет. А уж если не наплевать, то уверяю вас, что под это решение появится еще один стандарт (а в свое время так они все и появились)
|
|
19.01.2006, 01:02 | #4 |
Участник
|
Цитата:
Сообщение от Sitizen
По моему Вы немного путаете понятия. Стандарты и идеи - это разные вещи.
Цитата:
Для того чтобы регламентировать, "как будут решены те или иные задачи", создаются методические указания, в Аксапте на эту тему есть "Best Practice". Цель такой регламентации очевидна - уменьшение трудоемкости разработки и сопровождения, а также сроков и затрат на создание АСУ и ее частей. Другое дело, что у нас не любят использовать стандарты, у нас любят "творить", изобретать велосипед. Наверное, потому что так оно интереснее... Креатив-то надо куда-то девать... :-) Цитата:
Сообщение от Sitizen
Один опишет, что это нужно сделать настройками, другой - попытается разработать новый функционал, а третий посмотрит на все это и спросит у заказчика "А вам это надо?" и предложит изменить бизнес-процесс, чтобы "красиво" уложить его в существующий функционал. И никаких вам противоречий со стандартами.
Из-за такой вот отсебятины в решениях, когда каждый лепит, что в голову придет, очевидно страдает характеристика качества под названием "сопровождаемость" (подхарактеристики: анализируемость, модифицируемость, стабилизированность, тестируемость). Мой любимый пример такого куска хлама в Аксапте - русский модуль "Кадровый учет". Явно творец какой-то от души порезвился. Из всех характеристик качества этого модуля на удовлетворительном уровне, пожалуй, только нормосоответствие. Цитата:
Вы можете привести хотя бы один пример такого появления какого-нибудь стандарта на внедрение? |
|
19.01.2006, 12:00 | #5 |
Участник
|
|
|
|