6.1.2.1 Основы управления документами

(6.1.2.1.P1)

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

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

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

Теперь взглянем на Статус-отчеты. Вы должны заранее определить правила их наименования. Если каждый участник команды проекта отправляет менеджеру еженедельный отчет, то очень скоро у менеджера накопятся сотни Статус-отчетов. Если формат имени документа "Дата/Имя/Статус-отчет", то отчеты будут сортироваться в хронологическом порядке. Если документы называются "Имя/Статус-отчет/Дата", то они будут отсортированы по сотрудникам. Возможно, менеджер решит просто удалять Статус-отчеты после рассмотрения и обобщения. Все эти вопросы также относятся к сфере управления документами.

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

Структурированные и неструктурированные данные

(6.1.2.1.P2)

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

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

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

Примеры структурированных и неструктурированных данных приведены в следующей таблице.

Основы управления документами

(6.1.2.1.P3)

Рассмотрим компоненты процесса управления документами. Приведенный ниже процесс можно модифицировать под особенности Вашего проекта и включить в План управления проектом, который Вы будете разрабатывать на шаге 1.0 Определи работу. Многие из компонентов процесса нужны для поддержки последовательности стадий, которые документ будет проходить в виде своего жизненного цикла, описанного в разделе Жизненный цикл документа.

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

• Определите, где хранить документы. Команда проекта должна иметь общее пространство или хранилище (репозиторий), где могли бы размещаться документы. Это могут быть полки, общие папки на сервере, программное средство управления документами и т.п. Менеджер проекта должен убедиться, что документы проекта не хранятся где попало, в зависимости от предпочтений каждого участника его команды. Если допустить такое положение дел, то команда будет испытывать регулярные трудности и тратить много времени в поисках необходимого документа, особенно, если он передавался из рук в руки.

• Определите типы управляемых документов. Команде проекта также необходимо опрелить, какие типы документов они будут организованно хранить в репозитории проекта. Возможно, Вы решите хранить все документы на любой стадии завершения, включая все черновики и заметки из рабочих областей участников команды. Но также приемлемо будет и разрешить команде хранить собственные рабочие материалы в индивидуальных хранилищах (папках или ящиках), помещая в репозиторий проекта только финальные либо утвержденные версии документов.

• Определите физическую и логическую структуру хранилища документов. Определившись с местом хранения и типами хранимых документов, Вам следует решить, какую структуру следует придать хранилищу. Удачно организованная структура облегчит поиск документов, а также сократит число недоразумений типа "не туда положил". Первым делом, следует составить логическое представление о том, как документы должны быть организованы. Нарисуйте черновую схему организации документов на листе бумаги и дайте команде ознакомиться. Когда разумные возражения будут исчерпаны, Вам останется только воплотить организацию документов в структуру папок, шкафов, каталогов на жестком диске или разделов в программном инструментарии. Главное требование к структуре - она должна быть простой и понятной при размещении и поиске документов. Один из возможных вариантов такой структуры предложен в разделе 6.1.2.4 Типовая структура хранилища документов.

• Определите стандартный порядок именования документов. Даже удобная структура хранилища не избавит Вас от трудностей при поиске документов, если они будут именоваться произвольным образом. Два примера правил именования статус - отчетов приведены выше. Аналогичным образом следует стандартизировать правила именования и других типов документов. Хотя такое упражнение многим покажется скучным, примененное к сотням и тысячам документов, оно поможет Вашему проекту сэкономить невероятное количество трудозатрат за счет быстрого и надежного поиска необходимой информации.

• Определите, какие документы подлежат версионированию. Далее Вам надлежит решить, какие документы нуждаются в сохранении всего ряда последовательных редакций, а какие могут понадобиться только в последней версии. Многие важные документы (например, Устав проекта) должны храниться во всех утвержденных версиях с самого начала проекта. Для таких документов в правило наименования должен быть включен номер версии. Например, две последовательные версии Устава могут именоваться "Проект_АБВ_Устав_вер_1" и "Проект_АБВ_Устав_вер_2". При необходимости, люди легко отличат одну версию от другой. Другого рода документы (например, Реестр неотложных вопросов) не требуют версионирования, поскольку ведутся "нарастающим итогом". Для надежности в схему именования таких документов можно добавить дату. Например: "Проект_АБВ_Реестр_НВ_01_01_2008".

• Определите, будете ли Вы (и как) отслеживать статус утверждения документа. В ряде случаев, особенно если у документов долгий путь утверждения, бывает важно знать текущее состояние утвердения документа. Например, читая документ, Вам важно будет знать, утвержден он или это только черновик. С одной стороны, такая задача решается соответствующей структурой папок в хранилище. Более надежным решением будет дополнить титульный лист и колонтитулы документа обозначением статуса, к примеру "Черновик", "В рассмотрении", "Утвержден". Очевидно также, что все документы будут храниться в папках, соответствующих статусу.

• Определите стандартные форматы документов. Согласитесь, что создавать и читать документы легче, если для них подготовлены единые шаблоны. Такие шаблоны помимо стандартного внешнего вида (шрифты, логотип проекта) могут включать и стандартные для различных типов документов разделы, и даже заготовки каких-то блоков текста (например, обращение, обратный адрес).

• Установите стандартные инструменты для работы с документами (опция). Обычно такой проблемы не существует, но в некоторых случаях участники команды проекта из одной организации (или же из одной страны) для работы с документами используют совсем иные инструменты, чем из другой. Например, Ваш поставщик не сможет читать документы, если он использует не самую последнюю версию Microsoft Office. А Ваши субподрядчики из Австралии станут присылать Вам документы, подготовленные в WordPerfect. Еще хуже могут дела обстоять с электронными таблицами. В любом случае, если у Вас большая рассредоточенная команда, стоит убедиться, что такой коллизии не случится.

Обновления на TenStep.com.ua

Рады сообщить Вам о запуске бесплатного теста по экзамену PMP. Бесплатный тест по экзамену PMP
Желаете проверить свою готовность пройти сертификационный экзамен PMP? Бесплатно запишитесь в нашу Академию, а затем ответьте на 20 пробных вопросов в формате экзамена PMP.

Интересные сайты по управлению проектми и не только.

Сcылка по управлению проектами - Smashing Magazine at www.smashingmagazine.com/2008/11/13/15-useful-project-management-tools/

Полезный сайт - Shop Goodwill at www.shopgoodwill.com

Videos and Webinars

Free - Watch the TenStep action video! at www.TenStep.com/impactmovie
Free - Implementing Project Management in Your Organization - Free Webinar www.tenstep.com/impactmovie/thankyou.html
December 10 - Project Estimating - $99 - Click here http://www.tenstep.com/EstimatingWebinar.html
December 17 - Project Risk Management - $99 - Click here http://www.tenstep.com/RiskWebinar.html