Определите проблему
Первый месяц: составьте карту продукта, аудиторий, исходников, сборки, ревьюеров и релизного потока. Первые девяносто дней нужны для понимания продукта, людей и реального пути документации к пользователю — до попыток нового автора перестроить всю систему.
Выберите рабочую модель
Читайте обращения и историю изменений, чтобы увидеть места, где реальность сложнее задуманной модели документации. В первый месяц пройдите существующий publishing path целиком, воспроизведите основные пользовательские задачи и выясните, кто способен подтвердить каждую область продукта.
Встройте в процесс
Выпустите одно ограниченное улучшение и на нём изучите реальные ветки, preview, согласования и deployment. Во второй месяц возьмите ограниченное изменение от discovery до release и отмечайте все места, где теряются контекст, инструменты или ответственность.
Проверьте результат
Второй месяц: возьмите связную область и выстройте отношения с её экспертами и терминологией. В третий месяц предложите одно-два улучшения на основе наблюдаемого трения, а не полную замену процессов, принесённую из прошлой компании.
Сохраните сопровождаемость
Третий месяц: предлагайте системные изменения только после наблюдения реальных проблем и понимания рабочего процесса. Хороший результат onboarding — не только выпущенные страницы, но и писатель, который знает, как подтвердить факт, найти владельца и безопасно изменить систему.
Практический разбор
Превратите «Первые 90 дней в команде документации» в небольшое учебное задание с проверяемым результатом. Выберите артефакт, который можно закончить за одну-две сессии: одностраничную процедуру, API-пример, before/after редактирование, чистку терминологии или мини-кейс для портфолио. До начала определите, что именно будет считаться улучшением, а затем сравните первую и итоговую версии.
Сохраняйте свидетельства процесса, а не только красивый результат:
- исходную проблему и аудиторию;
- принятые решения и отвергнутые варианты;
- отзыв читателя, рецензента или эксперта;
- одно изменение, которое вы внесли бы при следующей попытке.
Такой цикл полезнее пассивного накопления курсов. Техническое письмо — ремесло повторяющихся решений в условиях ограничений. Маленькое завершённое упражнение с реальным ревью учит больше, чем большой теоретический проект, который никогда не дошёл до читателя.
Короткий редакционный чек-лист
- Определите проблему. Первый месяц: составьте карту продукта, аудиторий, исходников, сборки, ревьюеров и релизного потока.
- Выберите рабочую модель. Читайте обращения и историю изменений, чтобы увидеть места, где реальность сложнее задуманной модели документации.
- Встройте в процесс. Выпустите одно ограниченное улучшение и на нём изучите реальные ветки, preview, согласования и deployment.
- Проверьте результат. Второй месяц: возьмите связную область и выстройте отношения с её экспертами и терминологией.
