Лид редакции «Т‑Банка» о том, чем занимается техписатель и как он влияет на ИТ-продукты.
Как складывался твой карьерный путь?
Я родилась и училась в Беларуси. Во времена студенчества работала в сфере общественного питания: технологом, управляющей, официанткой, администратором, барменом и даже поваром. Это дало большой опыт управления людьми и организации процессов.
Позже мне захотелось зарабатывать больше и пробовать что-то новое. Я переехала в Москву. Увидела в «Вконтакте» вакансию от «Т-Банка» — тогда это ещё были «Тинькофф Кредитные системы». Нужно было консультировать клиентов. Именно там пригодились мои лидерские навыки: за пару лет я стала руководителем команды.
Компания начала менять коммуникации: рынок шёл к инфостилю, а мы всё ещё писали письма в духе «Уважаемый Иван Петрович, уведомляем вас…». Переучивать людей было
Мне стало интересно, как можно писать по-другому, и я начала в это погружаться. Мы с командой пробовали, искали свой стиль, работали над текстами, учились говорить с пользователем понятно. Потом я узнала о Максиме Ильяхове и начала изучать
В 2018 году внутри компании появился проект Friendly. Руководство собрало команду из разных отделов, мы вместе начали придумывать, как научить всех говорить
В 2020 году я стала лидом редакции. К этому моменту у меня уже был управленческий опыт и понимание, как строить процессы. Для лидера важно не делать всё самому, а находить людей, которые умеют лучше. И у меня это отлично получалось.
В 2023 году я начала карьеру технического писателя и стала первым руководителем команды техписов в компании.
Кто такие техписы?
Технический писатель — это человек, который пишет инструкции к сложным продуктам и системам. Он объясняет их работу пользователям, разработчикам или другим специалистам простым языком. Например, человек покупает автомобиль, фотоаппарат или
Предмет при этом не имеет значения. Это может быть машина, самокат, фотоаппарат, дверная ручка, инструкция от IKEA по сборке стола или цифровой продукт, который разрабатывает
У ИТ-продуктов тоже есть пользователи и интерфейсы, а значит, нужна понятная документация. И вот именно эти инструкции — как использовать продукт, что нажимать — пишет продуктовый технический писатель.
Я считаю, что продуктовое техническое писательство — относительно молодая профессия. Это не что-то вроде копирайтера, редактора или SMM-специалиста, которые давно на рынке. Технический писатель умеет сочинять, разбирается в метриках продукта и его технической части.
В 2025 году я выступала на международной конференции технических писателей. Там было много участников из разных компаний, не только крупных. Многие подходили и говорили: «У нас та же ситуация: нас всего один-два человека, а работы — огромное количество».
Ценность техписателей постоянно растёт, но их по-прежнему мало. Поэтому вполне естественно, что многие до сих пор не знают, кто это и чем они занимаются.
В редакции вы только пишете документацию?
Нет, не только. Мне везёт на уникальные задачи и вызовы, которые типичны для крупных корпораций. Когда нет жёстких ограничений, есть возможность что-то улучшить, перестроить, обновить.
У нас большая платформа — около 15 внутренних продуктов, у каждого своя документация. И ни в одном из них до появления нашей редакции не было технического писателя.
Вскоре стали очевидны две вещи. Во-первых, команды, создающие продукты, не понимают, на каком уровне у них документация. Во-вторых, некоторые начали рассматривать продажу своих решений вовне, и это стало сильным стимулом создать полноценную документацию, которая будет помогать пользователям. Так и появилась команда технических писателей.
Когда я пришла на платформу, начала выстраивать процессы обновления и ведения документации. Сначала с одной продуктовой командой, потом с другой.
Команды платформы пришли к нам за помощью с внутренними коммуникациями. Позже появилась цель развивать внутренний пиар, и задач стало ещё больше. Мы обладаем нужной экспертностью, чтобы поддерживать платформу в части не только документации, но и коммуникаций.
Дальше стояла самая сложная задача — разделить потоки и выстроить систему так, чтобы всё работало эффективно. Мы писали документацию, помогали с коммуникациями и при этом оставались сильной, слаженной командой.
В целом для команд в «Т-Банке» обычная практика — выходить за рамки своей роли. Даже у технических писателей работа не ограничивается документацией.
Мы не просто группа отдельных специалистов, а команда, где выстроены полноценные редакционные процессы. У большинства техписателей в компании максимум два человека в команде. Они работают в рамках своих продуктовых процессов, без общей системы: не измеряют эффект, не отслеживают влияние своей работы. Мы — исключение, и хотим внедрить системный подход во всей компании.
Я не приветствую практику, когда команда продукта или разработки нанимает специалиста из другой профессии, типа редактора или техписа. У него нет профессионального сообщества, никто не даёт обратной связи. Специалисту сложно развиваться и непонятно, куда двигаться в профессии.
Что самое сложное в работе технического писателя?
Самое сложное — это взаимодействие с людьми. В корпорации работа техписателя — не только написать текст. Можно изучить продукт, разобраться в его особенностях и отточить навыки письма, но трудности начинаются тогда, когда твоя работа зависит от других. Это характерно не только для редакторов — с тем же сталкиваются дизайнеры и разработчики. Нельзя выполнить задачу и закрыть её: всегда есть цепочка согласований, уточнений, правок.
Иногда приходится проходить десятки кругов обсуждений. А иногда — приходить в команду и объяснять, почему документ нужно писать именно так, почему это важно для пользователей и зачем вообще документацию стоит создавать вместе с редакторами, а не в одиночку.
Вот, например, сегодня на встрече продуктовая команда сказала, что хочет писать документацию самостоятельно. И моя задача — спокойно объяснить, почему надо делать это с нашим участием. Разница между документацией с нашим участием и без нас ощутима.
Как это доказать? Только фактами. Нужно собирать кейсы, статистику, реальные примеры. Хорошие отношения с командой помогают, но без доказательной базы никуда. Люди часто ориентируются на цифры, и тогда важно показать: вот документация, написанная без нас, — по ней поступило столько-то вопросов от пользователей. А вот версия, над которой работал редактор, — и количество вопросов уже меньше. Это наглядно и работает лучше любых слов.
Большинство людей пишут не для пользователя, они фиксируют поток собственных мыслей и не задаются вопросами: «Что понятно читателю?» и «Где он может запутаться?». А редактор как раз делает текст таким, чтобы читатель понимал пользу и ему не приходилось додумывать.
С кем из продуктовой команды больше всего взаимодействует технический писатель?
Зависит от конкретной команды и распределения ресурсов — кто из участников наименее загружен и кто отвечает за коммуникацию. Полезно выстраивать взаимодействие в целом со всей IT-командой: с дизайнерами, продакт-менеджерами, техлидами. Ещё важно находить общий язык с разработчиками.
Как ты объясняешь заказчикам, что текст плохой?
Это, кажется, общая боль всех редакторов. Но технический писатель приносит ценность — команда это видит и дальше отказываться от помощи уже не хочет. Например, есть команды, которым я помогаю просто так, хотя это не входит в круг моих обязанностей. Они сами обращаются за помощью, потому что понимают разницу и видят пользу.
А вот к тем, кто думает, что «и так сойдёт», приходится искать подход. Самый убедительный способ — не спорить на уровне вкуса, а показать результат. Провести исследование, посмотреть, как пользователи воспринимают текст, и наглядно продемонстрировать: вот что вы хотели донести, а вот что люди поняли. Это дорогой, но эффективный способ.
Что делать, если команда не принимает твою документацию или правки?
Сейчас такие случаи почти не встречаются. Это, на мой взгляд, показатель того, что мы выстроили хорошее взаимодействие с командами. Мы уже на том уровне зрелости, когда продуктовые команды приходят к нам за советом, а не спорят по мелочам.
Раньше споры бывали часто. Например, кто-то мог опубликовать новость или документ, проигнорировав редакторские правки. В таких случаях важно не обижаться, а разобраться, почему так произошло. Иногда человек просто не успел согласовать текст повторно — сработали дедлайны, вмешался бизнес, появились новые вводные. Тогда это не злой умысел, а рабочая необходимость.
Но если кто-то системно игнорирует правки и не видит в редактуре ценности — это уже отдельный разговор. Обычно я собираю такие кейсы и обсуждаю их с руководителем сотрудника, чтобы понять, в чём причина и как действовать дальше.
Какой навык важен для технического писателя?
Это не один навык, а целый набор:
Умение вести переговоры. Этот навык приходится постоянно развивать, потому что все люди разные и в каждой команде своя динамика. С кем-то можно договориться за день, а с кем-то нужен месяц, чтобы наконец прийти к общему пониманию и убедить в важности своей работы. При этом важно не только отстаивать свою точку зрения, но и уметь слушать других, принимать их аргументы.
Базовые знания UX. Документация — это часть продукта. Интерфейсу при создании продукта обычно уделяют достаточно внимания, а вот о документации часто забывают.
Прежде чем пользователь дойдёт до интерфейса, он чаще всего обращается к документации. Конечно, существуют продукты, которым документация не нужна, и мы иногда сталкиваемся с этим. Например, к нам приходили команды с запросом создать документацию с нуля или доработать текущую плохую версию. После исследования мы понимали, что достаточно доработать интерфейс — добавить несколько понятных кнопок, и пользователь сможет разобраться
Если техпис не способен хотя бы в общих чертах выстроить пользовательский путь, понять, как действует пользователь, какие у него есть сценарии и цели, то работать ему будет сложно.
Критическое мышление. Мы часто оказываемся в потоке задач и не всегда успеваем задать себе простой вопрос: действительно ли то, что мы делаем, нужно и важно? Мир и приоритеты компаний меняются быстро, и то, что было актуально вчера, сегодня может уже потерять смысл. Без критического взгляда легко увязнуть в рутине, которая больше никому не нужна.
Знание подхода docs as code — инструментов, которые превращают текст в готовую документацию. Это технический навык, но для новичка достаточно теоретических знаний.
Технические писатели работают рядом с разработчиками, которые могут помочь разобраться с инструментарием и процессами. Сейчас в этом также помогает искусственный интеллект. Когда я только начинала, использовала Chat GPT, чтобы понимать код.
По сути, каждый технический писатель сам формирует свой набор навыков — кусочек редакторской работы, немного UX, немного исследований. Всё это постепенно складывается в единый профессиональный портрет.
Как попасть в профессию технического писателя, если нет опыта?
Это сложно, но возможно. Первое — нужно пробовать откликаться на вакансии, делать тестовые задания. Никто не станет техписом, сидя и размышляя, с чего бы начать.
Второе — найти ментора. Это, пожалуй, самое ценное, что можно сделать на старте. Сейчас огромное количество людей готовы делиться опытом: кто-то за плату, кто-то просто потому, что хочет помочь.
Нужно просто пробовать
Ментор поможет понять, где пробелы, чего не хватает, а где всё уже хорошо. Он может помочь выстроить карту развития: какие хард-скилы подтянуть, чему научиться, что попробовать. Иногда оказывается, что человек уже готов к работе, просто не видит этого сам.
Но для этого нужно преодолеть страх просить помощи. У нас это не принято: людям кажется, будто просить совета стыдно. На самом деле это норма. Писать можно кому угодно — тому, чьи статьи читал, кого видел на конференции, кого тебе посоветовали. Возможно, он не ответит. Возможно, предложит консультацию за деньги. Но если сделать хотя бы несколько попыток, обязательно найдётся тот, кто откликнется.
Важно не просить «вообще помощи», а приходить с чётким запросом: хочу менторство, стажировку, ревью текста, разбор портфолио. Это дисциплинирует и помогает выстроить разговор.
К тому же в процессе человек учится презентовать себя: объяснять, что уже умеет, какие у него сильные стороны и чем он может быть полезен. Это отличная практика саморефлексии — без неё в профессии тоже никуда.
И ещё одно: люди, которые любят свою работу, всегда чувствуют тех, кто по-настоящему заинтересован. Обычно они охотно помогают — советом, опытом, контактами. Это и есть нормальное, живое профессиональное сообщество, где все выигрывают от обмена знаниями.
Ещё советую идти на стажировки, например к нам в «Т-Банк». Это отличный способ увидеть, как всё устроено изнутри, и понять, в каком направлении хочется развиваться дальше. Конечно, стажировка не гарантирует трудоустройство, но даёт главное — опыт. А без него невозможно понять, подходит ли тебе профессия и как в ней расти.
С какими запросами приходят к тебе на менторинг?
Чаще всего — с вопросом, как войти в профессию. Это, пожалуй, самая популярная тема. Мы вместе разбираем матрицу навыков, определяем, какие компетенции уже есть, а какие нужно развивать. Потом выстраиваем путь: какие скилы прокачивать в первую очередь, какие шаги сделать, какие материалы изучить. Дальше начинается практическая часть — задания, обратная связь, корректировка курса.
Вторая большая категория запросов — менеджерские. Ко мне приходят специалисты, которые уже работают, но хотят научиться выстраивать процессы: наладить взаимодействие в команде, определить цели, выстроить отношения с коллегами и руководством. Это, по сути, про развитие управленческого мышления и зрелости.
Хороший ментор — это немного коуч. Он не просто учит инструментам, а помогает человеку понять себя: чего тот хочет и почему, к чему стремится и какие задачи действительно его двигают к цели. Чтобы не просто дать совет, а помочь разложить ситуацию по полочкам и выстроить осмысленный маршрут, нужен опыт.
Какие материалы оказались для тебя полезными в работе технического писателя?
Статьи о том, как документацию создают в других компаниях. Чтение помогло понять, как устроены процессы и какие подходы применяются в индустрии.
Курс в «Нетологии» — «UX-редактор». Считаю его очень качественным и продуманным. Хотя он не про техническое писательство напрямую, всё равно очень полезен. Особенно тем, кто планирует работать в продуктовой компании. Все крупные финтех-компании, такие как
Проект Documentat.io. Его создатели делают отличные курсы. Тем, кто хочет освоить профессию технического писателя, я бы порекомендовала изучать этот контент.
Школа редакторов помогла тебе узнать что-то новое и полезное для работы?
На самом деле, я пришла в школу уже достаточно опытным специалистом, с большим профессиональным бэкграундом, поэтому обучение не стало для меня каким-то откровением. Но, конечно, были инсайты, которые я забрала и использую.
Первое, что я запомнила и активно применяю до сих пор, — это принцип ФФФ. История
Второй принцип — «отложи на завтра». Он тоже оказался полезным. Я до сих пор учусь этому, но именно школа помогла выстроить чёткое понимание, как действовать в условиях перегрузки. У меня очень интенсивный ритм работы: постоянно приходят запросы, множество задач, люди с разными приоритетами. И этот принцип помогает сохранять фокус. Он учит быстро определять, действительно ли задача срочная. Если никто не пострадал и ничего критического не происходит — значит, сегодня можно этим не заниматься.
Что бы ты посоветовала людям, которые только начинают путь в профессии?
Если коротко — действовать, даже когда страшно. Никто не скажет, что я интроверт, но на самом деле это так: я быстро устаю от общения. При этом моя работа полностью построена на взаимодействии с людьми, и, несмотря на внутреннее напряжение, у меня это хорошо получается. Просто мало кто догадывается, что каждый раз, когда я знакомлюсь с кем-то новым, мне по-прежнему страшно.
Действовать, даже когда страшно
Но суть в том, что страх не должен останавливать. Нужно просто делать. Просить помощи, пробовать, искать решения — действовать, даже если не уверен в себе.