Приветствую, уважаемые читатели Хабра! ???
В мире разработки программного обеспечения существует множество вызовов, и одним из них является столкновение с проектами, лишенными должной документации. Это часто вызывает чувство потерянности и озадаченности, подобно тому как путник оказывается в темном лесу без карты и компаса. В таких моментах первая мысль, которая приходит в голову, - "Может, лучше свернуть назад?"
Однако, несмотря на первоначальное замешательство, такие ситуации предоставляют уникальную возможность стать настоящим героем проекта. Представьте себе, каким уважаемым и крутым специалистом вы станете, создавая систему документации с нуля!
С таким мощным стимулом я и решила приступить к делу:
Разработка шаблонов для стандартизации: Начнем с того, что создадим набор шаблонов, которые помогут нам описывать каждый аспект проекта в едином стиле и формате. Это не только облегчит процесс документирования, но и сделает его более удобным и понятным для всей команды.
Анализ базы данных: База данных является краеугольным камнем любого проекта. Без глубокого понимания ее структуры невозможно построить четкую картину всего проекта. Поэтому мы начнем с детального анализа базы данных, чтобы убедиться, что мы имеем полное представление о ее структуре и связях между данными.
Создание сервисной карты: Давайте разложим все сервисы и их взаимосвязи на столе. Это поможет нам визуализировать работу нашей системы в целом и лучше понять ее архитектуру. Кроме того, это даст нам возможность выявить возможные узкие места и проблемные зоны, которые требуют дополнительного внимания.
Документация процесса тестирования: Четко описанный процесс тестирования - это ключевой элемент успешного проекта. Он не только помогает нам обеспечить качество продукта, но и повышает эффективность работы всей команды. Поэтому мы обязательно займемся созданием подробной документации по процессу тестирования, чтобы у нас была ясная стратегия и план действий на каждом этапе разработки.
Описание сценариев использования (use case): Представим себя в роли пользователя и опишем типичные сценарии использования нашего продукта. Это поможет нам лучше понять его функционал и потребности пользователей, а также выявить возможные улучшения и дополнительные функциональные требования.
Документация API с использованием Swagger: Документация API - это неотъемлемая часть любого современного проекта. Она позволяет другим разработчикам легко и эффективно взаимодействовать с нашим продуктом, используя наши API.
Классно, с чего начнем?
Первым шагом будет сбор информации. В этом нам поможет метод event storming - мощный инструмент для совместной работы и сбора знаний о проекте.
Собрав команду и разделив ее на различные области ответственности (backend, frontend, база данных и бизнес), мы предоставили каждой группе свое пространство на виртуальной доске в Miro и дали волю их творчеству.
В ходе этого процесса каждая группа описывала все, что знала о своей области, а я переходила от команды к команде, задавая уточняющие вопросы и улавливая ключевые моменты.
Результат превзошел все наши ожидания: на доске в Miro появилась огромная картина с кучей ценной информации, а каждая команда получила ясное представление о своей области ответственности.
Что дальше? Остается только расставить приоритеты и приступить к созданию документации на основе собранной информации.
P.S. Event storming - это не просто метод исследования клиентского опыта. Это настоящее искусство, позволяющее глубоко погрузиться в предметную область проекта и сформировать четкое понимание его структуры и функционирования.
Используйте этот мощный инструмент в своей работе и достигайте новых высот в разработке программного обеспечения!
А мы продолжим анализировать собранную информацию и делиться своими этапами по восстановлению документации на нашем проекте.
Исследования также демонстрируют, как отсутствие документации может повлиять на проект:
Увеличение времени разработки: Исследование, проведенное компанией VDC Research, показало, что отсутствие должной документации может увеличить время разработки на 25–30%.
Увеличение количества ошибок: Согласно отчету от института Standish Group, проекты без должной документации сталкиваются с увеличением количества ошибок на 20–25%.
Увеличение затрат на поддержку и обслуживание: Исследование, проведенное компанией Forrester Consulting, показало, что отсутствие документации может увеличить затраты на поддержку и обслуживание продукта на 30–35%.
Ухудшение пользовательского опыта: Опрос, проведенный компанией UserTesting, показал, что отсутствие достаточной документации делает использование продукта сложным и неудобным для более чем 70% пользователей.
Эти цифры подчеркивают важность разработки качественной документации для успешного завершения проекта. Даже небольшое увеличение времени разработки или количество ошибок может иметь серьезные последствия для проекта и его бизнес-целей.
Если понравилась статья, можете подписаться на мой ТЕЛЕГРАМ, там я рассказываю о системном анализе и не только ???
Комментарии (6)
netch80
10.05.2024 16:28+1База данных является краеугольным камнем любого проекта.
Посмотрел на несколько последних проектов, в которых участвовал.
SIP софтсвич. Общается с чем-то, представляющим себя как биллинг, по кастомному протоколу (RADIUS с вендорскими расширениями). Ну база тоже есть, но очень вспомогательная.
Компонент радиосоты, управление локальной конфигурацией, которая задаёт направление потоков данных через кастомизированное железо. О "базе данных" можно говорить только в плане состояния этой конфигурации в памяти между ребутами. Есть, конечно, центральная база (на всяких etcd), но это конфигурация, которую в основном правят руками.
Можно продолжать...
Я не против статьи в целом, но слишком много упрощений. И почему мне кажется, что вся статья была написана ради одного слова "Swagger"? И чем же он так хорош, что использовать его, а не 100500 аналогов? "Тема <xxx> не раскрыта" (c).
binary_file
10.05.2024 16:28+1Неплохо!
Данная статья сподвигнула на подумать о том, когда документации много и это тоже не всегда удобно
ManGegenMann
Отрицание, торг и увольнение с этой помойки.
zergon321
Ну, я вообще не видел ни одного коммерческого IT-проекта, где была бы хоть какая-то документация. Мэнэджеры не дадут времени её писать, им нужно доставлять фичи
ManGegenMann
Берешь пишешь документацию в рамках выполнения задачи. Все равно они сейчас вместо часов считают в папугаях разных, также пишем тесты и прочее.
Вот есть у вас задача на 5-7 часов. Добавим 2ч на тесты, 2ч на доку и в таких рамках сами для себя считаем. Менеджеру срем в голову 1-2 попугая, один хрен этот лупень поверит.
Filiber
я видел. и сейчас работаю на таком.
очень прикольно, когда можешьнайти 90 процентов инфы без камланий.
это, конечно, не путь джедая, но реально вштыривает.
а вот по некоторым решениям, которые мы привлекаем извне документации не то чтобы нет, но она крайне скудная.
тоже вштыривает. но есть нюанс :)