Документирование — отдельная статья доходов проекта

Введение

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

Оно суть головная боль и корм для корпоративной жабы компании-разработчика. С точки зрения «типового интегратора», это некий побочный процесс, результаты которого в основном нужны для закрытия официальных требований контрактов. Не будь требований – сколько можно было бы высвободить ресурсов! Да еще и не отвлекать от работы истинных кормильцев компании: продавцов, менеджеров и в некоторой степени программистов. Картина комплектование и организации работы «мощностей» по разработке документации – отдельная грустная песня, не для этой статьи.

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

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

Уважаемые сейлы, менеджеры продуктов и проектов – давайте активнее продвигать документацию. Давайте на ней зарабатывать!

Зачем заказчику документация?

Глобальный вопрос – зачем вообще заказчику нужна документация на конкретное решение? Не та «для галочки», которую с них спросит вышестоящее руководство, или которую требует нормативное регулирование отрасли. С ней все понятно, она просто нужна. Речь про документацию, которая реально применяется в дальнейшем и имеет прикладную ценность.

Универсального ответа на этот вопрос нет. В зависимости от обстоятельств, честный ответ будет варьироваться от «…й не нужна!» до «а как без нее?». Однако есть определенная зависимость. Чем продолжительнее предполагаемый период жизни и развития решения, тем важнее в нем роль документации.
Потому, что тем дольше понадобится:

Заказчику:

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

Исполнителю:

• Передавать компетенции по разработке решения (за 2 года сменится половина команды «в теме», дальше – больше).
• Передавать компетенции по обеспечению качества и сопровождению решения – тестировщики и персонал поддержки меняются еще быстрее.
• Актуализировать информационное обеспечение для менеджера продукта.

Если заказчик не справится, его ждут весьма ощутимые финансовые и временнЫе потери с перспективой разбираться, разрабатывать и внедрять решение заново. Если не справится исполнитель, то он просто перестанет быть исполнителем. Сразу или спустя некоторое время.

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

Другой довольно весомый аргумент, связанный со сроком службы решения – его стоимость в расчете за определенный период времени. Учитывая, что стоимость решения для заказчика «в год» составляет сумму всех расходов, деленную на количество лет, его штатная жаба должна быть кровно заинтересована, чтобы знаменатель в этой формуле был как можно больше. Одно дело, если система за 6 млн. проработает 2 года, и совсем другое, если хотя бы 3. Это целый миллион экономии каждый год.

Конечно, разработчики могут возразить «Ну и что? Мы просто наваяем через два года год еще одно решение за такие же деньги. Нам же лучше!». Но, во-первых, это не спортивно. А во-вторых, срабатывает ограниченное количество раз, после чего найти заказчика становится сложнее.

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

Что предложить Заказчику?

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

В большинстве случаев, включая проекты для коммерческих структур, при определении номенклатуры и содержания документации можно отталкиваться от связки ГОСТ 34.201-89 и РД 50-34.698-90. Не лишним будет также заранее поинтересоваться наличием у заказчика собственных ведомственных или корпоративных стандартов (или даже личными предпочтениями лица, принимающего решения).

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

Могу предложить следующие категории, которыми пользуюсь сам:

1. Предпроектная. В нее войдут документы, которые предшествуют проектированию решения. В том числе:

• отчеты об обследовании;
• концепции;
• технико-экономические обоснования;
• технические задания и т.п.

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

2. Проектная. Все, что относится к проектируемому (но пока еще не реализованному) решению. Проектных документов может быть довольно много (см. например, тот же ГОСТ 34.201-89) и от проекта к проекту акценты полезности и привлекательности тех или иных документов для потенциального заказчика могут смещаться, однако наиболее востребованными обычно являются документы, содержащие описание:

• задач, которые автоматизирует предлагаемое решение;
• технических подробностей о функционале и внутреннем устройстве решения;
• необходимых действий для того, чтобы проектируемое решение могло заработать «как положено» (стратегия миграции данных, план обучения персонала, аттестация рабочих мест и т.п.).

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

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

• схемы размещений технических средств на объекте автоматизации;
• схемы подключения питания и каналов связи;
• описания конфигурационных файлов;
• описание первичного наполнения справочников и баз данных;
• описание методов диагностики и т.п.

Бесценно, если заказчик планирует эксплуатировать и сопровождать решение своими силами (как минимум, частично).

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

5. Административно-регулирующая. Если решение предполагает вмешательство в оргструктуру заказчика (от изменения отдельных функций и переподчинения отдельных сотрудников, до изменений на уровне иерархии организации), то такие события в солидных конторах сопровождаются документально. И редко когда Заказчик горит желанием выполнить эту работу сам. Это веский повод предложить облегчить его и без того тяжкую ношу (и бюджет, разумеется). К документации этой категории можно отнести:

• административные регламенты оказания услуг или осуществления функций;
• регламенты функционирования подразделений;
• положения о структурных подразделениях;
• проекты приказов, которыми вводятся те или иные организационные изменения;
• должностные инструкции и т.п.

6. Обучающая. Я умышленно отделяю ее от эксплуатационной. Сюда предлагаю относить материалы, организованно подготавливающие персонал заказчика к выполнению своих задач при помощи нашего решения. Особо важное значение эти материалы имеют в условиях высокой текучести персонала (колл-центры, кассы розницы и т.п.). К обучающим можно отнести:

• программы обучения и контроля полученных «студентами» знаний;
• методические материалы;
• учебные курсы (в т.ч. аудио-видео).

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

Особо хочу остановиться на двух документах. «Вырвать» их из контекста. Это:

• Техническое задание, в котором в самом начале работ определяются рамки проекта и основные требования к решению.
• Программа и методика испытаний, подписывая которую, заказчик подтверждает, что предусмотренные в ней испытания полностью отвечают его ожиданиям от реализации требований ТЗ (вплоть до уровня целей и задач). Другими словами, он официально подтверждает, что предложенная на испытания система – именно то, чего он хотел.

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

Как предложить Заказчику?

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

1. Подготовить максимальную, оптимальную и минимальную комплектацию пакета документов, которую можно обоснованно предложить Заказчику в конкретной ситуации.
2. Грамотно и системно обосновать достоинства каждого из предлагаемых пакетов и каждого из входящих в него документов. Составить сравнительную таблицу.
3. Культурно оформить все это в разделе технико-коммерческого предложения.

Вместо заключения...

… поделюсь историей про номенклатуру документации и потребности заказчика.

Как-то довелось участвовать в разработке серьезного решения для весьма серьезного заказчика. Когда увидел требования, немного удивился: в них была прописана разработка порядка 35+ документов технорабочего проекта. То есть, практически весь 34-й ГОСТ.

На осторожный вопрос «Зачем вам все это богатство?» заказчик ответил примерно так: «Конкурирующий отдел из соседнего Управления только что принял систему, которую укомплектовали 20-ю документами. Мы не можем допустить, чтобы в глазах генерала наша разработка выглядела менее солидно!».

А вы говорите – «не продается!»