Отраслевое решение - стереотип или нет?

[sukhanchik]

Ой.. какую дискуссию я породил... Прям неудобно - напоминает спор о том - что лучше - 1С или Аксапта
Извиняюсь за задержку в ответе - времени не было.
Итак, мне задали вопросы - надо ответить

Цитата:

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

Хороший бизнес план !
Если мне его принесут (как бы я финдир) я задам такие простые вопросы:
1. Предложите способ выделения из проектных модификаций тех самых "стопудово всем подходящих" и 99% востребованых.

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

Цитата:

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

2. Оцените стоимость интеграции модификаций, собранных в единый слой с разных проектов.

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

Цитата:

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

3. Подсчитайте стоимость их переноса на все выходящие обновления. (Раз в полгода примерно).

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

Цитата:

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

4. Подсчитайте экономический эффект от их применения.

Это-то как раз просто. Классический пример - бага, тянущаяся еще с незапамятных времен. Исправляется - в одну строчку (я же говорил - модификации маленькие!). Но сколько времени потребутся чтобы вспомнить откуда растут ноги. Конечно - ради одной модификации - городить слой незачем. Но если их количество уже больше 10 - то почему бы и нет?
Опять-таки - считать надо в человеко-часах.

Цитата:

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

5. Оцените риск того, что они будут несовместимыми с следующими версиями. (как показывает ситуация с DAX 2009 - риск высокий).

А вот тут-то могу позволить не согласиться. Кто сказал - что надо бежать всем на новую версию? Надо еще со старой разобраться. Да фиг с ней с поддержкой от Микрософт - она много дает? С 3-шкой - подписываться на обновления было невыгодно - 4-ка дешевле стоит, нежели 3-шка со всеми обновлениями.
Да, риск большой. Я считаю - что надо задумываться о новой версии - когда из старой все будет выжато по максимуму. Яркий пример - 4-ка. Ну и кому нужен переход с 3-шки на 4-ку - когда уже маячит 2009-я? Ну кроме конечно партнеров, консультантов и прочих лиц, которые с этого кормятся? Или же можно провести аналог - Win XP - Win Vista. А тут уже вполне можно смотреть на систему - как на новую - и заново ее внедрять. Уверен - что переход с 3-шки на 2009-ку будет стоить гораздо дешевле (раза в 2 точно), чем переход с 3-шки на 4-ку и с 4-ки на 2009-ку.

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

И еще хочу заметить про базовый слой. Он нужен - для работы на проектах в рамках одной версии. Микрософт не будет никогда (я надеюсь ) делать кардинальные вещи в сервис паках. Он оставит их до выпуска новой версии. А значит хотя бы полусовместимость базового слоя (см мои пункты а, б, в, г) все равно будет.
И опять-таки - он оправдан - при большом (>5) количестве разных клиентов, хотящих одно и тоже (очень сильно похожее). Если за время жизни 4-ки к примеру - партнер не найдет такого количества клиентов (а будет например окучивать одного большого клиента в разных областях) - то очевидно - что ему этот слой не нужен