|
Календарь мероприятий
ноябрь  2024
Пн |
Вт |
Ср |
Чт |
Пт |
Сб |
Вс |
| | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | |
показать все 
Новости партнеров
Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость
Читать далее
RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза
Читать далее
Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium
Читать далее
ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве
Читать далее
Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов
Читать далее
показать все
Статьи
Тандем технологий – драйвер инноваций.
Читать далее
ИИ: маршрут не построен, но уже проектируется
Читать далее
Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»
Читать далее
Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»
Читать далее
Технологический ИИ-арсенал
Читать далее
Взгляд в перспективу: что будет двигать отрасль информационной безопасности
Читать далее
5 способов повысить безопасность электронной подписи
Читать далее
Как искусственный интеллект изменит экономику
Читать далее
Неочевидный САПР: выход ПО за рамки конструкторской деятельности
Читать далее
Скоро некому будет делать сайты и заниматься версткой
Читать далее
показать все
|
Не меняйте проекты как перчатки. Часть 6. Как превратить документацию в базу знаний
Главная /
Архив номеров / 2015 / Выпуск №8 (51) / Не меняйте проекты как перчатки. Часть 6. Как превратить документацию в базу знаний
Рубрика:
Управление проектами
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
 Марина Аншина, председатель Комитета по стандартам, Российский Союз ИТ-директоров
