Bankir.Ru
4 декабря, воскресенье 23:27

Объявление

Свернуть

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

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

Обучение пользователей

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

  • Обучение пользователей

    Вот такой вопрос.

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

    И еще – если сотрудник плохо знает программы типа MS Office, то каким образом решается эта проблема, кто учит и кто отвечает на вопросы, связанные с этими программами?

    Заранее благодарна за помощь.

  • #2
    Avory Что значит - разработка идёт постоянно? А то что разрабатывается - не внедряется? Разработка идёт в отрыве от пользователей? То есть они знают о том, какой софт разрабатывается и зачем?
    Соответственно вот тогда и происходит обучение - во время разработки (при косультациях с пользователями) и во время внедрения - когда разработчики и пользователями ночуют вместе за одним компом. 8-)
    Бывают, конечно, пользователи, которым хоть в лоб - хоть по лбу - подавай одну кнопку - и так что бы всё делала... Но автоматизаторы-то тут причём? 8-)

    Комментарий


    • #3
      Avory А по поводу MS Office - может и не брать таких - кому по работе он нужен - а они им пользоваться не умеют?

      Комментарий


      • #4
        вопрос в другом.
        Разработка идет вместе с толковыми пользователями, например на Центральном отделении. На них все и обкатывается. И проблем никаких нет. А дальше продукт уходит в филиалы и отделения, которые участия ни в чем не принимали, соответственно ничего не знают. Как правильно организовать процесс ИХ обучения, чья это забота и как можно избежать многих проблем?

        Комментарий


        • #5
          2 Avory:
          А дальше продукт уходит в филиалы и отделения, которые участия ни в чем не принимали, соответственно ничего не знают. Как правильно организовать процесс ИХ обучения, чья это забота и как можно избежать многих проблем?
          Все довольно просто. Любое нововведение должно документироваться. Далее документ со списком изменений высылаете в филиалы и отделения. Если кто-то считает чтение оного документа делом не нужным, то это его проблемы. При возникновении вопросов Вы всегда сможете отослать такого "умника" к документу за 1-2 минуты.
          Если изменения глобального свойства, то можно провести "семинар" собрав наиболее продвинутых пользователей отделений и филиалов, а обучение остальных на местах перепоручить им.
          Простенько и со вкусом.
          А по поводу MS Office - может и не брать таких - кому по работе он нужен - а они им пользоваться не умеют?
          Вот именно, если человек даже "офисом" пользоваться не умеет, то либо он прекрасно все делает без "офиса", либо .... В первом случае знания и не очень нужны, а вот во втором... В общем, решайте сами.

          Комментарий


          • #6
            Cost А вы представляете себе трудозатраты например на написание документации по модулю "Кредиты"?! Она сравнима с трудозатартами на разработку самого модуля!!! Ведь кроме руководства пользователя надо описать технологию - потому как пользователь будет задавать вопросы - а зачем эта кнопочка - а зачем - та? И ещё нужна документация на сопровождение - типовые проблемы и способы их устранения.
            Но основная проблема в том, что у пользователей аппетит приходит во время еды - и доработки совершают каждую неделю - а то и чаще. И документацию приходиться поддерживать в актуальном состоянии - что довольно затратно.[/B]

            Комментарий


            • #7
              Cost А вы как-то проверяете на знание MS Office-а?

              Комментарий


              • #8
                2 PVE:
                А вы представляете себе трудозатраты например на написание документации по модулю "Кредиты"?! Она сравнима с трудозатартами на разработку самого модуля!!!
                Ваши бы слова, да всем клиентам в уши!!!
                Об этом, в принципе, надо думать до принятия решения о собственной разработке. А также о поддержке пользователей, механизме обновлении версий и т.д. Естественно, что это все затратно, но без этого никуда. Вот мы и пришли к выводу, что неудобно банку заниматься собственными разработками.
                А вы как-то проверяете на знание MS Office-а?
                Довольно просто. Во время испытательного срока обычно.

                Комментарий


                • #9
                  Cost Дело в том, что у Avory-ы насколько я понял, проблема с обучением не столько собственно новому (или доработанному) софту, а новым технологиям - потому как под внедрением ПО обычно подразумевается и внедрение некой новой (изменённой) технологии.

                  То есть дело-то ВСЁ-таки не в том - собственная разработка - или нет! Вопрос обучения стоит в любом случае.

                  Комментарий


                  • #10
                    2 PVE:
                    ...проблема с обучением не столько собственно новому (или доработанному) софту, а новым технологиям...
                    Так если есть документация (ну или, соответственно нет оной), то не все ли равно софту или технологиям учить?
                    Вопрос обучения стоит в любом случае.
                    Естественно. Но при "промышленной" АБС обучение можно поручить и разработчику. А при "собственной" - своими силами. И тогда - документация. семинары, делегирование функций... (см. выше)

                    Комментарий


                    • #11
                      Cost Поручить стороннему разрботчику - дорого! Да и медленный этот процесс - сторонняя разработка. И слабо корректируемый. Приводит к довольно странным результатам! Да и дорог. За обучение - тоже надо платить.

                      Комментарий


                      • #12
                        2 PVE:
                        Вот ведь жизнь, опять скатились к обсуждению противостояния собственных и промышленных разработок.

                        Странно, кажется мне, что Вы сами себе противоречите:
                        Поручить стороннему разрботчику - дорого!
                        и
                        А вы представляете себе трудозатраты например на написание документации по модулю "Кредиты"?! Она сравнима с трудозатартами на разработку самого модуля!!!

                        То есть не учить и не документировать - дешево, но нельзя. А учить и документировать - дорого, но нужно. Истина где-то рядом... (с)Фокс Малдер

                        Комментарий


                        • #13
                          Cost А чём противоречие-то?!?! И сторонней разработки и документации нет из-за одних и тех же причин - дороговизны и отставания от жизни!

                          В чём противоречие-то?

                          Комментарий


                          • #14
                            2 PVE:
                            И сторонней разработки и документации нет из-за одних и тех же причин - дороговизны и отставания от жизни!
                            А, ну да... То есть прибыли нет из-за того, что программы устарели и трудоемкость операций высокая, а программы обновить не на что - прибыли нет. Примерно так?

                            Комментарий


                            • #15
                              2 Avory
                              По своему IT-опыту могу сказать, что при внесении серьезных доработок (существенное изменение технологии, внедрение нового модуля), как правило, разработчики/внедренцы устраивали предварительную презентацию для руководства заинтересованных подразделений. С одной стороны такая презентация несла целью ознакомление с грядущими изменениями тех, кто по тем или иным причинам не участвовал в разработке ТЗ, с другой - получение принципиального согласия на ввод в эксплуатацию или возврат на дальнейшую доводку.
                              Затем (непосредственно перед вводом в эксплуатацию) проходило обучение конечных пользователей. Здесь проблема в том, что при наличии множества филиалов данный процесс - дело довольно затратное. Массовое отвлечение сотрудников от текущей работы также вызывает проблемы. Т.е. еще раз оговорюсь - речь идет о серьезных доработках.
                              Для текущих изменений в ПО разработайте порядок ввода в эксплуатацию, предполагающий хотя бы минимальное документирование изменений и доведение данной документации до конечных пользователей. Плюс должен быть организован support пользователей - например в виде отдела сопровождения, который в курсе разработок и готов в любой момент проконсультировать пользователя относительно последних изменений. Масштабы поддержки пользователей и степень детализации документации - в зависимости от конкретной ситуации.

                              Комментарий


                              • #16
                                Misanthrope
                                Не могу не согласиться и не поддержать!

                                Комментарий


                                • #17
                                  Misanthrope Очень похоже на общие фразы, по-моему! Основная проблема в том, что требования к системе могут изменяться и уточняться очень часто - практически каждую неделю или каждый месяц. И это не блаж или недосмотр автоматизаторов или аналитиков, пользователей или руководства - а просто потребности рынка в лице клиентов. Пророков нет - и поэтому надо следовать генеральной линии довольно гибко.
                                  И что в таких условиях предлагается каждую неделю устраивать обучение?! Особенно для филиалов - да?! 8-)

                                  Комментарий


                                  • #18
                                    PVE
                                    Misanthrope же ясно сказал : "Для текущих изменений в ПО разработайте порядок ввода в эксплуатацию, предполагающий хотя бы минимальное документирование изменений и доведение данной документации до конечных пользователей". Кто мешает внедрить, например, такой порядок. Разработчик ПО перед внедрением новой версии готовит коротенький документ с описанием внесенных изменений и их глубокого смысла. Этот документ вывешивается где-нибудь (на файл -сервере или Интравеб, например) одновременно с внедрением или чуть раньше. Или по почте рассылается в филиалы. Пользователи, удивившиеся чему-то новому, лезут и смотрят что там такого нового сгородили. И самообучаются таким образом. А для особо непонятливых остается помощь службы сопровождения.

                                    Комментарий


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

                                      Комментарий


                                      • #20
                                        PVE
                                        Согласитесь, что разработчик сам от большого ума обычно ничего не меняет в своем ПО. Хотя бы потому, что времени нет отвлекаться на ерунду всякую без указания Начальства. Подготовленный программистом текст, конечно же , должен проверять и согласовывать спец службы сопровождения, которому потом придется с пользователями по этому тексту разбираться. Внедрять ПО , как бы срочно это не было, без документации вообще нельзя. Потом концов найти не удастся, если разработчик, например, уволится или еще что пожарообразное произойдет. Неужели разработчики не понимают, что ПО должно сопровождаться документацией, хоть в минимальноим объеме? А что, у вас часто за полчаса до рейса внедряют новое ПО? Это говорит об очень хорошей организации работ

                                        Комментарий


                                        • #21
                                          Siva Я же говорю - разработчики у нас документацию пишут - толку-то от неё нет. Пользователей не заставишь её читать. Только если по диагонали. Такая документация помогает только "концы найти" в случае чего. Но вопрос-то не об этом!
                                          За полчаса до рейса ничего нового внедрять никто не будет, конечно же внедряют вечером предыдущего дня - это пользователи спохватываются за полчаса до рейса - немотря на напоминания и документацию.

                                          Комментарий


                                          • #22
                                            2 PVE:
                                            А что, у вас часто за полчаса до рейса внедряют новое ПО?
                                            Это говорит об очень хорошей организации работ


                                            ...пользователи спохватываются за полчаса до рейса...
                                            Это говорит об очень хорошем уровне пользователей.

                                            Комментарий


                                            • #23
                                              PVE
                                              Ну это уж чисто организационный вопрос. Просите Руководство издать приказ по Банку типа :"Приказываю читать всю поступающую почту, а не по диагонали. Причем сразу, а не когда жареный петух .... , и внимательно. "
                                              А вообще таким безответственным пользователям можно инкриминировать не должное отношение к работе. Т.е. намекнуть на несоответствие...

                                              Комментарий


                                              • #24
                                                SivaПользователей не выбирают! 8-)

                                                Комментарий


                                                • #25
                                                  Siva Так в этом и был основной вопрос - как организовать пользователей!

                                                  Комментарий


                                                  • #26
                                                    PVE
                                                    Еще как выбирают! Пару раз рублем кого-нть наказать из них, все начнут читать все что положено. Если это еще ни разу не аукалось в финансовом плане Банку и Руководство пока "пользователей не выбирает", то можете пока оставить все как есть. А как аукнется, так смело и говорите, что все материалы были подготовлены и доведены до пользователей. С них и спрос за финансовые потери.

                                                    Комментарий


                                                    • #27
                                                      Siva Слабое место - качество доведенных материалов и ещё в том, что пользователи затрудняются зачастую адекватно оценить обстановку и принять корректное решение самостоятельно.

                                                      Комментарий


                                                      • #28
                                                        2 PVE:
                                                        Ничего не понимаю.
                                                        Я же говорю - разработчики у нас документацию пишут - толку-то от неё нет. Пользователей не заставишь её читать.
                                                        И
                                                        Слабое место - качество доведенных материалов...
                                                        Вы же сами себе и отвечаете. Если качество - слабое место, то и читать смысла нет, тут не поспоришь. Доведите качество до нормального уровня и пользователи наверняка будут читать.
                                                        А вот как повысить качество материалов, думаю, и сами хорошо знаете. Бесплатно - естественно никак.

                                                        Комментарий


                                                        • #29
                                                          PVE Качество документа служба сопровождения должна проверять и настаивать на доработке в случае необходимости. Причем вплоть до не внедрения ПО до тех пор, пока не доработают документ. Это, кстати, тоже было бы полезно каким-нть приказом или еще как-то официально утвердить. Чтоб разработчики посерьезнее к этому относились.
                                                          А насчет корректного решения , конечно, иногда придется помогать. Для этого служба сопровождения и нужна. Но если изменения небольшие (большие за неделю не сделаешь), чего там может такого сложного у пользователя возникнуть? Не совсем же они туперы?

                                                          Комментарий


                                                          • #30
                                                            Cost Я имел в виду качетство по отношению к уровню пользователей. Толковые пользователи - понимают, но их немного. А вот так что бы всем 100% разжевать - вот с этим и беда.

                                                            Комментарий

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

                                                            Свернуть

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

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