Не меняйте проекты как перчатки. Часть 6. Как превратить документацию в базу знаний::БИТ 08.2015
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
май    2019
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
25
26

показать все 

Новости партнеров

23.05.2019

PHDays: точно в девятку

Читать далее 

23.05.2019

НОРБИТ примет участие в TAdviser SummIT 2019

Читать далее 

23.05.2019

Итоги первого дня ЦИПР-2019

Читать далее 

23.05.2019

В этот четверг, 23 мая, в Москве пройдет V Международная конференция о подключенных автомобилях

Читать далее 

показать все 

Статьи

23.04.2019

Компании перед лицом меняющегося мира

Читать далее 

23.04.2019

Как защитить интеллектуальную собственность?

Читать далее 

23.04.2019

Зачем компьютеру этика?

Читать далее 

23.04.2019

Клиенты в интернете. Опрос

Читать далее 

23.04.2019

Кто будет править миром? Опрос

Читать далее 

22.03.2019

5 вопросов о «цифре»

Читать далее 

21.03.2019

Все под контролем

Читать далее 

12.03.2019

Тренды по UC

Читать далее 

21.04.2017

Язык цифр или внутренний голос?

Читать далее 

16.04.2017

Планы – ничто, планирование – все. Только 22% компаний довольны своими инструментами для бизнес-планирования

Читать далее 

показать все 

Не меняйте проекты как перчатки. Часть 6. Как превратить документацию в базу знаний

Главная / Архив номеров / 2015 / Выпуск №8 (51) / Не меняйте проекты как перчатки. Часть 6. Как превратить документацию в базу знаний

Рубрика: Управление проектами


 Марина Аншинапредседатель Комитета по стандартам, Российский Союз ИТ-директоров

Не меняйте проекты как перчатки.
Часть 6. Как превратить документацию в базу знаний

«Опять писанина», – подумаете вы. К счастью, именно современные ИТ предоставляют инструменты, заменяющие толстые тома инструкций и регламентов

Документальное сопровождение проектов ИТ

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

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

Словарь проекта

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

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

Что же такое «документ»? В соответствии с федеральным законом №28-ФЗ 26.03.2008: «документ – материальный носитель с зафиксированной на нем в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания, который имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения».

Хочу обратить ваше внимание, что в этом определении документ вовсе не обязательно представляет собой текст, но обладает несомненной материальностью. Иначе ведь не добиться его «общественного использования и хранения».

На Википедии схожее определение:

«Материальный объект, содержащий информацию в зафиксированном виде и специально предназначенный для ее передачи во времени и пространстве».

Впрочем, добавляет, что в более узком смысле документ – «облеченный в письменную форму носитель информации, удостоверяющий наличие фактов определенного значения».

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

Так что далее мы будем понимать его в широком смысле слова.

В определении из 28-ФЗ есть еще один важный момент – наличие у документа реквизитов, позволяющих его уникальным образом идентифицировать. Действительно, представьте, что заказчик использует последнюю версию словаря для определения, скажем, технического задания (например, из ИСО/МЭК 15289), а исполнитель – предыдущую (например, из ГОСТ 34). Они могут с пеной у рта доказывать друг другу, написал исполнитель ТЗ или что-то совсем другое.

Девиз документирования проекта может быть таким: «Меньше бумаги, больше наглядности!» Давайте беречь наши леса!

Есть еще один аспект документа, о котором в явном виде не говорит ни одно из вышеприведенных определений, а намекает, – определение из 28-ФЗ. Это один из показателей качества документа, а именно его свежесть. В каждый момент времени актуальна должна быть одна из версий документа. Остальные могут понадобиться для рабочих целей, например, чтобы проанализировать результаты проекта. Несвежий документ еще хуже осетрины второй свежести – может иметь губительные последствия для огромного количества людей.

Хотя, подозреваю, что образ документа у многих из нас ассоциируется с чем-то застывшим и неизменяемым.

