Комментарии 6
Чаще всего у документации есть заказчик. Это может быть менеджер, разработчик, дизайнер — любой человек, осознавший, что есть какая-то проблема в понимании происходящего.
Только этот заказчик сидит где-то в будущем. Вот лет через 5-10 существования продукта станет понятно, что текущая команда ничего не понимает в устройстве системы и в том, что и почему она делает, и будут хотеть, чтобы все это где-нибудь было понятно описано.
Ну и ладно) зато сразу определены вопросы, которые стоит покрыть в первую очередь. Да и вряд ли у продукта нет вообще никакой доки — скорее всего хоть кто-то что-то себе записывал для удобства. И сейчас всё чаще вижу людей, которым удаётся на старте доказать, что документация нужна и важна (если это действительно так).
Стоит-же в агильном манифесте «работающее приложение важнее сложной документации», а что под сложной понимать — тут непочатое поле для толкавания…
Всё так) поэтому надо думать что мы вообще пишем и для кого. Очень часто для понимания системы достаточно простой заметки, вместо талмуда с полным описанием каждого узла. Вопрос только, что иногда есть внешние требования
поэтому надо думать что мы вообще пишем и для кого.
Пишем учебник для будущих разработчиков, службы сопровождения и пользователей проекта. Чтобы после прочтения (без обращения к живым людям, знающих вопрос — они давно уволились и остался лишь 'черный ящик' системы) у них вопросов меньше было. А вот кто умеет такие учебники писать и как их вообще надо писать — большой вопрос. Этот навык термином 'технический писатель' не покрывается.
Тут ключевое слово "сложной".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая роль в команде: технический писатель