Работая с разными компаниями, в последние годы мы несколько раз сталкивались с задачей определения требований к взаимодействию в триаде «проектный офис, разработчики, эксплуатирующие подразделения». Практика в этой области весьма разнообразна. Столкнувшись с этой задачей в очередной раз, решил кратко суммировать накопленный опыт (спасибо нашим заказчикам!). Итак, вот основной набор регламентирующих документов в этой области:
- Документ, определяющий основные стадии создания новой АС (новой версии АС) или выполнения доработок. Обычно называется «Положение о разработке прикладного ПО» или аналогично. Основное содержание – по каждой стадии определяется состав работ, ответственных, входные и выходные документы. Важный момент – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. Плюсы – возможность учесть эксплуатационные требования при проектировании и меньшее количество сюрпризов при приёмке в эксплуатацию. Есть у многих.
- Документ, определяющий порядок приёмки новых АС в эксплуатацию. Может быть частью пункта 1. Обычно называется «Положение о внедрении информационных систем» или аналогично. Включает в себя определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и так далее. Может дополняться политиками релизов по информационным системам. Плюсы – возможность подготовиться к эксплуатации новых решений, согласование с бизнесом календаря релизов (при наличии политик релизов), необходимости и порядка выделения ресурсов на проведение UAT. Есть у многих (хотя и реже, чем п.1). В сумме пункты 1 и 2 образуют регламент управления изменениями и релизами в части разработки и внедрения прикладного ПО.
- Документ, определяющий архитектурные и технологические стандарты, распространяющиеся в том числе на разработку новых решений. Включает в себя определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания и настройки локаторов прикладных серверов и middleware, интерфейса пользователя и администратора, требований к резервированию, мониторингу, журналированию и так далее. Иногда сюда же относят решения по freeze периодам. Плюсы – возможность в результате разработки получить то, что можно надёжно эксплуатировать, и сокращать трудозатраты на развёртывание и эксплуатацию. Есть у единичных компаний, обычно крупных и наиболее зрелых в вопросах регламентирования деятельности.
Разумеется, разбивка может быть любой – не обязательно именно 3 документа. Важен перечень вопросов, по которым приняты решения и достигнуты соглашения. Это действительно помогает в работе.
Кому есть что добавить, велкам.
Печальный опыт показывает, что процесс сдачи системы в эксплуатацию от проектного офиса (ПО) к службе сопровождения (СС) проходит в ситуации “горящих сроков”. Основная задача ПО в этот момент — подписать все необходимые акты выполненных работ у заказчика, поэтому “свой брат сопровожденец” остается с обильным количеством “завтраков” не зависимо от качества разработанных регламентов. Обсуждая со службой сопровождения порядок передачи в эксплуатацию разрабатываемых систем пришли к выводу, что жизнь сопровождения была бы легче, если бы на этапах разработки и передачи системы в опытно-промышленную эксплуатацию (а не на этапе сдачи системы в пром!) требовать (и без этих документов к следующему этапу не переходить!!!) следующие документы:
1. Техническое описание системы
2. Руководство по эксплуатации (как для пользователей, так и для админов)
3. Проект регламента поддержки и сопровождения
4. Описание интерфейсов системы
5. Инструкцию по действиям для восстановления
В это же время, совместно со службой сопровождения, подготавливаются:
1. Ресурсный план службы сопровождения
2. Проект SLA
3. План обучения сотрудников сопровождения
4. Порядок подключения пользователей к системе
Не знаю, насколько в тему 🙂