Вернемся к словарю проекта. Выводы, которые мы можем сделать из определений документа, заключаются в том, что словарь не обязательно имеет письменную форму и должен постоянно обновляться. Электронные словари давно завоевали популярность удобством поиска, богатыми возможностями иллюстрации и поддержки версионности. Можно предусмотреть такую форму, когда участники проекта при использовании термина из словаря получают подсказку (звуковую или текстовую) со значением этого термина и могут еще раз проверить правильность его применения. ИТ предлагают огромные возможности работы с документами, которые пока что, к несчастью, используются очень ограниченно.

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

Итак, словарь проекта создан, определена процедура его изменения, поддержки и предоставления заинтересованным лицам, назначены ответственные за эти процедуры.

Устав проекта

Важнейшим документом проекта, определяющим его старт и указывающим на завершение, является Устав. На стадии определения проекта (статья №5 Жизненный цикл проектов ИТ) необходимо определить результат проекта и его ограничения. Проект, как любую систему (а проект – это, несомненно, система, так как состоит из отдельных взаимосвязанных частей и образует целостную сущность), можно описать, например, по модели Захмана, отвечая на вопросы: зачем, что, кто, как, когда и где будет происходить? Начинать стоит с вопроса «зачем», ответ на который в случае проектов ИТ зачастую вовсе не столь очевиден. Часто бизнес-заказчик проекта формулирует его так: «Чтобы было хорошо!» – интуитивно ощущая, что автоматизация в его деятельности может принести ощутимые плоды. Правда, с трудом представляет себе вкус, форму, цвет и размеры этих «плодов». Однако при известной ловкости ответ на этот вопрос все же можно получить.

Важнейший вопрос, «Быть или не быть», ИТ-проектов заключается в том, чтобы определить, что именно предстоит сделать. Бизнес-заказчик с трудом может это себе представить, а тем более сформулировать, а еще менее вероятно – сформулировать в понятных исполнителю терминах. Однако, не договорившись и не зафиксировав в Уставе проекта, что именно будем делать, двигаться дальше нельзя. Проблема в том, что в начале проекта его команда еще не сформирована, и взять на себя ответственность за выявление потребностей заказчика просто некому. Организации выходят из этой ситуации по-разному: назначая РП еще до официального открытия проекта, выделяя специальную роль для формализации требований или вписывая в Устав расплывчатые фразы, доопределяя проект в дальнейших документах, например, в Паспорте проекта.

В общем виде Устав проекта может состоять из следующих разделов:

  • Цели и задачи проекта.
  • Основные принципы реализации проекта.
  • Окружающая среда проекта, включая ограничения и допущения, принятые в проекте, и смежные проекты.
  • Критические факторы успеха проекта.
  • Показатели, определяющие качество проекта.
  • Риски проекта.
  • Организационная структура проекта на уровне функциональных ролей.
  • Методы коммуникаций в проекте.
  • Документация проекта: ее создание, хранение, доступ к ней, включая вопросы, связанные с информационной безопасностью.

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

Паспорт проекта

Другим важнейшим документом проекта в отличие от Устава, сопровождающим его на всем жизненном цикле, является его паспорт. Паспорт проекта представляет собой документ, однозначно идентифицирующий проект в глазах заинтересованных лиц. Состав Паспорта проекта может быть таким:

  • История возникновения проекта.
  • Цели проекта.
  • Границы проекта.
  • Этапы и ключевые вехи проекта.
  • Содержание результатов проекта по этапам.
  • Организационная структура проекта.
  • Бюджет проекта.
  • Процедура внесения изменений.

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

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

Таблица 1. Разница между Уставом и Паспортом проекта 

  Устав проекта Паспорт проекта
Владелец документа Бизнес-заказчик или специально выделенное лицо (например, бизнес-аналитик) Руководитель проекта
Изменчивость Стабилен Подвержен изменениям
Область использования Открытие проекта В течение жизненного цикла проекта и некоторый срок после его завершения (определяется правилами организации)
Назначение Принятие решения об открытии проекта Получение информации о текущем состоянии проекта и истории изменений

