SickJournal

Те, кто знает, о чем идет речь, похожи на тех, кто спит.

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

Поэтому далее - в двух словах о том, чем должен заниматься хороший квалифицированный технический писатель, строго на собственном опыте. «А ты что за хрен?» - 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 ошибок только в русском языке. Показал, говорю, смотрите, тут неверно, тут, вот тут. На что получил ответ: «Ну это же для медицинского учреждения документ. Для медиков, понимаете. Им всё равно, суть-то ясна - это главное!». А почему, спрашиваю, у вас описание каких-то действий в ТЗ содержится. Отвечает, мол, удобно, все сразу в одном документе.

Взял троих, ни об одном не пожалел.
Наташа, Антон, Николай, Никита, если вы это читаете - спасибо вам еще раз за вашу работу :)

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

  • 1
Взял троих, а в следующем предложении перечислил четверых — нипанятна-а :–)

Один из перечисленных перешел из отдела в отдел.

За последний абзац особое спасибо. Стало понятно, что не только у нас в документах все странно. Хотя, с другой стороны, это очень грустно.

Почти у всех так. По крайней мере, судя по документации, которую мы получаем от субподрядчиков и других подрядчиков.

Что делать, тоже понятно - хорошо работать. Как говорит один наш коллега, "давайте постараемся сделать хорошо, говно - само получится".

И еще надо воспитывать заказчика. Объяснять, что он имеет право требовать в плане документирования, что нет, согласовывать формы и шаблоны.

Короче, подходить к вопросу системно. Что, опять же, получается не всегда, но всё равно надо стараться.

  • 1
?

Log in