Глупые мысли об IT

Привет, народ!

Должен покаяться: я перестал писать в этот блог и виной этому Fallout 3 :) Чертова игра затягивает и я в этот месяц, пока играл, практически забросил заниматься другими делами. Но мои жена и дети вернулись из отпуска, я опять езжу на работу поездом, поэтому свободного времени для написания постов у меня будет больше :)
В этот раз я хотел бы поделиться с вами некоторыми мыслями о документации. Есть документация, которая представляет собой просто текст, написанный ради того, чтобы отчитаться о её наличие и “закрыть” этот пункт. Полезность таких документов крайне невелика и их можно спокойно исключить из дальнейшего рассмотрения. Но есть документация, которая представляет собой накопленные знания/информацию и в какой-то мере представляет культуру организации. Важность таких документов сложно недооценить, но есть три главные проблемы:

• Документацию мало кто хочет читать;
• Ее никто не хочет писать;
• В большинстве случаев непонятна полезность уже написанных документов.

Начнем с последнего пункта. Очень часто люди забывают, что документация должна быть применима каким-либо образом в реальной жизни. Если есть много документов, но непонятно, что с ними делать – грош цена всей этой информации. Документация должна быть написана так, чтобы поддерживать ключевые бизнес процессы и удовлетворять потребности в информации людей, участвующих в этих процессах и исполняющих различные роли. 
Простой пример: в моей компании есть четыре основных процесса: “продажа” (“pre-sales”), “инициация проекта”, “выполнение проекта” и “ежедневная поддержка” (“producation/business as usual”). Есть у нас портал, на котором опубликована масса технической информации (есть и неплохие документы). Но: разных людям нужна разная информация на разных этапах. В случае с “продажей” необходимо знать в общих чертах, что мы можем предложить клиенту, какая выгода от этого будет, сколько это будет приблизительно стоить и займет времени. В процессе инициации проекта надо понимать какие есть предварительные требования для внедрения какого-либо решения (инфраструктура, лицензии и т.п.). Во время внедрения – стандартные решения (“best practices”) для технического персонала и стандартный план проекта для менеджера проектов и т.д. Если опубликованные документы не могут моментально “кликнуть” в каком-либо месте, заявляя свою полезность – мало кто будет дотошно разбираться, как можно использовать тот или иной документ. Поэтому вся документация должна быть “привязана” к бизнес процессам, использовать стандартные шаблоны и т.п.
О первом и втором пункте. Все очень просто: люди по своей природе ленивы. Если их не заставлять, то 90% не будут делать “лишних телодвижений”. Для того, чтобы заставить работников писать/читать документацию, оценка эффективности того, как они это делают, должна быть частью ежеквартального/ежегодного пересмотра качества работы (KPIs, “performance review”) этих сотрудников. В таком случае у них будет личная заинтересованность в том, чтобы как можно полнее использовать документацию (т.е. накопленные знания) и самим ее писать (т.е. делиться своими знаниями).

Засим раскланиваюсь,
Рустам.