Портал №1 по управлению цифровыми
и информационными технологиями

Между разработкой и эксплуатацией

Работая с разными компаниями, в последние годы мы несколько раз сталкивались с задачей определения требований к взаимодействию в триаде «проектный офис, разработчики, эксплуатирующие подразделения». Практика в этой области весьма разнообразна. Столкнувшись с этой задачей в очередной раз, решил кратко суммировать накопленный опыт (спасибо нашим заказчикам!). Итак, вот основной набор регламентирующих документов в этой области:

  1. Документ, определяющий основные стадии создания новой АС (новой версии АС) или выполнения доработок. Обычно называется «Положение о разработке прикладного ПО» или аналогично. Основное содержание – по каждой стадии определяется состав работ, ответственных, входные и выходные документы. Важный момент – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. Плюсы – возможность учесть эксплуатационные требования при проектировании и меньшее количество сюрпризов при приёмке в эксплуатацию. Есть у многих.
  2. Документ, определяющий порядок приёмки новых АС в эксплуатацию. Может быть частью пункта 1. Обычно называется «Положение о внедрении информационных систем» или аналогично. Включает в себя определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и так далее. Может дополняться политиками релизов по информационным системам. Плюсы – возможность подготовиться к эксплуатации новых решений, согласование с бизнесом календаря релизов (при наличии политик релизов), необходимости и порядка выделения ресурсов на проведение UAT. Есть у многих (хотя и реже, чем п.1). В сумме пункты 1 и 2 образуют регламент управления изменениями и релизами в части разработки и внедрения прикладного ПО.
  3. Документ, определяющий архитектурные и технологические стандарты, распространяющиеся в том числе на разработку новых решений. Включает в себя определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания и настройки локаторов прикладных серверов и middleware, интерфейса пользователя и администратора, требований к резервированию, мониторингу, журналированию и так далее. Иногда сюда же относят решения по freeze периодам. Плюсы – возможность в результате разработки получить то, что можно надёжно эксплуатировать, и сокращать трудозатраты на развёртывание и эксплуатацию. Есть у единичных компаний, обычно крупных и наиболее зрелых в вопросах регламентирования деятельности.

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

Кому есть что добавить, велкам.

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 17

  • Сергей

    Печальный опыт показывает, что процесс сдачи системы в эксплуатацию от проектного офиса (ПО) к службе сопровождения (СС) проходит в ситуации “горящих сроков”. Основная задача ПО в этот момент — подписать все необходимые акты выполненных работ у заказчика, поэтому “свой брат сопровожденец” остается с обильным количеством “завтраков” не зависимо от качества разработанных регламентов. Обсуждая со службой сопровождения порядок передачи в эксплуатацию разрабатываемых систем пришли к выводу, что жизнь сопровождения была бы легче, если бы на этапах разработки и передачи системы в опытно-промышленную эксплуатацию (а не на этапе сдачи системы в пром!) требовать (и без этих документов к следующему этапу не переходить!!!) следующие документы:
    1. Техническое описание системы
    2. Руководство по эксплуатации (как для пользователей, так и для админов)
    3. Проект регламента поддержки и сопровождения
    4. Описание интерфейсов системы
    5. Инструкцию по действиям для восстановления
    В это же время, совместно со службой сопровождения, подготавливаются:
    1. Ресурсный план службы сопровождения
    2. Проект SLA
    3. План обучения сотрудников сопровождения
    4. Порядок подключения пользователей к системе

    Не знаю, насколько в тему 🙂

    • “Не знаю, насколько в тему”

      И да, и нет 🙂

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

      Да, потому что про разработку и эксплуатацию. И любопытно. Например, мне любопытен ресурсный план сопровождения. Более всего интересно, пересматривается ли он при доработках АС (а не при внедрении новых АС) и каковы механизмы его согласования.

  • Grigory Kornilov

    Важный фактор – “вес и компетенция эксплуатирующих подразделений”.

    • Григорий, хочется спросить Вас “И?”, чтобы помочь развить Вашу мысль 🙂

      • Grigory Kornilov

        Хорошо бы вначале описать веса\компетенций\распределение_полномочий между PMO, Development, Operation подразделений.
        Далее перейти к методам и объемам вовлечения Operation.
        И завершить описанием результатов (регламенты, артифакты, практика).

        • “Хорошо бы вначале описать веса…”

          В смысле “кто главнее”? Не очень представляю себе результат. У каждого своя область ответственности, все по-своему работают на общий результат. Что конкретно Вы хотите прописать и что это даст?

        • Сергей

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

          • Полностью согласен, кроме пункта про “важнее”.

            • Сергей

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

              • Так это скорее говорит о главенстве заказчика. Если бы заказчик не торопил, пошли бы дорабатывать документы штатным порядком, без всяких клятвенных обещаний. Нет?

                • Pavel Solopov

                  Т.е. всё сводится к виновности Заказчика. Если бы он не хотел в определённые сроки, да если бы он не хотел всяких фич… А если бы вообще ничего не хотел так вообще милое дело, никаких бы проблем не было. 🙂

                  • Павел, Вы слово “виновность” в моих постах где увидели? 😉

                    • Pavel Solopov

                      Это моя авторская интерпретация… И не говорите, что я не прав. хотя может и не на все 100. 🙂

                    • Нет, 100% я это не имел ввиду. Да собственно достаточно прочитать всю ветку, чтобы в этом убедиться – не я вообще поднял эту тему, и точно не клонил к чьей либо виновности или важности.

          • Grigory Kornilov

            ‘Занудством’ и ‘мы зарабатываем деньги’ можно все оправдать, был вес. Соответственно сценарий восстановления и далее не будет готовиться – не до этого, появились новые заказы.

            Дмитрию :
            Я предложил описать реальную ситуацию и ее обсудить. Возможно список документов, их наполнение, кто\когда их подготавливает\принимает зависит от ситуации.
            ‘работают на общий результат’ – всегда ли мотивация различных подразделений действительно исходит из некого одного общего результата?

            • Григорий, я как раз не вижу смысла уходить в конкретный случай – я же не спрашиваю совета, как поступить в проекте. Наоборот – пост был про обобщение нескольких частных случаев. Реальную ситуацию (кейс), тем более крупной компании, в комментарии к блогу и не описать, и не обсудить. Это несколько страниц, со ссылкой на внутреннюю нормативную документацию, с оргструктурой, со схемами действующих процессов. Разумеется, есть и вопрос права публикации такой информации – это и неэтично, и незаконно (есть NDA).
              Вы написали про вес, как один из решающих факторов. Я решил уточнить, что имеется ввиду. Ответ пока не понял.

              • Grigory Kornilov

                1. Меня интересовал бы вариант, приближенный к какому-то конкретному случаю. Конкретный не означает привязку к существующей огранизации и ее процессам.

                2. ‘Вес’ – свойство подразделения повышать приоритет своих интересов, влиять на принятие решений в пользу своих интересов.

                PS: У вас есть пример описания веса и его применения:
                “… говорит о главенстве заказчика. Если бы заказчик не торопил …”


Добавить комментарий для Grigory KornilovОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM