Как вы думаете, кто лучше всего знает продукт? PM, или может быть DM? Аналитик? Интерфейс-дизайнер? Ответ на все эти вопросы, скорее всего, будет «нет». По крайней мере, в случае большого проекта. Почему? Попробуем рассмотреть подробнее:
Главный. Он описывает концепт. Говорит: «Хочу, чтобы тут было синим, а эта кнопка всё уменьшала. А вот здесь, чтобы как в Windows 8 | iOS | в том приложении | лучше, чем у конкурента (ненужное зачеркнуть). И, очевидно, оно должно уметь делать всё красным и подкладывать квадратики».
Аналитик. Он пишет требования. Он знает, что должно быть в продукте. Он знает, как должны работать основные сценарии, но он обычно не вдаётся в тонкости реализации, ведь для этого есть интерфейс-дизайнер. И это задача интерфейс-дизайнера – сделать продукт красивым и удобным. Ведь продукт только на 20 процентов состоит из того, чем будут реально пользоваться, а на 80 – из маркетинговых материалов, галочек и сравнений с конкурентами. Иногда бывает даже так, что аналитик сильно удивлен по окончанию разработки тем, во что превратились его требования. Ведь, как известно, за время пути собака могла подрасти.
Интерфейс-дизайнер (ID). По требованиям рисует проект интерфейса. В идеальном случае проект – это практически единственный документ, которым нужно руководствоваться в разработке. Разве что часть технических спецификаций взять из требований. Но так бывает только в идеальном мире. В реальном мире интерфейс-дизайнер не обрабатывает разные исключительные случаи и ошибки. Это должен делать программист. Конечно, он советуется с ID в сложных ситуациях, но простые обычно делает сам.
Project manager (PM). Когда команда начинает не успевать, он приходит и проникновенным голосом спрашивает, почему мы не можем нарисовать красную линию зеленым цветом. А потом еще неоднократно уточняет и тиражирует полученную от разработчиков информацию, причем бывает, что через «испорченный телефон». Таким образом, PM обычно хорошо разбирается в проблемных частях продукта, причем имеет на всё это свой специфический взгляд. Впрочем, специфическим взглядом на любой вопрос отличается любой участник проекта. Но надо же что-то сказать про PM-ов.
Development manager (DM). Если продукт маленький (1-3 разработчика), он вполне понимает, что, как и зачем продукт делает. Если же продукт большой, то ему не хватит времени на вникание в детали. Для части функционала он вынужден доверять связке разработчик-тестер, считая, что там всё хорошо. Обычно DM хорошо разбирается в сложно реализуемых частях продукта и хуже – в простых и хорошо описанных интерфейс-дизайнером.
Итого, каждый из вышеперечисленных участников процесса разработки хорошо ориентируется на своей «поляне», но чаще всего не имеет полного представления о продукте.
Так кто же тот самый человек, который знает все? Это технический писатель. Работа технического писателя не только сложна и трудоемка, но и ответственна. Техпис должен сделать так, чтобы одинаковые вещи, сделанные разными людьми, назывались, во-первых – одинаково, а во-вторых – правильно. Он говорит «непонятно» и идет выяснять, что же происходит в данном месте программы. Именно он, в конце концов, должен придумывать названия новым фичам на основе неполных описаний разработчиков и формулировать тексты, описывающие сложные места программы. Он является переводчиком с программистского на русский. Технический писатель должен придумать понятный, красивый, и главное – короткий текст к функционалу, который, возможно, не совсем удачно спроектирован или реализован.
Кстати, вы знаете самый быстрый способ сделать продукт лучше? Конечно, переименовать кнопочки! Вот вам адаптация известного комикса на эту тему от vonvogel:Что ещё? Техпис проверяет целостность разных частей интерфейса и их соответствие друг другу. А ещё он пишет справку. Причем пишет так, чтобы она была понятна даже ёжику. Поэтому задача технического писателя заключается в том, чтобы написать хорошую справку. В которой пользователь всегда найдет ответ на свой вопрос, ответ этот будет понятным, и поиск его займет минимум времени. Что же это означает на практике? Структура справки должна быть интуитивно-понятная и как можно более простая. Текст должен читаться легко, фразы должны быть однозначными и по возможности более короткими. Нужно избегать сложных конструкций, текст должен быть хорошо сбалансированным – не слишком простым и не слишком навороченным, не бедным лексически, но и не полным витиеватых выражений. Нужно уметь простыми словами объяснять сложные вещи. Чтобы не путать пользователя, должно соблюдаться единообразие стиля изложения и оформления. Справка должна соответствовать продукту, т.е. необходимо описать новую функциональность, удалить то, чего больше нет, переписать то, что изменилось. И все это в условиях, когда программы либо еще нет, либо она не протестирована, либо не отлажена. Поэтому невозможно посмотреть, что и как работает.
Тут вспоминается история, как много-много лет назад выпускали мы продукт для нужд госучреждений. Продукт был на тот момент неполноценным – ни аналитика, ни дизайнера, один программист да тестер. О том, что в новой версии надо обновить документацию, вспомнили за пару дней до выпуска. Все бы ничего, но программа на тот момент не устанавливалась и не запускалась. Описать новый функционал со слов разработчика для опытного технического писателя – не проблема. Но мы же помним, что программа для госучреждений, да? А в них, как мы знаем, очень часто работают тетеньки средних лет, которые с компьютером не дружат и всего боятся. Мы, ясное дело, стараемся им помочь, отсюда – невероятное количество скриншотов в справке. И в результате получаем картину: программист пытается закончить продукт, тестер — запустить, PM бегает от одного к другому, вопрошая, успеем за сегодня все поправить и потестировать или нет, а технический писатель… правит в
А ещё технические писатели делают пользовательские руководства, руководства администратора, краткие руководства пользователя и много чего ещё. У каждого документа свое назначение, а значит, свои особенности и нюансы.
А еще мы выпускаем продукты для разных стран, поэтому техническим писателям у нас вообще скучать не приходится – программы нужно локализовать на много языков, хороших и разных. Именно техпис у нас собирает все материалы на перевод, проверяет их, встраивает в продукт, вносит изменения, возникающие по ходу разработки. Подробнее о серьезности процесса читайте тут.
Есть ещё одна история. Некоторое количество лет назад выпускали мы FineReader N. С файном у нас было все как полагается: аналитики проанализировали, дизайнеры нарисовали, программисты реализовали, техпис описал и все было переведено на 22 языка. И тут на тебе – бета-тестирование. И говорят нам пользователи (вернее даже один пользователь, а еще вернее, пользователь номер один): «А верните-ка нам две команды, ну, никак не можем без них жить. Да, заодно удалите два лишних сценария». Спросили DM’а, долго ли менять. «Нет, – говорит, две строчки закомментировать и две расскоментировать». Обрадовались все, кроме технических писателей. Им нужно было внести изменения в ресурсы программы, в справку, в руководства пользователя (которые были уже сверстаны к этому моменту), в QRC (она же Quick reference card или карточка быстрого знакомства), переснять часть скриншотов… Для одного языка получилось 49 правок. На количество языков умножьте сами (рисунок от MKrivosheev может помочь, если calc не работает. Видео-пояснения к картинке).Получается, что в идеале, каждый технический писатель должен одновременно быть немножко аналитиком, дизайнером, тестером, а иногда еще и программистом (техписы же и продукты для разработчиков описывают – например, такие).
В результате технический писатель – это такой супермен (хотя чаще всего супервумен) в команде разработки. Он должен быть одновременно и гуманитарием и технарем, иметь базовые представления о программировании и информационных технологиях, уметь разбираться в самых различных программах, от простых (например, Word) до довольно сложных (например, Visual Studio). Он должен быть дотошным и внимательным к мелочам, но при этом видеть продукт целиком, чтобы понимать, как лучше его описать. Уметь четко планировать свою работу, чтобы не утонуть в море своих задач. Обязан прекрасно владеть письменной речью и знать английский язык, как минимум, на уровне чтения документации. Не забудем про стрессоустойчивость, способность работать в режиме аврала, быстро переключаться с одной задачи на другую, и еще много-много всего. В общем, хороший технический писатель – штучный товар. Поэтому любите ваших технических писателей, берегите их и всячески им помогайте. Ибо без них ваши продукты будут немножко убогими и косноязычными, а с ними у вас будут счастье, деньги, успех. Ну, или, как минимум, хороший продукт.
Иван Корнеев chronomaster при участии Елены Фоменко,
Департамент продуктов для распознавания текстов.
