Страница не показывает весь навык
Полированная статья подтверждает, что вы умеете писать хороший текст. Она не показывает, как вы нашли недостающую информацию, определили аудиторию, разобрали конфликт требований или проверили финальную инструкцию.
Портфолио становится убедительнее, когда каждый пример оформлен как небольшой case study.
Сначала объясните проблему
Для каждого материала укажите, кто был читателем и какую задачу он решал. Опишите ограничения: неполное поведение продукта, несколько версий, жёсткий релизный срок, регулируемая терминология или сложная миграция.
Затем покажите, что изменили и почему. Сравнение структуры «до/после» часто говорит больше, чем красивый финальный скриншот.
Покажите разные виды доказательств
Один пример может демонстрировать процедуру, другой — API reference, третий — информационную архитектуру или автоматизацию качества. Если коммерческую работу публиковать нельзя, воспроизведите похожую задачу на открытом продукте или анонимизируйте структуру без раскрытия конфиденциальных деталей.
Код, схемы и небольшие репозитории полезны, если показывают процесс, а не отвлекают от него.
Покажите проверку
Расскажите, как запускали команды, валидировали примеры, работали с экспертами и проверяли, решает ли изменение исходную проблему. Документации доверяют, когда она связана с доказательствами.
Не приписывайте себе бизнес-эффект, который нельзя подтвердить.
Сделайте портфолио удобным для ревью
Три сильных кейса обычно полезнее двадцати случайных ссылок. Дайте каждому короткое резюме и быстрый доступ к артефакту. Проверьте ссылки, картинки и файлы без специальных прав.
Портфолио должно отвечать на практический вопрос работодателя: какую проблему документации этот человек сможет решить у нас?
Практический разбор
Превратите «Портфолио технического писателя должно показывать решения, а не только страницы» в небольшое учебное задание с проверяемым результатом. Выберите артефакт, который можно закончить за одну-две сессии: одностраничную процедуру, API-пример, before/after редактирование, чистку терминологии или мини-кейс для портфолио. До начала определите, что именно будет считаться улучшением, а затем сравните первую и итоговую версии.
Сохраняйте свидетельства процесса, а не только красивый результат:
- исходную проблему и аудиторию;
- принятые решения и отвергнутые варианты;
- отзыв читателя, рецензента или эксперта;
- одно изменение, которое вы внесли бы при следующей попытке.
Такой цикл полезнее пассивного накопления курсов. Техническое письмо — ремесло повторяющихся решений в условиях ограничений. Маленькое завершённое упражнение с реальным ревью учит больше, чем большой теоретический проект, который никогда не дошёл до читателя.
Короткий редакционный чек-лист
- Страница не показывает весь навык. Полированная статья подтверждает, что вы умеете писать хороший текст.
- Сначала объясните проблему. Для каждого материала укажите, кто был читателем и какую задачу он решал.
- Покажите разные виды доказательств. Один пример может демонстрировать процедуру, другой — API reference, третий — информационную архитектуру или автоматизацию качества.
- Покажите проверку. Расскажите, как запускали команды, валидировали примеры, работали с экспертами и проверяли, решает ли изменение исходную проблему.
