Разработка и эксплуатация

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

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

С точки зрения теории можно сколько угодно долго рассуждать на тему: в чьей области ответственности находится контроль выполнения всех мероприятий в момент передачи в эксплуатацию. На практике же ситуацию спасает только возведение мероприятий, которые должны быть выполнены до передачи в эксплуатацию в ранг ОБЯЗАТЕЛЬНЫХ требований, ничем не отличающихся от функциональных требований к системам, без реализации которых эксплуатация просто не может начаться. Ведь закладываются же на начальном этапе планирования проекта сроки на реализацию функционала, почему не заложить туда же дополнительные дни и трудозатраты на подготовку системы. Принцип, "главное взлететь, а как потом садиться будем, разберемся по ходу полета", не только с самолетами не доводит до добра 🙂

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

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Leonid

    «С точки зрения теории можно сколько угодно долго рассуждать на тему: в чьей области ответственности находится контроль выполнения всех мероприятий в момент передачи в эксплуатацию. На практике же ситуацию спасает только возведение мероприятий, которые должны быть выполнены до передачи в эксплуатацию в ранг ОБЯЗАТЕЛЬНЫХ требований…»

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

    1. Евгений Шилов Автор

      Leonid, фиксация ответственности, на мой взгляд, является обязательным, но не достаточным условием для организации работающей передачи в эксплуатацию. Судя по комментарию, Вы не согласны с моим предложением? А Вы что можете предложить? Давайте обсудим 🙂

  2. Георгий

    Требования по передаче в эксплуатацию могут быть возведены в ранг ОБЯЗАТЕЛЬНЫХ сколько угодно раз, но уж коли

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

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

    1. Евгений Шилов Автор

      А заложить эти работы в график проекта на этапе его планирования тоже миф?

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

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

      Есть ведь успешные примеры, где все работает, они «успешное исключение»?

      1. Георгий

        Заложить не миф — закладывают, прямо так и закладывают, изначально понимая, что не выполнят, закладывают чтобы ОБЯЗАТЕЛЬНЫЕ требования выполнить.

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

        1. Вадим

          Там как правило есть единые стандарты проектирования, внедрения, эксплуатации систем

          ну да, ну да, а к созданию ИТ-систем подходят как к капитальному строительству производственного объекта, включая такую хрень как землеотвод, проект организации строительства (ПОС) и прочие «крайне полезные» хитрости капстроя.

                    1. Вадим

                      тогда я скажу в такой форме «одна неотечественная пищевая компания», для которой я делал несколько лет назад одну систему.

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

                      хватит?

    2. Peshkov Alexander

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

      Уверен, что объяснять на уровне калькуляции проще, чем на уровне уже выпущенного и не пригодного к поддержке приложения...

  3. Вадим

    на самом деле достаточно проводить приемку системы в эксплуатацию (или о чем там шла речь) по формальным признакам/требованиям в соответствии ПМИ, которые необходимо разрабатывать с участием службы эксплуатации.

    и только сданную в эксплуатацию систему передавать в использование бизнесу!

  4. Анатолий Павлюченко

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

    Сложность возникает только тогда, когда новая потребность бизнеса возникает до того, как закончилось выполнение отложенных этапов. А вот тут уже всё зависит от «менеджера, отвечающего за уровень предоставления услуг». В его задачу входит убедить бизнес синхронизироваться. Возможно, даже, путём снижения требований.

      1. Анатолий Павлюченко

        Не зря я выделил эту роль таким образом! Это может быть и тот, кто сидит в пруду, и ИТ менеджер, и Административный директор. Две крайности — сисадмин и главный бухгалтер (отвечающий за ИТ). Главное, что одной из задач для этого человека является контроль за деятельностью ИТ подразделения, состоящей хоть из одного человека, хоть вообще без людей — приходящий админ, и согласование с требованиями других подразделений-людей.

        1. Вадим

          мысль понятна, хоть и не совсем верно сформулирована.

          на практике в последнее время организуются службы заказчика (или хотя бы определяются ролевые функции СЗ). вот только представитель СЗ контролирует не деятельность ИТ подразделения — это задача ИТ-менеджера, а контролирует качество получаемых «бизнесом» услуг на основании SLA.

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

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

          1. Анатолий Павлюченко

            В рамках уточнения, а не спора!

            Я описывал именно ситуацию с «сидением на двух стульях». Это больше связано с низким уровнем _процессной_ зрелости с одной стороны и с жестким _бизнес-прагматизмом_ с другой. Мне кажется, это как-раз подходит к теме этой ветки.

            СЗ — это уже достаточно высокий уровень зрелости. На постсоветском пространстве уже успели об этом забыть и ещё не успели «опять вспомнить».

  5. Peshkov Alexander

    СЗ — это заветная мечта миллионов трудящихся (мечтательно).

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26