| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
vshahmatov
Участник со стажем
Вступление в Клуб: 02.02.2010
|
 Вт Июн 19, 2012 15:04 Про обработку запросов. |
 |
Полезность: 5
|
Добрый день, коллеги!
В очередной раз пробежавшись по темам форума наткнулся на комментарии следующего рода:
| xxx пишет: | | yyy пишет: | | ... Куча времени уходит на переписку с банком и выяснение причин возникновения ошибки, хотя по сути исправления - дело пяти минут... |
Куча времени уходит на переписку с ЦФТ, даже когда им явно указываешь на ошибку в коде, приходится долго убеждать исправить ее, хотя по сути исправление- дело пяти минут..
проще самим поправить... |
из-за чего возникло желание написать данный пост с рекомендациями по оформлению заявок
Первоочередная задача сотрудника сопровождения при обработке запроса вида "Дефект":
1. Повторить ситуацию на схеме разработки
2. Убедиться, что данная ситуация является дефектом (противоречит документации, не позволяет выполнить требования ЦБ и т.п.)
После чего запрос уходит к разработке.
Соответственно при регистрации заявки в виде:
| Код: | | В операции [Класс].[операция] в строчке 153 передан не верный параметр, вместо "парам1" правильно будет передать "парам2+5" |
Несмотря на то, что проблема указана конкретно с точностью до строчки кода, повторить её специалисту затруднительно. В результате время, которое потребуется для передачи данного запроса в разработку на порядок больше чем запрос, в котором описана последовательность действий пользователя, приведшая к ошибке.
Кроме того, как показывает практика, достаточно часто предложенное исправление кода не может быть принято в дистрибутив в том виде как его предлагает инициатор из конкретного банка. Сторонний разработчик не всегда знает причин и истории развития той или иной операции, а кроме того, не редкость, когда специалисты в банках рассматривают функционал в разрезе своих настроек, и не всегда учитывают последствия предложенного исправления на другие банки с иной настройкой схемы. (прошу не воспринимать как упрек, или камень в чем-либо огород, но так действительно случается)
На мой взгляд, запрос, имеющий шансы на скорейшее разрешение должен содержать примерно следующую информацию:
1. Информацию для воспроизведения ошибки:
a. в каком продукте
b. какие операции запускал пользователь, в какой последовательности и с какими параметрами
c. какова специфика банка в данном бизнес процессе (все, что может касаться сути проблемы)
2. Что увидел пользователь и что он ожидал увидеть ("сумма созданного документа 10р а должно было быть 20" или "операция выдала сообщение об ошибке, хотя все данные корректны и должна была отработать" (не забываем при этом приводить колстек ошибки) )
3. Почему вы считаете, что результат работы системы ошибочен (ссылки на документацию или нормативные акты и выкладки и расчеты и т.п.)
4. И уже в дополнение к описанной выше информации можно добавить свое видение о исправлении "В операции [Класс].[операция] в строчке 153 передан не верный параметр, вместо "парам1" правильно будет передать "парам2+5"" |
|
 |
