Не важно, насколько хороша команда или как эффективна методология без документации проект можно считать провальным

Не важно, насколько хороша команда или как эффективна методология без документации проект можно считать провальным

Что ж… Начнем.

Сегодня хотим немного поворчать, и напомнить, как важно вести документацию по проектам и фиксировать все изменения.

Думаем, примеров много, не только у нас, но и у вас. И примеров именно болезненных. Так как без документации сопровождение, да и ведение проекта — это головная боль Руководителя или Менеджера проектов. А это как раз те, кто должен убедиться, что документация по проекту, за который отвечает руководитель в полном порядке, инструкции понятны клиенту, техническая документация актуальна для разработчиков.

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

Не важно, насколько хороша команда или как эффективна методология без документации проект можно считать провальным

А сейчас вернемся к сути.

В каждой компании есть коллега, работающий уже много лет, самостоятельно выполняющий кучу заданий, и когда нужно быстро получить ответ на вопрос, все идут к нему. Почему? Опять же: «так быстрее».

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

Да, скучно, много букв, много писать, но это лучше, чем не иметь вообще ничего.

Документация есть внутренняя и внешняя. Разница?

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

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

1. Проектные процессы

Здесь и план-график проекта со сроками, и список нужных контактов, и история изменений, и статусы задач. Наличие такой информации в одном месте делает процесс работы более комфортным. А также сильно разгружает аналитика/менеджера/тимлида и всех, кого волнует выполнение задач и сроки.

2. Бизнес-потребности и/или Бизнес-процесс

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

Не важно, насколько хороша команда или как эффективна методология без документации проект можно считать провальным

3. Концептуальная модель системы

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

4. Сценарии использования

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

5. Логика работы системы

По коду или БД не всегда получается понять смысл функционала. Например, формула оборачиваемости товара— это бизнес-правила, о которых коду ничего не известно. Их лучше всего сразу записывать в виде читаемого документа. Тогда на описание логики можно ссылаться при постановке задач программистам или тестировщикам.

6. Интеграция / Обмен данными

Подробное описание параметров и методов обмена данными, форматов сообщений важно для того, чтобы разрабатываемый продукт мог правильно общаться с другими системами.

7. Ограничения/нефункциональные требования

Какая максимальная нагрузка? А минимальные системные требования? Как часто должен проходить обмен данными, например, справочниками, раз в сутки в час ночи или чаще? Внешняя система не умеет принимать какие-то значения?

При формировании списка ограничений и нефункциональных требований, оговоренных заранее, так же помогает избежать конфликтных ситуаций с заказчиком.

Не важно, насколько хороша команда или как эффективна методология без документации проект можно считать провальным

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

Еще больше можно почитать на странице компании Logicon https://dzen. ru/logicon

11
2 комментария

Докуха? Может кукуха?)

1

да кому она нужна... делали докуху, когда пошли в реестр суверенного ПО... и точка..