Совсем другой набор инструментов
В 2006 году технический писатель заметно чаще жил в настольных издательских системах, офисных форматах и вручную поддерживаемых help-системах. Continuous delivery, совместная работа через Git и черновики от ИИ не были нормой для большинства команд документации.
Инструменты изменились радикально. Ядро профессии — гораздо медленнее.
Аудитория всё ещё первое проектное решение
Документ для администратора, API-разработчика и конечного пользователя нельзя получить из одного текста простой заменой заголовков. Понимание задачи читателя остаётся фундаментом полезной документации.
Структура переживает форматы
Форматы приходят и уходят. Понятная иерархия, progressive disclosure, предсказуемая навигация, единая терминология и организация вокруг задач удивительно хорошо переживают миграции. Хорошо устроенное старое руководство часто легче модернизировать, чем красивый, но хаотичный новый сайт.
Проверка фактов всё ещё отделяет документацию от копирайтинга
Техническому писателю всегда был нужен доступ к инженерам, продукту и реальному поведению системы. Сегодня часть проверок можно автоматизировать, но ответственность за достоверность никуда не исчезла.
Что действительно изменилось
Документация намного глубже вошла в software delivery. Техписы работают с репозиториями, API, CI, аналитикой и структурированным контентом. Публикация может происходить десятки раз в день. Читатели ожидают поиск, deep links, запускаемые примеры и быстрые обновления.
Что стоит забрать из 2006 года
У техписа 2006 года стоит сохранить дисциплину: знать аудиторию, проверять факты, управлять терминологией, проектировать структуру и отвечать за опубликованное. Инструменты, форматы и процессы должны спокойно меняться без ностальгического культа.
Практический разбор
Читайте «Что осталось от техписа 2006 года?» в двух колонках: что определялось технологиями своего времени, а что относилось к самой документационной задаче. Воспроизведите небольшой старый процесс современными средствами — например выпуск release notes, ведение глоссария или подготовку offline-руководства — и отметьте решения, которые остались прежними, хотя носитель полностью изменился.
Ищите устойчивые закономерности, а не только ностальгию:
- как читатель находил нужную информацию;
- как распространялись исправления;
- кто отвечал за точность после публикации;
- какие ограничения старого носителя заставляли работать дисциплинированнее.
Исторический материал полезен тогда, когда помогает яснее увидеть современную проблему. Цель не в том, чтобы вернуть старый workflow, а в том, чтобы отделить долговечные редакционные принципы от инструментов конкретной эпохи.
Короткий редакционный чек-лист
- Совсем другой набор инструментов. В 2006 году технический писатель заметно чаще жил в настольных издательских системах, офисных форматах и вручную поддерживаемых help-системах.
- Аудитория всё ещё первое проектное решение. Документ для администратора, API-разработчика и конечного пользователя нельзя получить из одного текста простой заменой заголовков.
- Структура переживает форматы. Форматы приходят и уходят.
- Проверка фактов всё ещё отделяет документацию от копирайтинга. Техническому писателю всегда был нужен доступ к инженерам, продукту и реальному поведению системы.
