В этой статье я завершу тему собеседований.
И вот о чем я хочу поговорить сейчас, так это о том, что требуют от технического писателя на собеседованиях, особенно коснусь такой злободневной темы как техническое задание.
Ой, не читайте дальше
В прошлых статьях я рассказал, что не всегда профессиональные качества техписа являются достаточными для трудоустройства, на данный процесс влияет множество качеств, начиная от того, с какой ноги встал собеседующий вас кадровик/начальник, до того, в какой неправильной обуви вы пришли. Да и ваш опыт, и ваши компетенции могут идти в разрез с видениями начальника, вплоть до полной несовместимости.
Когда вы приходите на собеседование, вас будут много спрашивать, очень часто затрагивая области, которые не являются вашими «родными», но от вас это будут требовать. Вы идете на позицию техписа для описания пользовательского интерфейса – будьте готовы, что начнут спрашивать API и умение составлять собственные примеры кода; идете на позицию, где требуется составить документацию на сервер – потребуют умение читать электрические схемы и чертить в CAD.
Отсюда и возникает самая большая проблема для технических писателей – узконаправленность. Если вы проработали достаточно больше время над документацией по ГОСТ, освоили и ЭС, и чертежи, знаете все нюансы ГОСТ 2, то при собеседовании в компании, где техпису надо будет разбираться в коде…, у меня для вас плохие новости: вы безнадежно отстали, и ваши шансы сменить специализацию ничтожно малы, оставайтесь в текущей специализации и всю жизнь пишите ГОСТы.
Так и есть, на самом деле, и не думайте, что в вашем случае будет по-другому. Пока вы сидели по уши в ГОСТ документации, ваши коллеги по цеху разбирались с системами верстками на xml, в том, как правильно пушить в GIT, и потихоньку точили гранит кода, вырастая за это время до уровня неплохого разработчика. Верно и обратное – вы никому не нужны с вашим кодом и гитом, если вы ни разу не писали ГОСТ документацию и не сдавали пакет документации государственному заказчику.
Вы отстали, и ваши шансы на собеседовании на не вашу специализацию стремятся к нулю, смиритесь, особенно, если вы живете в России, и вам уже за 35.
Впрочем, вернемся к самому собеседованию.
БезнадЁга
Придя на собеседование, вы подвергаетесь вопросам, которые по идее должны вскрыть вашу компетенцию, показать профессиональный потенциал и умение ясно и точно излагать позицию компании в документе.
Это неправда! Задача на собеседованиях в российских компаниях – это смотрины невесты/жениха. Вы можете писать отличные и понятные тексты, но собеседующий вас человек экстраверт, а вы интроверт – все, пока и до свидания. И самое страшное, что может случиться – вы начнете доказывать, что ваше видение документации лучше, и ваш подход к написанию документации правильней. Итог-то понятен, вас вежливо вышвырнут.
Не делайте так, если вам нужна работа, прикиньтесь болванчиком, оно спокойнее. И вот почему [о чем ниже].
Тестовое задание
Так мало букв и столько боли и потраченных нервов, времени. Вам дают тестовое задание на дом, отнимая столько драгоценного личного времени, чтобы что?! Вы думаете для того, чтобы выявить ваши компетенции? Отнюдь, не будьте наивны. Большинство тестовых заданий является частью уже действующего проекта и желанием бесплатно получить решения и, возможно, их же и внедрить. Ну а вам помашут ручкой. Особенно стоит остерегаться технических заданий, которые по своему объему занимает чуть ли не 3-5 полноценных рабочих дней. Мне становится смешно, когда такое исходит от компаний «рога и копыта», я готов смириться и сделать такое задание от Google, но не от очередной распиловской государственной дочки. Мы такие важные, мы лидера рынка, поэтому вот вам задание, напишите нам РЭ, а мы посмотрим, как вы справитесь.
Но даже если вы согласились сделать тестовое задание, не спешите и хорошенько обдумайте, как вы его напишите, что от вас ожидают. И это очень важно. В России проводится множество профессиональных конференций, где выступающие лекторы из года в год твердят, что они исповедуют «user friendly» документацию, что документация должна быть понятной и простой, что документация должна давать ответы на большинство вопросов человеку, её [документацию] читающему. Эти самые лекторы хвалятся друг перед другом о применяемых инструментах, о внедренных технологиях и прочему.
Не ведитесь! Они врут!
Никому в России не нужна качественная, понятная и читаемая документация. Выполняйте техническое задание максимально формализованным языком, чем ближе к ГОСТ, тем лучше. От вас не требуется донести до пользователя контент в понятном ему виде, от вас требуется документ, который будет максимально литературно нечитабельный и непонятный обычному человеку. Все красивые слова на конференциях о качестве контента остаются только словами вот уже много лет, структура и наполнение документа застряли в глубоком Советском Союзе, и, придя в это болото со своим, модернистским видением, вы рискуете остаться без работы.
Лучше с Программным Изделием и работой, знаете ли :)
А у нас не так!
Почему я это пишу, откуда я это знаю и какое право имею так утверждать?
Я постоянно участвую в конференциях, митапах, встречах, состою в различных профессиональных пабликах, общаюсь с иностранными коллегами, изучаю иностранную документацию. Я вижу, как развивается западная отрасль, как она все больше и больше становится ориентирована на обычного пользователя, как не боится идти на эксперименты и говорить с пользователем на одном языке. И чем дальше, тем сильнее разрыв в качестве контента и особенно в самом главном критерии документации – читабельности.
Также в силу своего хобби пишу различные технические статьи для нескольких крупных порталов и волей-неволей приходится просматривать похожие статьи своих коллег. И меня сильно удручает качество этих статей — крайне много копипаста, на разных порталах под разными никами копируются одни и те же ошибки, очень много тонких технических моментов и вовсе не указываются. При этом аналогичные статьи на иностранных порталах обладают большим функционалом и понятливее доносят мысль до конечного пользователя.
И когда я пытаюсь донести до русскоязычного сообщества, как мне кажется, правильные тенденции, то утыкаюсь в стену равнодушия, ибо никому ничего не нужно. Я хожу по собеседованиям, выполняю тестовые задания даже, казалось бы, инновационных компаний [как они сами себя называют] в попытках узнать, изменилось ли что-либо. Ничего.
Отсюда хочу сделать вывод: при подготовке тестового задания соблюдайте строгий язык формализма, не обманывайтесь яркими картинками на сайтах компаний.
Ну, а если подытоживать все статьи про собеседования, то помните, что самая частая фраза, которую я встречал на собеседованиях [да и каждодневной работе]:
- Документация должна быть написана так, чтобы её не хотелось читать @руководители, продуктовые менеджеры и прочие начальники.
Всем спасибо )