План проекта

Любой проект реализуется в соответствии с некоторым планом. Проекты ИТ, например, проекты внедрения корпоративных систем, в которых обычно происходит сложная декомпозиция работ и присутствуют критические пути, требуют тщательного планирования. Выбор формы плана зависит от масштабов проекта, проектной зрелости заинтересованных лиц, корпоративных правил и привычек. Важно только поддерживать план проекта в актуальном состоянии и нащупать баланс между уровнем детализации и наглядностью плана. Возможно, для достижения такого баланса понадобится не один план, а группа связанных между собой планов. Чаще всего принято делать план проекта в форме диаграммы Ганта, пример которой для проекта разработки ПО представлен на рис. 1. Однако план проекта может быть приведен в форме таблицы Excel,особенно для относительно несложных проектов.

Рисунок 1. Пример плана проекта в диаграмме Ганта

Рисунок 1. Пример плана проекта в диаграмме Ганта

Документация проекта

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

Таблица 2. Список документов проекта внедрения ERP-системы

Наименование
документа
Описание Утверждающее лицо
1 Договор с внешним подрядчиком/поставщиком Проект договора предоставляется подрядчиком Куратор проекта
2 Презентация о старте проекта Описание целей, задач, рамок проекта и подхода к его выполнению для ключевых вовлеченных в проект руководителей и сотрудников Управляющий совет проекта
3 Устав проекта Описание целей и рамок проекта, организация проекта, стандарты и процедуры управления проектом, стандарты проектной документации, детальный план-график проекта (приложение №1 к Уставу) Управляющий совет проекта
4 Техническое задание Техническое задание на систему  
5 План управления
коммуникациями
Детальный план и бюджет коммуникаций и взаимодействия с заинтересованными сторонами. Включает список ключевых и конечных пользователей, контакты Руководитель проектного офиса
6 Описание настроек Документация по сделанным в системе настройкам Руководитель управления сопровождения и поддержки систем
7 Проектное решение по формированию ролей и полномочий Описание подхода к формированию ролей, системных функций (для систем SAP – транзакции), допуски по группировкам и т.д. Список пользователей и присвоенные им роли Управляющий совет проекта
8 Концепция обучения Разработка плана и концепция обучения. Цели, группы, порядок и объем обучения, требования к среде обучения. Подготовка списка обучаемых ключевых и конечных пользователей, контакты Управляющий совет проекта
9 Программа обучения Формирование перечня курсов, даты и места проведения, состав обучаемых ключевых и конечных пользователей, их контакты. Подготовка сводной таблицы по проведенному обучению Управляющий совет проекта
10 Инструкции пользователей Функции, транзакции, шаги, системные экраны и правила заполнения Руководитель управления сопровождения и поддержки систем
11 Концепция перехода в опытно-промышленную эксплуатацию (ОПЭ) Описание порядка и принципов проведения опытно-промышленных испытаний, а также роли каждого из участников Управляющий совет проекта
12 Концепция поддержки пользователей Описание структуры системы поддержки пользователей в течение первых трех месяцев после ввода в ПЭ, а также отличия поддержки пользователей системы от существующего регламента поддержки пользователей Управляющий совет проекта
13 Оценка готовности к изменениям Отчет об уровне информированности пользо-вателей и их лояльности к проекту
(в зависи-мости от проекта и в соответствии с Планом управления изменениями)
Руководитель проектного офиса
14 Протоколы обучения и акты допуска к работе с системой Курс, дата фактического проведения, состав участников, подписи участников. Дата проведения аттестации, Ф.И.О. допущенного и допускающего, подписи участников Экспертный совет проекта
15 Программа и методика испытаний Определение задач, инструментов и участников испытаний Руководитель управления функциональной настройки
16 Сценарии тестирования Варианты исполнения каждого бизнес-процесса, связанные в законченные циклы операций, план интеграционного теста, критерии приемки теста, тестовые данные Управляющий совет проекта
17 Протоколы ролевого интеграционного тестирования Сценарии тестирования, дополненные следующей информацией: даты фактического проведения, участники, выполненные шаги, полученные результаты, замечания Экспертный совет проекта
18 Протоколы миграции данных Принятые заказчиком сводные таблицы загруженных данных Экспертный совет проекта
19 Протоколы готовности к переводу в промышленную эксплуатацию (ПЭ) Подтверждения от ответственных лиц о готовности соответствующих подразделений начать промышленную эксплуатацию системы Управляющий совет проекта
20 Методика проведения и анализа результатов работы в ПЭ Определение этапов процесса, классификация причин замечаний, описание шагов по устранению замечаний, перечень участников процесса сверки и их функции Управляющий совет проекта
21 Руководство по администрированию системы Описание регламентных процедур по администрированию системы: регулярное резервное копирование, восстановление системы после сбоев, установка пакетов обновлений и нот, известные проблемы и их решение по результатам ОПЭ, мониторинг работоспособности и доступности системы, мониторинг основных показателей производительности системы, аудит действий пользователей Управляющий совет проекта
22 Регламент по сопровождению пользователей Описание регламентных процедур по сопровождению пользователей на этапе начального периода ПЭ Управляющий совет проекта
23 Коммуникации, связанные с запуском в ПЭ Информирование конечных пользователей о начале работы в новой системе; сообщение о дате ввода в ПЭ (в зависимости от проекта и в соответствии с Планом управления изменениями) Куратор проекта
24 Протокол УС с решением о готовности системы к ПЭ и завершении Фазы 2 проекта   Управляющий совет проекта
25 Приказ о вводе в ПЭ Приказ ГД организации о запуске системы в ПЭ Куратор проекта
26 Детальный план Этапа 5. Начальная поддержка промышленной эксплуатации и завершение проекта Детальный план-график работ по Этапу 5. Начальная поддержка промышленной эксплуатации и завершение проекта Управляющий совет проекта
27 Коммуникации в начале ПЭ Коммуникация о переходе на новую систему для широкой аудитории; благодарность членам рабочих групп, экспертных, управляющих, оперативных советов (в зависимости от проекта и в соответствии с Планом управления изменениями) Куратор проекта
28 Отчет о результатах работы в ПЭ Статистические данные и выводы о результатах работы в ПЭ, согласованные ответственными лицами. Перечень выявленных и исправленных ошибок, реализованных в системе доработок. Список оставшихся нереализованными доработок, который согласован с заказчиком. Список включает: статус реализации доработки, уровень критичности устранения нереализованной доработки, сроки осуществления доработки, лица, ответственные за реализацию доработок Управляющий совет проекта
29 Акт передачи системы в техническую поддержку Содержит: 1. Перечень переданных документов, необходимых для самостоятельного со-провождения системы Заказчиком в рамках ПЭ. 2. Утверждение о готовности функционала системы к ПЭ в соответствии с КП и ТЗ (на основе отчета о результатах работы в ПЭ) Руководитель управления сопровождения и поддержки систем

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

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

  • Хранить документацию в едином месте.
  • Предусмотреть систему ссылок, связывающих документы между собой.
  • Использовать удобную систему наименований, отслеживать версионность документов, обеспечить прозрачность текущей актуальной версии.
  • Обеспечить удобные средства поиска.
  • Все это можно реализовать достаточно простыми средствами (например, MS Office).

Существуют международные и отечественные стандарты управления отдельными типами проектной документации. В качестве примера можно привести Процесс менеджмента программной документации в ИСО/МЭК 12207-2010.

Формы документации

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

Девиз документирования проекта может быть таким: «Меньше бумаги, больше наглядности!» Давайте беречь наши леса!

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №03 (86) 2019г.
Выпуск №03 (86) 2019г. Выпуск №02 (85) 2019г. Выпуск №01 (84) 2019г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика