“Без бумажки ты букашка, а с бумажкой…” – у многих на слуху это выражение, но актуально ли оно в наше время информационных технологий или это бюрократический атавизм? Давайте рассмотрим на примере Вашего IT проекта.
Даже если Ваша команда пропагандирует Agile подходы к разработке и лозунги о том, что работающий продукт важнее четко описанной документации, это не отрицает тот факт, что описания не должно быть совсем.
Основная цель документации – облегчить процесс разработки проекта, упростить коммуникацию в команде, уменьшить количество вопросов и споров. Причем понимание не только между членами команды, но даже будущий Вы можете противоречить прошлому себе и это нормально т.к. при отличающихся входных параметрах можно прийти к различным выводам. Но если негде посмотреть результаты предыдущих обсуждений или описания функционала системы, то рассуждения и исследования придется повторять, а не продолжать их, что приводит к неминуемому расточительству времени и эмоциональному выгоранию.
Но важно не просто написать документацию, важно поддерживать ее в актуальном состоянии! Подробно описанная, но неактуальная документация приведет к тому, что кто-то из участников команды будет продолжать ей следовать и вести проект к пропасти багов.
Вам необходимо принять решения о том, какая документация будет вестись и поддерживаться на проекте в актуальном виде, исходя из состава и обязанностей членов команды. Можете принять это решение самостоятельно или прислушаться к нашему подходу.
- В первую очередь необходимо определиться с хранилищем ресурсов документации. Какое-то одно место, где будут собраны все материалы проекта, ссылки на актуальные документы, диаграммы и т.п. Таким образом можно избавиться от бесполезной траты времени на поиск нужной информации. Это может быть либо онлайн документ, либо вики сервис...не столь важно какой выбрать, важно чтоб участники команды имели туда доступ.
- Второй минимально необходимый документ - успешный сценарий использования Вашего продукта и собственно набор персон, которые будут использовать Ваш продукт. Это может быть руководство пользователя, MRD в котором изложены бизнес-требования и описание поведения системы или последовательность вызовов с параметрами, если речь идет о взаимодействии системы.
Поделюсь очевидным лайфхаком для тех, кто разрабатывает аналоги существующих продуктов, как и мы.
До этого умозаключения догадались не сами, а почерпнули из произведения Тома Де Марко “Дедлайн”, в котором одна из IT команд мистера Томпкинса сэкономила кучу времени на составлении собственной документации, взяв за основу подробное руководство аналога.
Смекаешь?!
- Тест кейсы. Это отличное дополнение к успешному сценарию системы, т.к. они, по сути, описывают все возможные сценарии использования системы. Особенно если в команде есть тестировщики, а они должны быть! Этот документ прежде всего систематизирует проведение регрессионных и смоук тестов, но так же помогает описать возможные сценарии поведения системы.
- UI/UX макеты. Визуальное описание интерфейса взаимодействия системы с пользователем, UI элементов и их состояний. Мы используем Figma.
- Архитектура системы. В нашем случае использования микросервисной архитектуры требует описания сервисов, их назначение и взаимосвязи.
- Диаграммы. Описание каждой из которых может вылиться в отдельную статью, поэтому просто обозначим наиболее полезные на наш взгляд: диаграмма состояний и переходов, диаграмма последовательности, диаграмма связей
Как итог, документация – Ваш друг и помощник, призванный привнести дисциплину в Ваш проект и позволить коллегам относиться к проекту с бОльшим вниманием. Использовать ли необходимый минимум или писать подробное, всеобъемлющее ТЗ - решать Вам.
... Продолжение следует...