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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#документация #оформление #ТЗ #интеграция #логика #история #знания #методология #представление #проект