5 причин взять в команду технического писателя

Удобство работы конечного пользователя является критическим для успеха любого ИТ-проекта, цель которого — выйти за рамки создавшей его группы и отправиться покорять массы. С этим мало кто возьмется спорить. Традиционно удобство связывают с эргономикой интерфейса (usability). Но где-то на границе между usability и технической частью проекта находится не менее важная область — техническая документация, которая объясняет пользователю, как это эргономичный интерфейс должным образом использовать.
На западе технические писатели, дающие жизнь такой документации, в не меньшем почете, чем сами разработчики. А вот в России, к сожалению, официально технических писателей не существует. Это, правда, противоречит с огромным спросом на грамотных специалистов на рынке труда.
Чем, собственно, занимается технический писатель? Если в двух словах — то он занимается переводом инструкции с языка программистов на язык «обычных смертных». Практика показывает, что талантливые программисты редко умеют грамотно и связно выражать свои мысли «на бумаге», поэтому им в пару просто необходим специалист, который будет доводить их гениальную мысль до окружающих. Да и зачем тратить рабочее время программиста на литературные опусы, когда он может успешно развивать продукт дальше?
Итак, зачем же нужен технический писатель, порождающий десятки тысяч знаков текста, среднестатистической ИТ-компании?
Еще одна линия тестирования
Технический писатель первым получит в свои руки работающий продукт. Более того, по роду своей деятельности он воспользуется практически всеми заложенными туда функциями. Такой человек снижает вероятность появления ошибки в продукте, попадающем клиенту.
Повышение эргономики интерфейса
С одной стороны общаясь с программистами, а с другой стороны, разглядывая продукт глазами обычного пользователя, технический писатель может рекомендовать наиболее удобные и эргономичные интерфейсные решения.
Экономия времени внедрения решения
Какой бы ни была техническая документация, проданный продукт рано или поздно заработает (пускай на это будут потрачены часы рабочего времени технической поддержки, программистов и т.п.). Но грамотно составленный Quick Start Guide избавит пользователя от десятка грабель, торчащих изо лба, т.е. сэкономит время всем заинтересованным сторонам.
Повышение удовлетворения клиента от продукта
Обратиться ли к вам клиент впоследствии — зависит от того, как быстро и комфортно были удовлетворены его потребности. В этом смысле быстрое внедрение и грамотный Quick Start Guide ведут к повышению общей удовлетворенности покупкой.
Облегчение работы технической поддержки
Далеко не все пользователи сразу бросаются за телефон, как только сталкиваются с первыми трудностями. Многие пытаются справиться с проблемой собственными силами. И еще до того, как будет открыт вездесущий google, они нажмут F1 или откроют печатное руководство пользователя и попытаются найти ответ на свой вопрос. Будет ли информация из справки им полезна — зависит исключительно от квалификации технического писателя.
Техническим писателем не обязательно должен быть штатный сотрудник; за неимением большого объема работы можно обратиться и к аутсорсерам, работающим на сдельной основе. Но последние тенденции таковы, что многие предприятия со временем переходят с услуг аутсорсеров на собственных нанятых квалифицированных работников. Такой шаг можно рекомендовать любым организациям, занимающимся постоянными разработками. Аутсорсинг может быть полезен в том случае, когда есть желание постоянно развивать саму технологию написания документации. Очевидно, что те, кто строят на этом свой бизнес, будут «на коне» последних веяний. Но такие условия требуются единицам.
Никто при этом не запрещает вывести собственного технического писателя за штат. Большая часть работы такого сотрудника может выполняться и дома, без ущерба для качества. А это более интересные условия для квалифицированных сотрудников, экономия на рабочем пространстве и компьютерах.
Дополнительные материалы
Дерик (Баранова) Екатерина [ekataios], 18 февраля 2011, 13:27
()
Комментарии (6)
КомментироватьКолмаков Антон [cheh], 18 февраля 2011, 14:54
А вот что Можно бы обсудить - это требования к контенту, пораждаемому техническим писателем.
Рубинштейн Кирилл [krubinshteyn], 18 февраля 2011, 17:41
Хороший техписец стоит дорого, и найти его сложно. Но с другой стороны, любой хороший бизнес-аналитик может быть хорошем техписцем.
Давлицаров Андрей Рустемович [Tomi], 20 февраля 2011, 16:09
Когда писал Инструкцию для собственных коллег-программистов на радиолокационной станции, а также пользователей - офицеров комических войск, исходил из следующей пропорции: 30 процентов описания относятся к нормальному запуску системы и ее обслуживанию, 60 процентов - диагностика сбоев и отказов, чтобы обезопасить себя от дурацких вопросов пользователей. А первые 10 процентов уходили на описание терминов, чтобы мы с пользователями говорили на одном языке. И чтобы не слышать в телефоне возмущенное "Ой у нас ничего не работает - приезжайте скорее".
Но я вынужден был ориентироваться на военные стандарты. Полагаю, в гражданских системах все немного проще. Ведь можно User Guide написать так, чтобы он читался легко. Да и адаптировать его к каждому пользователю не столь уж сложно. Может, конечно, 20-летний опыт журналистики помогает. Но, повторюсь, писать "док" должен специалист.
Котельников Илья [iluha], 21 февраля 2011, 09:46
хотелось бы, но на самом деле технический писатель добавляет всего лишь еще одну субъективную оценку. Его взгляд точно так же постепенно "замыливается", как и у любого разработчика продукта.
(Проверено на личном опыте).
Солопов Павел [PaSol], 21 февраля 2011, 13:55
Многое, конечно, правильно сказано. Но естьи более чем спорные моменты. Но вот вопрос, особенно к автору сей статьи, который почему-то неизвестен.
Как вы ставите задачу тех.пису? Просто: на тебе, дружище, дистрибутив, инсталируй, настраивай, разбирайся, а заодно и описывай?
Или всё же разработчик, проектировщик или кто-то там ещё делает описание, а тех.пис уже причёсывает его и приводит в божеский вид?
Солопов Павел [PaSol], 21 февраля 2011, 13:58