Про работу и собеседования

Когда говоришь, что работаешь техническим писателем, со стороны собеседника неизменно следует шутка про чукчу. Обидно за профессию.

Поэтому далее — в двух словах о том, чем должен заниматься хороший квалифицированный технический писатель, строго на собственном опыте.

«А ты что за хрен?» — 9 лет как технический писатель, 2 года как руководитель группы технических писателей.

Картинок дальше не будет, только буковки.

Чем занимаются технические писатели:

1. Оказывают помощь в формировании, оформлении и проверке документации, например, функциональных требований (ФТ), технических заданий (ТЗ), технорабочих проектов (ТРП), программ и методик испытаний (ПиМИ), описаний технических решений (ОТР), общих описаний системы (ООС), руководств пользователей/администраторов/технологов, какие там роли в системе есть. Если квалификация тех. писателя низкая, он может только проверить оформление и русский язык. Если высокая, и технический писатель способен анализировать и тестировать, то он может проверить логику построения ТЗ, ТРП, нарисовать функциональные макеты интерфейсов, а также самостоятельно (без предоставленных тестировщиками тест-кейсов) написать ПиМИ. Настоящие джедаи вообще умеют писать ПиМИ только по ТЗ и ТРП.
2. Формируют разного рода вспомогательную документации, например, программу обучений пользователей и раздаточные материалы, презентации, инструкции для сотрудников колл-центров. Хороший технический писатель понимает, для кого и что он пишет. Поэтому, например, инструкция по работе с контентом сайта, который наполняют 20-летние маркетологини, должна быть построена одним образом, с одними акцентами. Инструкция для отдела 50-летних тётушек, которые до этого вообще редко видели компьютер — совсем другим образом.
3. Поддерживают документацию в актуальном виде после сдачи системы в промышленную эксплуатацию. Обычно после окончания проекта, когда на всей документации стоит штамп «Согласовано», заказчик начинает генерировать «хотелки» — давайте тут кнопочку, давайте тут переделаем, тут вчера решили по-другому и прочее. Одновременно заказчик хочет иметь доступ к некой (всегда актуальной) версии документации. Обычная практика — на основе проектных документов сформировать некое описание системы (единое или разбитое на части) и далее документировать все хотелки заказчика по факту их реализации, например, на базе некой вики-подобной системы.

А теперь о том, какую роль играет технический писатель в проектной группе. Я рассматриваю работу по проекту в довольно крупной конторе, которая, например, на протяжении 5-7 лет разрабатывает, модифицирует и расширяет некий продукт, сторонний или свой.

Каждый из участников проектной группы смотрит на проект в некой своей собственной перспективе. Аналитик — на уровне бизнес-процессов, разработчик — на уровне, скажем, интерфейсов и сервисов. И только технический писатель видит проект весь и целиком — только он читал, разбирался и правил всю документацию, а также лишний раз проверил, что эта документация соответствует действительности. Поэтому хороший технический писатель:

1. Видит косяки, которые не видит больше никто — несоответствие бизнес-логики и логики в реализации, кривости интерфейса и прочее. И если это хороший тех. писатель, он тут же сообщит об этом аналитиками и разработчикам. А то и выдаст ценный совет.
2. Является центром компетенции. Только технический писатель знает, как что-то должно работать, работает сейчас, как будет работать, кто этим занят и где это описано. Критически важным это свойство является тогда, когда, например, модифицируется одна из подсистем большой системы. А система в целом состоит из 20–30 таких подсистем, тогда приходится держать в голове не только саму модификацию, но и связи модифицируемой подсистемы с другими подсистемами. Только тех. руководитель проекта и технический писатель понимают в этом случае, какие конкретно изменения необходимо внести в описания каких подсистем и связей (сервисов, например), чтобы актуализировать документацию.
3. Является единственным, кто способен нормально провести обучение пользователей и ответить на самый широкий спектр вопросов, от «Что делает эта кнопочка?» до «Как настроено кеширование?». Именно потому, что имеет то самое мета-видение системы, о котором я написал выше.