wan
Участник со стажем
Вступление в Клуб: 22.04.2012
|
| Ср Июн 20, 2012 01:30 Re: Про обработку запросов. |
|
Полезность: Нет оценки
|
| zzz пишет: |
Соответственно при регистрации заявки в виде:
| Код: | | В операции [Класс].[операция] в строчке 153 передан не верный параметр, вместо "парам1" правильно будет передать "парам2+5" |
|
никто и не утверждал, что заявки надо регистрировать в таком виде...
такие вообще надо заворачивать, как не соответствующие регламенту
| zzz пишет: |
1. Повторить ситуацию на схеме разработки
2. Убедиться, что данная ситуация является дефектом (противоречит
После чего запрос уходит к разработке.
|
алгоритм верный, только проблема со скоростью ухода и возврата оттуда...
как утверждает yyy это дело пяти минут, только цфт редко когда укладывается в заданные нормативы
| zzz пишет: |
Кроме того, как показывает практика, достаточно часто предложенное исправление кода...
|
да боже упаси предлагать менять код, сами и разбирайтесь как его менять...
разговор был о том, что после предоставления информации по пунктам 1 a b c и 2 (даже включая трассировку).
следует ответ, что повторить ситуацию на схеме разработки не удалось
и даже после указания на явную логическую ошибку кода цфт может сразу не признать ошибку
(ведь мудрый разработчик в цфт, знающий причины и историю развития, учел функционал в разрезе всех своих настроек на разных схемах...)
хотя, как правило, обещает исправиться в следующей версии
а так в цфт все шустро и складно, а в банках тянут время |
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
|
|
zlodey
Участник - экстремал
Вступление в Клуб: 27.09.2007
|
| Пт Июл 20, 2012 13:00 Re: Про обработку запросов. |
|
Полезность: Нет оценки
|
| wan пишет: | да боже упаси предлагать менять код, сами и разбирайтесь как его менять...
|
Хорошо сказано, только очень часто пока не разжуешь и в рот не положишь сопровожденцы даже не могут вкурить суть проблемы и начинают требовать прислать им совершенно ненужную инфу, а ведь банку приходится тратить на это свое время, а значит и деньги. Проще и быстрее было бы просто показать фрагмент кода программисту, программист скорее разберется, что нужно поправить. |
|
|
vshahmatov
Участник со стажем
Вступление в Клуб: 02.02.2010
|
| Вт Июл 24, 2012 10:01 Re: Про обработку запросов. |
|
Полезность: Нет оценки
|
| zlodey пишет: |
Хорошо сказано, только очень часто пока не разжуешь и в рот не положишь сопровожденцы даже не могут вкурить суть проблемы и начинают требовать прислать им совершенно ненужную инфу, а ведь банку приходится тратить на это свое время, а значит и деньги. Проще и быстрее было бы просто показать фрагмент кода программисту, программист скорее разберется, что нужно поправить. |
Как я писал ранее, главная задача сопровождения - повторить дефект. Если вы уже разобрались в нем, и понимаете механизм срабатывания баги, то дайте сопровожденцам четкое описание условий возникновения проблемы (последовательность действий в навигаторе) и пояснение, почему читаете логику ошибочной, и ваш запрос в кратчайшие сроки попадет к разработчику. |
|
|
Alexsey
Эксперт
Вступление в Клуб: 06.09.2007
|
| Вт Июл 24, 2012 15:00 Re: Про обработку запросов. |
|
Полезность: Нет оценки
|
| vshahmatov пишет: | | zlodey пишет: |
Хорошо сказано, только очень часто пока не разжуешь и в рот не положишь сопровожденцы даже не могут вкурить суть проблемы и начинают требовать прислать им совершенно ненужную инфу, а ведь банку приходится тратить на это свое время, а значит и деньги. Проще и быстрее было бы просто показать фрагмент кода программисту, программист скорее разберется, что нужно поправить. |
Как я писал ранее, главная задача сопровождения - повторить дефект. Если вы уже разобрались в нем, и понимаете механизм срабатывания баги, то дайте сопровожденцам четкое описание условий возникновения проблемы (последовательность действий в навигаторе) и пояснение, почему читаете логику ошибочной, и ваш запрос в кратчайшие сроки попадет к разработчику. |
Витя, в свое время (3 года назад) много раз на это наступали. Предоставляли весь спектр от строки в коде до ссылок на нормативные акты (ФЗ, инструкции, положения и указания ЦБ). Срок в лучшем случае 2-3 месяца. В это время стояла заплатка. Про то, как сейчас не могу сказать - не знаю. Да и потребности в этом нет.
_________________
всегда есть как минимум 2 выхода |
|
|
vshahmatov
Участник со стажем
Вступление в Клуб: 02.02.2010
|
| Вт Июл 24, 2012 15:34 |
|
Полезность: Нет оценки
|
Всегда остается человеческий фактор. Сопровожденцы тоже люди, и иногда чего-то не знают. Да и разработчик может ошибаться, и оспаривать предложение банка на ровном месте. И бизнес специалисты банка бывало оказывались неправы.
Сферического сопровождения в вакууме не достичь, но упростить друг другу работу мы все способны. |
|
|
Alexsey
Эксперт
Вступление в Клуб: 06.09.2007
|
| Вт Июл 24, 2012 15:48 |
|
Полезность: Нет оценки
|
Взаимодействие это конечно очень хорошо. Мне лично, очень хочется чтобы очевидные вещи, подкрепленные нормативными актами, решались не за 2-3 месяца, а хотя бы в течении недели. Я думаю это устроит обе стороны и сделает систему лучше.
_________________
всегда есть как минимум 2 выхода |
|
|
devor
Профи
Вступление в Клуб: 13.02.2012
|
| Ср Июл 25, 2012 08:07 |
|
Полезность: Нет оценки
|
| Alexsey пишет: | | Взаимодействие это конечно очень хорошо. Мне лично, очень хочется чтобы очевидные вещи, подкрепленные нормативными актами, решались не за 2-3 месяца, а хотя бы в течении недели. Я думаю это устроит обе стороны и сделает систему лучше. |
В последние год-два ситуация поменялась в лучшую сторону. |
|
|
zlodey
Участник - экстремал
Вступление в Клуб: 27.09.2007
|
| Ср Сен 19, 2012 11:32 Вот так надо писать запросы в ЦФТ |
|
Полезность: Нет оценки
|
"В последних версиях значительно увеличилось количество случаев, когда в долго и надежно работающий функционал вносятся "улучшения" (запросы BS00349007, BS00459793 и др.), в результате которых блокируется работа всего банка. Предлагаю усилить контроль за качеством обновлений, выявить и "обезвредить" виновных."
А то мы все цацкаемся с ними...Вообще пора в договоры сопровождения прописывать штрафы за некачественные обновления. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
