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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

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

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

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

  1. Сергей

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

    1. Техническое описание системы

    2. Руководство по эксплуатации (как для пользователей, так и для админов)

    3. Проект регламента поддержки и сопровождения

    4. Описание интерфейсов системы

    5. Инструкцию по действиям для восстановления

    В это же время, совместно со службой сопровождения, подготавливаются:

    1. Ресурсный план службы сопровождения

    2. Проект SLA

    3. План обучения сотрудников сопровождения

    4. Порядок подключения пользователей к системе

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

    1. Дмитрий Исайченко Автор

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

      И да, и нет 🙂

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

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

      1. Grigory Kornilov

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

        Далее перейти к методам и объемам вовлечения Operation.

        И завершить описанием результатов (регламенты, артифакты, практика).

        1. Дмитрий Исайченко Автор

          «Хорошо бы вначале описать веса...»

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

        2. Сергей

          Насколько я понимаю, на этапе передачи системы в эксплуатацию проектное подразделение всегда важнее — они подписывают акты у заказчика, вот-вот придут живые финальные деньги (а с ними премии :-))

          И в этот момент занудство сервисного подразделения (не согласую подписание актов — вы сценарий восстановления системы после сбоев не подготовили) будет восприниматься как минимум как недружественное и не командное.

          Поэтому:

          1. Перечень необходимых для службы сопровождения документов (которые я постарался перечислить выше) необходим чуть ли не на старте проекта;

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

          3. Иначе (возвращаясь к теме основного сообщения) какие бы подробные и качественные регламенты по взаимодействию между проектным офисом и службой сопровождения мы ни написали — работать они не будут.

          И еще замечание. В случае, когда ПО и СС разные организации, необходимость контроля за разработчиками ложится на плечи заказчика.

            1. Сергей

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

                1. Pavel Solopov

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

                    1. Pavel Solopov

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

                    2. Дмитрий Исайченко Автор

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

          1. Grigory Kornilov

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

            Дмитрию :

            Я предложил описать реальную ситуацию и ее обсудить. Возможно список документов, их наполнение, кто\когда их подготавливает\принимает зависит от ситуации.

            'работают на общий результат' — всегда ли мотивация различных подразделений действительно исходит из некого одного общего результата?

            1. Дмитрий Исайченко Автор

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

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

              1. Grigory Kornilov

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

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

                PS: У вас есть пример описания веса и его применения:

                «... говорит о главенстве заказчика. Если бы заказчик не торопил ...»

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

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

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

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

АВГ
28