Подытоживаю: основная роль технического писателя — упорядочивать хаос, который неизбежно возникает в процессе разработки и модификации любой мало-мальски сложной системы. Следить за всеми процессами — анализа, разработки, тестирования — и вовремя указывать участникам рабочей группы на потенциальные косяки.

Ну и писать дурацкие инструкции, которые никому не нужны, естественно. Это я к тому, что среди идиотов и всевозможных людей, которые никогда не писали и не документировали ничего более сложного и важного, чем «Блокнот», бытует такое мнение, что, мол, информация о том, как и что внутри работает, передается из уст в уста. А интерфейс должен быть интуитивно понятным, и если надо писать бумажки, то это явно говорит о плохом дизайне. И делать это может любой идиот.

Так вот.

Когда стало понятно, что группу тех. документирования необходимо расширять, я попросил сотрудницу отдела HR открыть вакансию, отобрать резюме и прислать их мне. Проводились такие поиски уже дважды, ниже я описываю ситуацию обобщенно.

Собеседования проводил сам. Собеседование было единственным «препятствием» на пути кандидата к должности тех. писателя, решение берем/не берем принимал лично я. С кандидатами разговаривал, а также выдавал текст на 2 страницы, в котором было необходимо исправить все ошибки, которые кандидат сможет найти или посчитает ошибками. Текст содержал массу разнородных косяков: простые описки, некорректно оформленные части, логические противоречия и несогласованности, стилевые ошибки. Часть информации просто отсутствовала, о чем можно было догадаться, если хоть какой-то опыт работы в области у кандидата был. Ошибку содержал и единственный приведенный в тексте скриншот. На вычитку документа давалось 20 минут, что чудовищно много для двух страниц неплотного текста, да еще и с картинкой. Кандидат оставался один на один с выданным ноутбуком, с доступом в интернет. В ворде, который стоял на ноутбуке, была отключена автопроверка орфографии, при этом я просил при выполнении задания пользоваться всеми доступными им средствами, хоть звонить друзьям.

Итоги вот какие:

• Из примерно 20 человек двое догадались включить автопроверку орфографии. То есть просто верно поняли задание.
• С отключенной проверкой орфографии лишь только двое исправили большую часть опечаток в тексте, один исправил почти всю логику, один (помимо корректировки логики) увидел, что скриншот некорректный.
• Почти никто не знает, как пишется слово «молодежь». Почти никто не понимает, что в технической документации тексте слово «система» в 99,99% не может писаться с маленькой буквы.
• Почти никто не знает, как оформляются списки. Почти никто не понимает, что выделяется кавычками, а что нет, и какими конкретно кавычками. Про правописание частицы «не», правописание слова «геолокация» я вообще молчу.

То есть более-менее с корректировкой дурацкой инструкции справились 4 человека. Почти все хотели зарплату не менее 50 тыс. рублей (указана в вакансии не была, называли сами), почти все считали себя едрическими профессионалами и сразу начинали спрашивать, сможет ли компания купить им удобное кресло и мощный компьютер со вторым монитором, кормят ли обедом бесплатно и можно ли приходить попозже.

50 штук за русский чуть выше уровня школы и умение мыслить логически.

Пока просматривал резюме и беседовал лично, видел всякое.

Один пришел в шлепках и с черным мусорным пакетом в руках. Сидел и держал его на коленях, пока писал тестовое задание. На мое предложение переложить пакет на соседний стул, чтоб не мешал, резко отказался и злобно посмотрел.

Другая перечислила в резюме все страны, в которых была. Это прекрасно, но для резюме клёвой чикули, не для резюме технического писателя.
С еще одной состоялся такой диалог:
— У меня есть для вас тестовое задание, на 20 минут буквально.
— Э… мне еще дочку из садика забирать…
— Его надо сделать в любом случае, дома нельзя. Поэтому давайте сейчас.
— Ну… меня обычно так брали на работу, без тестовых заданий…
Тётка хотела вдвое больше, чем платят тех. писателю в среднем по Питеру.

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

Взял троих, ни об одном не пожалел.

Наташа, Антон, Николай, Никита, если вы это читаете — спасибо вам еще раз за вашу работу 🙂

Вот так обстоят дела с «любыми дураками», которые могут писать инструкции.