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

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

Я в своей практике использую принцим “минимализма” для документации:
- не создаю никому не нужные стопки документов, файлов и ссылок, т.к. их может никто так и не прочитать;
- не храню документы в одном месте, поскольку существует:
- внутренняя информация компании, которая не относится к проекту (зачастую доступ открыт только сотрудникам компании);
- документация конкретного проекта (доступ открыт только членам команды проекта);
- личная документация, заметки, инструкции (доступ только у владельца документа);
- общедоступная документация (доступ можно предоставить, либо документ доступен всем).
Программ и ресурсов для поддержания документации в надлежащем виде очень много. Основные: Microsoft Office, Google Services, Dropbox, iCloud, Confluence, Slack и другие.
Для описания процессов предпочитаю создавать блок-схемы, структурировать требования в таблицы и писать самые основные инструкции со скриншотами.
Пожелания по тематике будущих статей принимаются на электронный адрес request@business-cases.info.