Документация в области информационных технологий является важным элементом, обеспечивающим эффективное функционирование как отдельных проектов, так и крупных систем. В мире, где технологии стремительно развиваются, а объём информации постоянно растёт, правильное оформление документации становится не просто необходимостью, а залогом успешного выполнения задач и реализации идей. Хотя бытует мнение, что можно обойтись и без ведения документации, тем более что никто не требует её обязательного наличия.
Вместе с экспертами в сфере IT разбирались, для чего именно нужна документация, какие функции она выполняет, какие её виды существуют, как она формируется, пишется и как же её эффективно использовать в работе.
Разработка IT-продукта может сопровождаться сменой проектных команд, потому что, как правило, это длительный процесс. При этом на адаптацию у новой команды может не быть времени или его не так много, а интеграция новых фич должна продолжаться непрерывно.
- Кроме того, одна и та же проектная команда может со временем начать по-другому смотреть на продукт, появляются разночтения в терминах предметной области и т. д. Проектная документация призвана решить эти проблемы. Да, разрабатывать документацию не требуется в рамках процесса разработки, однако многие тимлиды уделяют ей большое внимание, - отметил разработчик компании "Автоматика-сервис", старший преподаватель кафедры ПМиФИ ОмГТУ Михаил Гуненков.
Это часть процесса работы над проектом, который отнимает время спринта и, если действительно документация необходима, то на неё выделяют время и так далее.
- Ключевое здесь "если действительно необходимо". В краткосрочных проектах при проверке продуктовых гипотез для стартапов, а также на ранних этапах итеративной разработки скорее стоит концентрироваться на функциональности решения. Но тем не менее, как только появляются предпосылки для планомерного развития проекта, необходимо планировать работу над документацией, - подчеркнул Михаил Гуненков.
В целом эксперты отмечают, что в любом проекте есть документация, вопрос только, в каком она виде. Это и техническое задание, и документация IP, описание того, как, например, работает сервис, она может включать в себя технические спецификации, руководства пользователя, описания архитектуры и многое другое. Каждая из этих категорий играет свою уникальную роль и помогает командам разработчиков, тестировщиков, администраторов и пользователей эффективно взаимодействовать друг с другом.
- Никто не заставляет вести документацию, но она всё же требуется по ходу выполнения задач, потому что выполняет роль коммуникации между разными участниками процесса разработки и между разными командами. Например, кому-то пришла идея или продуктовый менеджер проверил какую-то гипотезу и пошёл дальше обсуждать уже с командой, насколько это реально сделать, какие сроки займёт и так далее. Всё это нужно фиксировать. Если передать просто на словах от одного человека к другому, то по дороге информация может потеряться и тогда нужно будет вновь обращаться к человеку, который изначально ею владеет. Если же её зафиксировать, то ни у кого не возникнет проблем в нужный момент ознакомиться с информацией по проекту, - отметила руководитель отдела разработки текстов в Ozon Tech Екатерина Ушакова.
Ещё документация нужна, чтобы все понимали цели, задачи, сроки выполнения и бюджет проекта.
- И здесь важен каждый из этих пунктов, потому что успешность проекта определяют именно эти три параметра. Соответственно, если всё это не описано, то заказчик может ожидать одно, команда иметь в виду другое, проектный менеджер - третье. И в итоге все всеми будут недовольны. Скорее всего, результат получится не тот, который был нужен, либо вся сделанная работа будет не актуальной. Чтобы этого избежать, и нужна документация, - подчеркнула руководитель IT-проектов Мария Панченко.
Какие виды документации существуют?
Документация может быть разной: глоссарий предметной области, диаграммы бизнес-процессов, таблицы функциональных и нефункциональных требований, записи о принятых архитектурных решениях (ADR), базы знаний в формате Wiki и так далее. Многое зависит от масштабов проекта или самой компании. Например, стартап легко сопроводить и минимальным пакетом документов, поскольку фокус направлен на гибкость и скорость.
- Здесь есть три основных документа: концепция проекта, чтобы понимали цели, задачи и как мы будем измерять результат; план проекта, чтобы мы понимали сроки; и требования - функциональные и технические, которые помогут, собственно, сделать проект в том объёме, который необходим, - уточнила Мария Панченко.
- Хотелось бы ещё остановиться на журнале рисков, здесь может быть журнал, документ. Допустим, я делаю всегда в Excel-документе, независимо от того, где я работаю, в стартапе или в корпорации. Это такая табличка, где каждый риск оценен по источнику возникновения, по возможности вероятности реализации, по серьёзности воздействия. Соответственно, в связи с этой оценкой вырабатывается план: что с этим риском делать, делать ли вообще или можно проигнорировать, - подчеркнула Мария Панченко.
В корпорации документооборот значитильно больше, а сами документы более детализированные. Здесь во главе угла контроль и зарегламентированное понимание того, как проектом управляют, кто за что несёт ответственность: больше ролей - больше документов.
В корпорации может быть создано большое количество разных по уровню управления комитетов, поэтому без обширного списка внутренних документов точно не обойтись. В технической части может быть много вариаций, и это не только чертежи и инструкции.
- Кстати, в корпорации всегда задокументированы рекомендации для будущих проектов. Хотелось бы, чтобы эта практика была введена и в стартапах. Да, там тоже проходят ретро, встречи, где обсуждают, какие допустили ошибки, что можно было сделать лучше, но не всегда по итогу вырабатывается документ, в отличие от того, как это тщательно фиксируют в корпорациях, - подметила Мария Панченко.
Есть корпорации с внедрённой корпоративной системой управления проектами (КСУП). В этом случае вся документация стандартизированна, автоматизированна, интегрирована в соответствии со стандартами всех функциональных подразделений.
- Часто бывает в корпорациях, когда у тебя проект относится ко всей компании или какой-то её части. Чтобы его реализовать, нужно работать не только внутри своего департамента, но и с другими. Это уже кросс-функциональные коммуникации и запрос ресурса у других подразделений. И чтобы их запросить, нужно понимать, кто какими ресурсами человеческими, финансовыми, временными обладает. Тут важно, чтобы эти связи были налажены, - пояснила Мария Панченко.
Понятно, что у каждой IT-компании будет свой пакет документации, который нужен для качественной работы над проектом. Но всё же давайте обозначим необходимый минимум:
- Концепция проекта;
- Функциональное задание;
- Техническое задание;
- План-график;
- Регулярные и итоговый отчёты.
- Также важно обеспечивать преемственность проектных команд, работающих над общим продуктом. Если удаётся сохранить целевую регулярность выхода обновлений и стандарты качества разрабатываемого решения на протяжении длительного времени (больше года) - значит пакета документации достаточно, - считает Михаил Гуненков.
Как писать документацию?
Наши собеседники рассказывают, что человек, пишущий документацию, чаще опирается на свой опыт в профессии, а новичкам как правило приходится работать по шаблонам уже существующих документов в конкретной компании.
- Если вы приходите в новую компанию и вам нужно написать какую-то документацию, хорошо бы запросить шаблон, иначе вы можете сделать в привычном именно вам формате, но непривычном для сотрудников. И им будет сложно ею пользоваться. При этом иногда бывает полезно написать документ так, как ты его видишь, и потом уже запросить шаблон и адаптировать документ. Тогда больше шансов, что ты привнесёшь какие-то важные доработки, инсайты, нюансы в документ. Если вы пришли в стартап и вам говорят "да как-нибудь напиши", то будет здорово, если есть коллеги, которые могут подсказать или дать какой-нибудь шаблон. Также будет полезно взять у стейкхолдеров их мнение о том, как они себе это представляют и что для них важно видеть в том или ином документе. Иначе их ожидания могут разойтись с тем, что вы им подготовите. Ну а с КСУП жить проще - всё автоматизировано и все шаблоны в системе, - пояснила Мария Панченко.
Документацией может заниматься любой участник проекта. Например, разработчик описывает интерфейсы, тестировщики составляют сценарии проверки, архитекторы разрабатывают диаграммы, системный аналитик, соответственно, пишет анализ рынка, самой системы и так далее.
- И есть специальная профессия - технический писатель. Он может сопровождать команды разработки, помогать им готовить проектную документацию. Именно, чтобы этим занимался не кто-то на полставки параллельно с основными задачами, а чтобы был отдельный человек, который может обеспечить команду всей необходимой документацией для разработки продукта, - добавила Екатерина Ушакова.
Прежде чем приступать к написанию документации, необходимо понимать, кто будет ею пользоваться, а также какие цели и задачи с помощью этих документов вы стараетесь решить.
- Проектная документация должна быть опорой, поддержкой всей разработки. И она должна находиться ровно в том месте, где "обитает" команда. Если, например, у команды есть общий чатик в каком-нибудь мессенджере, то ссылки на всю документацию должны быть там. Если команда привыкла общаться почтой, то документация частично может быть как раз-таки в цепочках писем. Но в любом случае залог полезной документации в том, чтобы она была там, где ею будет пользоваться внутренняя команда разработки, - уверена Екатерина Ушакова.
Чтобы документация действительно работала на проект, ею необходимо пользоваться. Бывает, что команда попросту игнорирует написанное, забывает про документацию, например, потому что ею неудобно пользоваться или она непонятно написана.
- Она бывает многотомной и очень сложной. Но когда она такая, то должна быть разбита на блоки, к которым удобно обратиться. И документация должна своевременно обновляться. При изменениях обновлённые данные должны быть загружены в систему и заинтересованные стороны должны получать уведомления, что что-то изменилось, - резюмировала Мария Панченко.
Итак, мы поняли, что документация зависима от масштаба проекта и используемой методологии. Качественная документация не только облегчает процесс разработки и внедрения, но и способствует улучшению поддержки пользователей, обеспечивая им необходимые знания для правильного использования продукта. При этом она становится инструментом передачи знаний внутри команды и между различными подразделениями. В этом контексте игнорирование важности документации может привести к путанице, снижению качества работы и потере времени.
Чтобы больше знать, чем живёт мир информационных технологий у нас в Омске и за его пределами, читайте нашу рубрику "Войти в IT".
