Business Cases
Iuliia Maianska's Blog | Leadership Consultant
    Share
Project Management

Бизнес-кейс 8. Проектная документация: “Да” или “Нет”?

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

В наше время Ajile методологии и фреймворков – многие слишком буквально воспринимают тезис : «частые поставки продукта важнее проектной документации», и поэтому не тратят своё драгоценное время на описание рабочих процессов, основных требований и проблемных вопросов, не составляют технические заметки и не делятся своими наработками/знаниями/опытом… 

В моей практике встречались такие компании, у которых на все вопросы можно было найти ответы (это большие корпорации и компании со штатом сотрудников от 150 до нескольких тысяч), а также компании, где всё держится на трёх китах (это стартапы, компании малого и среднего бизнеса от 20 до 150 сотрудников в штате). Но куда не посмотри, все рано или поздно приходят к выводу, что знания нужно оставлять на бумаге или в облаке. Кажется, что на написание документации требуется очень много времени, но в перспективе это экономит время на изучение проекта новоприбывших сотрудников, не занимает время опытных специалистов на введение в курс дела новичков, позволяет оценить объём работ, автоматизировать процессы и т.д. Главная причина в составлении документации для любого бизнеса – это выявить слабое звено в процессе и начать работать с ним, чтобы в конце концов запустить все механизмы машины…

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

Я в своей практике использую принцим “минимализма” для документации:

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

Программ и ресурсов для поддержания документации в надлежащем виде очень много. Основные: Microsoft Office, Google Services, Dropbox, iCloud, Confluence, Slack и другие.

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

Пожелания по тематике будущих статей принимаются на электронный адрес request@business-cases.info.

2 Comments

  • Своевременно мониторить и актуализировать текущую документацию можно несколькими способами: 1) непосредственно после реализации фичи, после чего обновлять DoD (Definition of Done) файл или инструкции, без каких невозможно будет выполнить реализацию следующей задачи; 2) раз в период (например, раз в месяц) обновлять документацию по проекту глобально (что-то не актуальное архивировать или удалять, обновлять сроки и изменять приоритетность фич в следствии маркетинговых исследований или полученной статистики…). В первом случае обновляется документация на больших проектах и это делает тот, кто выполнил задачу (разработчик/дизайнер и т.д.), но менеджер контролирует выполнение этого этапа. Во втором случае все изменения выполняет проектный менеджер, некоторые части можно делегировать аналитику.

  • Спасибо за статью! Поделитесь, пожалуйста, вашим опытом, каким образом можно своевременно мониторить актуальность и корректность имеющейся документации по проекту? Кто должен отвечать за это, как приоритизировать задачи по обновлению инструкций и прочих материалов?