«Классика» vs Agile — Pro и Contra

205

Практически каждый из ведущих производителей информационных систем имеет свою методологию внедрения. Oracle AIM, ASAP, Microsoft Dynamics Sure Step, 1С — наиболее известные у нас. В методологии вендор прописывает набор документов, этапы проекта, роли участников проектной команды.

Далее, многие компании-внедренцы берут эти методологии, и многие адаптируют «под себя», под конкретную структуру компании и конфигурацию персонала.

Но, если внимательно посмотреть, то во всех этих методологиях — как «оригинальных» от вендора, так и «адаптированных» от внедренца — есть примерно один и тот же набор последовательных этапов и документов, которые должны быть сделаны. Называться они, конечно, могут по-разному, но основной «костяк» примерно следующий: обследование, функциональные и технические требования, проектирование, спецификация на доработки/ настройки, пользовательская документация.

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

Другой подход — максимально запараллеливать процессы внедрения, отказываться от «тонн документации», максимально рано показывать заказчику прототип системы и «итеративно» работать с ним. Плюсы и минусы данного подхода также понятны — с одной стороны, скорость, другой — такой подход требует намного более проактивного и рискованного стиля управления, намного более строгого контроля объема и бюджета проекта.

Как вы считаете — в каких случаях какой подход наиболее применим? Какие проблемы есть на том или ином пути и как их преодолевать?

