Как писать документацию к проекту

Как создать идеальную внутреннюю документацию

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

А теперь представьте, что он решил уволиться.

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

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

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

Что такое внутренняя документация?

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

Она отличается от внешней документации, которую (как это ясно по названию) используют люди за пределами вашей организации, — например, от инструкций для покупателей.

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

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

Типы внутренней документации

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

Разумеется, это не единственный возможный вид внутренней документации. Другие распространенные типы перечислены ниже.

Документация команды. Информация, связанная с работой, которую выполняет команда. Это могут быть цели, планы проектов, график работы команды, отчеты о состоянии, протоколы собраний и т. д.
Справочная документация. Задокументированные процессы относятся к этой более широкой категории. Справочная документация помогает сотрудникам получить знания по важным темам, процессам и корпоративным политикам (к примеру, как подать заявление на отгул).
Проектная документация. Документация такого типа относится к конкретному проекту. Она может включать в себя предложения, требования к продукту, рекомендации по дизайну, наброски, дорожные карты и прочее.

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

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

Для чего нужна документация

Слишком многие компании недооценивают роль внутренней документации (пока нормальное течение процессов не нарушит какой-нибудь кризис, оставив их у разбитого корыта). Согласно исследованию BPTrends, лишь 4 % компаний всегда документируют внутренние процессы. Еще 50 % признают, что занимаются этим вопросом от случая к случаю.

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

Выполняйте больше работы, не тратя время впустую

Допустим, вам требуется вместо коллеги выполнить рассылку клиентам информационного обзора за месяц. Быстро ли получится, если вы станете разбираться во всем самостоятельно? Или же будет гораздо быстрее, если перед вами окажется подробная инструкция со снимками экрана, поясняющими, как именно нужно извлечь и распространить информацию?

Второй вариант очевидно быстрее, да?

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

Поднимите адаптацию сотрудников на новый уровень

По данным компании Gallup, лишь 12 % сотрудников полностью согласны, что их организация успешно справляется с адаптацией новых кадров.

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

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

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

Запустите процесс обмена знаниями

Слишком часто ценная информация и опыт хранятся только в голове у отдельных участников команды, а значит, недоступны другим. В этом случае увольнение сотрудников становится серьезной проблемой — особенно с учетом результатов одного из исследований, где 42 % опрошенных признали, что выполнение их работы требует уникальных знаний.

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

Формирование процесса работы с внутренней документацией

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

1. Определите основные процессы

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

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

Ставя перед собой задачу задокументировать абсолютно все, вы явно завышаете планку и рискуете захлебнуться в работе. Поэтому лучше сразу определить критерии, что именно стоит документировать.

2. Создайте стандартный шаблон

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

Краткое описание, для чего существует данный процесс
Основные участники процесса
Что требуется для выполнения процесса (ПО, ресурсы и т. п.)

Эти поля послужат гарантией того, что у каждого читателя будет достаточно информации, чтобы легко выполнить описанное в документе.

БОНУСНЫЙ СОВЕТ.

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

3. Определите, где хранить описания процессов

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

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

4. Выделите время для наведения порядка

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

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

Прочтите это руководство, чтобы подробно разобраться, как организовать процесс ведения внутренней документации.

Чем может помочь ПО для создания внутренней документации

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

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

Похоже, что это хорошая штука? Мы тоже так думаем. Ознакомьтесь с Confluence и начните создавать внутреннюю документацию по единым схемам и без лишнего стресса.

Избавьте команду от лишних проблем и забот

Многие считают, что внутренняя документация — это излишняя формальность. Но представьте еще раз: что случится, если завтра решит уволиться ваш ключевой сотрудник? Сколько ценных знаний и важного опыта вы потеряете?

Если внедрить строгую практику создания документации, вы и ваша команда будете выходить из подобных непредвиденных обстоятельств с оптимизмом и уверенностью.

Как вести IT-документацию, чтобы удерживать порядок на проекте

Советует Technical Program Manager в Booking.com — Тарас Федорук.

