Павел Абдюшев

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

1. Как мы переработали структуру нашей документации.
2. Как автоматизировали создание и обновления описания самых больных разделов:

•  модели данных;
•  задач по обработке данных внутри приложения, их параметров;
•  пакетов задач и их расписания;
•  примеров запросов к API;
•  release notes для заказчика.

1. Каких успехов уже достигли:

•     уменьшили число обращений от заказчиков из-за неактуальной документации;
•     упростили поддержку и поиск;
•     стали больше доверять нашей документации;
•     ускорили передачу поддержки заказчиков между коллегами.

1. С какими техническими и организационными проблемами столкнулись в процессе оздоровления и что планируем сделать в ближайшем будущем.

ПО постоянно изменяется. Выходят минорные обновления, патчи, баг-фиксы, крупные обновления, новые версии и релизы. Разработчикам хочется похвастаться тем, что они сделали, а пользователям прочитать о том, что же изменилось в продукте.

Мы начали писать release notes (заметки к релизу с описанием изменений) для своего продукта 5 лет назад. И были горды собой — выносили в relese notes только главные задачи, указывали их номер в JIRA вместе со ссылкой, писали подробную инструкцию, как перейти на новый релиз.

Но потом мы заметили, что заказчики не используют новые возможности. Стали выяснить, почему? Оказалось — они про них не знают! Мы расстроились, задумались, а потом переработали формат описания изменений с нуля. И это сработало!

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