Документирование в ИТ-проектах: своими силами или нанять стороннего исполнителя?
Если вы хотите использовать эти знания в текущем периоде и в последующей работе, необходимо все документировать. Своими силами или отдать документацию на аутсорсинг? Рассмотрим подробнее.
Проблематика документирования — в недостатке информации
Если изначально в проекте документирование велось недостаточно хорошо, с расширением штата ситуация только усугубляется. И приходит время, когда новые участники команды не могут полностью погрузиться в проект, поскольку им не хватает информации. Как результат, только отдельные сотрудники понимают каждый этап проекта (зачастую те, кто стоял у его основ).
Чтобы это исправить, нужно частями у сотрудников собрать информацию, понять историю всех этапов и начинать описывать работу проекта.
Однако на практике это происходит довольно непросто. И поскольку документирование в проекте с самого начала в надлежащем виде не велось, нередко бывает, что собрать всю информацию в полном виде уже невозможно.
Понимая проблематику, руководитель IT-проекта задумывается о том, чтобы не тратить внутренние ресурсы, а передать этот участок работы стороннему исполнителю. Прежде чем говорить, о том, насколько такой вариант хорошо, давайте разберемся, какая бывает документация в проекте.
Виды документации
При разработке ПЗ документация объясняет функциональность продукта, унифицирует информацию и становится основой для обсуждения важных моментов с заказчиком.
Поход к разработке ПЗ напрямую влияет на тип документации и ее объем. Например, Agile основан на коллективной работе, тесном сотрудничестве с клиентами и заинтересованными сторонами, гибкости и способности быстро реагировать на изменения. И на начальном этапе данный метод не требует всесторонней документации.
В данном случае ее можно разделить на две основные категории. Первая — Product documentation (документация по продукту) — описывает продукт и содержит инструкции по выполнению различных задач с ним. Другими словами, речь идет о требованиях, технических характеристиках, логике и мануалах. Основные типы Product documentation:
• System documentation — описывают саму систему и ее части (Requirement documents, Design decisions, Architecture descriptions, Program Source code, Testing documents).
• User documentation — инструкции, зачастую предназначенная для конечных пользователей продукта и команды поддержки (Tutorials, User guides, Troubleshooting manuals, Installation, Reference manuals).
Вторая категория документов — Process documentation (документация процесса) — описывает процесс. Сюда могут входить Standards, Project plans, Test schedules, Reports, Meeting notes и т. д.
Чтобы сформировать документацию, которая будет помогать вашей команде во всех проектах, стоит описывать следующие разделы:
• roles and responsibilities (роли и обязанности);
• team goals and business objective (цели команды и бизнес-цели);
• background and strategic fit (предыстория и стратегия);
• assumptions (предложения);
• user stories (пользовательские истории);
• acceptance criteria (критерии принятия);
• user interaction and design (взаимодействие пользователей и дизайн);
• questions (вопросы);
• not doing (не делать).
Аутсорсинг в документировании
Получение качественной услуги от сторонней компании не определяется только подписанием соответствующего договора. В IT-проекте важны все детали и, если пропустить хотя бы одну, это может привести к существенным проблемам. Следовательно, сторонняя компания, выполняющая документирование, должна глубоко вникнуть в особенности проекта, а так происходит далеко не всегда. Здесь и кроется главный недостаток аутсорсинга.
IT-проекты, которые приглашают сторонние ресурсы для тестирования, разработки или документирования, нередко сосредоточены на удешевлении таких услуг. Однако опыт показывает, что на подобных этапах экономить точно не стоит.
Качество выполнения документирования подрядчиком определяет не количество задействованных людей, а наличие опыта работы в подобных проектах, подход к организации процесса, взаимозаменяемость сотрудников и отлаженная система менеджмента.
Выбирая стороннюю организацию, в данном случае важно понимать, что создание документации столь же ресурсно-затратный процесс, как разработка или тестирование.
В то же время, назначить в IT-проекте одного человека, который самостоятельно полностью его опишет, не получится. Этим должна заниматься вся команда под тщательным контролем.
Итак, мы убедились в необходимости документировать работу IT-команды и рассмотрели возможность привлечь для этого подрядчика. Недостаток такого варианта заключается в риске не получить желаемый результат. А своими силами документировать не всегда выходит по организационным причинам. Что же делать? Вариантов несколько. Первый — выделить своего сотрудника, который хорошо знает все процессы, и обязать его контролировать документирование на всех этапах и всеми участниками команды.
Второй вариант — не думать об экономии, а все же отдать документирование на аутсорсинг, выбрав исполнителя, чей опыт и практика являются гарантией качественного предоставления услуги.