В криминологии существует теория разбитых окон: «Если в здании разбито одно окно и его никто не замечает, то через какое-то время не останется ни одного целого окна». Согласно этому, если не поддерживать порядок, люди более охотно его нарушают и «забивают» на правила.

Во время разработки IT-проектов важно вести документацию и следить за тем, чтобы в ней был порядок. Именно на нее смотрят, чтобы сделать выводы относительно проекта. А еще это ваша защита на случай, если что-то пошло не по плану. Разобрались с Technical Program Manager в Booking.com Тарасом Федоруком, зачем в IT проектная документация и как ее вести, чтобы снизить риски в ходе разработки.

Тарас — президент украинского представительства PMI. Прошел более 10 профессиональных сертификаций, в частности PMP (Project Management Professional) и PSM ІІ (Professional Scrum Master ІІ). Получил награды «Лучший руководитель проектов в IT» по версии Ukrainian IT Awards в 2019 году и PMI Rising Leader в 2022.

*Скоро у Тараса стартует онлайн-курс в Laba «Проджект-менеджмент в IT».

Что такое проектная документация и зачем ее готовят

Задание на разработку начинается с идеи. Чтобы что-то создать, сначала это нужно представить. Чтобы не потерять мысли, лучше зафиксировать их в виде текста или графически. Фактически проектная документация — это процесс описания идеи от момента ее возникновения до выпуска результатов в релиз.

Позднее, в течение проекта, документация расширяется не только благодаря информации о продукте, а и о процессе. Другими словами, мы отвечаем на вопрос «Как?» — как коммуницировать, отчитываться, работать с качеством и т. д. Объем документации зависит исключительно от того, какую проектную информацию нужно сохранить и насколько легко ее потом можно получить.

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

Что дает проектная документация в IT:

Меньше обсуждений в командных чатах и поисков причин «почему так, а не иначе»
Более быстрое погружение в контекст
Более простое понимание и оценка объемов изменений
Более простое принятие управленческих решений (например, понимание того, какой сервис можно убрать и как это отразится на всей системе)
Возможность комплексно оценить IT-структуру и вовремя заметить ошибки или пробелы в архитектуре
Возможность комплексной оценки хода проекта: что из процессов эффективно, что — лишнее (и почему), что нужно улучшить

По моему опыту, 80–90% проектов реализуются без существенных проблем или вопросов со стороны клиента. Он даже может не требовать наличия технической документации (но это не значит, что ее не нужно вести).

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

Что может случиться, если не вести проектную документацию

Как-то я работал на проекте, где не было конкретных стандартов документации. Ее никто не требовал и не проверял, но я всегда готовлю документацию.

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

Команда провела исследование, после чего подготовила отчет, как именно реализует задачу и какой бюджет на это нужно выделить. При согласовании заказчик попросил добавить в IT-систему функционал, который мы не обсуждали на старте. Тогда мы оценили, во сколько это обойдется. Но у клиента не было столько времени и бюджета на дополнительные функции. Чтобы не тратить время зря, мы начали работать над функционалом, согласованным в контракте.

Через 5 недель клиент вернулся и расторг договор. В контракте была прописана компенсация на такой случай — заказчик не мог просто выйти из проекта. Но он задал прямой вопрос: «А чем вы занимались эти 5 недель? Как я могу быть уверен, что вы действительно работали над проектом?»

В таких ситуациях устав проекта, еженедельные отчеты, план фаз проекта и другие документы спасают команду от перспективы остаться «у разбитого корыта». У нас была необходимая проектная документация, поэтому клиент выплатил компенсацию за расторжение договора и не стал обращаться в суд (как обещал, пока мы не показали IT-документацию).

«Я хотел системно взглянуть на управление IT-проектами. Выбирал из 10 курсов и остановился на Laba»

Какие бывают виды документации на проекте

Всю документацию можно разделить на две категории:

System documentation — документы, которые описывают саму систему и ее части: Requirement documents, Design decisions, Architecture descriptions, Program Source code, Testing documents и т. д.
User documentation — инструкции, подготовленные преимущественно для конечных пользователей продукта и команды поддержки: Tutorials, User guides, Troubleshooting manuals, Installation и Reference manuals.

