Приветствую, уважаемые читатели Хабра! ??‍?

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

Однако, несмотря на первоначальное замешательство, такие ситуации предоставляют уникальную возможность стать настоящим героем проекта. Представьте себе, каким уважаемым и крутым специалистом вы станете, создавая систему документации с нуля!

С таким мощным стимулом я и решила приступить к делу:

  1. Разработка шаблонов для стандартизации: Начнем с того, что создадим набор шаблонов, которые помогут нам описывать каждый аспект проекта в едином стиле и формате. Это не только облегчит процесс документирования, но и сделает его более удобным и понятным для всей команды.

  2. Анализ базы данных: База данных является краеугольным камнем любого проекта. Без глубокого понимания ее структуры невозможно построить четкую картину всего проекта. Поэтому мы начнем с детального анализа базы данных, чтобы убедиться, что мы имеем полное представление о ее структуре и связях между данными.

  3. Создание сервисной карты: Давайте разложим все сервисы и их взаимосвязи на столе. Это поможет нам визуализировать работу нашей системы в целом и лучше понять ее архитектуру. Кроме того, это даст нам возможность выявить возможные узкие места и проблемные зоны, которые требуют дополнительного внимания.

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

  5. Описание сценариев использования (use case): Представим себя в роли пользователя и опишем типичные сценарии использования нашего продукта. Это поможет нам лучше понять его функционал и потребности пользователей, а также выявить возможные улучшения и дополнительные функциональные требования.

  6. Документация API с использованием Swagger: Документация API - это неотъемлемая часть любого современного проекта. Она позволяет другим разработчикам легко и эффективно взаимодействовать с нашим продуктом, используя наши API.

Классно, с чего начнем?

Первым шагом будет сбор информации. В этом нам поможет метод event storming - мощный инструмент для совместной работы и сбора знаний о проекте.

Собрав команду и разделив ее на различные области ответственности (backend, frontend, база данных и бизнес), мы предоставили каждой группе свое пространство на виртуальной доске в Miro и дали волю их творчеству.

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

Результат превзошел все наши ожидания: на доске в Miro появилась огромная картина с кучей ценной информации, а каждая команда получила ясное представление о своей области ответственности.

Что дальше? Остается только расставить приоритеты и приступить к созданию документации на основе собранной информации.

P.S. Event storming - это не просто метод исследования клиентского опыта. Это настоящее искусство, позволяющее глубоко погрузиться в предметную область проекта и сформировать четкое понимание его структуры и функционирования.

Используйте этот мощный инструмент в своей работе и достигайте новых высот в разработке программного обеспечения!

А мы продолжим анализировать собранную информацию и делиться своими этапами по восстановлению документации на нашем проекте.


Исследования также демонстрируют, как отсутствие документации может повлиять на проект:

  1. Увеличение времени разработки: Исследование, проведенное компанией VDC Research, показало, что отсутствие должной документации может увеличить время разработки на 25–30%.

  2. Увеличение количества ошибок: Согласно отчету от института Standish Group, проекты без должной документации сталкиваются с увеличением количества ошибок на 20–25%.

  3. Увеличение затрат на поддержку и обслуживание: Исследование, проведенное компанией Forrester Consulting, показало, что отсутствие документации может увеличить затраты на поддержку и обслуживание продукта на 30–35%.

  4. Ухудшение пользовательского опыта: Опрос, проведенный компанией UserTesting, показал, что отсутствие достаточной документации делает использование продукта сложным и неудобным для более чем 70% пользователей.

Эти цифры подчеркивают важность разработки качественной документации для успешного завершения проекта. Даже небольшое увеличение времени разработки или количество ошибок может иметь серьезные последствия для проекта и его бизнес-целей.

Если понравилась статья, можете подписаться на мой ТЕЛЕГРАМ, там я рассказываю о системном анализе и не только ??‍?

Комментарии (6)


  1. ManGegenMann
    10.05.2024 16:28
    +5

    Отрицание, торг и увольнение с этой помойки.


    1. zergon321
      10.05.2024 16:28
      +2

      Ну, я вообще не видел ни одного коммерческого IT-проекта, где была бы хоть какая-то документация. Мэнэджеры не дадут времени её писать, им нужно доставлять фичи


      1. ManGegenMann
        10.05.2024 16:28

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

        Вот есть у вас задача на 5-7 часов. Добавим 2ч на тесты, 2ч на доку и в таких рамках сами для себя считаем. Менеджеру срем в голову 1-2 попугая, один хрен этот лупень поверит.


      1. Filiber
        10.05.2024 16:28
        +1

        я видел. и сейчас работаю на таком.

        очень прикольно, когда можешьнайти 90 процентов инфы без камланий.

        это, конечно, не путь джедая, но реально вштыривает.

        а вот по некоторым решениям, которые мы привлекаем извне документации не то чтобы нет, но она крайне скудная.

        тоже вштыривает. но есть нюанс :)


  1. netch80
    10.05.2024 16:28
    +1

    База данных является краеугольным камнем любого проекта.

    Посмотрел на несколько последних проектов, в которых участвовал.

    SIP софтсвич. Общается с чем-то, представляющим себя как биллинг, по кастомному протоколу (RADIUS с вендорскими расширениями). Ну база тоже есть, но очень вспомогательная.

    Компонент радиосоты, управление локальной конфигурацией, которая задаёт направление потоков данных через кастомизированное железо. О "базе данных" можно говорить только в плане состояния этой конфигурации в памяти между ребутами. Есть, конечно, центральная база (на всяких etcd), но это конфигурация, которую в основном правят руками.

    Можно продолжать...

    Я не против статьи в целом, но слишком много упрощений. И почему мне кажется, что вся статья была написана ради одного слова "Swagger"? И чем же он так хорош, что использовать его, а не 100500 аналогов? "Тема <xxx> не раскрыта" (c).


  1. binary_file
    10.05.2024 16:28
    +1

    Неплохо!
    Данная статья сподвигнула на подумать о том, когда документации много и это тоже не всегда удобно