19 октября, четверг 23:07
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Программисты в банке, самоделки

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Программисты в банке, самоделки

    Всем добрый день!
    Может кто-нибудь заинтересуется о вопросе "самоделок", так называемых собственных разработок силами программистов банка.
    Требовать ли премии и как оценивать размер последних?

  • #2
    Извини, но я не понимаю суть предложенной темы в части гонораров, оплаты. Если ты программист, то это часть твоей работы. Основная цель, как я понимаю, это обеспечить работу системы, а средства зависят от возможностей организации и способностей людей. Хотя, может я просто ничего не смыслю в системах оплаты труда программеров. Вернемся к теме. Тема самоделок, я думаю более чем актуальная, наверное для любой организации. Есть плюсы, есть минусы. Очень бы хотелось, послушать знающих людей о том как избежать минусов. Сам, бывает, грешу созданием какой-нибудь чучки, но делаю это в Accesse и чувствую, что чего-то не хватает. То ли SQL Server еще поставить, то ли бросить фигней страдать и научиться чему-нибудь стоящему (Delfy какой-нить-то). Вообщем, хочется совета: чем писать, как это делать грамотнее и т.п. Я ведь уже решил для себя, что писать можно и нужно, главное не забыть, что пишешь не для себя, а для людей, кто с тобой работает, кто будет работать после тебя. Вот.

    Комментарий


    • #3
      Я считаю иначе по поводу оплаты труда программеров
      Как то не очень хочется писать за зарплату
      А вообще оценить наш труд трудно.
      Писать быстро можно на Delphi + MS SQL и причем удар делать на
      Transact-SQL (хранимые процедуры) (сам давно)

      Комментарий


      • #4
        Присоединяюсь к мнению г.Prog32...
        На мой взгляд, тот размер оплаты труда который мы имеем на сегодняшний день, соответствует примерно такому требованию отдачи от нас, как сопровождение и настройка стороннего ПО...
        Совсем не лишне требовать от нас и разработки собственного ПО, но в данном случае, предлагаю оплачивать наш труд в размерах соизмеримых с оплатой труда фирм производителей банковского ПО, т.к. в конечном счёте для банка продукт будет получаться более высокого качества и точнее удовлетворяющий потребностям банка.
        Но к сожалению часто получается по другому... Ну надо, так надо...
        Единственная рекомендация, это разрабатывать ЛЮБОЕ ПО после ПИСЬМЕННОЙ заявки руководства...

        Комментарий


        • #5
          К тому же появляется некоторая зависимость банка от конкретного человека (разработчика) и можно потом диктовать свои условия

          Ищу сотрудничества, обмен опытом и своими разработками
          немного о себе: я уже более 3 лет в банке (RS-Bank 4.31)
          пишу на Delphi под MS SQL 6.5-7.0 есть собственные внедренные примочки(системы) для банка: обменный пункт, комплатежи, сейчас занимаюсь
          частными вкладами

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

          Вот так.

          Комментарий


          • #6
            > Руководство в принципе не желает сотрудничать с фирмами
            > производителями банковского софта, на это есть программисты банка

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

            Комментарий


            • #7
              > Руководство в принципе не желает сотрудничать с фирмами
              > производителями банковского софта, на это есть программисты банка

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

              Комментарий


              • #8
                У меня в трудовом контракте нет ни слова о разработке отдельных систем
                сопровождение, администрирование - это я понимаю, за это получаю зарплату (только в раб время)
                Но если требуют писать собственный софт, например, Частные вклады,
                Обменные пункты, Ком платежи - и все за ту же зарплату, при этом руководство отказывается приобретать эти системы у фирм разработчиков
                налицо сокращение расходов банка
                в отделе автоматизации нет подотдела разработчиков, может затребовать
                пересмотрения должностных обязанностей?

                Комментарий


                • #9
                  В таком случае лучше вообще пересмотреть структуру отдела автоматизации, выделить отдельные направления по сопровождению, по разработке, по обслуживанию средств связи и коммуникаций и т.д.
                  И закрепить все это в должностных инструкциях.
                  По идее разработчик не должен отвлекаться на сопровождение софта (в смысле администрирования, обучения сотрудников и т.д.) - этим должен заниматься администратор системы. А разработчик - устанять ошибки, писать новый софт, дополнять существующий новым функционалом на основе постановок задач.
                  С уважением, Евгения

                  Комментарий


                  • #10
                    Блин, денег мало -- уйди в другой банк... Не берут -- ну, тут ничего не сделать...

                    Комментарий


                    • #11
                      Блин, денег мало -- уйди в другой банк... Не берут -- ну, тут ничего не сделать...

                      Комментарий


                      • #12
                        Я согласен, и уровень зарплаты должен быть выше

                        Комментарий


                        • #13
                          В банке , котором я работаю, поступили немного другим образом. А именно , прикупили АБС, которая являеттся полностью открытой, т.е. Ситема на базе Sybase SQL Anywhere с полностью открытыми таблицами, ссылками, процедурами, пояснениями и т.д.
                          Дык вот, после этого поступили таким образом - посопровождались у производителей полтора годика, потом прекратили сопровождение , т.к. свои программисты уже были готовы писать под этот опердень... Так и по сей день.
                          Получается , что на этом банк экономит большме деньги.
                          Пример. За месяц-полтора (два с обкаткой) был запущен проект нормальный обменных пунктов, т.е в обменнике комп делает всё от регистрации до печати, на дискетах информ передается в П и из него в Банк. Обработка в Банке занимает около 2-3 минут на пункт.Вся отчетность автоматически. Все проводки автоматически.И т.д.
                          Когда спросили у разработчиков нашей АБС почем это всё встанет если у них брать, получилось $3000 начальная поставка банковского модуля и $400 за каждый пункт + сопровождение порядка 10-20 проц от суммы в год.
                          Можете посчитать на примере полутора десятков обменников, скока это выходит.... Ясен пень, даже за 2 месяца зарплатой столько не выйдет.
                          + к этому банк имеет нормальное сопровождение тоакого комплекса всегда под рукой (первое время даже домой в выходные звонили )

                          Смысл в том, что программист в банке нужен не для того , что бы сетку содержать, чинить, прокладывать (нужное подчеркнуть) или починка, сборка техники, А ДЛЯ РАЗВИТИЯ программного обеспечения. И это не установка Винды98 вместо Винды95 и не установка и сопровождение глюкавых ЦБшных прог.
                          ЭТО ИМЕННО НАПИСАНИЕ СВОИХ ПРОГ.
                          Поэтому программист когда идет в банк , должен понимать, что он будет писАть. Всё остальное вышеперечисленное - по сути это технология и сопровождение.

                          Вроде всё. Теперь ругайте.

                          Комментарий


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

                            Комментарий


                            • #15
                              Уважаемые господа.
                              вот мой взгляд на данную тему.
                              Несколько лет я трудился начальником управления автоматизации банка.
                              Я считал, что моя прямая обязанность, как начальника отдела, донести до руководства такую стратегию развития программно-аппаратного комплекса банка, которая не ставила бы банк в зависимость от наличия в отделе автоматизации или неналичия такового разработчика систем и подсистем АБС. Да, я абсолютно согласен, что ядро АБС и любой ее подсистемы должен быть разработан и сопровождаем специализированной компанией (Диасофт, R-Style, Програмбанк или еще кто там сейчас есть на рынке). Отдел АСУ мелких и средних банков НЕ ДОЛЖЕН, НЕ ИМЕЕТ ПРАВА разрабатывать и внедрять собственные подсистемы, реализующие какие-либо масштабные (в понимании бухгалтера банка) подсистемы. Кончается это всегда плохо, потому что не существует людей, которые всю свою жизнь и даже немножко больше работают на одном месте (у философов есть высказывание: "Человек, работающий на одном месте больше ПЯТИ лет - плохой сотрудник").
                              Отдел автоматизации в среднем и мелком банке - это отдел поддержки.
                              К сожалению, руководство это плохо понимает. Понимание достигается только при возникновении совершенно конкретных проблем, могущих привести к остановке производственного процесса в банке. Донесение до понимания руководства банка РИСКА ВОЗНИКНОВЕНИЯ ТАКОЙ СИТУАЦИИ - ЗАДАЧА НАЧАЛЬНИКА ОТДЕЛА АСУ (или как-нибудь там по-другому).
                              Такое чуть было не случилось у нас. Отчеты ЦБ у нас в банке на момент моего прихода формировались не внутри АБС программкой под VBA - ну удобно было так человеку, который ранее этими вещами занимался, вот он и разработал ее для себя, ЛИЧНО ДЛЯ СЕБЯ. А мы стали пользоваться, потому что средств купить подсистему у разработчика нашей АБС все как-то не находилось, а сил самостоятельно примочки писать не было.
                              Мне удалось уговорить руководство взять на работу еще одного специалиста по нашей АБС для поддержания отчетов для ЦБ - взяли. Через месяц на компьютере, где стояла эта VBA-шная примочка потерял винчестер...
                              Руководство было только радо, что так все хорошо получилось и даже денег дало на приобретение отчетов ЦБ, написанных компанией-разработчиком нашей АБС...
                              Другой пример более показателен. Один из банков нашего города как-то в свое время не озадачился вложениями в АБС специализированных компаний. Руководство решило пойти по пути, что совя рубашка ближе к телу, программеры банка под UNIX'ом написали опердень. Документашка, исходники, все чин по чину... Но в один прекрасный день компашка программеров разлетелаьс в разные стороны, а через пару недель вся Россия узнала о переходе на новый план счетов...
                              С тех пор этот банк ориентирует отдел АСУ только на СОПРОВОЖДЕНИЕ...
                              А вообще смотрите в трудовой договор, должностную инструкцию и не бойтесь задавать вопросы руководству, а также "пинать" начальника отдела, который обязан защищать перед руководством ваши интересы.
                              И не бойтесь искать другое место работы, как правило, там где вас сейчас нет действительно лучше.
                              Ну а уж если что-то написал - чест ьтебе и хвала, если иного не написано в трудовом договоре... ))

                              С уважением,
                              Сергей.

                              Комментарий


                              • #16
                                >Отдел АСУ мелких и средних банков НЕ ДОЛЖЕН, НЕ ИМЕЕТ ПРАВА >разрабатывать и внедрять собственные подсистемы, реализующие какие->либо масштабные (в понимании бухгалтера банка) подсистемы.
                                Полностью согласен с Марк_сом
                                Примеров можно привести море, когда увольнение программиста (программистов) ставило банк в интересное положение. Если программист не только толковый, но и порядочный, он не станет писать программы "под себя", которые работают только в его руках, подчеркивая его "незаменимость", он будет писать программы, которые будут служить долго и верно даже после его увольнения, но люди бывают разные...
                                Поэтому глобальные подсистемы АСБ должны быть приобретены у надежных производителей. К сожалению, в банковкой России нет универсальной программы (типа 1С) и приходися программистам при переходе из банка в банк приспосабливаться к "местной" АБС, что, конечно, развивает мозги, но...
                                Что же касается темы форума-гонорар за разработку и вообще оплата труда программиста в банке, то это, с моей точки зрения бесполезный разговор в нашей стране. Люди, у которых "мозги кипят", ТАМ посучают за свой труд столько, сколько не получает, к примеру, бухгалтер или экономист. Но и здесь бывают банки, где труд программиста в почете, но это зависит от внутренней банковской политике и от начальника отдела.

                                Комментарий


                                • #17
                                  Согласен! Есть банки где спецы очень ценяться! И получают на уровне начальников отделов! А любая АБС глюкалова и требует накрутов в большей или меньшей степени. Я админ а не программер... Но все равно пишу софт во славу банка - чтоб облегчить жизнь себе и людям...
                                  Программеры при банке близки к жизни...Делают то что надо и быстро...
                                  А разработчики устраняют баги и корректируют софт под распоряжения ЦБ... За частую они далеки от банка... И дай бог если там 10 процентов девелоперов работали в банке... А самые лучшие разработчики - это бывшие банковские программеры...

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

                                  Комментарий


                                  • #18
                                    В корне не согласен !
                                    Программист в банке нужен как раз для того, чтобы писать программы. Сопровождение программ, будь то АБС, ЦБшные проги или проги других программеров - это ТЕХНОЛОГИ. Давайте разделим эти понятия.
                                    Дальше. НОРМАЛЬНЫЙ программист,т.е. не обиженный отношением и з/п, будет писать программы, которые будут работать и работать (как Energizer ) и после ухода этого программиста. А вот технологи будут производить настройку этой программы (т.е. не сам текст, а именно настоечные таблицы и файлы) под новые изменения.
                                    В этом и есть смысл программиста в банке.
                                    Если Вы считаете , что программист нужен для СОПРОВОЖДЕНИЯ - то это называется ТЕХНОЛОГ. Простите меня, но у технолога другие задачи и другая з/п.

                                    Собственные разраьотки в банке позволяют банку (и даже не столько банку, просто любой конторе) не быть зависимой от внешних обстоятельств (выходной в конторе разработчика, увольнение конкретного работника в конторе разработчика, его запой или другая болезнь,кроме того, правильная ИМХО позиция при распределении средств на развитие).

                                    Если все деньги , направляемые на развитие, напрявлять не на закупку и сопровождение, а распределять как 80% на поощрение собственных разработок и 20 на приобретение новых у сторонних производителей, то это ИМХО наиболее правильно.

                                    Мой банк так и поступил. Сейчас мы уже совсем от сопровождения отказались. Только собственными силами.В результате денег на собственные разработки полно и начальство довольно.

                                    Комментарий


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

                                      Комментарий


                                      • #20
                                        Когда я говорил о том, что отдел автоматизации мелкого и среднего банка должен акцентировать свое внимание на сопровождении, я не имел ввиду, что они ну совсем ничего не пишут. Конечно пишут, но только вещи, которые называют тонкой настройкой под конкретные запросы конкретного банка. Всякие там отчеты нужны и прямые, и обратные, и в шашечку, и в клеточку, и по диагонали, и те, которые были нужны еще вчера, и заменяющие ЦБ-шные паршивые проги, и т.д., и т.п. Это не то же самое, что написать свой собственный опердень. Это означает акцентирование внимания на обходах багов, бяк, ляпов, безумных и неразумных идей разработчиков, а также удовлетворение текущих растущих потребностей внутрибанковских шутников.
                                        А теперь посчитайте целесообразность содержания штата программеров, пишуших опердень. Вы потеряете дар речи, такое было у одного моего знакомого управляющего банком. Когда же он заставил посчитать, как там будут обстоять дела с расходами, если купить, например, ЦФТ-шную штуку - не самая дешевая вещь, согласитесь, то сделал однозначный вывод в пользу приобретения АБС и полного отказа от самописцев. Программеры были переориентированы на решение других задач. И еще раз повторюсь, что сопровождение не есть в моем понимании "работа технолога" (аргументы выше).
                                        Кроме того, важен вопрос, какая АБС используется в банке. На мой взгляд, практически не существует в России банка, который бы при реальном внедрении не удовлетворился одной из российских разработок (не буду ее называть, а то еще подумаете, что я ее рекламирую): вполне реальные цены, хорошая масштабируемость, приемлемая скорость работы, встроенный язык программирования, приемлемая документация... Заметьте, ни разу не сказал: "Отличная или великолепная". Есть куча минусов, есть дыры, есть ляпы. Но они все обходятся, устраняются, отслеживаются... Если фирма - разработчик вдруг развалится, то, не увлеичивая штат программеров можно жить еще несколько лет до выбора другой системы.
                                        И еще раз повторюсь. Если в вашем контракте (трудовом договоре) не написано, что за разработку чего-то там вам будут доплачивать, то вы можете ожидать только похвалы.
                                        Но в том банке, где я работал, был достаточно подробный трудовой договор и конкретные должностные интрсукции. Да, мы выполняли что-то и сверх инструкций и договоров, но за это я, начальник отдела автоматизации, всегда требовал дополнительной оплаты. В противном случае устраивал тендер между компаниями, которые занимаются аналогичными вещами профессионально, и результаты тендера отдавал руководству банка, а потом устраивалось обсуждение. Результат, чаще принимались решения в пользу привлечения сторонних фирм. Почему? Думайте сами.
                                        С уважением,
                                        Сергей

                                        Комментарий


                                        • #21
                                          Вообще не очень понятна тема... Если банк нанимает _программистов_ - то они должны программировать. Сисопы - сисопить. Коммуникационная служба - заниматься своим делом... Если процессинг есть - должна быть и служба обихаживания банкоматов, расстановки ПОСТ. Из этого набора и формируется управление автоматизации (у нас - центр информационных технологий).
                                          Деньги - ни при чем, есть места, где платят мало, есть - где хорошо.

                                          А покупных продуктов у нас нет. Вообще (это про АБС). И интерфейсы ко всему на свете (свифту, рейтеру и прочему). Процессинг купили - так все равно свой бэк-офис работает.

                                          А что касается зависимости - правильно писАть нужно. И не будет ее.

                                          ------------------
                                          /dendy

                                          Комментарий


                                          • #22
                                            Поддерживаю dendy.У нас аналогично.
                                            dendy, сайт у вас тоже покупной. Угадал?

                                            Честное слово, не хочется связываться с покупными АБС. Не в деньгах дело. Банк не маленький, >50 филиалов >1000 человек.
                                            Работает 10 лет. От новой системы ничего принципиально не измениться. Одни проблемы заменят другие. Как-то мы вели переговоры с одной часто упоминаемой здесь компанией. К вечеру они нас убеждали, что нам менять ничего не надо. Не буди лихо, пока оно тихо...

                                            Сложных программ в банке не бывает. Надо профессионально разбираться во всем самому и создавать технологические цепочки от начала до конца. Естественно, нормативные документы все знать. Это и должностных обязанностях у меня прописано, как начальника отдела АБС. Надо не брезговать тем, чтобы посидеть на каком-нибудь новом АРМе пару часов, реально клиентов пообслуживать. Потом подняться из оперзала к себе и переделать "под людей", причем, чтобы на программе мог и даун работать. Тогда никто не скажет, что система сложная и неудобная. Ориентироваться на слабого в связке. У меня много таких подходов, если кому интересно, могу еще подкинуть.

                                            О зарплате. Дополнительно платят за переработку, новые вещи и, помню, за проблему 2000.

                                            Говоря, о зарплате, ответьте себе на вопрос - Вы будете работать в 2 раза лучше, если Вам будет платить в 2 раза больше. Если да - ищите другую работу.

                                            Комментарий


                                            • #23
                                              Без написания своих прог банку не обойдтись. Написал клиента для работы с региональной системой электронных платежей . Он связывает ее с оперднем банка , выдает сверхоперативную отчетность по поступлениям и файлы для банк клиента. При заключении контракта были устно оговорены меры независмости банка от меня. Мне и самомуне нужна их зависмость от меня.Т.е пишу на Visual Basic, придерживаясь стндартов оформления листинга. Предварительно проектирую на BPWin, ERWin так что общая документация возникает сама собой.Сечас установил Rational Rose для бесика так что будет еще детальнее. Пока был в отпуске комплекс программ в 52 тысячи строк кодаа сопровождали без мня.

                                              Комментарий


                                              • #24
                                                2 AK

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

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


                                                ------------------
                                                /dendy

                                                Комментарий


                                                • #25
                                                  Абсолютно согласен с MARK_Sом! За десять лет нагляделся на банковские разработки in house и их последствия, начиная с Садко и кончая историей, которую наблюдал тут в одной кредитной организации (где работают мои знакомые) буквально в последнее время. Во-первых, разработка толковой АБС - это сотни человеко-лет (спросите представителей фирм). Во-вторых, разработчики самого крутого банка знают только технологию и опыт работы ЭТОГО банка (в лучшем случае, еще нескольких других), а разработчики специализированной фирмы -- технологию и опыт всех банков, в которых стоит их разработка. В-третьих, в банке практически никогда не удается наладить корректный производственный процесс разработки (с планированием, документированием, ведением версий, тестированием и т.п., см. Брукса и др.). Как правило, технические задания как положено не разрабатываются и не выдаются, в результате с программиста невозможно спросить за результат, так как он сам себе и ставил задачу, и решал ее, и разрабатывал критерии оценки. В банках обычно не бывает профессиональных системных аналитиков-постановщиков задачи, поэтому разрабатываемая система делается исходя из представлений о бизнес-процессах, которые есть у программистов и конечных потребителей. При этом почти всегда совершается классическая ошибка, от которой предостерегают все учебники по АСУ: вместо оптимизации бизнес-процесса под информационную технологию автоматизируется существующий (без нее) бизнес-процесс. Короче, происходит автоматизация хаоса. Еще хуже с развитием системы, так как оно неизбежно идет не планомерно, а в рамках "затыкания дыр".

                                                  Желаю удачи!
                                                  Александр Евтюшкин

                                                  Комментарий


                                                  • #26
                                                    Существующие фирменные продукты ужасны
                                                    > АБС - это сотни человеко-лет (спросите представителей фирм).
                                                    А никто и не мешает взять крутейшую абс и на хорошем CASE снять и оптимизировать ее структуру
                                                    >Во-вторых, разработчики самого крутого банка знают только технологию >и опыт работы ЭТОГО банка (в лучшем случае, еще нескольких других), >а разработчики специализированной фирмы -- технологию и опыт всех >
                                                    >банков, в которых стоит их разработка.
                                                    Непонятно зачем работая в конкретном банке писать программу на все случаи жизни. Сомнительна такая универсальность персонала фирм разработчиков. Я таких не видел.

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

                                                    Свою программу в банке пишут когда специалистам не удаетсяя сделать что то вручную. Критерий простой - один человек делает то, что ранше делала целая бригада. CASE позволяет легко решить проблемы с документацией и корректировать по мере надобности постановку. Профессионалов постановщиков готовили для работы не ЕС. Сейчас их ни в одну фирму разработчика ПО не возмут просто по возрасту. Где же им работать как не в банке. То что бизнем процесс должен подстраиватся под ваши программы это интересное утверждение. Я с ним не согласен. .

                                                    Комментарий


                                                    • #27
                                                      Хочу поделиться своим взглядом на "самоделкиных".Во-первых держать целый штат программеров могут себе позволить только крупные банки.
                                                      А что делать мелким?.Во-вторых "Опердень"- это вообще отдельная тема.
                                                      А что помимо опердня других проблем мало?Я работаю автоматизатором 4 года(у нас как раз "мелкий" банк) и по моему глубокому убеждению
                                                      Если на решение задачи по самым скромным прикидкам требуется свыше 3-ех месяцев-даже и не стоит затевать ее решение своими силами.В любом случае мелочевкой всякой заниматься придется(типа импорта данных из одной проги в другую или прикинуть Нормативы) -без этого никак.Масса задач на стыке подсистем(Оболочка для Конвы и иже с ней своя должна быть, потому как меняется не реже 1 раза в месяц).Понятное дело лучше всегда иметь исходный код под рукой. Но СВой банк-клиент??Чур меня Чур.И напоследок не помню кто сказал:Программисты в банках делятся на плохих и тех,про которых Начальство просто не знает,что они плохие программисты...

                                                      Комментарий


                                                      • #28
                                                        Коллега. Не понял вашего мрачного взгляда на жизнь. До банка я работал на горном комбинате. Один делал всю асу. И внедрение и сопровождение сети и разработка. Монтировали кабельную систему специалисты.Написанное работает на пяти предпритиях.Потом пропреподвал по программе MSP в учебном центре весь набор продуктов с которыми работал. Теперь пишу программы для банка средних размеров. Думаю, что уровень у меня повыше чем у фирменных разработчиков. Большинство из них по образованию не программисты , а какие нибудь физики или теплотехники не нашедшие работу по специальности.

                                                        Комментарий


                                                        • #29
                                                          Господи, да откуда в вас всех столько яду?

                                                          Milon, скажите, со сколькими сотрудниками софтовых фирм Вы знакомы? В сотверных фирмах программистов процентов 25-30 от общего числа работающих.
                                                          Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                                          Комментарий


                                                          • #30
                                                            To Milon:
                                                            Отвечаю не в последовательности исходного сообщения.

                                                            1. Читать надо внимательно. Бизнес-процесс должен не "подстраиваться под софт", а перестраиваться для оптимального использования возможностей информационных технологий. И под этот оптимизированный бизнес-процесс должен строиться софт.

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

                                                            3. Что до реверс-инжиниринга готовых АБС, то на этот счет я советую поговорить с Форсом. У них ушло года два, а то и больше, пока они _действительно_ освоили Symbols. Есть еще аналогичные примеры. Но главное даже не это. Никакая серьезная АБС не является коробочным продуктом (да простят меня некоторые отечественные разработчики). Любая информационная система есть на 70% бизнес-процесс и на 30% программный продукт. В эпоху АСУ это хорошо понимали, но потом погоду стали делать мальчики, наскоро освоившие FoxBase и Clipper; сейчас ситуация медленно и мучительно меняется к лучшему, чему свидетельство и этот форум. Реверс-инжиниринг не решит проблему адекватности бизнес-процесса и программного продукта. Серьезные западные фирмы поставляют свои АБС в течение 6-9 месяцев, из которых не менее двух третей срока уходит на адаптацию "скелета" к бизнес-процессам конкретного банка. Какой "образ" АБС в этом случае брать для реверс-инжиниринга? Если "скелет", то система не будет полной (для конкретного банка это проблема). Если готовую, внедренную систему - то, во-первых, кто даст скопировать ее, а во-вторых, это будет система ДРУГОГО конкретного банка.

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

                                                            5. Людей, склепавших АСУ на коленке в одиночку без постановки задачи и поэтому возомнивших о себе ;-), я с 1987 г. наблюдал без счета. Видел и их продукты, и то, что творилось с предприятиями, в которых они стояли, и т.д., и т.п. Чем раньше человек поймет, что дисциплина и культура разработки информационных систем появились не потому, что все (остальные) разработчики лохи, тем будет лучше для него.

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X