Корпоративное внедрение

• Об услуге
• Роли участников проекта
• Этапы




При внедрении СЭД по технологии проектного внедрения необходимы следующие роли участников проекта. Причем некоторые роли могут быть совмещены в одном лице, быть внутри компании Заказчика или быть предоставлены Исполнителем.




Роль в проекте	Функции
Спонсор проекта	Постановка целей проекта, контроль результатов, финансирование проекта, выделение ресурсов
Руководитель проекта	Управление проектом (планирование, учет, анализ, корректировка, мониторинг, коммуникации), отчетность перед  спонсором
Аналитик	Определение требований к документообороту, описание бизнес-процессов, моделирование бизнес-задач в "1С:Документообороте", тестирование, постановка задач для программистов, обучение пользователей
Программист	Программирование на "1С:Предприятие 8.2"
Системный администратор	Установка СУБД, кластера "1С", web-сервера, организация резервного копирования БД и томов, администрирование

 

 Проект внедрения СЭД состоит из следующих этапов:







Этап№1. Формализация требований и формирование проектных решений

Цель этапа: получить детальные требования к системе "1С:Документооборот", сформировать проектные решения для реализации этих требований.

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

Результат этапа: Документ "Техническое задание" согласован с Заказчиком.

Этап№2.  Разработка и настройка прототипа Системы

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

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

Результат этапа: "Протокол тестовых испытаний" подписан заказчиком.

Этап№3.  Подготовка к опытной эксплуатации

Цель этапа: Подготовить систему к эксплуатации, сформировать у пользователей системы минимальный набор знаний и навыков, необходимых для работы с системой.

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

Система развертывается на серверах заказчика.

Результат этапа: Утверждены инструкции пользователей, Документ "Протокол обучения пользователей".

Этап№4. Опытная эксплуатация системы

Цель этапа: выявление возможных ошибок, несоответствий, пожеланий пользователей к доработке системы.

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

Результат этапа: Документы "Журнал опытной эксплуатации", "Протокол о запуске системы в промышленную эксплуатацию".

• Об Agile
• Scrum
• Backlog
• Спринты
• Преимущества технологии

Agile (в частности, Scrum) подразумевает гибкую разработку. Основная особенность технологии  в том, что клиент получает готовый продукт в каждый определенный период времени.

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

Как строится процесс работы при использовании технологии Agile (Scrum)?

В процессе встречи с клиентом формируется общий список задач. По технологии Scrum это называется backlog.

Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации.

Например, в backlog мы записываем, что нужно создать в системе 800 пользователей, завести в системе управленческую структуру, входящие и исходящие документы, автоматизировать договорную деятельность. 

После того, как backlog сформирован, мы берем тайм-аут на оценку этих задач. Указываем, например, что для заведения 800 пользователей нам потребуется неделя. Для заведения управленческой структуры – еще неделя. При этом задача полностью включает в себя уточнение требований по этой задаче; возможно, подготовка какой-то спецификации, выполнение непосредственных работ в программном продукте. И тем самым потом по результату у нас будет понимание, какая задача с какой длительностью будет выполнятся. Это на этапе предварительных переговоров.  

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

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. Считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.

Мы планируем, что у нас проект будет состоять из 4 спринтов. Каждый спринт по одному месяцу, например. И по результату первого месяца – первого спринта – у нас будет система, в которую пользователь может войти и работать с входящим документом. По результатам второго спринта он сможет работать с входящими, исходящими, договорами. По результатам третьего спринта будет организована работа с тендерной документацией. По результату четвертого спринта будет организована интеграция со сторонними системами.

Преимущества технологии Agile:

• Быстрый результат: у пользователей появляется возможность начать работать в системе уже через месяц.
• Снижение рисков для заказчика и исполнителя, за счет постоянного выпуска нового продукта его акцептации. Безболезненное, преждевременное закрытие контракта. Например, по итогам реализации первого спринта заказчик остался недоволен. Оплачивается первый спринт, закрываются работы по нему, и заказчик может разорвать с нами отношения, подыскать другую проектную команду либо продолжить работать с нами, но по другой технологии.
• Снижение стоимости за счет отсутствия проектной документации. Проектная технология обязательно подразумевает наличие документов, которые требуют трудозатрат исполнителя (проектная документация). Agile может существовать без проектной документации, риски у исполнителя снижаются за счет того, что мы раз в месяц показываем готовый продукт.
• Прозрачность для спонсора проекта. Перед началом проекта мы backlog, который даёт прозрачное представление о стоимости работ.
• Еще один из плюсов – это безболезненные изменения в ходе проекта. Работы запланированные на следующий спринт не изменяются. Но Заказчик моет управлять backlog`ом.