Bankir.Ru
5 декабря, понедельник 07:31

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

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

Автоматизация работы отдела разработки программного обеспечения

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

  • Автоматизация работы отдела разработки программного обеспечения

    Возникла вот необходимость в тотальном subj'е. Сейчас у нас работа отдела разработки организована следующим образом : пользователи заполняют стандартные бланки заявок на разработку\доработку ПО, подписывают их у своих начальников и несут в отдел разработки. Начальник отдела разработки распределяет заявки по программистам, согласовывая при этом сроки исполнения. Далее заявки отдаются в отдел сопровождения, где специально заточенная девушка забивает эти самые заявки в MS Project (без определения приоритетов). После исполнения заявки бланк отдается на подпись заказчику, после чего в MSP заявке проставляется 100% исполнения.
    Так вот, хочется этот процесс типа заавтоматизировать , избавиться от бумаг и сделать вот что :
    1. конечные пользователи сами заносят в некую систему свои заявки;
    2. заявка далее попадает к соответствующему начальнику для визирования;
    3. после визирования заявка попадает начальнику отдела разработки, который может либо вернуть заявку конечному пользователю для уточнения чего-нибудь (на этап 1.), либо отмаршрутизировать заявку нужному программисту;
    4. программист устанавливает заявке срок выполнения либо возвращает заявку конечному пользователю для уточнения чего-нибудь (на этап 1.);
    5. юзер, увидев после этапа 4. срок исполнения, либо молчаливо соглашается с ним, либо обвиняет по телефону начальника отдела разработки в саботаже, подрыве работоспособности банка и т.п.;
    6. в случае, если юзер смог своими воплями убедить начальника отдела разработки в исключительной важности своей заявки, начальник может проставить заявке некий высокий приоритет (или сдвинуть срок начала работы и\или срок выполнения). О чём опять же должен узнать программист;
    7. После выполнения заявки программист устанавливает дату выполнения в заявке и отправляет её для визирования юзеру;
    8. после получения визы юзера заявка считается исполненной.
    Основные задачи этой гипотетической системы :
    - избавиться от словесных объяснений юзерам типа "а мы Вашу заявку уже год держим, потому что работы много" - надо показать агрессивному юзеру красивую картинку текущей загруженности программиста(ов), чтобы юзер осознал собственную ничтожность;
    - получить реальную онлайновую картину работы отдела разработки для показа высоким начальникам.
    Причем хочется максимально воспользоваться возможности каких-либо готовых систем, дабы не изобретать велосипед. Пока есть смутная идея реализовать всё вышеописанное в Лотусе со связкой через ODBC с MSP... Если у кого - нибудь есть идеи по этому поводу (не только выбора инструментов, но и по процессу хождения заявок), не сочтите за труд поделиться pls.
    WBR, Александр Турчин

  • #2
    2 Александр_Турчин
    Буквально с начала нового года запустил такую систему у себя. Вернее заменил старую на новую. В основе новой лежит Rational ClearQuest.
    Вначале написали модель хождения заявки по подразделениям компании, затем реализовали. Вроде все довольны, но есть еще пути совершенствования.
    Теперь думаем к нему (ClearQuest) прицепить систему контроля изменений ПО (ClearCase).

    Если есть вопросы о подробностях, то плиз на b-mail.
    Добро всегда побеждает зло. Потому что кто победил - тот и добро.

    Комментарий


    • #3
      Александр_Турчин
      По опыту работы аналогичной системы на нашей фирме есть еще два момента, которые Вами не учтены
      Во-первых трудоемкость должен определять не конечный программист-имполнитель, а его начальник, поскольку на это завязаны как оплата труда программиста, так и контроль за самим программистом
      Во-вторых в вашей модели нет такого важного этапа как тестирование и передача готовой программы юзеру, а это тоже важно

      Александр Тырков

      Комментарий


      • #4
        TeamTrack от TeamShare, Inc. рекомендую посмотреть.

        Комментарий


        • #5
          А мы как раз начали именно с ClearCase (было очень критично) ну и сейчас ходят разговоры о ClearQuest

          Комментарий


          • #6
            Александр_Турчин
            А что Вас смущает в организации системы в Lotus? Помоему чистой воды документоборот, и ежли у Вас повсеместно стоят лотусовые клиент, ну а тем паче используете web то 2 недели работы
            С уважением

            SunDog

            Комментарий


            • #7
              2SunDog : А что Вас смущает в организации системы в Lotus?

              Хм. А Вы попробуйте на LotusScripte или тамошней жабе написАть отчет, выдающий результаты в виде a-la Ms Project. Опять же в стандартных Лотусовых интерфейсах такие вещи, как объединение задач в цепочку или разрыв выполнения не особо-то реализуешь .
              WBR, Александр Турчин

              Комментарий


              • #8
                Александр,

                1. Такой документооборот - workflow работает и прекрасно реализуется на ЛотусНотусе в виде базы.
                2. Такой workflow - в виде сообщений реализуется на МS Exсhange.

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

                Мой опыт показывает, что юзеры и ТОП менеджеры с трудом понимают диаграммы Ганта, особенно, когда надо вчера и жаждут личного общения с менеджером, который изменит приоритеты, доказав свою необходимость на рабочем месте. Первичную оценку трудозатрат и загруженности вполне можно доставить программистам, при наличии у них понимания и правильной мотивации.

                Вы можете выделить одного человека, который будет контролировать и отслеживать данный тип изменений/запросов на правомочность. Дать юзерам прямой доступ к Вашему ресурсу - погубить Вашу власть и работоспособность ресурса - Вам нужен какой-то баланс - или стоимость работ или еще какое-то разделение по направлениям. Я знаю, что софт не главное при таких проблемах, хотя с ним легче.

                Комментарий


                • #9
                  Александр_Турчин
                  А может просто отказаться от прожекта? Полность перенести данный процес в лотус, и работать там... а если нужны графики загруженность так это сколько угодно или через LSX или еще банальнее вот так..
                  |||||||||||
                  |||

                  |||||||||||||||||

                  А вот со сложностью реализации последовательного выполения не соглашусь, чисто лотусовая задача, с разрыом выполнения наверное немного сложнее будет.. хотя если подумать
                  С уважением

                  SunDog

                  Комментарий


                  • #10
                    Александр_Турчин
                    у нас в конторе подобная система внедрена (самопальная), могу поделиться своими наблюдениями
                    Наблюдение 1.
                    1. конечные пользователи сами заносят в некую систему свои заявки;

                    то, что пользователи заносят как заявки - это ужас чистой воды. Самый оптимальный вариант - это когда пользователь доверяет программисту и объяснив ему свои беды по телефону или в личной встрече пишет те слова, которые ему сказал программист. Иначе согласовывать текст заявки можно будет до посинения. Или программист молча принимает заявку as is и делает то, что он считает нужным. Как правило, пользователь остается доволен.

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

                    у нас к заявке привязывается задача, которая и маршрутизируется программисту. Или несколько задач. Или задача из одной заявки связывается с несколькими заявками.

                    8. после получения визы юзера заявка считается исполненной.

                    согласна с ANT7 ,
                    Во-вторых в вашей модели нет такого важного этапа как тестирование и передача готовой программы юзеру, а это тоже важно

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

                    Еще немаловажным мне кажется для каждой заявки иметь признак - к какому ПО она относится.
                    И не хватает статуса - отправлено на доработку разработчику ПО.

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

                    Вообще, хранить историю заявок бывает полезно в том числе, например, чтобы увидеть, как меняются требования к системе при смене пользователей.

                    Комментарий


                    • #11
                      Julls : могу поделиться своими наблюдениями

                      Thanxx, мысли имхо хорошие.

                      Когда ИТ начинает работать по заявкам, то окончательно становаится подразделением автоматизаторов, а не информационных технологий.

                      А как же тогда быть ? Пользователи ведь всё время чего-то хотят... У нас в месяц проходит более 100 исполненных заявок (+ естественно перспективные разработки). Как же без заявок быть - посылать пользователей куда подальше или как ?
                      WBR, Александр Турчин

                      Комментарий


                      • #12
                        Александр_Турчин
                        Однозначно требовать заявку, иначе рано или плздно кто--нибудь из пользователей скажет, что вы сделали то что ему вовсе не нужно, а нужно ему восе другое и он об это м Вам и говорил.
                        Кстати все ли получненые зааявки вами исполняются или бывают отказы?
                        С уважением

                        SunDog

                        Комментарий


                        • #13
                          Александр_Турчин

                          Как же без заявок быть - посылать пользователей куда подальше или как ?

                          без заявок, кончено, нельзя. Но и не заявками едиными сыт пользователь.

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

                          Комментарий


                          • #14
                            2SunDog : Кстати все ли получненые зааявки вами исполняются или бывают отказы?

                            Конечно, бывают отказы. В основном безумные идеи пользователей отсеиваются в ходе предварительных телефонных разговоров путём "мягкого убеждения", но бывает и официоз с отказами по заявкам.
                            WBR, Александр Турчин

                            Комментарий


                            • #15
                              >>>У нас в месяц проходит более 100 исполненных заявок
                              Тут МS Project даже вреден.
                              А почему бы Вам не внедрить бизнес процесс ITIL change managent и workflow решение на Лотусе или через Веб.

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

                              А у Вас вообще хелпдеск то есть ?

                              Комментарий

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

                              Свернуть

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

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