Жил был продукт для больших компаний. С хорошей документацией, которую команда вела в конфлюенс.
Продукт рос, документация пухла, но оставалась хорошей.
Число заказчиков тоже увеличивалось, а под каждого заказчика появлялось новое пространство с описанием продукта — с одной стороны, унаследованном от общей документации, а с другой — описывающее специфичные для заказчика доработки и настройки.
В какой-то момент выросшая документация выросла настолько, что вышла из-под родительского контроля команды:

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

Но команда не растерялась и отправила документацию на лечение.
О проведенном процессе исцелении я и расскажу в докладе:

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

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

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

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

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

Доклад "Вяжем плед из требований для теплой ламповой поддержки".
Тизер: Как узнать, что происходит с вашим приложением и как подготовить требования для этого?
Одна из характеристик качества приложения — сопровождаемость. Я работаю аналитиком в команде, которая разрабатывает коробочный entrprise-продукт для компаний с миллионами клиентов. Это телеком, банки, страховые. Мы собираем клиентские данные из разных систем компании в одну базу, чтобы упростить обслуживание клиентов. Из-за интеграций с операционными системами, которые работают с клиентом в режиме реального времени наша система становится бизнес-критичной, поэтому мы должны гарантировать ее работоспособность.
Но предусмотреть абсолютно все ошибки и ситуации невозможно, поэтому важно понимать, что в каждый момент происходит с системой для предупреждения ошибок или поиска причины проблемы. Мы не просто поставляем продукт, но и оказываем третью линию поддержки всем нашим заказчикам.
В докладе расскажу, с чего мы начинали и как за 5 лет выстроили механизмы, позволяющие нам предупреждать серьезные проблемы и поддерживать 15 заказчиков силами 2 человек.

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

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

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

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