Как меняется "техническое писательство" из-за usability

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



Итак, я писала, что для технических писателей существует диапазон ожидаемых заказчиком умений. Кому-то достаточно того, что техписатель потыкает на сайте мышкой, чтобы прописать последовательность действий пользователя, например, при регистрации на сервисе. Другим нужно, чтобы писатель вдумчиво переработал ТЗ, сформированное на этапе постановки задач программистам. Третьи хотят, чтобы результатом работы технического писателя было полноценное "исследование" в заданной области. К примеру, если мы говорим об описании для программного обеспечения автоматизации радиовещания, ставится задача прописать не только особенности интерфейса и возможности продукта, но и методологию работы с ним: принципы программирования эфира и т.п. Таким образом, условно технических писателей можно делить по квалификации, допустим, на "начинающих", "опытных" и "экспертов" (в зависимости от того круга задач, с которыми они способны самостоятельно справиться).
В отличие от других профессий, связанных с написанием текстов технической и "околотехнической" тематик, техписатель уже успел очень хорошо "засветиться" на сайтах с вакансиями. Тут и заказчики хорошо представляют, кто им нужен, и исполнители, если уж хотят заниматься документацией, так явно и пишут: "Резюме на вакансию технического писателя". Т.е. с помощью простого поискового запроса можно получить подборку и резюме, и вакансий, откуда легко определяется "зарплатная вилка". К сожалению, она-то потом и усложняет поиск действительно квалифицированных сотрудников.

По моему опыту общения с разными отделами, кадровики особо не пытаются с другими обсуждать полученные таким образом данные о предполагаемой зарплате. Редко идет разговор о том, чтобы собрать сведения, какие задачи предстоит решать техническому писателю в разных организациях, и применять какой-то сложный анализ для вывода адекватной суммы. Гораздо чаще берется "зарплатная вилка", а дальше методом "палец-потолок" определяется, насколько сложная задача стоит перед компанией (т.е. где именно внутри этой "вилки" расположить нанимаемого специалиста). Лишь в исключительных ситуациях зарплата предлагается существенно выше, чем "определяет" рынок.
Что получается в итоге? На простые и средне-сложные задачи специалисты находятся легко (их временные затраты отбиваются предложенным доходом), но для сверх-сложных задач компании ищут исполнителя годами. Квалифицированные исполнители не видят смысла идти на низкую зарплату, а повысить зарплату мотива нет, ведь "так делает остальной рынок". Замкнутый круг, из которого, безусловно, бывают исключения, но они встречаются не так часто, как того хотелось бы.

Вообще исключения встречаются тем чаще, чем больше заказчиков оказывается в "безвыходном" положении, когда нужен именно эксперт, иначе продукт не продать. Но сейчас ситуация с описаниями в принципе видоизменяется. С развитием концепции понятных пользователю интерфейсов, у многих компаний описания превращаются в документ, формируемый "для галочки" (для подписания акта приемки). При таком подходе требования к качеству этого документа не просто снижаются - они стремительно падают. Т.е. заказчик вполне может отказаться от услуг дорогостоящего "эксперта", наняв специалиста с требованиям поскромнее, не потеряв при этом продажи.
Проблема в том, что вместе с экспертом из компании (а иногда - и из отрасли в целом, ведь всем надо что-то кушать) уходит и умение описать не только пункты интерфейса, но и методологию работы. А, т.к. описания все же иногда требуются, изложить ее хочется. Дабы заполнить пробел, многие просто копируют в новые описания части о методологии из старых текстов, ведь методики изменяются гораздо медленнее. Спустя несколько редакций документ превращается в эдакого "Франкенштейна", где уже не прослеживается единая мысль и не отражены новые тенденции в работе. Но при этом существующий персонал компании не способен побороть порожденного монстра, поскольку тот, кто обладал видением, давно уволен.

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