7 принципов создания проектной документации в IT

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

#1. Придерживайтесь однотипной структуры

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

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

#2. Пишите просто и понятно

Техническая документация может выглядеть по-разному: быть оформленной в Microsoft Word, в форме таблицы, дизайн-системы в Figma или дерева в Confluence.

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

#3. Используйте схемы и диаграммы

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

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

#5. Обеспечьте удобный доступ к документации

Я не сторонник того, когда вся проектная информация собирается в одном Excel-документе, где есть куча вкладок с расписанием, рисками, принципами коммуникации и т. д.

Разделение документов, а не оформление в одном, — это удобно. А еще поможет легко ограничить доступ к sensitive информации для определенных лиц, если возникнет такая потребность. К примеру, ваш Регистр Стейкхолдеров содержит подробные сведения о том, как вы планируете привлекать их к проекту. Тогда будет неловко, если коллеги начнут читать о ваших планах провести неформальную встречу или поздравить их с Днем рождения.

Также все документы должны просто и однотипно называться. Если это устав — его нужно оформить отдельно и дать соответствующее название, например:

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

#6. Развивайте культуру документирования в команде

Не обязательно все должен документировать один человек. Например, устав — это ответственность руководителя проекта. В то же время техническую документацию должны создавать архитекторы или Senior/Lead-разработчики, стандарты тестирования — QA Lead, User Guide — технические райтеры.

Поэтому важно объяснять важность ведения проектной документации в команде, учить людей, как это делать, и способствовать тому, чтобы они составляли свои артефакты.

#7. Закрывайте техдолг

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

Пишите документацию так, чтобы проект можно было легко и безболезненно передать другой команде.

Как формировать документацию в живом проекте?

Хотел бы обсудить сложившуюся ситуация и как то определится с планом действий в этом направлении. Так что буду признателен за ваши советы, ваш интеллект и ваш опыт.

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

Короче говоря — у нас есть проект Х который уже существует более 6 лет.
Он живой, на нем бегает около 200/300к пользователей и в нем идут постоянные доработки и развивается существующего функционал.

Есть большое желание проект Х переписать на новую архитектуру. Возможно даже улучшить или полностью переосмыслить/доработать ранее написаный функционал. Некоторые вещи уже были переписаны и даже живут как отдельные микросервисы.

Но существует проблема с документацией. Она как бы и есть, но проще сказать что её вовсе нет. По сколько в некоторых местах она просто устарела, а в других местах на каком то этапе перестала наполнятся. Можно сказать что ядро проекта хорошо документировано и поддерживается, но это только от общего функционала.
Собственно, хотел бы услышать от вам советы, или получить рекомендации работы в этом направлении, возможно какие то best practice ссылочки может.

Лично мои мысли, а возможно в дальнейшем и действия в этом направлении — планирую поверх процесса разработки наложить модель работы с документацией таким образом, что бы если команда сталкивается с написанием нового функционала или доработкой старого, она сперва должна разобрать написаный код или отразить его в документации. Думаю что стоит рассматривать должность technical writer, но я не представляю как его интегрировать в команду, знания по проекту ему можно передавать месяцами. К тому же, хотелось бы интегрировать такого человека более менее безболезненно в плане продуктивности всей команды.

Ваши мысли/мнения/опыт/best practice по этому поводу?

�� Подобається Сподобалось 0

До обраного В обраному 0

Схожі топіки

Чому деякі тест-сьюіти стають поганими, або Способи покращення тестової документації
Чи експортуєте ви тестову документацію на Git?
AsyncAPI для розподілених систем
Як перевіряти документацію за допомогою автоматичного засобу — лінтера Vale

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

21 коментар

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Полезны обзорные документы на основные _крупные_ компоненты, интерфейсы и их взаимодействие. Эти вещи редко меняются.

А всё остальное — смотреть в коде.

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