Не меняйте проекты как перчатки.
Часть 6. Как превратить документацию в базу знаний
«Опять писанина», – подумаете вы. К счастью, именно современные ИТ предоставляют инструменты, заменяющие толстые тома инструкций и регламентов
Документальное сопровождение проектов ИТ
Только мазохисты любят читать регламенты, должностные инструкции, методики и прочие внутрикорпоративные документы. А проектная документация к тому же скоропортящийся продукт – успей прочитать, пока не устарела. При этом в ИТ-проектах такая документация обладает весьма пышными формами, почему и имеет хорошие шансы остаться невостребованной, несмотря на уловки, к которым прибегают проектные менеджеры.
Но без документации проект рискует вылиться в анархию, которая никогда еще ни к чему хорошему и полезному не приводила. Попытку разрешить это противоречие вы найдете в этой статье.
Словарь проекта
Любое дело, а тем более проект, стоит начинать со словаря. Задумавшись, а еще лучше – поэкспериментировав, вы удивитесь, насколько одни и те же слова люди зачастую понимают по-разному. В быту, если докопаться до сути, это одна из самых распространенных причин конфликтов. В деловых отношениях, частью которых является проектная деятельность, это приводит к тем печальным результатам проектов ИТ, о которых я писала в прошлых статьях. Эта беда, по крайней мере частично, решается созданием словаря проекта, ознакомлением с ним заинтересованных лиц и поддержанием его в актуальном состоянии.
Тут необходимо небольшое отступление. Давайте будем последовательны, начнем с себя и, раз уж заговорили о «документе», определимся, что мы будет понимать под этим термином, хотя бы в этой статье. Впрочем, вам никто не мешает взять одно из нижеприведенных определений и в словарь своего проекта.
Что же такое «документ»? В соответствии с федеральным законом №28-ФЗ 26.03.2008: «документ – материальный носитель с зафиксированной на нем в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания, который имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения».
Хочу обратить ваше внимание, что в этом определении документ вовсе не обязательно представляет собой текст, но обладает несомненной материальностью. Иначе ведь не добиться его «общественного использования и хранения».
На Википедии схожее определение:
«Материальный объект, содержащий информацию в зафиксированном виде и специально предназначенный для ее передачи во времени и пространстве».
Впрочем, добавляет, что в более узком смысле документ – «облеченный в письменную форму носитель информации, удостоверяющий наличие фактов определенного значения».
Для наших с вами целей существенно, что документ не обязан представлять собой текст, а может, например, иметь электронную форму.
Так что далее мы будем понимать его в широком смысле слова.
В определении из 28-ФЗ есть еще один важный момент – наличие у документа реквизитов, позволяющих его уникальным образом идентифицировать. Действительно, представьте, что заказчик использует последнюю версию словаря для определения, скажем, технического задания (например, из ИСО/МЭК 15289), а исполнитель – предыдущую (например, из ГОСТ 34). Они могут с пеной у рта доказывать друг другу, написал исполнитель ТЗ или что-то совсем другое.
| Девиз документирования проекта может быть таким: «Меньше бумаги, больше наглядности!» Давайте беречь наши леса! |
Есть еще один аспект документа, о котором в явном виде не говорит ни одно из вышеприведенных определений, а намекает, – определение из 28-ФЗ. Это один из показателей качества документа, а именно его свежесть. В каждый момент времени актуальна должна быть одна из версий документа. Остальные могут понадобиться для рабочих целей, например, чтобы проанализировать результаты проекта. Несвежий документ еще хуже осетрины второй свежести – может иметь губительные последствия для огромного количества людей.
Хотя, подозреваю, что образ документа у многих из нас ассоциируется с чем-то застывшим и неизменяемым.
Вернемся к словарю проекта. Выводы, которые мы можем сделать из определений документа, заключаются в том, что словарь не обязательно имеет письменную форму и должен постоянно обновляться. Электронные словари давно завоевали популярность удобством поиска, богатыми возможностями иллюстрации и поддержки версионности. Можно предусмотреть такую форму, когда участники проекта при использовании термина из словаря получают подсказку (звуковую или текстовую) со значением этого термина и могут еще раз проверить правильность его применения. ИТ предлагают огромные возможности работы с документами, которые пока что, к несчастью, используются очень ограниченно.
При этом не забудьте, что словарь проекта не должен вступать в противоречие ни с корпоративным словарем, ни со словарями других проектов организации. В случае расхождения определений один или оба словаря должны быть обновлены.
Итак, словарь проекта создан, определена процедура его изменения, поддержки и предоставления заинтересованным лицам, назначены ответственные за эти процедуры.
Устав проекта
Важнейшим документом проекта, определяющим его старт и указывающим на завершение, является Устав. На стадии определения проекта (статья №5 Жизненный цикл проектов ИТ) необходимо определить результат проекта и его ограничения. Проект, как любую систему (а проект – это, несомненно, система, так как состоит из отдельных взаимосвязанных частей и образует целостную сущность), можно описать, например, по модели Захмана, отвечая на вопросы: зачем, что, кто, как, когда и где будет происходить? Начинать стоит с вопроса «зачем», ответ на который в случае проектов ИТ зачастую вовсе не столь очевиден. Часто бизнес-заказчик проекта формулирует его так: «Чтобы было хорошо!» – интуитивно ощущая, что автоматизация в его деятельности может принести ощутимые плоды. Правда, с трудом представляет себе вкус, форму, цвет и размеры этих «плодов». Однако при известной ловкости ответ на этот вопрос все же можно получить.
Важнейший вопрос, «Быть или не быть», ИТ-проектов заключается в том, чтобы определить, что именно предстоит сделать. Бизнес-заказчик с трудом может это себе представить, а тем более сформулировать, а еще менее вероятно – сформулировать в понятных исполнителю терминах. Однако, не договорившись и не зафиксировав в Уставе проекта, что именно будем делать, двигаться дальше нельзя. Проблема в том, что в начале проекта его команда еще не сформирована, и взять на себя ответственность за выявление потребностей заказчика просто некому. Организации выходят из этой ситуации по-разному: назначая РП еще до официального открытия проекта, выделяя специальную роль для формализации требований или вписывая в Устав расплывчатые фразы, доопределяя проект в дальнейших документах, например, в Паспорте проекта.
В общем виде Устав проекта может состоять из следующих разделов:
- Цели и задачи проекта.
- Основные принципы реализации проекта.
- Окружающая среда проекта, включая ограничения и допущения, принятые в проекте, и смежные проекты.
- Критические факторы успеха проекта.
- Показатели, определяющие качество проекта.
- Риски проекта.
- Организационная структура проекта на уровне функциональных ролей.
- Методы коммуникаций в проекте.
- Документация проекта: ее создание, хранение, доступ к ней, включая вопросы, связанные с информационной безопасностью.
Однако в некоторых случаях вполне допустимо обойтись первыми двумя-тремя пунктами. Чтобы правильно определить состав Устава проекта, надо уяснить, что этот документ должен содержать информацию, необходимую и достаточную для открытия проекта, и обычно является приложением к соответствующему приказу или распоряжению. Устав проекта обычно не подлежит изменениям.
Паспорт проекта
Другим важнейшим документом проекта в отличие от Устава, сопровождающим его на всем жизненном цикле, является его паспорт. Паспорт проекта представляет собой документ, однозначно идентифицирующий проект в глазах заинтересованных лиц. Состав Паспорта проекта может быть таким:
- История возникновения проекта.
- Цели проекта.
- Границы проекта.
- Этапы и ключевые вехи проекта.
- Содержание результатов проекта по этапам.
- Организационная структура проекта.
- Бюджет проекта.
- Процедура внесения изменений.
Как в паспорте человека можно менять прописку, вносить информацию о детях и т.д., так и в Паспорт проекта в отличие от Устава могут вноситься изменения. И процедура внесения этих изменений должна быть определена, согласована и предоставлена для общего использования.
Паспорт проекта должен давать возможность легко найти проект среди других по любому важному критерию, проследить его историю и оценить результаты. В некоторых случаях Устав проекта играет роль Паспорта, иногда – наоборот. В целом разница между этими документами представлена в таблице 1.
Таблица 1. Разница между Уставом и Паспортом проекта
| |
Устав проекта |
Паспорт проекта |
| Владелец документа |
Бизнес-заказчик или специально выделенное лицо (например, бизнес-аналитик) |
Руководитель проекта |
| Изменчивость |
Стабилен |
Подвержен изменениям |
| Область использования |
Открытие проекта |
В течение жизненного цикла проекта и некоторый срок после его завершения (определяется правилами организации) |
| Назначение |
Принятие решения об открытии проекта |
Получение информации о текущем состоянии проекта и истории изменений |
План проекта
Любой проект реализуется в соответствии с некоторым планом. Проекты ИТ, например, проекты внедрения корпоративных систем, в которых обычно происходит сложная декомпозиция работ и присутствуют критические пути, требуют тщательного планирования. Выбор формы плана зависит от масштабов проекта, проектной зрелости заинтересованных лиц, корпоративных правил и привычек. Важно только поддерживать план проекта в актуальном состоянии и нащупать баланс между уровнем детализации и наглядностью плана. Возможно, для достижения такого баланса понадобится не один план, а группа связанных между собой планов. Чаще всего принято делать план проекта в форме диаграммы Ганта, пример которой для проекта разработки ПО представлен на рис. 1. Однако план проекта может быть приведен в форме таблицы Excel,особенно для относительно несложных проектов.
Рисунок 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.
Формы документации
Мы с вами договорились, что в этой статье документ понимается в широком смысле слова, то есть он имеет полное право принимать любые удобные формы. Например, Паспорт проекта может представлять собой набор ссылок на таблицы, графики и даже рисунки. А описание коммуникаций проекта вполне может быть выполнено средствами инфографики. Для каких-то документов, например, по обучению, можно использовать формат видео или звукозапись.
Девиз документирования проекта может быть таким: «Меньше бумаги, больше наглядности!» Давайте беречь наши леса! В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
Вакансии на сайте Jooble
|
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
