Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

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

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

Удобство работы конечного пользователя является критическим для успеха любого ИТ-проекта, цель которого — выйти за рамки создавшей его группы и отправиться покорять массы. С этим мало кто возьмется спорить. Традиционно удобство связывают с эргономикой интерфейса (usability). Но где-то на границе между usability и технической частью проекта находится не менее важная область — техническая документация, которая объясняет пользователю, как это эргономичный интерфейс должным образом использовать.

На западе технические писатели, дающие жизнь такой документации, в не меньшем почете, чем сами разработчики. А вот в России, к сожалению, официально технических писателей не существует. Это, правда, противоречит с огромным спросом на грамотных специалистов на рынке труда.

Чем, собственно, занимается технический писатель? Если в двух словах — то он занимается переводом инструкции с языка программистов на язык «обычных смертных». Практика показывает, что талантливые программисты редко умеют грамотно и связно выражать свои мысли «на бумаге», поэтому им в пару просто необходим специалист, который будет доводить их гениальную мысль до окружающих. Да и зачем тратить рабочее время программиста на литературные опусы, когда он может успешно развивать продукт дальше?

Итак, зачем же нужен технический писатель, порождающий десятки тысяч знаков текста, среднестатистической ИТ-компании?

Еще одна линия тестирования

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

Повышение эргономики интерфейса

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

Экономия времени внедрения решения

Какой бы ни была техническая документация, проданный продукт рано или поздно заработает (пускай на это будут потрачены часы рабочего времени технической поддержки, программистов и т.п.). Но грамотно составленный Quick Start Guide избавит пользователя от десятка грабель, торчащих изо лба, т.е. сэкономит время всем заинтересованным сторонам.

Повышение удовлетворения клиента от продукта

Обратиться ли к вам клиент впоследствии — зависит от того, как быстро и комфортно были удовлетворены его потребности. В этом смысле быстрое внедрение и грамотный Quick Start Guide ведут к повышению общей удовлетворенности покупкой.

Облегчение работы технической поддержки

Далеко не все пользователи сразу бросаются за телефон, как только сталкиваются с первыми трудностями. Многие пытаются справиться с проблемой собственными силами. И еще до того, как будет открыт вездесущий google, они нажмут F1 или откроют печатное руководство пользователя и попытаются найти ответ на свой вопрос. Будет ли информация из справки им полезна — зависит исключительно от квалификации технического писателя.

Техническим писателем не обязательно должен быть штатный сотрудник; за неимением большого объема работы можно обратиться и к аутсорсерам, работающим на сдельной основе. Но последние тенденции таковы, что многие предприятия со временем переходят с услуг аутсорсеров на собственных нанятых квалифицированных работников. Такой шаг можно рекомендовать любым организациям, занимающимся постоянными разработками. Аутсорсинг может быть полезен в том случае, когда есть желание постоянно развивать саму технологию написания документации. Очевидно, что те, кто строят на этом свой бизнес, будут «на коне» последних веяний. Но такие условия требуются единицам.

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

Дополнительные материалы

Комментарии (6)

  • Аватар

    Колмаков Антон [cheh], 18 февраля 2011, 14:54

    0
    Если технический писатель ещё  и специалист в предметной области, он как аналитик полезен.

    А вот что Можно бы обсудить - это требования к контенту, пораждаемому техническим писателем.
  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 18 февраля 2011, 17:41

    0
    В СНГ почему-то должность технического писателя рассматривают аналогично "прапорщику в армии":  не рядовой, но расти только до старшего прапора. Часто техписец на одном уровне с тестировщиком (то, что работу тестировщика часто недооценивают — промолчу).

    Хороший техписец стоит дорого, и найти его сложно. Но с другой стороны, любой хороший бизнес-аналитик может быть хорошем техписцем.
  • Аватар

    Давлицаров Андрей Рустемович [Tomi], 20 февраля 2011, 16:09

    0
    Техписец может не быть разработчиком, но обязан являться специалистом в предметной области. Будучи редактором отдела экономики в одной из ведущих городских газет утвердился во мнении: проще экономиста научить писать, чем журналиста экономике.
    Когда писал Инструкцию для собственных коллег-программистов на радиолокационной станции, а также пользователей - офицеров комических войск, исходил из следующей пропорции: 30 процентов описания относятся к нормальному запуску системы и ее обслуживанию, 60 процентов - диагностика сбоев и отказов, чтобы обезопасить себя от дурацких вопросов пользователей. А первые 10 процентов уходили на описание терминов, чтобы мы с пользователями говорили на одном языке. И чтобы не слышать в телефоне возмущенное "Ой у нас ничего не работает - приезжайте скорее".
    Но я вынужден был ориентироваться на военные стандарты. Полагаю, в гражданских системах все немного проще. Ведь можно User Guide написать так, чтобы он читался легко. Да и адаптировать его к каждому пользователю не столь уж сложно. Может, конечно, 20-летний опыт журналистики помогает. Но, повторюсь, писать "док"  должен специалист.
  • Аватар

    Котельников Илья [iluha], 21 февраля 2011, 09:46

    0
    Повышение эргономики интерфейса -
    хотелось бы, но на самом деле технический писатель добавляет всего лишь еще одну субъективную оценку. Его взгляд точно так же постепенно "замыливается", как и у любого разработчика продукта.
    (Проверено на личном опыте).
  • Аватар

    Солопов Павел [PaSol], 21 февраля 2011, 13:55

    0

    Многое, конечно, правильно сказано. Но естьи более чем спорные моменты. Но вот вопрос, особенно к автору сей статьи, который почему-то неизвестен.

    Как вы ставите задачу тех.пису? Просто: на тебе, дружище, дистрибутив, инсталируй, настраивай, разбирайся, а заодно и описывай?

    Или всё же разработчик, проектировщик или кто-то там ещё делает описание, а тех.пис уже причёсывает его и приводит в божеский вид?

  • Аватар

    Солопов Павел [PaSol], 21 февраля 2011, 13:58

    0
    Не знаю как уж там на западе с техюнисами, но знакомство с документацией одной на софт одной крупной и известной компании заставляет усомниться, что они уделяют этому серьёзное отношение. По качетсву не скажу, не столь силён в английском, а вот по полноте описания, часто очень слабо. Или вообще ничего, или много но не по теме.