1) Статическая либо не меняется вовсе, либо выбрасывается и заменяется новой, с кодом в этом случае все примерно так же. Минусы очевидны: кто-то должен ее писать еще и понятной для всех, без противоречий и прочей фигни, ведь любая ошибка будет очень дорогой, из всех возможных вариантов того кот будет это делать подходит больше всего БА, который раньше был программистом, причем программистом лучше среднего, мне кажется это крайне редкая ситуация, которую достигнуть можно только волей случая, если будет заниматься кто-то другой, то скорее всего получится то, что сейчас у себя на проекте видит каждый: документация это таски в джире, получить какой-то практический толк с такой документации маловероятно. Приходим к тому что этот способ — это компромис между качеством документации и ценой

2) Динамическая документация должна быть написана/отредактирована, после того как код уже готов. Сразу видно что это всевозможные тесты, которые при определенных усилиях со стороны разработчиков будут документацией для всех (по факту bdd). Так же написание/редактирование документации понятным текстом в конфлюенсе, обычно программисты пишут так что ценность такой документации низкая и фактически сделана для галочки. Комментарии в коде, хоть они имеют очень много недостатков и мало кто может написать их правильно, а не прокапитанить, они все же могут быть хоть какой-то документацией, они всегда обязаны быть динамическими или вред от их устаревания может быть очень большим. Ну и автогенерируемая документация, из самых простых примеров это встроенные механизны, позволяющие генерировать на вебсервисе страничку с ее апи. Т.е. тут есть два способа: ручной труд и автоматизация. С ручным все понятно: переваливание ответственности на программиста, и рано или поздно провал с его стороны. С автоматизацией же все выглядит куда перспективней. Тестируемый код, юнит тесты, интеграционные тесты, системные тесты, нагрузочные тесты, секюрити тесты и многие другие могут дать хорошую гарантию того что то что было заложено изначально до сих пор работает как задумывалось. А чтобы получить больше инфы вроде той что генерируется по контрактам вебапи нужно очень тщательно продумывать как писать код. У меня такое получилось ровно один раз, потому что это был круд, я писал все один и ооп головного мозга, так что я рефлексией обошел всесь солюшен вдоль и поперек и из исполняемых команд уже не составило труда сгенерить документацию по значимым операциямю Но чем запущеней проект и чем больше в нем разных штук, тем сложнее это сделать

итого надо самое лучшее из двух подходов выбрать, а не как обычно бывает самое худшее

Описание и документирование IT-проектов – must-have для успешного бизнеса

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

Что ж, пришло время узнать правду – если вы хотите успешно вести проект и пользоваться всеми возможностями IT, без четких описаний и документирования не обойтись.

В противном случае вас ждет путаница, хаос и тщетные попытки найти ответы на вопросы: Как это работает? Почему это не работает? Что теперь делать?

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

Документирование нужно вам, если вы хотите:

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

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

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

Предпроектная

отчеты, концепции, техническое задание

Проектная

задачи, спецификации, стратегии

Рабочая

схемы инфраструктуры, описания конфигураций

Эксплуатационная

Административная

регламенты, должностные инструкции

Обучающая

учебные материалы для новых сотрудников

И что, теперь придется составлять всю эту документацию?!

Конечно, нет. Вы всегда можете привлечь к этой задаче специализированного подрядчика, например ITSource.

Как это работает у нас?

Оцениваем существующую документацию (если таковая имеется), определяем ее актуальность и уровень соответствия задачам бизнеса и производственным процессам.

Находим единый стандарт для документирования вашего проекта, предлагаем общую концепцию фиксации и документирования информации о работе IT-инфраструктуры.

Подбираем и внедряем программное обеспечение для документирования изменений, фиксации запросов на изменение (если оно оправдано спецификой инфраструктуры) и/или описываем схему внесения изменений в документацию и план оповещения участников IT-процеса.

Создаем модель IT-инфраструктуры и описываем все ее компоненты и особенности использования отдельными группами пользователей IT-инфраструктуры.

Объясняем, как и кому необходимо использовать каждый отдельный компонент IT-инфраструктуры. Что и когда предпринимать в случае возникновения проблем либо непредвиденных ситуаций.

Придумать хороший IT-проект – бесценно. А уже для его описания, внедрения и дальнейшей поддержки существуют специализированные компании.