Одной из важнейших подпрактик практики управления жизненным циклом является управление конфигурацией. Напомним, что конфигурация – это текущее актуальное состояние системы (воплощения системы: всех частей на всех системных уровнях) и её описаний в их соответствии. А управление конфигурацией – это отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Сама же конфигурация может быть описана (defined) и документирована (described). Документация системы всегда является документацией каких-то конфигурационных единиц данной системы. Проанализировал несколько проектов, которые ведутся в подразделении и обнаружил, что описание системы, изложенное в ее документации, отличается от реального функционала системы. И если процесс разработки частей системы, их перенос между средами более-менее выстроен, то про документацию в этом процессе часто забывают.
Зачем необходима документация? Каковы возможные причины того, что часто появляются расхождения между воплощением системы и ее документацией? Сразу оговорюсь, что мы не рассматриваем случаи, когда нужно подготовить какой-то набор документов для отчетности, аудита, «чтоб было». Это есть, с этим надо жить. Мы говорим про ситуации, когда действительно подразумевается, что документация необходима именно для работы с системой.
Цель документации – это передача знаний. Между членами проектной команды, между Заказчиком и Исполнителем. Основными «потребителями» документации системы являются пользователи системы и сотрудники, отвечающие за ее эксплуатацию. Также ими являются члены команды разработчиков, включая программистов, инженеров по требованиям, тестировщиков итд.
Например, если не вести архитектурную документацию, то на вопрос, как устроена конкретная система, через какое-то время документированного ответа не будет. А еще через какое-то время, после естественной ротации персонала, никто не сможет это сказать и на словах - и система превратится в нечто, рядом с чем боятся даже дышать. Эксплуатационная документация (руководство пользователя и администратора), является обязательством пользователю со стороны системы - какие функции и как должны работать. Если в документации написано одно, а в системе делается совсем другое, пользователь может инициировать заведение инцидента, поскольку для него именно этот документ первичен. Ситуация аналогична ценнику в магазине, который имеет приоритет перед ценой, которую «пробивают на кассе».
Создание документации – это большой труд. Им в ходе проекта занимаются практически все участники проектной команды. Однако часто бывает, что результат этого труда оказывается с весьма скромным. Да, отсутствие документации понимается как недостаток, однако, когда она появляется, оказывается, что поддерживать ее в актуальном состоянии затратно, найти в ней нужную информацию непросто.
Считаю, что основной причиной, по которой про документацию часто забывают, является то, что ей не пользуются. Чтобы труд по созданию документации не пропал даром, она должна использоваться. Чем больше у документации читателей, и чем чаще они обращаются к ней, тем более они будут требовательны к автору, тем выше будет качество документов. Никому не нужный документ – некачественный документ. Чтобы повысить качество документации, необходимо сделать так, чтобы она начала активно использоваться.
Наблюдая, за взаимодействием членов проектных команд, взаимодействие с Заказчиком, вижу, что участники процесса при возникновении конкретных вопросов, предпочитают не обращаться к документации, а найти знающего человека и спросить у него. На мой взгляд, это происходит не сколько из-за лени участников процесса или «невыстроенности» самого взаимодействия, а потому, что та документация, что разрабатывается, крайне неудобна в использовании. Например, уже сейчас документация Word устарела, она не позволяет отразить связанный во едино характер информации, обеспечить эффективную навигацию по ссылкам и поиск документов.
Для того, чтобы документацией захотели пользоваться, надо правильно подойти к ее формату и содержанию. При этом, когда мы говорим о формате, то имеется ввиду не только размеры, отступы и шрифты, но и интерактивность документов, возможность совместного редактирования, возможность гибкой организации ссылок внутри документа и между документами с соответствующей навигацией. Например, для этих целей хорошо подходит формат Wiki, в котором в любой момент чтения можно перейти к редактированию документа, а сразу после сохранения новая версия становится доступной для других пользователей. Пользователям документации не требуется отправлять документы по почте, проверять версии документа, и даже использовать режим рецензирования, поскольку wiki-формат позволяет отслеживать измененные фрагменты в документе и их авторство.