Проектная документация в IT — зачем и кому это нужно

Записывать можно все, что угодно, но нужно ли это? Если нужно, то когда, кому и почему?

Можно отметить два вида документации, которая наиболее важна для разработчика:

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

Кому это вообще нужно?

  • Вам самим — не будет лишним задокументировать новые бизнес-процессы, даже если «все всё знают» и в проекте задействовано всего несколько человек. Стоит этим заняться даже если проект закреплен за одним человеком — стоит помнить, что мы не роботы и иногда не можем вспомнить деталей событий полугодичной/годичной давности. По сути, вы делаете эту работу для себя из будущего.
  • Новым сотрудникам — польза подобных материалов для новичков очевидна, но не увлекайтесь и грамотно структурируйте, чтобы эти самые новички могли быстро и безболезненно найти необходимые сведения.
  • Всем — для экономии времени. Сделайте информацию максимально доступной всем сотрудникам, прежде всего — проектной команде. Когда у человека появится вопрос, он не побежит отвлекать коллегу, а найдет соответствующий раздел и разберется самостоятельно. Тут впору еще раз обратить ваше внимание на необходимость разумно структурировать данные. Для команды будет гораздо полезнее схема, при которой если кто-то заболел/в отпуске/так далее, его можно подменить, исключив тем самым любой возможный ущерб.
  • Всем — для «условной заменимости». Если человек покидает проект, в котором отсутствовала документация, он уносит с собой интеллектуальную собственность компании. В этом случае можно надеяться только на то, что сотрудник ушел без драм и готов предоставлять краткие консультации при наличии желания и свободного времени. Когда компания наладила процесс отчуждения интеллектуальной собственности и знания стали общедоступными, каждый участник становится «условно заменимым». При этом нет никакой гарантии, что новый человек будет столь же ответственным — работодатели это понимают (или должны понимать). Поэтому «условной заменимости» стоит бояться только не квалифицированному сотруднику, а степенью осознания данных процессов можно мерить свой профессионализм.

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

Кто отвечает за документацию в IT-проекте?

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

Как поступить программисту?

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

Если над ней работают:

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

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

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

02.09.2018
284
Автор: Ася Яскер