выпуск апгрейдов не реже 1 раза в 2 недели
На страницу Пред. 1, 2, 3, 4, 5 След.
|
| Предыдущая тема :: Следующая тема |
| Поддерживаете ли Вы выпуск апгрейдов ЦФТ-Банк не реже 1 раза в 2 недели? |
| Да |
|
7% |
[ 4 ] |
| Нет |
|
80% |
[ 46 ] |
| Не знаю |
|
12% |
[ 7 ] |
|
| Всего проголосовало : 57 |
|
| Автор |
Сообщение |
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
 Вт Апр 26, 2011 13:02 |
 |
|
Ирина!
Приношу извинения, если не очень понятно формулирую свои мысли и вопросы. Ваш ответ я трактую следующим образом: Вы бы сделали свой локальный расчет неверно рассчитанного показателя, минуя ЦФТ-шные операции и библиотеки.
Описанный Вами механизм интересен, но он требует дополнительных трудозатрат по сравнению с исправлением ошибки, найденной в дистрибутивном коде: время на поиск ошибки все равно придется потратить (не писать же расчет показателя с нуля?) + время на реализацию своего "правильного" алгоритма. Если есть на это время, то, несомненно, это выход! У нас времени на это нет.
Новинку с копированием библиотек мы пока не используем, хотя данное решение имеет право на существование. Думаю, что и не воспользуемся им, т.к. данный механизм применим только в отчетности, а нам необходим типовой подход ко всем операциям Системы. |
|
 |