12687
Коментарии: 205

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Сергей Цветаев
    Рейтинг: 10
    1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    27.03.2013 12:42

    Прототипное внедрение очень нравиться, помогает заказчику понять что он хочет при заказной разработке.

    • Михаил Петров Сергей
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      27.03.2013 18:30

      А как его "удержать" в рамках скоупа, сроков, бюджета проекта при этом? как не "свалиться" в неконтролируемое "улучшательство" и не потерять фокус? Есть Ваш рецепт? :)

      • Сергей Цветаев Михаил
        Рейтинг: 10
        1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
        Руководитель проектов
        27.03.2013 18:34

        Я знаю только один рецепт, руководителю проекта нужно уходить, сразу как только он это почувствовал, а если он не чувствует таких вещей ему не нужно начинать так работать.

        • Михаил Петров Сергей
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          27.03.2013 18:46

          руководителю проекта нужно уходить - может, уж не так радиально? :) может - просто поменять подход? а насчет если он не чувствует таких вещей ему не нужно начинать так работать - вот с этим полностью согласен

  • Леонид Хлопин
    Рейтинг: 10
    Ульяновский государственный педагогический университет
    Заместитель начальника отдела ИТ
    27.03.2013 13:34

    Приветствую, Михаил! Про "другой подход". Не буду рассказывать предысторию, были и "тонны бумаги", и разборки с подрядными организациями по качеству и срокам работ, и т.п. Вооружившись "оправдательной" фразой, что стандарты проектного управления это не догма а рекомендации (прошу не путать с ГОСТами, многие имеют законодательную силу), выстроил в холдинге следующую схему проектного управления, действующую последние 2-3 года (не знаю сохраняется ли она сейчас, после моего ухода). 1. Анализ ситуации и разработка схемы (регламента) бизнес-процессов (БП). Чтобы не тратить время на анализ и описание ситуации "как есть" и "как должно быть", я ввел в работу на первом этапе специалистов по БП, которые анализировали ситуацию и на основании желаемых целевых заданий проектировали схему БП "как будет". Выходными документами в этом случае являлись: схема БП; регламенты; макеты инструкций на рабочих местах. Это в общем-то и требовалось заказчику, в том числе и внутрихолдинговому. Утверждение документов (условно в версии 1.0). 2. На основании п.1., формировались задания на разработку, доработку, настройку информационных систем. Не одно большое ТЗ, а "локальные" задания по мере продвижения работ по п.1. В нашем случае информационные системы «1С: 8 УПП» и другие на платформе «1С: Предприятие 8». Программистами выполнялись необходимые работы. Окончательно дорабатывались рабочие инструкции и регламенты (версии 1.1. и т.д.). 3. Непосредственно внедрение, т.е. - установка системы (модулей системы), обучение персонала, тестирование работы персонала и информационной системы. В случае обнаружение ошибок или выявленной необходимости корректировок БП и регламентов, переходили снова к п.1. (но только по выявленным ошибкам, замечаниям и предложениям). 4. Опытно-промышленная эксплуатация: тестирование БП, информационной системы, персонала. В случае необходимости корректировок БП и информационной системы - переход к п.1. (но только по выявленным ошибкам и замечаниям). В случае необходимости корректировок персонала - переход на "параллельную ветку" бизнес-процессов предприятия. В общем данная схема минимизировала непродуктивный документооборот (и потери времени на его изучение) и сократило сроки получения заказчиком первого результата. Сделала прозрачным для заказчика процесс работы по проектам. Для этой схемы, конечно, требуется определенный уровень зрелости департамента ИТ (руководителя, руководителей подразделений и ведущих специалистов по направлениям) и наличие в его структуре специалистов по БП. Это может быть и подразделение по организационному развитию внутри предприятия. К сожалению, как правило, почему-то функции организационного развития приписывают к дирекции по персоналу, В реальности функции организационного развития к функциям дирекции по персоналу имеют опосредованное отношение, т.е. дирекция по персоналу осуществляет исполнение заказа на подбор и подготовку персонала для проектируемых организационных структур. P.S. Кстати по дирекциям по персоналу и кадровым агентствам. Не знаю, какие надо писать в резюме знакомые им слова, чтобы привлечь их внимание и привести их в бурный восторг (вернее знаю, но обманывать не хочу: возраст 30 лет; опыт работы 100 лет в компаниях федерального уровня в Москве, Санкт-Петербурге; наличие 3-х высших образований - информационные системы и технологии, менеджмент, экономика и финансы; и т.п.). ;-) Просто обидно в 47 лет, оказаться никому не нужным по своей специализации в ИТ, имея серьезный опыт, хорошую теоретическую подготовку и умение делать правильные вещи правильно. Но, к сожалению, это жизнь, поэтому приходится менять род занятий на "старости лет". ;-)

    • Михаил Петров Леонид
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      27.03.2013 18:38

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

      • Леонид Хлопин Михаил
        Рейтинг: 10
        Ульяновский государственный педагогический университет
        Заместитель начальника отдела ИТ
        28.03.2013 02:54

        Да, у меня были 2 (две) штатные единицы специалистов по бизнес процессам. Должность называлась "Ведущий специалист по моделированию бизнес-процессов" (не совсем удачно, хотел поменять название). Это не было основанием для работы по сокращенному циклу. Вернее сказать - это давало возможность работать по сокращенному циклу. Проектирование шло под семейство продуктов на платформе "1С: Предприятие 8". В принципе, все ERP системы строятся по единой методологии, различие в основном только в программных реализациях, интерфейсах и функциональных возможностях. Конкретная реализация конечно накладывает определенные ограничения, их соответственно приходится учитывать при проектировании бизнес-процессов. На первом этапе режим работы скорее напоминал "мозговой штурм". Организовывалась проектная группа из представителей заказчика и специалистов департамента ИТиРБП. Я в том числе играл активную роль, выступая в большей степени как специалист по бизнес-процессам и "модератор" этой группы. Бывало, что активно участвовали и директора предприятий. Но ведущая роль была за департаментом ИТ и РБП (мы себе ненавязчиво "присвоили" часть функций дирекции по организационному развитию ;-) ). Определялись общий скелет проектируемых (модернизируемых) бизнес процессов и общие требования, после чего в рабочем порядке специалисты по БП совместно с ключевыми специалистами заказчика проводили окончательную доводку проектируемых бизнес-процессов. На этом этапе подключались и специалисты по 1С. Т.к. творчество было совместным с внутренним заказчиком, то вопрос ответственности как-то уходил на второй план, т.к. данная схема процесса выработки решения не допускает отрицательного результата (во всяком случае вероятность его очень низкая). Но, еще раз подчеркиваю, данная схема была ориентирована на использовании внутренних ресурсов проектных подразделений холдинга. В этом случае "большой заказчик" один - собственники холдинга.

        • Михаил Петров Леонид
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          28.03.2013 10:21

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

          • Леонид Хлопин Михаил
            Рейтинг: 10
            Ульяновский государственный педагогический университет
            Заместитель начальника отдела ИТ
            28.03.2013 12:07

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

            • Михаил Петров Леонид
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              28.03.2013 16:51

              Т.е., резюмируя - при поддержке топов, при создании эффективной рабоче группы, которая сама определяет тот набор документов который необходим - можно делать agile-внедрение, так примерно?

              • Леонид Хлопин Михаил
                Рейтинг: 10
                Ульяновский государственный педагогический университет
                Заместитель начальника отдела ИТ
                28.03.2013 23:21

                В общем - да.

    • Леонид
      27.03.2013 21:49

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

      • Михаил Петров
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        28.03.2013 17:05

        Валерий, а про технологии - какие мысли?

        • Михаил
          28.03.2013 21:22

          Моя реплика больше относится к мысли Леонида о невостребованности квалифицированных руководителей проектов. Заказчик действительно как-то помельчал в части управленческих запросов. После 2008 года не вижу достойных проектов. А на счет технологий убеждаюсь, что технологии внедрения одинаковы и для крупных и не очень предприятий. Для меня размер предприятия, принятое программное обеспечение, отрасль не играют определяющего значения. Оцениваю клиента исключительно по квалификации и вменяемости его персонала. 9()% всех проблем - это проблемы с персоналом. Применяются различные методы: убеждение, демонстрация, принуждение, пользовательские инструкции и т.д. Самое эффективное при этом, привлекать на самых ранних стадиях персонал, который будет работать в системе на конкретных рабочих местах. К сожалению заказчики не понимают важности финансирование в квалификацию своих работников. В результате бывает, задача решена, модуль работает, но после подписания акта - штопор, персонал недоучен, некорректный ввод информации. Я уделяю большое внимание беседам с конечными пользователями. Сколь угодно случаев, когда все красиво прописано, бизнес-процессы регламентированы, но регламенты ни фига не работают. На счет документации, у меня не было случая, чтобы заказчик на 100% профинансировал ее разработку. Поэтому приходится искать оптимальные варианты. Заказчикам могу посоветовать, никогда не экономить на разработке подробных пользовательских инструкций. В процессе эксплуатации снимают многие проблемы.

          • Михаил Петров
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            29.03.2013 11:22

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

            • Михаил
              29.03.2013 12:07

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

    • Михаил Петров Леонид
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      31.03.2013 14:34

      Про нужные слова кстати. Для разрядки. Если бы водителей принимали на работу так же, как ИТшников, то выглядело это примерно так. Вакансия: водитель. Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности. Зарплата: 1500-2500 рублей, определяется по результатам собеседования.

      • Леонид Хлопин Михаил
        Рейтинг: 10
        Ульяновский государственный педагогический университет
        Заместитель начальника отдела ИТ
        31.03.2013 14:36

        !!! ;-)))

      • Михаил
        31.03.2013 21:42

        Михаил, класс! Можно возьму как цитату?

        • Михаил Петров
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          31.03.2013 22:42

          Не я автор (и соответственно правообладатель) - анекдот из народа. Все могут пользоваться :)

  • Сергей Цветаев
    Рейтинг: 10
    1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    27.03.2013 13:36

    На сколько ваш подход схож с Scrum реализациями проекта, а может в чем различен ? Еще вопрос Вам не кажется что скорость технологического развития особенно в ИТ ставит процесс "полноценного" документирование в пережиток прошлого.

    • Леонид Хлопин Сергей
      Рейтинг: 10
      Ульяновский государственный педагогический университет
      Заместитель начальника отдела ИТ
      27.03.2013 14:02

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

      • Михаил Петров Леонид
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        27.03.2013 18:53

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

        • Леонид Хлопин Михаил
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          28.03.2013 03:02

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

          • Михаил Петров Леонид
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            28.03.2013 10:17

            конкретный перечень определялся для каждого проекта - вот как раз интересно, как, в зависимости от чего менялся этот перечень?

            • Леонид Хлопин Михаил
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              28.03.2013 12:16

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

            • Леонид Хлопин Михаил
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              28.03.2013 12:24

              Я оказывается строил проектную работу по Agile методологии! Даже и не знал об этом, вот ведь однако ;-)))

              • Михаил Петров Леонид
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                28.03.2013 16:53

                главное - грамотно отбрэндировать :)

    • Леонид Хлопин Сергей
      Рейтинг: 10
      Ульяновский государственный педагогический университет
      Заместитель начальника отдела ИТ
      28.03.2013 12:44

      Мой подход, как оказалось, все-таки практически ложится на Agile методологию. Насколько я понял: - Scrum жестко относится к процессу планирования и выполнения работ и оперирует более короткими временными интервалами; - Scrum ориентирован именно для "бригады" разработчиков конкретного ПО или какого-либо одного продукта. Возможно ошибаюсь. Пока продолжаю изучение методологии Scrum.

      • Александр Дурманов Леонид
        Рейтинг: 10
        42
        CEO
        28.03.2013 15:13

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

        • Михаил Петров Александр
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          28.03.2013 16:56

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

          • Александр Дурманов Михаил
            Рейтинг: 10
            42
            CEO
            28.03.2013 17:13

            Да. Хочется конечно сказать что это "индивидуально для каждого проекта" и "руководитель должен найти грань" но сдается мне, что это не совсем так. Я считаю целесообразным иметь хотя бы порядок спринтов, (без четких сроков) и формализовывать требования перед каждым спринтом (никаких user story). После спринта - пересмотр порядка спринтов (мало ли, обстановка изменилась). Примерно так у нас строится разработка ПО, получается пока неплохо.

            • Михаил Петров Александр
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              28.03.2013 17:24

              А разработчики свои?

              • Александр Дурманов Михаил
                Рейтинг: 10
                42
                CEO
                28.03.2013 17:31

                Да, разработчики свои, но с аутсорсом тоже никаких проблем нет, как раз из-за наличия спецификации к спринту. Сейчас будем пробовать проецировать этот подход на внедрение и поддержку ИС.

                • Михаил Петров Александр
                  Рейтинг: 809
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  28.03.2013 19:40

                  именно "аутсорс" - т.е. покупаете "голову", а дальше используете как просто обычного своего работника? проецировать этот подход на внедрение и поддержку ИС - вот это и интресно, поделитесь опытом?

        • Леонид Хлопин Александр
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          28.03.2013 23:17

          Scrum предназначен для внутреннего оперативного управления "бригады" разработчиков программного обеспечения и подобных продуктов. Здесь ключевые слова: "бригада" - небольшая группа программистов-разработчиков; "оперативное управление" - работа над небольшими задачами с горизонтом планирования 2-4 недели. И данная методология не предназначена и неприменима для проектов внедрения и крупных проектов разработки каких либо продуктов.

          • Александр Дурманов Леонид
            Рейтинг: 10
            42
            CEO
            29.03.2013 10:21

            Ну почему, есть вполне себе большие ребята, типа LinguaLeo, которые разработываются целиком по этой методологии. Ну и обсуждение ведется не про Scrum конкретно, а скорее о самих agile принципах.

            • Леонид Хлопин Александр
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              29.03.2013 11:12

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

            • Михаил Петров Александр
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              29.03.2013 11:29

              Да, согласен

      • Михаил Петров Леонид
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        28.03.2013 16:54

        У меня то же понимание. Особенно в части - что это инструмент именно для команд разработчиков. Во внедрении же корпоративных систем есть масса задач и помимо разработки...

  • 27.03.2013 18:25

    Оба подхода имеют право на существование. Выбор, пожалуй, зависит от того, какого рода система внедряется: ERP или интернет-магазин, например. А также от степени зрелости компании в целом и отдлеьных подразделений. Документирование должно быть обязательно. Фиксация принятых решений на бумаге перед непосредственной реализации способствует принятию более взвешенных решений. Правда, иногда в бумагах бывает много воды. Вот от нее нужно избавляться.

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      27.03.2013 18:32

      какого рода система внедряется: ERP или интернет-магазин - а в чем разница в подходах? Документирование должно быть обязательно - конечно. Вопрос - в каких случаях в каких объемах?

  • 28.03.2013 08:04

    Все зависит от типа систем и масштабов внедрения. Если это внедрение ERP-систем, не важно на какой платформе 1С, SAP или Oracle, где задачи достаточно легко алгоритмизируются, то предпочтительнее первый подход. При заказных разработках систем АСУТП или учетных систем близких к АСУТП, лучше применять прототипное внедрение, поскольку на начальном этапе заказчик не может адекватно оценить какая информация ему может потребоваться в дальнейшем.

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      28.03.2013 10:16

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

  • 28.03.2013 09:54

    Зависит от сложности и размера проекта... Для вендора всегда удобнее Agile методологии но когда риски зашкаливают, MSF всеж таки предпочтительнее...

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      28.03.2013 10:14

      Для вендора всегда удобнее Agile - почему? это же более рискованно...

    • Александр Дурманов
      Рейтинг: 10
      42
      CEO
      28.03.2013 11:01

      По моему опыту, при использовании Agile в больших проектах, все минусы agile выплывают во всей красе.

      • Михаил Петров Александр
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        28.03.2013 15:00

        Большой - это в каких параметрах?

        • Александр Дурманов Михаил
          Рейтинг: 10
          42
          CEO
          28.03.2013 15:08

          Нельзя, конечно, однозначно метрики определить. Сроки внедрения прототипа - от полугода, количество участников проекта (включая задействованых сотрудников заказчика) - от 15 человек. Как-то так для нас.

  • 28.03.2013 15:31

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

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      28.03.2013 17:03

      Да-да-да, вот и хочется примерно такую градацию с помощью присутствующего здесь профессионального сообщества нащупать :) Получается, наверное, не "плоскость" а многомерное пространство - выше, например, коллега Александр еще про масштаб проекта пишет, может - еще какие-то есть параметры?

    • Леонид Хлопин
      Рейтинг: 10
      Ульяновский государственный педагогический университет
      Заместитель начальника отдела ИТ
      29.03.2013 00:21

      Можно добавить определение специфики проекта: 1. Уникальный проект. Создание и внедрение уникальной информационной системы, включая разработку уникальных программных приложений в рамках проекта. Полная схема управления проектами. 2. Типовой проект (тиражируемое решение). Внедрение типовой информационной системы с адаптацией под конкретного заказчика в пределах программной платформы вендора. Возможно управление проектами по Agile методологии (при наличии квалифицированной проектной команды со стороны подрядчика и заказчика). 3. Типовой проект с необходимостью разработки отдельных уникальных модулей вне программной платформы вендора. Возможно управление основным проектом по Agile методологии (при наличии квалифицированной проектной команды со стороны подрядчика и заказчика), с выделением в отдельный подпроект разработку уникальных модулей с полной схемой управления подпроектом. Кстати, в строительстве, типовые здания и сооружения строят по близкой к Agile технологии управления проектами строительства.

      • Леонид
        29.03.2013 08:59

        "Кстати, в строительстве, типовые здания и сооружения строят по близкой к Agile технологии управления проектами строительства." Наверно мы по разному понимаем Agile технологии. Я не представляю как можно построить по Agile технологии дом. Часть дома построили, спросили заказчика оно или нет, и если первый этаж не тот, то переделали первый, а остальное оставили? Именно так я понимаю Agile, как технология которая позволяет менять направление движения по пути. Получаем удешевление на соглосовании проета, но повышается цена, за счет обеспечения гибкости системы. А что касается типовых зданий, то они сторятся быстро не из-за Agile технологии, а именно из-за того, что проект типовой, когда многие условия определены, вопросы уже решены заранее. И что самое главное, изменение условий просто не возможно иначе проект не типовой и сроки уже полетят, цена взлетит и строитель не влезет в целевые затраты.

        • Леонид Хлопин
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          29.03.2013 10:07

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

      • Михаил Петров Леонид
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        29.03.2013 11:38

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

        • Леонид Хлопин Михаил
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          29.03.2013 11:48

          Это от двух вариантов старых добрых терминов НИОКР и ОКР. ;-) Если уникальное решение, значит опыта еще нет и надо очень аккуратно выбирать решение, возможно закладывая дополнительные поисковые разработки или тестирование вариантов (эксперименты). Если типовое или тиражируемое, то значит уже известны результативные варианты решений и можно следовать им или брать их за основу, немного оптимизируя под конкретный случай.

          • Михаил Петров Леонид
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            29.03.2013 12:30

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

            • Леонид Хлопин Михаил
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              29.03.2013 22:03

              Согласен! Довольно часто приходилось так работать, увы. Если обозначить подобные ситуации работой в режиме "аврала", т.е. кризисной ситуаций, в которых, как обычно надо быстро принимать решения и осуществлять необходимые действия, то вполне можно и опустить необходимость разработки полной документации согласно инструкции действующей в "мирный" период, и МЧС нам в помощь! ;-) Но, действительно, во что бы то ни стало надо получить от заказчика ту единственную и самую главную бумажку, которая потом спасет нас в мирное время, даже если мы все сделали правильно и был достигнуть требуемый результат. "Все, что сделал предъявитель сего, сделано на благо государства и по моему приказу" (компании) ;-))) В оригинале ...

  • Леонид Хлопин
    Рейтинг: 10
    Ульяновский государственный педагогический университет
    Заместитель начальника отдела ИТ
    28.03.2013 23:47

    Я бы рекомендовал авторам сообщений внимательно читать тему и заданные рамки дискуссии и ограничиваться в своих сообщениях высказываниями в рамках заданной темы. Иначе получается, обсуждение обо всем и в итоге конкретно ни о чем. В данной дискуссии тема и границы заданы вполне конкретно: - Вопросы управления проектами внедрения корпоративных информационных систем управления предприятиями (ERP, CRM и т.д и т.п.) !!! Авторам следующих дискуссий я бы рекомендовал более четко устанавливать темы и границы рассмотрения вопросов. Ранее, в какой-то дискуссии, я уже писал об этом.

  • Максим Мотин
    Рейтинг: 20
    ПАО АВТОВАЗ
    Директор проекта трансформации бизнес-процессов для внедрения решений SAP
    29.03.2013 04:40

    В вопросе использования той или иной методологии внедрения и\или разработки есть ещё одна ось координат - количество ресурсов (материальных и\или людских), выделенных на проект. Если бюджет позволяет, либо есть внутренние выделенные штатные единицы типа "бизнес-аналитиков" - тогда есть резон использовать более "тяжелые" методологии - PMI, ASAP, AIM и проч., включая наши ГОСТы 34 серии. Если же в распоряжении команды проекта нет таких ресурсов - волей-неволей придется организовать работы по усеченным методологиям, отражая на бумаге только ключевые моменты процесса внедерения. На полноценные функциональные требования, ТЗ, ЧТЗ, процесс управления изменениями просто не будет времени.

    • Максим
      29.03.2013 08:47

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

      • Михаил Петров
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        29.03.2013 11:44

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

        • Михаил
          29.03.2013 12:44

          Конечно согласен с комментарием, что в любом проекте есть отношения, не зависимо от методологии :-) И про упор в Agile верно: Методология базируется на следующих принципах, зафиксированных в Agile Manifest: 1. Люди и их взаимодействие важнее, чем процессы и инструменты; 2. Работоспособное ПО важнее, чем обширная и детальная документация; 3. Сотрудничество с заказчиком важнее, чем переговоры по условиям контракта; 4. Реагировать на изменения важнее, чем следовать плану. К стати, к примеру Леонида, про Agile в строительстве. Думаю П-44Т - типовой проект, где планировку не поменять, она такая есть. А если мы еще не знаем, что хотим в плане планировки помещений, то строим монолит. Вот тут Agile, но здесь за гибкость приходится платить, т.к. монолит дороже :-) Так же и в ПО, если у нас монокод, написанный под одну задачу, то его сделать проще, о многом не надо думать (ни тебе параметров, ни подключаемых процедур, ни модулей и т.д.). НО внести изменения в такой код - лучше новый написать. За то, что появляется возможность гибко изменять продукт на выходе, по ходу его создания приходится платить более дорогой разроботкой. Другое дело, что удорожание разработки окупает дополнительную работу по сбору требований на систему. Развивая мысль, скадывается впечатление, что появление Agile - это не новое открытие, а использование возможности, возникшей из-за того, что расходы на доработку стали меньше, чем расходы на сбор и анализ данных для формулирования задачи. И не надо забывать, что в анализ входит прогноз развития событий на время проекта и время использования результатов проекта. А прогноз - не тривиальная и как следствие - не дешевая задача.

          • Михаил Петров
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            29.03.2013 22:37

            Проставил плюсики обоим Вашим постам - очень верно на мой взгляд

          • Леонид Хлопин
            Рейтинг: 10
            Ульяновский государственный педагогический университет
            Заместитель начальника отдела ИТ
            29.03.2013 23:17

            Если мы внедряем систему бухучета, то нам мало остается простора для творчества, т.к. вся "конструкция" достаточно жестко задается законодательством. Если мы внедряем ERP систему, то простора для творчества уже горазда больше, но оптимальные схемы основных бизнес-процессов в этом случае тоже достаточно отработаны, и специфичных для каждого конкретного предприятия не так много. Если мы внедряем MES систему, то простора для творчества примерно 60-90% в зависимости от уникальности технологий и производственного процесса, применяемых на предприятии. И снова о строительстве. ;-) В строительстве, для конкретного типа грунтов и планируемой нагрузки, как правило, выбираются наиболее подходящий из типовых вариантов фундамента. Для многоквартирных домов, выбираются типовые варианты планировки квартир ( в том числе и "нулевой" вариант) и т.д. Даже для индивидуальных домов (коттеджей) существуют типовые проекты, которые могут быть адаптированы под ваши пожелания. Но самое главное, прежде чем начинать строить, мы уже должны иметь решение по основной - несущей конструкции системы.

  • Александр Щетинин
    Рейтинг: 10
    ООО "Тюменьнефтегазпроект"
    Зам. исполнительного директора по ИТ
    29.03.2013 06:59

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

    • Михаил Петров Александр
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.03.2013 22:42

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

  • 29.03.2013 09:25

    Не лежит у меня душа к предложенному в начале делению. Документация нужна вначале, и ее должно быть достаточно много. Помните поучительное стихотворение «Я сначала начерчу дом такой, какой хочу…»? В середине (непосредственное внедрение) документации не много, чисто производственные рабочие документы: протоколы согласования, текущие графики, отчеты и т.п Достаточно много документации должно составляться в процессе опытной эксплуатации, это в основном окончательная редакция регламентов для персонала заказчика.

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.03.2013 12:31

      ее должно быть достаточно много - какой?

      • Михаил
        29.03.2013 21:09

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

  • Владимир Когут
    Рейтинг: 10
    РеутДент, ДентБлан, Медсофт
    Руководитель службы ИТ
    29.03.2013 10:23

    Михаил Викторович! Хотел прокомментировать когда было 4 сообщения, но выставка по медицинской информатике поглотила все свободное время, а тут за три дня комментариев появилось огромное количество. Опускаю дальнейшие лирические отступления. Есть некий перечень основных, я бы даже сказал обязательных этапов внедрения, названных Вами "костяком". Отход от этого "костяка" в ту или иную сторону, фактически расстрел на месте - провал кампании внедрения. Но вот брать какую-то методологию за основу никогда не рекомендовал бы. Если стоит задача внедрить, то она должна быть выполнена, в противном случае "всем спасибо, все свободны". Если использовать всевозможные "подходы", "методологии", то на выходе мы получаем результат укладывающийся в статистику внедрения. Леонид Алексеевич, собственно хорошая теоретическая подготовка и ведет к статистическим результатам. Кои и привожу. Для примера статистика внедрения CRM систем: http://www.interface.ru/fset.asp?Url=/misc/rcrm1.htm. Руководству всегда нужны результаты не вписывающиеся в статистику. Поэтому необходимо брать "костяк", а далее по ситуации, полагаясь на теоретический багаж, практический опыт, интуицию. В каждом конкретном случае все индивидуально, а конечный результат должен быть только положительным. Индивидуальность каждого случая зависит от множества исходных данных. Валерий Николаевич, преклоняюсь перед Вашим опытом. Вменяемость персонала разбил бы на следующие основные категории: - возраст; - социальный статус; - образование; - сфера работы(коммерция, гос.)

    • Леонид Хлопин Владимир
      Рейтинг: 10
      Ульяновский государственный педагогический университет
      Заместитель начальника отдела ИТ
      29.03.2013 12:00

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

    • Михаил Петров Владимир
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.03.2013 12:32

      брать какую-то методологию за основу никогда не рекомендовал бы - поясните, пожалуйста, почему?

  • Леонид Хлопин
    Рейтинг: 10
    Ульяновский государственный педагогический университет
    Заместитель начальника отдела ИТ
    29.03.2013 11:40

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

  • Владимир Когут
    Рейтинг: 10
    РеутДент, ДентБлан, Медсофт
    Руководитель службы ИТ
    29.03.2013 16:08

    При внедрении тиражируемых продуктов по какой-либо методологии мы получаем результат, который отражен в статистике по успешности внедрения. Как правило, в 15- 20% случаев проекты успешны, они оправдывают вложенные средства. Пользователи ими пользуются, использование продукта приносит прирост… В 60-70% случаев внедряемый продукт саботируется, частично используется, частично есть небольшие и непродолжительные плюсы, бросается, потом опять реанимируется. Мучают продукт, мучаются пользователи и руководство. В 15-20% случаев полный провал. Вот такая неутешительная статистика. http://crm-portal.ru/ru-22/crm-resheniya/opyit-vnedreniya/vnedrenie-crm-v-rossiyskih-kompaniyah-grabli-na-kotoryie-hochetsya-nastupat-snova-i-snova.html К сожалению, руководство на нее совсем не обращает внимания при принятии решений о внедрении тех или иных продуктов или систем. Нужен обязательно положительный конечный результат. Вот тут начинается творчество. Симбиоз технологий, методик, способов и методов. В ход идет все. Не только информационные технологии, но все, что входит в прикладную информатику. Валерий Николаевич написал «Оцениваю клиента исключительно по квалификации и вменяемости его персонала. 9()% всех проблем - это проблемы с персоналом. Применяются различные методы: убеждение, демонстрация, принуждение, пользовательские инструкции и т.д. Самое эффективное при этом, привлекать на самых ранних стадиях персонал, который будет работать в системе на конкретных рабочих местах.» И я с ним полностью согласен. Так как персонал работает, а руководство получает красивые циферки и картинки с графиками, показывающими ну просто стремительный рост… всего, чего только можно. Персонал - он же люди, очень разный и применять к ним шаблоны, не получится. Если вы на выходе хотите получить действительно положительный результат. Был случай при внедрении медицинской ИС, где персонал от 16 до 85 лет. Девушка выскочившая совсем недавно из школы, и на слова: «Нажмите мышкой на эту кнопку», она крепко зажимает в руке мышку и стучит ею по ЖК монитору, точно попадая в необходимую кнопку. И бабулька 1932 года, строчащая на клавиатуре как пулемет, настрополилась в свое время на печатной машинке.

    • Леонид Хлопин Владимир
      Рейтинг: 10
      Ульяновский государственный педагогический университет
      Заместитель начальника отдела ИТ
      29.03.2013 22:35

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

      • Владимир Когут Леонид
        Рейтинг: 10
        РеутДент, ДентБлан, Медсофт
        Руководитель службы ИТ
        01.04.2013 09:43

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

        • Владимир
          01.04.2013 10:47

          Поддержу Владимира. Мы статистику навязываем клиенту. Иначе у клиента рано или поздно возникает вопрос: "А на фига я плачу, ведь они ничего не делают". Когда роем канаву, работу видно и результат. В ИТ работа, как правило "за кадром", и у клиента невольно создается впечатление, что он платит ни за что. Я статистике уделяю особое внимание.

        • Леонид Хлопин Владимир
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          01.04.2013 12:46

          Если внедрением занимается внешняя подрядная компания, то у нее прямой интерес сделать меньшее за большие деньги и в случае неуспеха проекта свалить все на Заказчика. Это не значит конечно, что все так поступают. Я вообще-то, за недолгим периодом, всегда работал на стороне заказчика и выступал и в роли "Заказчика" и в роли "Подрядчика", в том числе и одновременно. И практически всегда в своей трудовой биографии занимался внутри корпоративными проектами внедрений. Основная задача которая стояла передо мной и которую я отрабатывал - получать эффективный результат в заданные сроки с минимальным привлечением ресурсов (в том числе и внешних). Вопрос не в том, чтобы показывать заказчику статистику, а в том, чтобы реально донести до него риски проекта и чтобы их минимизировать в ходе проекта. Построить схему проекта и порядок выполнения работ так, чтобы даже в случае остановки проекта по каким либо причинам, заказчик получил частичный законченный результат, соответствующий плану-графику работ. Определить риски проекта и предложить пути их минимизации это вообще-то "обязательная программа" в работе над проектом. Обычно, если внешняя подрядная организация начинала приводить статистику, в качестве тех или иных оправданий, то у меня как у представителя Заказчика всегда появлялся вопрос - ребята, а вы уверены в своей компетенции? Если вы предполагаете, что проект может быть неуспешным в силу каких-либо обстоятельств - опишите эти риски и предложите реальные решения и мероприятия по их устранению. Вас и привлекают на проект не для оглашения общей статистики, а для получения результата. Оценка необходимости проекта для заказчика осуществляется не на основе статистики, а на основе предполагаемого экономического эффекта от его результатов, в том числе и опосредованных. Профессиональная, порядочная внедренческая компания, сама предложит заказчику отказаться от проекта или изменить его объемы и цели, если в ходе обследования и анализа выяснится, что для заказчика будет получен отрицательный результат или неоправданные затраты. В своей практике приходилось, после анализа ситуации, убеждать внутренних заказчиков отказаться от проектов, изменять их цели и объемы, порядок следования проектов внедрений. Переваливать всю ответственность за принятие решение по началу проекта на Заказчика это как-то совсем не профессионально. В большинстве случаев, заказчик не обладает необходимым уровнем компетенции, чтобы самостоятельно принять обоснованное решение по проекту внедрения. В том числе и довольно часто встречающаяся ситуация с Заказчиком: З. - У всех есть, значит и у меня тоже должно быть! П. - А Вам зачем? Может не надо?! З. - А чтобы было - как у всех!.

        • Леонид Хлопин Владимир
          Рейтинг: 10
          Ульяновский государственный педагогический университет
          Заместитель начальника отдела ИТ
          01.04.2013 12:47

          Если внедрением занимается внешняя подрядная компания, то у нее прямой интерес сделать меньшее за большие деньги и в случае неуспеха проекта свалить все на Заказчика. Это не значит конечно, что все так поступают. Я вообще-то, за недолгим периодом, всегда работал на стороне заказчика и выступал и в роли "Заказчика" и в роли "Подрядчика", в том числе и одновременно. И практически всегда в своей трудовой биографии занимался внутри корпоративными проектами внедрений. Основная задача которая стояла передо мной и которую я отрабатывал - получать эффективный результат в заданные сроки с минимальным привлечением ресурсов (в том числе и внешних). Вопрос не в том, чтобы показывать заказчику статистику, а в том, чтобы реально донести до него риски проекта и чтобы их минимизировать в ходе проекта. Построить схему проекта и порядок выполнения работ так, чтобы даже в случае остановки проекта по каким либо причинам, заказчик получил частичный законченный результат, соответствующий плану-графику работ. Определить риски проекта и предложить пути их минимизации это вообще-то "обязательная программа" в работе над проектом. Обычно, если внешняя подрядная организация начинала приводить статистику, в качестве тех или иных оправданий, то у меня как у представителя Заказчика всегда появлялся вопрос - ребята, а вы уверены в своей компетенции? Если вы предполагаете, что проект может быть неуспешным в силу каких-либо обстоятельств - опишите эти риски и предложите реальные решения и мероприятия по их устранению. Вас и привлекают на проект не для оглашения общей статистики, а для получения результата. Оценка необходимости проекта для заказчика осуществляется не на основе статистики, а на основе предполагаемого экономического эффекта от его результатов, в том числе и опосредованных. Профессиональная, порядочная внедренческая компания, сама предложит заказчику отказаться от проекта или изменить его объемы и цели, если в ходе обследования и анализа выяснится, что для заказчика будет получен отрицательный результат или неоправданные затраты. В своей практике приходилось, после анализа ситуации, убеждать внутренних заказчиков отказаться от проектов, изменять их цели и объемы, порядок следования проектов внедрений. Переваливать всю ответственность за принятие решение по началу проекта на Заказчика это как-то совсем не профессионально. В большинстве случаев, заказчик не обладает необходимым уровнем компетенции, чтобы самостоятельно принять обоснованное решение по проекту внедрения. В том числе и довольно часто встречающаяся ситуация с Заказчиком: З. - У всех есть, значит и у меня тоже должно быть! П. - А Вам зачем? Может не надо?! З. - А чтобы было - как у всех!.

          • Владимир Когут Леонид
            Рейтинг: 10
            РеутДент, ДентБлан, Медсофт
            Руководитель службы ИТ
            01.04.2013 15:11

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

            • Леонид Хлопин Владимир
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              01.04.2013 15:14

              ROI например.

              • Владимир Когут Леонид
                Рейтинг: 10
                РеутДент, ДентБлан, Медсофт
                Руководитель службы ИТ
                02.04.2013 14:22

                Два неизвестных. ROI и Прибыль. Прибыль берем наверно все таки из средних статистических данных? Статистика - мать порядка, мать науки - по разному ее называют. Не получится у вас откреститься от статистики. Подвергну сомнению ваше утверждение "Оценка необходимости проекта для заказчика осуществляется не на основе статистики, а на основе..... "

                • Леонид Хлопин Владимир
                  Рейтинг: 10
                  Ульяновский государственный педагогический университет
                  Заместитель начальника отдела ИТ
                  02.04.2013 16:03

                  Данные мы берем из экономической истории конкретного предприятия. Далее, позволю себе остаться при своем мнении.

            • Леонид Хлопин Владимир
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              01.04.2013 15:22

              Я имел ввиду в большей степени консалтинговые компании (это естественный тренд развития компаний интеграторов).

              • Владимир Когут Леонид
                Рейтинг: 10
                РеутДент, ДентБлан, Медсофт
                Руководитель службы ИТ
                02.04.2013 14:26

                Вот тут соглашусь, тренд такой есть у интеграторов, причем в сторону полного ухода от ответственности...

                • Леонид Хлопин Владимир
                  Рейтинг: 10
                  Ульяновский государственный педагогический университет
                  Заместитель начальника отдела ИТ
                  02.04.2013 16:05

                  Не все так плохо ...

          • Леонид
            01.04.2013 15:11

            Леонид, противоречия нет. Просто статистика подкрепляет тобой сказанное. С ней легче разговаривать.

            • Леонид Хлопин
              Рейтинг: 10
              Ульяновский государственный педагогический университет
              Заместитель начальника отдела ИТ
              01.04.2013 15:16

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

    • Михаил Петров Владимир
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.03.2013 22:48

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

      • Владимир Когут Михаил
        Рейтинг: 10
        РеутДент, ДентБлан, Медсофт
        Руководитель службы ИТ
        01.04.2013 09:16

        Михаил Викторович! Даже не сомневался, что ситуация «про девушку с бабулькой», очень знакома. Пример хоть и 10 летней давности для Москвы, но очень показательный. К счастью как раз в то время в Москве начался очень положительный, в плане компьютеризации период, началась «домашняя информатизация». Все начали покупать компьютеры, вне зависимости от необходимости. Наверно мода такая была, как в начале 90-ых пользовались спросом микрокомпьютеры, подключаемые к телевизорам, всякие «Микроши» и им подобные. С тех пор с московскими пользователями проблем практически не возникает в плане навыков работе с компьютером и периферией. «Девушка с бабулькой» сейчас переместились в регионы, поэтому для вас ситуация очень знакома. Если в городах милионниках с пользователями ситуация приблизительно как в столице, то в городах с населением в 250000 чел. ситуация отстает на 2-5 лет. Вот тут приходится планы, графики и бумажное творчество, здорово корректировать.

      • Владимир Когут Михаил
        Рейтинг: 10
        РеутДент, ДентБлан, Медсофт
        Руководитель службы ИТ
        01.04.2013 10:11

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

        • Михаил Петров Владимир
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          01.04.2013 10:48

          Берем его личность и прокатываем по паре тестов - а можете опытом поделиться? что за тесты?

          • Владимир Когут Михаил
            Рейтинг: 10
            РеутДент, ДентБлан, Медсофт
            Руководитель службы ИТ
            01.04.2013 13:51

            В начале тест Люшера, затем 16–ти факторный тест Кетелла или более сложный MMPI, но в нем пока не возникала необходимость, его как правило проходят перед поступлением на работу в органы - МВД или ФСБ. Его прохождение занимает практически 2 часа, это очень долго. Есть структуры, где этот тест обязателен - это банки, есть и другие серьезные структуры, где прохождение этого теста обязательно, не буду упоминать их в суе. Тест Люшера занимает 3-5 минут, Кеттела – не более 20 минут. За мою практику было 2-3 таких сложных случая. И эти «верблюды» тормозили весь караван, поэтому проблему необходимо было решать. В серьезных организациях в отделе кадров, как правило, результаты теста Кеттела должны быть в личном деле, это несколько упрощает ситуацию. Но возникает другая проблема – доступ к результатам. Путем переговоров она решаема. Либо на этапе переговоров с заказчиком, его команде вы предлагаете заполнить «опросные листы». Ох и в дебри мы вами…

            • Михаил Петров Владимир
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              01.04.2013 20:36

              Дебри не дебри :) а что делать? :) Знаком с обоими тестами... подход понятен, спасибо!

              • Владимир Когут Михаил
                Рейтинг: 10
                РеутДент, ДентБлан, Медсофт
                Руководитель службы ИТ
                02.04.2013 09:24

                Для положительного результата и не так извернешься ;-)...

                • Михаил Петров Владимир
                  Рейтинг: 809
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  02.04.2013 09:56

                  Это точно :)

    • Владимир
      03.04.2013 08:21

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

      • 03.04.2013 09:20

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

        • 03.04.2013 09:46

          Не совсем так. Если говорить названиями систем: CRM - управление отношенями с клиентами. ERP - планирование работы предприятия. Особая ценность CRM - установление тесных взаимотношений с клиентом и как результат, получение более достоверных планов потребностей клиентов и договренностей, по их удовлетворению. Эта информация подается на вход ERP, для планирования обеспечения довгоренностей. И если ERP работает плохо или ее нет и процессы не поставлены другим способом, то договренности срываются и ухудшается имидж компании и отношения с клиентами. Поэтому получается что установка интегрированной CRM "вывавливает" на клиента проблемы организации, которая решать CRM не предназначена. Отсюда сопротивление менджеров, т.к. они могут головой этого не понимать, но нутром чувствовать, что толку не будет. CRM может внедряться на предприятии, которое не готово к этому и здесь не проблема не проекта, не управления организацией, а проблема построения взаимодействия внутри организации, проблема задания ритма организации. У Голдрата хорошо об этом написано в его расказах про Цель.

          • 03.04.2013 20:22

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

      • Владимир Когут
        Рейтинг: 10
        РеутДент, ДентБлан, Медсофт
        Руководитель службы ИТ
        03.04.2013 09:50

        По CRM системам можно создать отдельную дискуссию, которая будет популярна не менее остальных. Внедрение и необходимость CRM - злободневный вопрос. Предположу, что ваше замечание основывается на не совсем удачном опыте внедрении CRM. И собак Валерий Леонтьевич, повесили в большей степени на вас. Очень большое заблуждение "верхушки", что внедрение CRM - это проект ИТ. Программу купили, внедрили - не работает.... айтишники виноваты. Цели внедрения CRM и ее назначение, никак не сходятся с целями и задачами ИТ подразделения(управления, департамента, отдела) на 100%. Доля ИТ в CRM - 20%, в некоторых случаях 30%. Сомневаюсь в том, что вашему подразделению не удалось купить CRM, не удалось заинсталлить на серверах,и не подать пользователям на десктопы. "Паровоз" при внедрении, да какое там при внедрении, при решении о необходимости внедрения должен быть из другого "состава".

        • Владимир
          03.04.2013 09:57

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

          • Владимир Когут
            Рейтинг: 10
            РеутДент, ДентБлан, Медсофт
            Руководитель службы ИТ
            03.04.2013 12:02

            Да, при следовании денег в трубу, никакая методология тут не поможет.

        • Михаил Петров Владимир
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          03.04.2013 10:39

          "Паровоз" при внедрении, да какое там при внедрении, при решении о необходимости внедрения должен быть из другого "состава" - наверное, это не только для CRM, но и любой корпоративной системы справедливо?

          • Владимир Когут Михаил
            Рейтинг: 10
            РеутДент, ДентБлан, Медсофт
            Руководитель службы ИТ
            03.04.2013 12:07

            Да, верно подмечено. "Паровоз" из соответствующего "состава" приведет к "коммуни..." то есть к коммерческому успеху, я хотел сказать.;-)

  • Роман Цованян
    Рейтинг: 10
    ПервыйБИТ, проектный офис "Савеловский"
    Директор по развитию проектного направления
    31.03.2013 18:07

    В waterfall модели (та, которая с кучей бумаг) на самом деле минимизируются риски обеих сторон - заказчик минимизирует риски по деньгам за счет заранее прогнозируемого бюджета fix price, а исполнитель может дать более точную оценку и не сильно перезакладываться в случае, когда есть много подробной и качественной документации. Естественно, что в этом случае, любые изменения стоят дополнительных денег и времени. А так же всегда четко понятно, кто конкретно со стороны заказчика виновен в нечеткой постановке задачи. Это далеко не всем нравится, но тем не менее всем заказчикам почему то нравится fix price. А одно без другого не бывает. Во всех других методологиях (agile, lean, scrum и т.п.) производится просто перераспределение ответственности за наступление рисков неполного и неточного scope и некачественной документации между заказчиком и исполнителем в сторону исполнителя, но в обмен на это заказчик просто платит исполнителю большую сумму денег. Когда указанные риски по полноте требований и документации высоки - нужно использовать гибкую методологию. Когда они в пределах допустимого уровня, нужно использовать waterfall. Но надо помнить, что agile и другие гибкие методологии всегда подразумевают оплату работы исполнителя по модели time&materials, а не по fix price. Так же, для использования гибких методологий, должен быть высокий уровень доверия между заказчиком и исполнителем. Иначе, если все риски передать только исполнителю, заставить его гибко работать за fix price и постоянно его "нагибать", ему будет очень плохо, и он неожиданно скоро перестанет качественно работать, а то и вообще сбежит.

    • Михаил Петров Роман
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      31.03.2013 19:20

      agile и другие гибкие методологии всегда подразумевают оплату работы исполнителя по модели time&materials, а не по fix price - не всегда... есть опыт и по fix price. Вот с этим для использования гибких методологий должен быть высокий уровень доверия между заказчиком и исполнителем полностью согласен, один из ключевых критериев, нет доверия - никакого agile

      • Роман Цованян Михаил
        Рейтинг: 10
        ПервыйБИТ, проектный офис "Савеловский"
        Директор по развитию проектного направления
        01.04.2013 13:26

        Гибкая работа по fix price возможна, только если в стоимость перезаложены риски на 100-200%. Либо это фикс за ограниченный период времени без требований к результатам, что есть на самом деле t&m.

        • Роман
          01.04.2013 14:59

          Иногда получается по месячным планам-графикам (перечень работ/время/сумма)

          • Роман Цованян
            Рейтинг: 10
            ПервыйБИТ, проектный офис "Савеловский"
            Директор по развитию проектного направления
            01.04.2013 15:18

            Т.е. договариваетесь на состав релиза по историям пользователей, затем их оцениваете и делаете фикс? В этом случае, риски раздувания скоупа никуда не деваются, если истории пользователей не детализированы до техзадания. А это значит, что исполнитель добровольно берет на себя эти риски, но я так думаю, что вы их в стоимости все равно учтете, иначе просто обанкротитесь :)

            • Роман
              01.04.2013 21:05

              Риски стараемся поделить с клиентом. Главное вовремя поймать и разрулить.

          • Михаил Петров
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            01.04.2013 20:44

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

            • Михаил
              01.04.2013 23:02

              Естественно. Всё искусство в том, чтобы главную цель не потерять.

        • Михаил Петров Роман
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          01.04.2013 20:40

          Можно попытаться свести перезаклад рисков к более приемлемым величинам - 15-30%. Как Владимир Игоревич выше отметил - костяк все равно надо набрасывать, как документов, так и рамок проекта. И последовательным уточнением постепенно снимать вопросы (а равно и риски).

  • 31.03.2013 21:38

    Доверие - фактор сильно способствующий, но не определяющий. Доверие может придти буквально через пару месяцев.

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      01.04.2013 11:00

      Можно, конечно, как говорили классики, "ввязаться в драку - а потом посмотрим" как там доверие установится и т.п. Но это - смертельный номер...

      • Михаил
        01.04.2013 14:53

        Не совсем, за неимением лучшего приходится работать. Кстати, доверие тоже не всегда помогает. "доверяй, но проверяй", это реальность нашей деятельности.

        • Михаил Петров
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          01.04.2013 23:11

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

          • Михаил
            02.04.2013 00:41

            Документы надо писать, чтобы система не только была запущена, но работала после подписания акта.

            • Михаил Петров
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              02.04.2013 09:48

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

              • Михаил
                02.04.2013 14:18

                А вот это ошибка. После внедрения может быть сделана окончательная редакция пользовательского документа. Основа пользовательских документов закладывается на ранних стадиях.

                • Михаил Петров
                  Рейтинг: 809
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  02.04.2013 15:15

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

                  • Леонид Хлопин Михаил
                    Рейтинг: 10
                    Ульяновский государственный педагогический университет
                    Заместитель начальника отдела ИТ
                    02.04.2013 16:44

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

                    • Михаил Петров Леонид
                      Рейтинг: 809
                      Счетная палата Российской Федерации
                      Директор департамента цифровой трансформации
                      02.04.2013 17:16

                      Несомненно. Но это если планировать сделать все это по ходу проекта, а потом "пронести сроки" и лихорадочно доделывать - то будет крэш. Я же имею ввиду, что изначально можно запланировать сделать такую документацию в конце, не распыляясь на нее по ходу непосредственно внедрения.

                      • Леонид Хлопин Михаил
                        Рейтинг: 10
                        Ульяновский государственный педагогический университет
                        Заместитель начальника отдела ИТ
                        02.04.2013 17:32

                        В совей практике планировали и делали по разному. Но по последним проектам перешли к варианту, когда разработка технической документации осуществлялась по плану графику-проекта, с дальнейшей корректировкой по мере необходимости и окончательной плановой "версткой" в конце проекта. Т.е. готов очередной модуль или законченный "кусочек" системы - соответственно в плановом порядке делается раздел документации. Это позволяет начинать проводить обучение и тестирование сотрудников, кто будет работать с этим модулем или частью системы, до окончания работ по всему проекту и соответственно выявлять ошибки и недоработки на более ранних стадиях.

                        • Леонид
                          02.04.2013 20:43

                          Проверено. Работает.

                        • Михаил Петров Леонид
                          Рейтинг: 809
                          Счетная палата Российской Федерации
                          Директор департамента цифровой трансформации
                          02.04.2013 23:14

                          Да, полностью согласен в случае "почти нормального" внедрения. Но - отвлекитесь от него, абстрагируйтесь :)

                          • Леонид Хлопин Михаил
                            Рейтинг: 10
                            Ульяновский государственный педагогический университет
                            Заместитель начальника отдела ИТ
                            03.04.2013 00:09

                            Если есть хорошая команда профессионалов (под руководством специалиста по системной инженерии), тогда можно делать по любому варианту - получится, в том числе и направить заказчика на путь истинный. За исключением тех случаев, когда нужны волшебники или непосредственно Господь Бог (хоть и нехорошо упоминать его имя в суе!). ;-) P.S. Системная инженерия — междисциплинарный подход и средства для создания успешных систем; междисциплинарный подход, охватывающий все технические усилия по развитию и верификации интегрированного и сбалансированного в жизненном цикле множества системных решений, касающихся людей, продукта и процесса, которые удовлетворяют потребности заказчика.

                • Леонид Хлопин
                  Рейтинг: 10
                  Ульяновский государственный педагогический университет
                  Заместитель начальника отдела ИТ
                  02.04.2013 16:37

                  Именно так.

                  • Михаил Петров Леонид
                    Рейтинг: 809
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    02.04.2013 17:17

                    А если рассматривать такой подход как часть agile? :)

    • Роман Цованян
      Рейтинг: 10
      ПервыйБИТ, проектный офис "Савеловский"
      Директор по развитию проектного направления
      01.04.2013 13:34

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

      • Роман
        01.04.2013 14:53

        Всё верно.

      • Михаил Петров Роман
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        01.04.2013 20:45

        Хороший подход. Можно "притереться", оттюнить команду

  • Владимир Когут
    Рейтинг: 10
    РеутДент, ДентБлан, Медсофт
    Руководитель службы ИТ
    01.04.2013 09:52

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

    • Михаил Петров Владимир
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      01.04.2013 10:55

      Да, очень четкое изложение.

  • 03.04.2013 00:27

    Миша, привет! На самом деле вопрос о соотношении стандартного проектного управления и Agile один из самых обсуждаемых в профессиональной среде проектных менеджеров. Факт заключается в том, что Agile подход более-менее хорошо проработан только для одного вида ИТ проектов - проектов по разработке ПО (custom development). Примеры которые ты привел (AIM, ASAP и проч.) это совсем другая опера - внедрение систем с их доработкой. Более конкретно, ERP систем. Agile в том виде, в котором он существует сейчас для них принципиально не применим, так как одним из ключевых положений того же SCRUM является наличие одного выделенного представителя заказчика. Которого все разработчики вместе скопом и мучают. Как ты знаешь не хуже меня выделить для ERP одного человека, который все будет рассказывать просто не реально.. Иными словами SCRUM - подход к сокращению издержек на коммуникации внутри команды разработчиков, за пользователей он никак не озабочен - пусть одного в жертву принесут и из него все извлечем. Для проектов по внедрению систем с их адаптацией это, в подавляющем большинстве случаев, не реально. Это конечно не значит, что отдельные элементы подхода не могут использоваться. Могут и будут. Более того новая версия PMBOK уже признает де факто существование Agile и дивергенция подходов будет происходить и в дальнейшем - примеры есть в дискуссии выше. Для проектов же внедрения систем с их доработкой (это как раз упомянутые ERP и проч.), по моему мнению, основным направлением будет не Agile, а адаптивный инструментальный подход - ориентация на подбор конкретных инструментов проектного управления, под конкретный проект в конкретных условиях конкретной организации. Вот моя статья на эту тему для журнала "Проектное управление" http://www.slideshare.net/palferov/-14996036

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      03.04.2013 11:02

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

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    03.04.2013 09:25

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

    • Марк
      03.04.2013 09:51

      Я считаю тесное взаимодействие с клиентом - это в принципе главный определяющий фактор успешного внедрения. Всё остальное только способствует.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      03.04.2013 10:44

      совместная работа заказчика и подрядчика в одной системе управления проектами - поясни, пожалуйста

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        03.04.2013 11:15

        Работа в одном ПО управления проектами. Общие графики, общие ресурсы (временные, не денежные). Опыт был как с ПО на стороне Исполнителя, так и на стороне Заказчика. Использовали Spider, MS Project, Bitrix.

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          03.04.2013 11:27

          Понял мысль, спасибо!

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    06.04.2013 14:43

    Why Agile is not a methodology to build IT Strategy but software

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      06.04.2013 16:20

      Статья как-то из серии "понемногу обо всем". Очевидно, стратегию по agile разрабатывать непонятно как, вряд ли можно. В то же время agile-подход применим не только к разработке софта, но и к реализации ит-проектов в целом. Как его называть - agile, адаптивные метологии... - не суть важно. В общем, не совсем понял тему... :(

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    06.04.2013 16:18

    Статья как то из серии "понемногу обо всем". Очевидно, стратегию по agile разрабатывать непонятно как, вряд ли можно. В то же время agile-подход применим не только к разработке софта, но и к реализации ит-проектов в целом. Как его называть - agile, адаптивные метологии... - не суть важно. В общем, не совсем понял тему... :(

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    17.05.2013 10:32

    Agile Beyond IT Agile has often been considered a methodology for IT projects, but increasingly, other departments are seeing the value of this way of working. Here, Marcel Stekelenburg, Project Manager & Quality Assurance Manager at Marktplaats.nl describes the journey that his organization has taken to introduce Agile into other areas of the business.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      17.05.2013 13:05

      And responding to change is more important than following a plan :)

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        17.05.2013 13:17

        Никакой план не пережил начала боя... :)

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          17.05.2013 13:30

          В этом и смысл

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    21.05.2013 10:06

    What Exactly is Agile? Is Kanban Agile? The Agile community suffers a significant confusion between adoption and transformation. Sadly, change agents talk of adopting Agile and not about transforming the culture of a company to support the Agile mindset. The sad consequence of this myopia is of change agents accidentally undertaking a transformation without full buy-in or understanding of the organizational consequences. The typical result is failure.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      21.05.2013 11:42

      Да-да... кстати, заходи в мою новую дискуссию - что-то ее не пометили новой в списке дискуссий, только на главной...

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        21.05.2013 11:46

        Я видел. Заходил. Только что в подобной участвовал. Договорились до того, что все надо учить ArchiMate... :) Включая уборщиц и генерального...

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          21.05.2013 11:51

          Для начала надо им объяснить что такое архитектура :) пиши там :)

          • Марк Шварцблат Михаил
            Рейтинг: 30
            КТ "Акведук"
            ИТ-директор
            21.05.2013 12:24

            От ить, чОрт языкастый... Мёртвого уговорит... :)

            • Михаил Петров Марк
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              21.05.2013 16:33

              Это часть профессиональных скиллов :)

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    22.05.2013 13:10

    О как... How Manufacturing Can Learn From Software To Become Agile It’s ironic that the idea of Agile—a central concept of competitiveness in the 21st Century economy—which began in manufacturing in the early 1990s, took hold in software, not manufacturing. While manufacturers continued to focus on process consistency and efficiency, it was software developers who picked up the ball on Agile and ran with it. It was software developers who showed us in detail how a firm could become Agile on a systematic basis.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      22.05.2013 19:26

      Да уж...

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    29.05.2013 14:48

    Three Aspects of Agile BI Вот где-то через так мы выйдем на "Бизнес 2.0"... Может быть. Когда-нибудь.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.05.2013 23:32

      Честно говоря, напомнило "сапоги всмятку"...

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        30.05.2013 09:26

        Ну не Вильям наш Шекспир, конечно... :) Мантрообразненько...

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          30.05.2013 10:34

          Ну вообще как-то все в кучу свалено

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    29.05.2013 15:05

    Как оно всё сУрьёзно-то... Succeed with Agile Education ICAgile exists to support education in the agile space. Use ICAgile's definitive learning roadmap to find accredited courses that recognize students as they progress along their specialty paths. Ну и роадмэп внушаИтЬ... Роадмэп

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      29.05.2013 23:33

      Да, это уже нетленкой попахивает... Дело уверенно шло на рационализацию.

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        30.05.2013 09:26

        Кого и каким зверским способом будем рационализировать? :)

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          30.05.2013 10:36

          Ну похоже что ребята по этой ссылке весь мир хотят... сделать сертификацию а-ля PMP и стричь купоны на сертифицированных agile-менеджерах... только раскрутки им явно не хватает

          • Марк Шварцблат Михаил
            Рейтинг: 30
            КТ "Акведук"
            ИТ-директор
            30.05.2013 10:40

            Лиха беда начало... Подвижные западные товарищи быстро норовят монетизировать любой модный тренд.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    31.05.2013 14:48

    The Tradition and Behavioral Aspect of Agile Project Management In today’s globally competitive era, thousands of projects are being conceptualized and signed by the hour. But not all are completed within the allocated time. Only a handful of these projects are 100% accomplished while the rest are buried, wasting millions of dollars. Factors such as miscommunication in the team and lack of collaboration with clients and sponsors contribute to why projects fail.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    05.06.2013 14:34

    Для начинающих развивать гибкость... :) Top 10 Ways to Blow Up an Agile Project Everyone knows agile is better. But if you do it just right, agile can be fragile, too. Follow these 10 'tips' and your project is bound to come off the rails.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    05.06.2013 15:05

    Agile Information Architecture In this blog post I cover the concept of Agile Information Architecture. The terms “agile” and “architecture” in one phrase almost seem like a contradiction. So, here I unpack this term to clarify its meaning, ascertain its relevance within the broader field of BI, and to discuss a useful tool that can be utilised to assist in its implementation.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    05.06.2013 15:18

    Некоторые мысли надо учесть... Why Agile Isn't Working: Bringing Common Sense to Agile Principles Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers. I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    08.06.2013 02:19

    хорошая подборка, спасибо, особенно последнее

  • Дмитрий Соколов
    Рейтинг: 285
    АО "Генериум"
    Руководитель ИТ
    09.07.2013 23:40

    Подниму затухшее обсуждение и внесу свои 5 копеек. По моему мнению - "классику" противопоставлять Агилю не совсем верно. Выбор того, как будет вестись и документироваться проект в первую очередь зависит от того, что делаем, на чем делаем, каковы познания команды, и, на сколько это команда большая. Тут проще наверно на примерах показать. Случай первый - внедряем ERP. Как бы не уверял функциональный заказчик (владелец проекта) в уникальности процессов, всё же 80% функционала в ERP есть. Что бы это не было, SAP, Oracle, Галактика или 1С. Соответственно, если само внедрение разбито на этапы, а не внедряется сразу а всё, то намного эффективней использовать агиль со спринтами в 4-6 недель. Первое - это снижает затраты времени на документацию, второе - владелец видит результат, и, есть "возможность маневра", если е туда поехали. Третье - это снижение цены ошибки проектирования. Теряем максимум 4-6 недель, а не человеко-годы. Если при этом используется труд подрядчика, то при спринтах сложнее "мухлевать" с трудозатратами. Единственное, такой подход от руководителя (как со стороны ИТ, так и от владельца) отнимает больше времени. Это неизбежное "зло". Тем не менее, это все дает быстрый результат. Изменения, если можно так сказать, попадают "в кассу", а не "вы 4 мес. в экселе порисуйте, а мы потом сделаем". Помимо этого, тут и пиар ИТ - владелец видит, что ИТ реально работает, а не "сидит где-то в комнате". Случай второй - разрабатываем эксклюзив. Тут ситуация обратная, нежели чем с ERP. Спринты по 4-6 недель могут привести к тому, что софт "уедет в бесконечную разработку". Как раз при разработке софта не на какой-либо бизнес-платформе, а на старом-добром Си(Паскаль/Шарп/и т.д.) важно иметь "горы документации", что бы правильно спроектировать как хранение данных, так и саму архитектуру ПО, ибо цена ошибки в этом случае очень велика. Был у меня печальный опыт, когда подобная "ошибка" привела к тому, что для системы пришлось городить "внешний модуль" для работы с данными и отдельно базу с "данными для данных", т.к. на этапе проектирования приняли 4НФ для СУБД, а потом, когда система стала "большой и толстой" на СУБД получили бешеную деградацию производительности на выборках. И сделать уже ничего нельзя, т.к. система в проме уже 2,5 года. Так же при создании системы "с нуля" при агиле можно "закопаться в деталях", в то же время, если есть четкие описания и ТЗ, то нужно следовать к конечной цели, а "сопли" подобрать уже после завершения работ по созданию "скелета" ПО. Случай третий - возьмем миксер и смешаем. Когда делал учетную систему, в которой 70% модулей разрабатывалось "с нуля". Разработчики, коих было 5 штук были разделены на 2 группы - 2 человека и 3 человека. 2 человека писали "скелет" по "большим документам". Этот скелет принимали по этапам. Т.е. было "все как у взрослых". 3 разработчика работали в "спринтах" по 6 недель. При том - спринт - это минорный релиз ПО, "обновление скелета" - это мажорный релиз. Как-то так. Однако, это теперь я "такой умный", когда проекты реализовывались, я про агиль, скрам и подобные технологии и не слышал даже. Были задачи и были ограничения (ресурсы, время, деньги). В рамках ограничений необходимо было получить результат. Вот и получали, как могли. Когда первый раз про агиль прочитал, то был сильно "удивлен", т.к. "без образования" применял то, что "умные люди написали". Немного сумбурно написал, так что, если что не понятно, могу пояснить.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    10.07.2013 00:38

    "классику" противопоставлять Агилю не совсем верно
    конечно
    как будет вестись и документироваться проект в первую очередь зависит от того, что делаем, на чем делаем, каковы познания команды, и, на сколько это команда большая
    да! и спасибо за прекрасные примеры

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    26.07.2013 10:45

    IT Agility vs. Strategy

    :)

    We all remember the old saying: culture eats strategy for lunch. Nowadays, as the speed of change is accelerated, there comes to the new saying: Agility will eat strategy every morning. Are agility and strategy mutually exclusive or they do co-exist? And what’s the best way to balance strategy and IT agility?

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    15.08.2013 10:04

    Introducing Enterprise wide Agile in big organizations

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    16.08.2013 13:10

    В теории все правильно :)

    • Марк Шварцблат Михаил
      Рейтинг: 30
      КТ "Акведук"
      ИТ-директор
      16.08.2013 14:32

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

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    05.09.2013 13:24

    CIO's Agile Practices in Managing IT Complexity

    Businesses become over-complex and hyper-connected today, agility is the ability of an organization to sense opportunity or threat, prioritize its potential responses, and act efficiently and effectively. More specifically, what does Agile mean for IT and business, how does CIO leverage agile in managing IT complexity?

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    08.10.2013 12:47

    CIO as Agility Leader: Agile vs. Waterfall

    Agile and Waterfall is not opposite, but complimentary.
    agile+vs.+waterfall.jpg

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      09.10.2013 16:02

      yes!

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    09.10.2013 12:21

    CIO Success Story: Agile Development

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      09.10.2013 16:03

      отлично!
      "When I have all the time and money I need" - такое бывает? ;)

      • Марк Шварцблат Михаил
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        09.10.2013 16:12

        Ну в нашей стране и не с нами... А так - Вселенная бесконечна... Вероятность есть... :)

        • Михаил Петров Марк
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          10.10.2013 16:48

          даааа уж )

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    10.10.2013 12:27

    Как-то бы дискуссию "закрепить" вверху. Или народ проинформировать. Она была давно. Возможность подписки появилась позже. Народ ее не видит.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    10.10.2013 12:28

    Is Agile still not 'Agile' Enough

    With the popularity of Agile methodology, it spurs varies debate upon the ‘agility’ of Agile, Does Agile mean completely free thinking or doing; or are those agile principles and practices are still too static and rigid, not ‘agile’ enough to adapt to the changes?
    agile23.jpg

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    10.10.2013 12:30

    The Next Phase of Agile Development

    CIOs are under tremendous pressure to pick up the pace of change. Their current IT systems and work styles are holding them back and slowing them down. More pliable, organic models and mindsets are called for in today’s dynamic environment. CIOs shouldn’t think of themselves as keepers and protectors of solid structures. Rather, they are orchestrators of alive, bustling environments with the ability to grow from marketplace blows.

    • Михаил Петров Марк
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      10.10.2013 16:45

      Да, так и есть имхо

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    15.10.2013 10:04

    From ‘Doing Agile’ to ‘Being Agile’

    Agile is not just the software management methodology, from efficiency to effectiveness to agility, it is an ultimate goal organizations pursue to reach their maturity. In deed, we want to see teams and organizations being agile rather than doing agile. Doing agile is still not good enough, as it is a process only; being agile means changing the way people think and behave. So one of the burning topics is how you can use agile practices effectively on large programs or across the wider organization?
    being+agile2.jpg

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    28.10.2013 09:30

    Is Agile a Methodology or a Set of Guidelines?

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    30.10.2013 11:18

    Is Agile Team too ‘Tactical”

    'Going Agile' shouldn't be a pretext for forgetting the big picture of what the project is all about. Sometimes you keep working on tiny stories that everyone (including the Product Owner) loses the big picture vision. Engineering teams can get caught in operations and forget longer term strategy. This is a sign of leadership deficiency and rewards given for the wrong things.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    02.11.2013 10:04

    How to Define IT Agility?

    Agility is a common business term that is used frequently these days to measure how fast business will respond to opportunities or threats, and enterprises are even having key agility indicators. IT Agility is about how IT will enable business agility, how fast IT will deliver the required effectively and efficiency. The more alignment between business and IT the more level of agility for both will be achieved.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    07.11.2013 14:40

    Не про ИТ, но в русле...

    Agile Business Management; Adaptability for Sustainable Business Growth


    First, a brief introduction. If you've heard the terms "Agile" or "Lean", I want you to put any preconceived ideas aside (and if you haven't, read on). Agile is a set of values, principles, techniques and frameworks for the adaptable, incremental & efficient delivery of work. They can be applied to any type of work including finance, sales, HR, marketing, corporate strategy, leadership, and more.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    19.11.2013 10:44

    Does Agile Stimulate or Stifle Innovation

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    27.11.2013 11:42

    The 7 Core Techniques of Agile Development

    As a CIO, I've been successful with agile development because I insist that every agile development team be composed of people who are skilled in one or more of what I call the core techniques. There are seven core techniques:
    • Brainstorming and facilitation
    • Process mapping
    • Data modeling
    • System prototyping
    • Object-oriented design and programming
    • DevOps
    • Agile project management

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    20.12.2013 12:13

    Agile Scalability

    From techopedia: Scalable agile is an agile software development process that refers to the ability to manage large projects with multiple teams. Based on its conceptual framework, agile software development is often considered to not be scalable and only intended for small projects and teams. Thus, Agile's scalability is a heated and debated subject. Many believe that agile development cannot be sustained when a project is large or multiple teams are involved. The flipside is that many open-source projects could be considered loosely agile given the iterative nature. So what are further perspectives upon Agile scalability?

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    26.12.2013 13:29

    When Agile BI is Not Agile

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    27.12.2013 11:34

    Top Agile Trends

    We’re living in an interesting time, with the exponential growth of information and disruptive technologies; the foundation for a quantitative leap is building up. Now it’s clear that Agile is turning into a mainstream methodology, what are the Agile trends in the upcoming new year?

  • 27.12.2013 14:53

    Марк Рудольфович, чуть чуть подождите. Понятно, что надо обсуждать Agile, с Нового года будет эксперт по этому подходу, тогда, я надеюсь, с большей пользой все ваши находки обсудим.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    28.12.2013 13:13

    Agile Development: Agile Project Management

    Agile development teams skilled in the first six core techniques and guided by continuously updated project plans like this one are highly productive and they become an awesome competitive advantage for the IT groups and companies that employ them.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    13.01.2014 12:48

    Can Outsourcing Make You More 'Agile'?

    Agile software development has made its way into complex enterprise environments, but keeping the process in-house may be too expensive.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.