Bankir.Ru
23 мая, вторник 17:34

Объявление

Свернуть

На Bankir.ru начался цикл публикаций, созданных по следам обсуждений на форуме

Показать больше
Показать меньше

Бюрократия?

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

  • Бюрократия?

    Вместе с ростом банка растет бюрократия в моем подразделении. Если 3 года назад мы выполняли заказы пользователей, что называется "со слуха", то год - полтора назад ввели служебные записки с тех.заданием на разработку.
    На данном этапе просто служебных записок уже не хватает - часть разработок остается в стадии тестирования конечным пользователем, а через некоторое время объявляются несуществующими. Появляются разговоры, что программисты ничего не делают, что на них надо постоянно давить и т.д. и т.п. Понятно, что таких немного, но они есть, и именно они портят имидж управления .
    Сталкивался ли кто в своей практике с необходимостью бюрократии? Решалили такие проблемы?
    А то я решила придумать бланк заявки на разработку - такой монстр получился, самой стыдно стало .
    С уважением, Людмила.
    Чем больше связей, тем меньше степеней свободы.

  • #2
    2 Чернушка

    Уважаемая Чернушка, по моему мнению - от пользователей все-таки приходится защищаться - просто потому, что среди них попадаются хм-м не очень добросовестные. Конечно, можно все свести к заявкам - и такая схема работы достаточно распространена. Но как показывает жизнь - не совсем эффективна. Точнее - она эффективна в работе с внешними организациями, а внутри - больше порождает волокиты и формализма. Но ведь Вы - программист, в банке наверняка есть локальная cеть - Вам не приходила в голову идея оформить это в некое Интранет-приложение, просто в сетевое приложение-органайзер ?
    То есть - есть входящая заявка на доработку - с соответствующими полями, которая приходит к начальнику подразделения. Дальше начальник распределяет работы м/у сотрудниками, когда программа готова к тестированию - пользователю передается сообщение об этом, при этом дата фиксируется в БД. И т.д. и т.п. Если сделать получение нужной отчетности - по заявкам, времени их выполнения, тестирования и пр., руководству всегда можно будет наглядно продемонстрировать статистику. Тогда у не очень радивых пользователей возможно поубавится охоты списывать свои огрехи на АСУ. И вам будет понятней, чем собственно вы занимаетесь.
    Также бывает полезным предусмотреть степени срочности выполнения заявки.
    Единственный на мой взгляд недостаток работы по заявкам - это то, что АСУ при недостатке людей скатывается до реактивной роли в своей работе вместо активной. Но это уже совсем другая история :-)

    Комментарий


    • #3
      Проблема стара как мир. Я бы добавил, что зачастую пользователь сам не понимает, что ему надо. восприняв 'на слух', программист выполняет работу, после чего оказывается, что "я вам совсем не то говорила". и работа повторяется с нулевого цикла. Мы у себя используем следующую процедуру, может и не идеальную.
      1. Пользователь очерчивает (служебной или 'на слух' в зависимости от того, подставлчл ранее или нет) проблему.
      2. Програмист совместно с представителем подразделения-заказчика готовит упомянутый вами документ, содержащий
      источники информации
      описание интерфейса ввода (при необходимости)
      алгоритмы расчета
      шаблоны отчетных форм
      Для этого выделено 2 человека, включая меня, грешного.
      3. Собственно разработка
      4. прием в эксплуатацию с оформлением акта
      Забюрократизировано, зато
      получили то, что просили.
      если работает не так, то можно найти, почему.

      отдельный вопрос контроля сроков по 2,3,4 этапам, но это за рамками темы

      Комментарий


      • #4
        У нас, например, введено специальное "Положение
        о порядке приобретения, разработки, эксплуатации и сопровождения программного обеспечения в ........"
        Где четко определяется как и что должно быть написано или приобретено.
        Цитирую...

        2.1.1. Новое прикладное ПО приобретается или заказывается при изменении функций подразделения обусловленных:

        - внедрением новых услуг в Банке,
        - изменением в законодательстве,
        - невозможности выполнения подразделением своих функций или потерей конкурентоспособности подразделения при использованием эксплуатируемого ПО,
        - отсутствием соответствующего прикладного ПО в подразделении.

        В заявке на приобретение или заказ нового ПО должно быть указано:
        - назначение ПО;
        - перечень автоматизируемых с помощью предполагаемой разработки функций;
        - существующие способы решения предлагаемых к автоматизации функций, в том числе наименование, версия (если известны), рекомендуемые предприятия - производители ПО;
        - технические требования к разработке (если предполагается);
        - предполагаемый эффект от внедрения разработки;
        - характер используемой информации;
        - какие существующие автоматизированные подсистемы будут затронуты при реализации данного ПО;
        - желательный срок реализации.
        - сотрудник подразделения - заказчика, уполномоченный решать вопросы по заказу ПО. (Если такой сотрудник не указан, то вопросы по новому ПО решает руководитель соответствующего подразделения).
        По инициативе подразделения - заказчика для формирования технических требований на разработку создается рабочая группа из представителей заинтересованных подразделений Банка и ДА. Состав рабочей группы и план ее работ утверждается Первым заместителем Президента, курирующим ДА.
        2.1.2. Заказ или приобретение нового ПО у стороннего производителя.
        Выбор стороннего производителя ПО производится, как правило, на конкурсной основе. Заключение договоров, предусматривающих приобретение или разработку ПО, осуществляется согласно действующим нормативным документам Банка. Все необходимые согласования при подготовке договоров проводятся подразделением - заказчиком прикладного ПО, а при приобретении системного ПО - ДА.
        Заказ нового ПО у стороннего производителя осуществляется на основании технических требований или технического задания, согласованного с ДА и утвержденного в порядке, установленном в п. 4.1. настоящего положения.
        Полученное по договору ПО и сопроводительная документация поступают в архив службы главного технолога.
        2.1.4. Разработка прикладного ПО силами ДА производится, как правило, в случаях:
        - отсутствия на рынке подходящего по функциями ПО;
        - невозможности комплексирования ПО сторонних производителей с ПО, эксплуатируемым в Банке;
        - высоких затрат на приобретение ПО или разработку сторонним производителем, по сравнению с его разработкой в ДА;
        - возможности утечки интеллектуальной собственности Банка (ноу-хау) в процессе разработки ПО сторонним производителем.
        2.2. Модернизация ПО.

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

        Заявка на модернизацию ПО принимается от подразделения - заказчика или от подразделения - пользователя, с обязательной визой подразделения заказчика. В течении 5 дней ДА:
        - принимает заявку на исполнение, о чем извещает подразделение - заказчика;
        - обращается к производителю ПО;
        - либо запрашивает дополнительную информацию;
        - либо дает мотивированный отказ от исполнения заявки.
        Выполнением заявки считается подписание ответственным представителем подразделения - заказчика акта о приемке измененного ПО в эксплуатацию.

        Вот так!
        Verba volant, scripta manent.

        Комментарий


        • #5
          "Положение"? Как же, как же, узнаю родной банк. А после создания программы "контрольная компиляция", вычисление хэш-функций, аттестация аттестационной комиссией, отправка в "фонд программ и документации". И после любой перекомпиляции (ведь хэш-функция поменялась!) все по новому кругу... А перед установкой Акт о сверке хэш-функций, а после установки Акт об установке. (Я ведь правильно угадал банк?) Вот это БЮРОКРАТИЯ! Программы писать некогда, едва успеваем читать инструкции и положения. Так что служебные записки - не бюракратия, так... подстраховка.
          Простите, если что не так: очень больную мозоль зацепили.

          Комментарий


          • #6
            "Узнаю брата Колю!"
            Сбер всегда любил бюрократию. Особенно достают контрольные компиляции.

            to Чернушка

            По моему мнению у Вас пропущена одна существенная процедура - согласование ТЗ с заказчиком, чтобы не было даже повода заявить, что "я совсем не то хотел(а), что вы там напрограммировали".
            Добро всегда побеждает зло. Потому что кто победил - тот и добро.

            Комментарий


            • #7
              to Accounter
              Ну, до такой бюрократии мы, наверное, еще только через год дойдем. Пока достаточно просто общего описания проблемы и внешнего вида отчетов. Доработка ТЗ идет в интерактивном режиме.

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

              Комментарий


              • #8
                to Чернушка

                А никто и не спорит, что нужен гибкий подход к заданиям. Если софт пишется меньше чем, скажем, за 2-3 дня, то быстрее и эффективнее все сделать "в лет". Но если встает задача, требующая проработки и большого объема функционала, то без согласования ТЗ между постановщиком, заказчиком и программистом жить очень тяжело. Непонимание в этом случае это страшная проблема.
                А заявки на доработку все равно нужны, так как позволяют планировать загрузку программистов и объем выполненных работ. Но я не вижу необходимости из такой заявки делать монстра - если задача небольшая, то все решается на уровне "заказчик-разработчик" и описывать в заявке особо нечено, кроме названия и трудозатрат, если же должен подключиться аналитик или технолог, то он берет на себя все остальные описания (нормативная база и т.п.), которые включаются не в заявку, а в ТЗ.
                Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                Комментарий


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

                  Как с этим боротся тоже понятно. Почитайте "Интернет и адаптивные инновации" на osp.ru или те же "6 принципов" от Microsoft. Только предлагаемые там решения не понравятся Вашему руководству. Законы Паркинсона, к сожалению, пока никто не отменял :-)

                  Комментарий


                  • #10
                    2 Зануда.
                    Судя по тому, что я не понял о чем ты, то банк угадан не правильно

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

                    2 Accounter
                    Проблема согласования заказчика и изготовителя неплохо рассмотрена тут
                    Verba volant, scripta manent.

                    Комментарий


                    • #11
                      Если подходить к бюрократии как к элементу контроля, то это безусловно благо. Понятно, что сам контроль не должен мешать процессу. А вот то, что он будет мешать специалистам - это точно.

                      Для эффективной организации бюрократии есть ряд общепризнаных методик - INSM+ITIL, CobiT ... Может их использовать? Тем более если мучает болезнь роста. Представляете отчет на правлении - "Мы разработали стратегию развития ИТ. Основная цель - внедрение эффективной системы контроля за развитием ИТ в Банке".

                      Уважение и почет руководства, а не бюрократия ;-).

                      Константин.

                      Комментарий


                      • #12
                        2 Чернушка!
                        Здравствуйте дорогая Чернушка!
                        Повествую свою историю!
                        Так случилось, что территориально мой отдел разнесён!
                        Часть сидит в центральном - остальная на выселках!
                        Так вот тех программеров, что сидят в центральном бухи и еже с ними замордовали! Давали всякие задания - типа срочно написать то се! Ребята до того завалились работой, что просто ужас! Положить КОНЕЦ этому пришлось строгим наветом своим родным программерам, что все дописки, скрипты и доработки делать по служебным запискам с мой резолюцией. Все грабли просил переводить на меня! После этого в течение 2-х месяцев была тихая война! Но за тем анализируя вместе с программерами служебные записки оказалось, что 70% доработок - лишнее! Да и командование увидело нашу работу!
                        По остальной части служебных записок выбрали рациональное зерно и реализовали. Моя задача сводилась к анализу, накоплению, отфутболиванию, разбору служебных записок. Море бумаги извелось на своё нижнее полушарие прикрыли и работу сделали КАКУЮ действительно нужно!
                        Darii

                        Комментарий

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

                        Свернуть

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

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