omela
Участник со стажем
Вступление в Клуб: 01.07.2008
|
| Вт Апр 26, 2011 13:35 |
|
|
| timochev пишет: | | Описанный Вами механизм интересен, но он требует дополнительных трудозатрат по сравнению с исправлением ошибки, найденной в дистрибутивном коде: время на поиск ошибки все равно придется потратить (не писать же расчет показателя с нуля?) + время на реализацию своего "правильного" алгоритма. Если есть на это время, то, несомненно, это выход! У нас времени на это нет. |
Данная операция чаще используется для перечня кодов, дистрибутивный расчет которых сложно представить, пытаясь подстроиться под нужды банка, которые иногда достаточно интригующие 
Подход с ожиданием исправления, исправление его на дистрибутиве и появления возможностей не менее трудозатратный (особенно для разработчика  ), поверьте.
Как правильно было замечено, исправление ошибок и отсутствие некоторых возможностей могут исправляться достаточно долго – в зависимости от сложности и приоритетности задач. Все это время предлагаете лазить с ключом и корректировать дистрибутив ? Я - ЗА, если этот вариант не превышает 3-ех строчек кода, реально исправляет глобальную ошибку и обещан исправится в ближайшем дополнении.
Ели вы плохо оформите заявку и кроме вас больше никто не оформил данную проблему, то ждите, что ее можно реализовывать еще дольше.
_________________
Трехглазый передает привет банкирам, и желает им долгого здравия (:. |
|
|
Васильев Николай
Профи
Вступление в Клуб: 29.06.2007
|
| Вт Апр 26, 2011 15:25 |
|
|
Я вот смотрю, и все разговор скатывается на отчетность. Ирина, Вы занимаетесь только отчетностью? Дистрибутивного функционала вам хватает полностью? Вы участвуете непосредственно в установке обновлений? Дистрибутивный код правите?
Вот почему спрашиваю.
К примеру, в одном из обновлений поменялось создание платежного документа. Свалились, сотно, импорты из других систем(а у нас их , к примеру штук 8 еще).
К примеру, банк работает с производными фининструментами, реализации которых просто нет в ИБСО . Или скажем появилась только что, но естно за деньги. Давно уже работает своя реализация , ИНТЕГРИРОВАННАЯ в систему. И это не какая то отдельная операция, а именно своя технологическая цепочка, которая начинается в дистрибутивном коде. И каждое обновление требует контроля.
К примеру, переоценку долгое время правили в дистрибутиве из за многофилиальности.
К примеру, правим дистрибутив каждое обновление в части УФЭБС.
К примеру, в дистрибутиве запрещено прагмой репок с определенными условиями- тоже правим.
Наиболее частый пример-использование дистрибутивных функций, процедур из своих операций - соотно каждое обновление-контроль.
И с другой стороны - банк работает без выходных. Время работы таково, что едва хватает на бэкап ежесуточный(разница с филиалом 7 час) . Каждое обновление согласовываем с бизнесом. Ставим исключительно ночью, чаще всего с пятницы на субботу. В субботу запускаем бизнес и продолжаем ставить ДОПОЛНЕНИЯ.Режим достаточно рискованный.
Говорить о том что обновления легкие слабое утешение, компиляция все равно занимает существенное время.
Ну вобщем для нас раз в две недели тяжкий вариант.
Тем более в летнее время. |
|
|
svn
Профи
Вступление в Клуб: 04.02.2008
|
| Вт Апр 26, 2011 16:04 |
|
|
| а щас как отберут ключи разработчика.. что вы делать будете? |
|
|
Igorka
Профи
Вступление в Клуб: 28.09.2007
|
| Вт Апр 26, 2011 18:02 |
|
|
| svn пишет: | | а щас как отберут ключи разработчика.. что вы делать будете? |
умеючи, очень многое можно сделать. |
|
|
omela
Участник со стажем
Вступление в Клуб: 01.07.2008
|
| Вт Апр 26, 2011 23:34 |
|
|
| Васильев Николай пишет: | | Я вот смотрю, и все разговор скатывается на отчетность. Ирина, Вы занимаетесь только отчетностью? Дистрибутивного функционала вам хватает полностью? Вы участвуете непосредственно в установке обновлений? Дистрибутивный код правите? |
Не только отчетностью, к счастью для меня, к тому же опыт работы не в одном банке и не по одной направленности. Занималась накатами не только обновлений, дополнений и ядра, но и выковыриванием (адаптацией) части функционала из полноценных обновлений, когда банку было сложно перейти сразу на новую версию, а в некотором смысле в этом была критическая необходимость (например, переход на 321-П, 318-П), которая и закладывается в эти самые новые и самые свежие обновления.
Продукты свои так же пишем и их наличие на накатах, в большинстве своем, тоже не сказываются.
Как тяжело переходить с одной версии Oracle на другую (здравствуй, 11g) и сколько времени занимает копирование и разворачивание схемы + обучение специалистов, когда новшества этого требуют - тоже в курсе.
Все ваши проблемы мне, поверьте, понятны. На внедрении банков титанов присутствовала. Знаю, как сильно меняют и переделывают функционал для них, не зря при первом озвучивании своей точки зрения я представила два варианта и один из них, как раз был про вас, но тут возникает следующий вопрос… вернее даже несколько.
| Васильев Николай пишет: | | Ну вобщем для нас раз в две недели тяжкий вариант. |
Раз уж ввязалась в дискуссию, скажите, как быстро вы устанавливаете обновление сейчас, притом, что оно выходит раз в 1,5-2 месяца? Как часто вы регистрируете ошибки, которые вам обещают исправить в версии, которая должна выйти в довольно далеком (по нынешним быстротечным меркам) будущем? Сколько личного времени вы (ваши коллеги) сейчас тратите на устранение этих ошибок, придумывая наспех заплатки, которые не всегда вяжутся с дальнейшей цепочкой, потому что ошибки исправлять надо, а разработчик не может предоставить вам исправление по некоторым пунктам раньше, чем это запланировано следующей версией?
Я себе представляю все это так: обновление выходит раз в две недели. Далее человек, который занимается обновлениями версии в банке, устанавливает его на свежую тестовую копию рабочей схемы. Сотрудники ИТ проверяют "валидность" (работоспособность) своих доработок, специалисты бизнес подразделений проверяют (если есть возможность, то в свободные минуты рабочего времени) операции, которыми пользуются и отписывают, что все Ок. Далее принимается решение о необходимости срочного наката. Если в этом нет критической необходимости, то вроде как поддержку предпоследней версии никто не отменял(?) и ждем следующую, которая выходит через 2 недели, ставим его на ту же тестовую схему и проверяем по той же схеме. Далее принимается решение, что мы морально отстаем, потому что поправили и то и это, изменения в нормативных документах и т.п., а у нас на рабочей схеме этого и того еще нет. Выбирается один день в месяце (как обычно не в конце месяца, когда начисление процентов, гашения и начало отчетного периода) и ставятся оба обновления (если их объем позволяет уложиться в день) на рабочую версию. Раз в месяц - такой вариант тоже не реально?
Другое дело, что у вас режим работы без выходных, но тогда по логике у вас и службе сопровождения не привыкать и механизм отлаженный для таких маневров уже должен быть... риски, куда без них. Вроде из-за уменьшения этих самых рисков и началась эта канитель с ускоренным обновлением
Лично я жду обновлений с большим нетерпением, особенно, когда вопросы ребром стоят по той части, которая должна в этих самых обновлениях присутствовать и от скорости их установки начинают зависеть многие вещи.
Вы требуете улучшенного сопровождения и при этом хотите, чтобы разработчик предусмотрел все, что банк творит на схеме. Свои риски ЦФТ наверняка взвешивал и наверняка пытался предугадать, исходя опять таки из того, что банк пользуется дистрибутивным функционалом, а раз нет - регистрируйте доработки и их проверят на соответствие. Вроде все варианты предусмотрены
Я не пыталась тут определить единственное правильное решение, к тому же манера темы в виде опроса этого не предполагает сама по себе. Просто интересно было, почему только мои наблюдения привели меня к варианту "Да", несмотря на то, что ваши проблемы мне, как я уже сказала выше, весьма понятны и принятая вами позиция имеет место быть.
Вы имеете право ее отстаивать, если она вам ближе, удобнее по всем параметрам и, к тому же, вы за нее платите
_________________
Трехглазый передает привет банкирам, и желает им долгого здравия (:. |
|
|
Igorka
Профи
Вступление в Клуб: 28.09.2007
|
| Ср Апр 27, 2011 08:21 |
|
|
| Цитата: | | как быстро вы устанавливаете обновление сейчас, притом, что оно выходит раз в 1,5-2 месяца? Как часто вы регистрируете ошибки |
раз в 2-3 месяца.
ошибки регистрим регулярно, нередки случаи типа:
- У вас тут ошибка в 11.1
- исправим в следующей версии 11.2, она скроро выйдет, а пока вы можете руками ......
неделя препирательств
- вот вам библиотека из 11.2
- ой, а в ней другая ошибка
- а у нас не повторяется!
- а у нас стабильна
- а пришлите 1,2,3,4,5,6,7,8,9,10,......, нет, не повторяется
- а мы вам доступ на нашу схему!
- ага, видим, исправим в 11.3-6
мы мысленно, "А что испортите?"
| Цитата: | | при этом хотите, чтобы разработчик предусмотрел все, что банк творит на схеме. |
хотим, чтобы ЦФТ не портил то, что рботает. |
|
|
Васильев Николай
Профи
Вступление в Клуб: 29.06.2007
|
| Ср Апр 27, 2011 08:50 |
|
|
| svn пишет: | | а щас как отберут ключи разработчика.. что вы делать будете? |
Есть такие люди- шаманы
Шаманить будем, оракла никто не отменял, лицензию разработчика
не спрашивает, за разработку денег не требует, в количестве не ограничивает и тд ... в отличие от ЦФТ.
ЗЫ. ваш филиал в Тольятти на чем работает? На ИБСО, в онлайне? |
|
|
zlodey
Участник - экстремал
Вступление в Клуб: 27.09.2007
|
| Вт Ноя 22, 2011 20:49 |
|
|
Непреложным фактом является то, что требуя с банков деньги за их собственные доработки, ЦФТ лишил свой продукт главного конкурентного преимущества на рынке, а именно наличие конструктора, среды разработки приложений.
Все остальные рассуждения - поток сознания. |
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
|
|
IBSO
Профи
Вступление в Клуб: 20.08.2009
|
| Чт Ноя 24, 2011 11:40 |
|
|
Погрешности статистики |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Чт Ноя 24, 2011 13:13 |
|
|
Ха! Я писал письмо в ЦФТ, чтобы мнение нашего банка тоже поместили в результаты этого опроса. Но мне ответили, что опрос проводился среди тех банков, которые перешли на установку двухнедельных обновлений.  Я ответил, что мы тоже две штуки попробовали установить (11.7 и 11.8 ), в результате чего получили подтверждение точки зрения, сформулированной в открытом письме и последующей переписке. Но мнение в опросе все равно не опубликовали.
Да и на наше официальное майское письмо руководство ЦФТ так до сих пор не ответило. Даже напоминания не помогают. 
Такое отношение о многом говорит. |
|
|
IBSO
Профи
Вступление в Клуб: 20.08.2009
|
| Чт Ноя 24, 2011 13:52 |
|
|
Ну почему они должны отвечать нам?
Представьте ситуацию : подорожал бензин (жилье, хлеб и т.д.). Весь народ пишет письма правительству, а правительство каждому отвечает и еще о ! чудо! снижает цены на это все...
Чудес не бывает, к сожалению, как бы нам этого не хотелось. |
|
|
Gagana
Участник - экстремал
Вступление в Клуб: 05.06.2008
|
| Пн Фев 13, 2012 13:33 |
|
|
| zlodey пишет: | Непреложным фактом является то, что требуя с банков деньги за их собственные доработки, ЦФТ лишил свой продукт главного конкурентного преимущества на рынке, а именно наличие конструктора, среды разработки приложений.
Все остальные рассуждения - поток сознания. |
ЦФТ, видимо, больше не считает наличие удобного компилятора главным конкурентным преимуществом своей Системы. Хотя возможность использования этого удобного инструмента остается. Возможно, ЦФТ вообще не хочет свести свою роль к разработке платформы разработки, теряя функциональные рынки. Главность данного конкуретного преимущества - это следствие застревания многих давних партнеров ЦФТ в старой ИТ-парадигме. Возможно, ЦФТ вообще считает локал одним из главных зол для бизнеса банков. Потому что он, по мере накопления, мешает банку развиваться и отвечать на вызовы внешней среды.
Кто знает этих ЦФТ-шников? |
|
|
vtar
Эксперт
Вступление в Клуб: 20.03.2009
|
| Пн Фев 13, 2012 14:07 |
|
|
| Gagana пишет: |
Кто знает этих ЦФТ-шников? |
Толстый троллинг.
>Главность данного конкуретного преимущества - это следствие >застревания многих давних партнеров ЦФТ в старой ИТ-парадигме
Ну как бы, не ПАРТНЕРОВ, а КЛИЕНТОВ.
> Возможно, ЦФТ вообще считает локал одним из главных зол для >бизнеса банков
Возможно, ЦФТ сумеет донести мысль о вреде локалов до ЦБ РФ, ФНС и прочих "регуляторов" ... |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
