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

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

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

Почему же такой человек в один прекрасный день может взять и уйти?

В этой статье хочу поделиться своим опытом, без отсылки на умные исследования Гарварда и Стэнфорда. Для себя выделила пять причин. Ими делюсь.

1. Нет включения в командную работу.

2. Нет обратной связи.

3. Нет цели.

4. Нет контроля.

5. Нет ценности.

Заранее благодарю за комментарии и дополнения.

Причина 1. Нет включения в командную работу

Мы плывем в одной лодке. Слышали такое выражение у себя в команде? По-моему, это очень верное сравнение: работы команды над проектом в ИТ с работой экипажа корабля.

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

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

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

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

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

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

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

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

Техписатель полноправный член экипажа на вашем корабле. Его ошибка может стоить успеха всего проекта. Поэтому вовлекайте его в проект полностью и всегда. А не только тогда, когда по вашему мнению должно быть начато документирование. Этим вы не только облегчите его работу, но и дадите почувствовать себя нужным человеком в команде. А это очень важно для качественного результата. Но вы это и сами знаете, да?

Причина 2. Нет обратной связи

Если новой фичей начнут пользоваться сразу после релиза, то документацией по этой фиче начнут пользоваться после n-ной неудачной попытки получить нужный результат. Так бывает во всех продуктах. И даже если документ реально поможет пользователю получить от новинки то, что он хочет, автор документа вряд ли об этом узнает.

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

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

А теперь поднимите руки те, у кого в команде так заведено. Особенно те, у кого техписатель один на всех.

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

Мы люди. И мы не можем всегда все делать правильно. Да еще и так, чтобы другим было понятно.

Поэтому: налаживайте процесс вычитки документации у себя в команде. Давайте своему техписателю обратную связь. Как положительную, так и конструктивно отрицательную, если вам или пользователям что-то не нравится.

Мой личный опыт дал мне понять, что если по документу все хорошо или к нему нет замечаний, значит, никто мой документ не читал. Потому что все не может быть всегда хорошо. Потому что я человек и я могу сделать опечатку, если и не логическую ошибку. За первое просто неудобно перед людьми, за второе Можно схлопотать от руководства и клиента. Но и первого, и второго можно избежать, если просто проверить документ. Хотя бы один раз, свежим взглядом.

А еще правильная обратная связь поможет вашему техписателю развиваться и совершенствоваться. То же самое будет происходить и с документацией на вашем проекте. Ведь это ему не помешает, верно?

Причина 3. Нет цели

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

Поэтому задача написать хоть что-нибудь, просто потому что проект заканчивается, а о нем ни слова не написано, меня лично сбивает с толку.

Какая информация и от кого мне может понадобиться для создания такого документа? Какую проблему я решаю, когда мне нужно написать хоть что-нибудь? Кому я помогу, если я напишу хоть что-нибудь?

Вы можете ответить: ну, как же, вот уйдет проект в поддержку, там и пригодится вот это что-нибудь.

Поэтому: давайте будем ставить четкую задачу техписателю. Мол, нужно описание проекта, которое могло бы помочь ввести в курс дела новенького разработчика, который будет поддерживать этот проект. Например. Цель есть, проблему решаем. Всё отлично!

А если мы решили написать хоть что-нибудь для кого-нибудь, кого проект, возможно, но не факт, может заинтересовать, то и пары предложений будет вполне достаточно. И можно даже не трекать. Кому надо, тот и сам все сможет узнать, верно?

Причина 4. Нет контроля

На первый взгляд отсутствие контроля за работой это вух-ху! как здорово.

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

Главное сдай документ вовремя. Всё. Шикарно же, разве нет? Нет.

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

Когда у тебя задач пять, отодвинуть их в сторону и взять шестую с, конечно же, самым высоким приоритетом не сложно. Но а что если у тебя таких задач штук 10-15? И пусть 2-3 из них, ну, не срочные, но чем быстрее, тем лучше?

Ты оставляешь их в неопознанном статусе на неопределенное время. Потому что вникнуть в абсолютно новую задачу быстро не получится. Пока вопросы, пока ответы. А там глядишь, и до конца срока дня два осталось. А ты злишься-кипятишься и не укладываешься в них. (Дальше по сценарию.)

Поэтому: изредка, раз-два в месяц, интересуйтесь, как там вообще у вашего техписателя дела. Обязательно посмотрите, чем он может быть занят в тот момент, когда вы собираетесь обрадовать его новой задачей. И обсудите с ним вместе, как быть.

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

Причина 5. Нет ценности

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

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

Первый: документация у вас будет, но качество ее будет сомнительным. Вашу команду такое устроит?

Второй: документация у вас будет и будет качественная, но в один не предвещающий ничего плохого день вы получите от вашего техписателя письмо с заявлением о добровольном увольнении. Когда вы на последней встрече 1 на 1 спросите у него, в чем дело, он ответит (если у вас доверительные отношения), что не ощущает, чтобы его работу ценили.

Вот это ощущение отсутствия ценности себя как специалиста в команде очень сложно объяснить. Ты просто чувствуешь это, и всё. Потому что тебя не зовут на демо, тебе не дают обратную связь, тебе не помогают определить цель и твою работу никто не контролирует.

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

Поэтому: осознайте необходимость и ценность хорошей документации на вашем проекте уже сейчас. Спросите себя, зачем вам документация? Кто ее конечный пользователь? Какой она должна быть? Даже если вы не сможете дать четкие ответы на эти вопросы, не переживайте хороший и ответственный техписатель вам поможет. Но вы должны дать ему хоть какую-то информацию, а еще время и мотивацию для дальнейших исследований.

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

Но если вы не можете дать себе ответ ни на один из вопросов выше, просто не нанимайте технического писателя. Пусть документацию пишут разработчики, QA-инженеры, аналитики, архитекторы, тим лиды, менеджеры. Кто угодно. И чуть позже вы сможете нанять техписателя, потому что поймете, почему же он все таки вам нужен.

Удачи!

Несколько лет назад я услышал от одного коллеги историю. Он в то время работал начальником отдела технической документации в IT компании. Дело было на собрании, посвященном знакомству с новым техническим директором. Тот, пожав моему коллеге руку и узнав о его роли, пошутил: Документация? Так ее же не читает никто! Двадцать первый век на дворе.

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

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

Что такое хорошая документация?

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

А в чем задача документации? Ответов на этот вопрос может быть много. Документация может использоваться для обучения, для справки, или даже служить своего рода рекламой. Я слышал от коллеги историю о том, как менеджер по продукту просил ее написать документацию для нового продукта за три дня, делая упор на том, что все равно какую, ее никто читать не будет, она нужна только чтобы проект сдать. И это тоже задача, хоть и очень грустная.

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

Хорошо, допустим. А что позволяет документации выполнять задачу? Какая она, хорошая документация, и как ее создавать? Есть ряд практик, которым мы следуем, когда пишем документацию в Plesk, и сегодня я хотел бы о них рассказать. Итак...

Хорошую документацию легко найти

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

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

1. Человек начинает пользоваться Plesk.

2. Человек сталкивается с затруднением.

3. Человек пытается разобраться с затруднением самостоятельно.

4. Когда желание преодолеть затруднение пересиливает нежелание тратить время на поиск помощи, человек вводит запрос в Google и открывает первую ссылку в выдаче.

Замечу, что по данным Google Search Console запросы пользователей не включают слово документация. Люди ищут plesk login, plesk install, plesk ftp и так далее. Скорее всего, запросы, по которым пользователи находят документацию вашего продукта, выглядят похоже. Чтобы пользователям было проще найти вашу документацию, важно использовать те термины и формулировки, которые они используют. Это особенно важно в случае если поисковая система на вашем сайте документации не очень хорошо производит нечеткий поиск.

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

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

Как же привлечь внимание пользователя за те десять секунд, что у нас есть? Отличная практика разместить в самом начале каждого раздела краткое (не больше трех-четырех предложений) описание его содержания, в идеале оформив его так, чтобы оно визуально отличалось от остального текста и бросалось в глаза. Сюда же можно добавить ссылки на схожие по смыслу разделы, чтобы облегчить дальнейший поиск пользователям, оказавшимся не там, где они планировали. Вот как может выглядеть такое описание:

В этом разделе вы узнаете, как создать новый FTP аккаунт в Plesk. Если вы хотите узнать, как изменить логин или пароль существующего FTP аккаунта, пройдите по ссылке.

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

Хорошую документацию легко понять

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

В работе я руководствуюсь высказыванием Антуана де Сент-Экзюпери: Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать. Когда готов первый черновик документации для новой фичи, первое, на что я смотрю можно ли сделать текст проще и короче. Что помогает в этом?

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

• Простые предложения.

• Короткие (4-6 предложений) абзацы.

Впрочем, здесь же я хочу упомянуть и еще одно правило, которым руководствуюсь: Пиши так коротко, как возможно, но не короче. Не нужно выплескивать ребенка вместе с водой и приносить полноту и ясность в жертву краткости.

От одной коллеги я слышал о таком любопытном юзкейсе: в ее организации документацию пишут на английском языке, но клиенты пользуются ей по всему миру. Поэтому технические писатели намеренно используют максимально простой английский, чтобы встроенные в современные браузеры автоматические переводчики могли как можно более точно выполнить перевод. Таким образом, клиенты по всему миру могут читать документацию на родном языке, а организация не платит за перевод. Это было бы невозможно без осознанных усилий, направленных на то, чтобы сделать текст документации максимально простым и понятным.

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

Некоторое время назад я искал технического писателя в свою команду. В тестовом задании, предлагавшемся соискателям, была просьба написать короткую инструкцию, объясняющую, как установить расширение в Chrome. Один из кандидатов снабдил каждый шаг полноразмерным снимком экрана, что раздуло небольшую инструкцию на пару страниц. Чем это плохо? Напомню, что попадая на новую страницу, человек не начинает вдумчиво читать, он пробегается по ней глазами. Большой объем вкупе с обилием иллюстраций отпугивает, несложная процедура кажется чем-то сродни запуску ядерного реактора. Сложилось ощущение, что у соискателя были какие-то установки ("снимки экрана это хорошо"), но не было понимания, что любым инструментом нужно пользоваться к месту и в меру. Отбор он не прошел.

Хорошая документация описывает сценарии

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

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

В свете этого, когда пользователь обращается к документации, написанной с использованием классического подхода, ему приходится конструировать процедуру самостоятельно, зачастую из информации, разбросанной по разным разделам. Хмм, наверное, мне нужно сперва сделать вот это действие, потом вот это, а затем вот это? И тут сразу возникают следующие проблемы:

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

• Сконструированная пользователем процедура может быть неполной или вовсе неверной.

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

• Если сценарий не очень частый, пользователю, возможно, придется вернуться к нему через продолжительное время. К тому времени он может уже забыть о том, как выполнять нужную процедуру, и ему потребуется конструировать ее заново.

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

• Как мне создать почтовый ящик?

• Как мне поменять пароль?

• Как мне удалить базу данных?

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

Хорошая документация самодостаточна

При написании документации в Plesk мы руководствуемся принципом Every page is page one (EPPO) почерпнутым из одноименной книги Марка Бейкера. Чтобы понять его суть, давайте подумаем о том, как люди читают печатные книги, и как ищут информацию в Интернете:

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

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

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

Приведу пример. Некоторое время назад для того, чтобы защитить сайт SSL сертификатом, нужно было выполнить в панели Plesk следующие действия:

1. Сгенерировать запрос на подпись сертификата (certificate signing request) и купить сертификат в центре сертификации (certificate authority).

2. Загрузить полученный сертификат в хранилище.

3. Выбрать загруженный сертификат в настройках веб сервера.

Номинально, каждый из приведенных выше пунктов можно рассматривать как отдельный сценарий, но подобный подход может ввести пользователя в заблуждение, так как для достижения цели (сайт защищен SSL сертификатом) нужно выполнить все вышеприведенные действия в правильной последовательности.

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

Хорошая документация достоверна

Иными словами, она точно отражает то, как продукт выглядит и работает прямо сейчас, а не полгода назад. В наше время SaaS-продуктов, коротких релиз циклов и принудительных автоматических обновлений это правило, к сожалению, нарушается все чаще. Как ни странно, этим нередко грешит документация гигантов индустрии, таких как Microsoft или Google.

Думаю, не нужно объяснять, почему это вдвойне плохо, когда официальная документация содержит недостоверные сведения. Логотип компании на странице документации внушает уверенность, и посетитель тратит время попусту, пытаясь найти кнопку, которую убрали из интерфейса три релиза назад. Когда он понимает, что инструкции неверны, это действует как ушат холодной воды на голову и подрывает доверие и к документации, и к продукту, и к бренду. Единожды солгавший, кто тебе поверит?

Для того, чтобы подобного не происходило, команда технических писателей должна иметь следующее:

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

• Достаточно ресурсов, чтобы своевременно отражать эти изменения в документации.

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

Хорошая документация пишется для определенной аудитории

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

К счастью, с этим искажением можно справиться. Достаточно помнить о нем и знать, кто целевая аудитория документации, которую вы пишете, и каким багажом знаний обладает ее среднестатистический представитель. Например, если вы документируете клиент Git, можно предположить, что представителю целевой аудитории не нужно рассказывать, что такое система управления версиями или как сделать коммит, но стоит задокументировать, как настроить доступ в репозиторий по SSH ключу. А если у вас в голове возникает мысль Это, наверное, всем известно, напомните себе, что вы пишете документацию не для всех, а для конкретной аудитории с конкретными знаниями и потребностями.

Проиллюстрирую этот пункт следующим примером: несколько лет назад я получил обратную связь от двух разных пользователей на один и тот же раздел. Она звучала примерно так:

• Пользователь А: Что вы пишете, как для дураков? Разжевываете вещи, которые любому известны!

• Пользователь Б: Вы знаете, не каждый из нас гений. Пожалуйста, пишите яснее, мне ничего не понятно.

Как вы думаете, кто из них был прав? На самом деле, правы оба. Судя по всему, раздел, на который они жаловались, как раз и был написан для всех, но в итоге не смог сослужить службу никому. Он был слишком сложен для новичка, но не содержал подробностей, интересных эксперту. Как избежать подобных ситуаций? Знать, кто целевая аудитория, и писать с учетом ее потребностей. Ничего страшного, если вы получаете обратную связь только одного типа (слишком сложно или слишком просто) это означает, что жалуются люди, не входящие в ЦА (конечно, если подобных обращений не десять штук за неделю).

Хорошая документация оказывает поддержку

Один из верных признаков плохой документации она разжевывает очевидное, но не оказывает поддержки там, где это нужно. Не всегда достаточно просто перечислить шаги, которые необходимо пройти для достижения цели. Если в процессе того или иного сценария пользователю нужно сделать выбор, последствия которого не каждому могут быть очевидны, документация может и должна облегчить принятие решения, дав дополнительную информацию. Это называется "помощь в принятии решения" (decision support).

Приведу пример. В Plesk для защиты от спама используется программа под названием SpamAssassin. Одна из доступных пользователю настроек (spam filter sensitivity) управляет тем, насколько строго фильтр отсеивает входящие письма с подозрением на спам. Работает она просто: пользователь задает значение, выраженное положительным числом не больше 127. Чем меньше число, тем строже фильтр. Вот как могла бы быть описана эта настройка в плохой документации:

Введите желаемое число в поле Spam filter sensitivity и нажмите Ok.

Технически вышеприведенная инструкция верна, но практически от нее мало пользы. Пользователь, не знакомый с работой SpamAssassin, не знает, какое число он может ввести и как это повлияет на работу фильтра. Как можно было бы сделать лучше?

Введите желаемое число (больше 0 и не больше 127) в поле Spam filter sensitivity и нажмите Ok. Чем меньше число, тем меньше вероятность того, что в ваш ящик попадет спам, и тем больше вероятность ложного срабатывания, и наоборот.

А можно ли сделать еще лучше? Как насчет такого:

Введите желаемое число (больше 0 и не больше 127) в поле Spam filter sensitivity и нажмите Ok. Чем меньше число, тем меньше вероятность того, что в ваш ящик попадет спам, и тем больше вероятность ложного срабатывания, и наоборот. Рекомендуемое значение 7, оно обеспечивает надежную защиты от спама с минимальной вероятностью ложного срабатывания и подойдет большинству пользователей.

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

Как еще можно облегчить жизнь пользователя? Не превращать его в Буриданова осла. Если продукт позволяет добиться того или иного результата несколькими путями, я не описываю их все. Я выбираю оптимальный (самый простой, самый быстрый и так далее) и рассказываю только о нем. Если же между этими путями есть разница (скажем, один быстрее, но подразумевает действия, требующие технических навыков или потенциально рискованные, например, выполнение запросов INSERT или UPDATE в базе данных), я описываю все варианты, эксплицитно указывая на различия между ними, чтобы помочь пользователю выбрать оптимальный для него вариант.

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

Заключение

Теперь вы знаете, как писать хорошую документацию по версии Plesk. Прежде чем откланяться, я хотел бы рассказать еще об одном принципе, который я также позаимствовал у Марка Бейкера. Он звучит просто Напиши одну хорошую страницу (Write one good page). Почему он кажется мне очень важным: если у вас уже есть массив документации, написанный по старинке и не соответствующий лучшим практикам, велик соблазн опустить руки. Переписать все с нуля это целый подвиг! У нас нет столько времени и ресурсов! Но это не обязательно.

Наверняка среди вашей документации есть более посещаемые разделы и менее посещаемые (а если вы не знаете, сколько посетителей читает вашу документацию, то это отличный повод настроить веб аналитику). Переработайте ваш самый посещаемый раздел. Проследите за реакцией пользователей. Сделайте выводы, внесите коррективы, возьмитесь за второй по популярности раздел. И, возможно, пожимая вам руку, новый технический директор скажет Документация? Это же очень важно! Загляну к вам в три часа, хочу узнать, как вы работаете.

Спасибо за внимание!

P.S. Хочу сказать Спасибо! моим коллегам Катерине Говердовской и Владимиру Головизнину за помощь в подготовке статьи.

Мы решили продолжить наш цикл статей про разработку пользовательской документации, но на этот раз нам захотелось рассказать еще об одном способе создания инструкций для пользователей это съемка видеороликов. Мы расскажем о процессе их производства: от возникновения идеи до загрузки ролика на YouTube-канал. У нас нет студии и профессиональных актеров, мы все делаем сами и хотим показать вам, что это не так сложно. Здесь вы найдете: идеи, готовые алгоритмы и, быть может, вдохновитесь на съемку своей видеоинструкции.

Когда обычной инструкции не достаточно

Иногда уже в процессе написания обычной инструкции понимаешь, хорошо бы показать какие-то процессы в видео. Например, если лампочка на устройстве, котором мы описываем, мигает несколько раз или меняет цвет. Да, можно написать если лампочка устройства мигает три раза, а потом гаснет, то устройство не работает. Вроде как всё понятно, а если лампочка не просто мигает, а несколько раз меняет цвет, то такое уже будет сложнее объяснить при помощи текста.

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

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

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

Что делает пользователь с обычной инструкцией? Он не читает ее полностью, а находит необходимый раздел и выполняет описанную в нем процедуру. А это значит, что он будет искать обычную инструкцию в том случае, когда смарт-карта у него уже есть, и наша обычная инструкция будет полезной только для существующих пользователей и вряд ли поможет нам привлечь новых. А смарт-карта новая она еще мало у кого есть. Вряд ли пользователь, который еще не купил эту смарт-карту, будет читать инструкцию на 20 страниц, ему проще посмотреть небольшой ролик и понять, что это за устройство.

Все начинается с идеи и оценки ее реализации

Идея пришла уже после написания инструкции, но далеко не все подобные идеи заканчиваются реализацией. Ведь производство ролика стоит дороже написания инструкции и необходимо было осознать, действительно ли рационально сейчас тратить на это ресурсы компании. И мы задали себе вопрос: кому кроме наших пользователей может пригодиться такая видеоинструкция? Ее глобальная цель привлечь внимание к новой смарт-карте, поэтому она точно пригодится нашим менеджерам, они смогут отправлять ролик потенциальным заказчикам. Ещё такой ролик или его фрагмент можно показывать на презентации устройства, вставить в пресс-релиз и добавить в новостную ленту в социальных сетях. А этого уже достаточно для того, чтобы запустить процесс его производства. Ну и не стоит забывать про очевидную цель загрузить новый ролик на YouTube-канал, чтобы наши подписчики про нас лишний раз вспомнили. У вас цели могут быть другие.

Кто нужен для производства видеоинструкции

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

• Руководитель проекта или продукта. Как вы уже догадались, того продукта, для которого мы будем снимать ролик.

Зачем он нам: сформулировать цель ролика, ответить на вопросы в процессе написания сценария, вычитать сценарий и оценить ролик.

• Технический писатель. Тот, который писал инструкцию для нашей смарт-карты. Он уже многое знает и напишет сценарий быстрее, чем любой другой, кому придется разбираться в этой теме. Зачем он нам: написать сценарий и снять видео с экрана своего компьютера. Также, если в видео есть реальные кадры, то нарисовать раскадровку для видеооператора. Это идеальная картина, бывает так, что технический писатель и режиссер, и оператор, и монтажер.

• Видеооператор. Ему совсем не обязательно быть в теме, для него создана раскадровка, и он по ней работает. У нас это не всегда отдельный человек, если нет на это ресурсов, то тот, кто пишет сценарий и снимает живые кадры. В этот раз он у нас был. Зачем он нам: качественно снять живые кадры и при необходимости помочь с монтажом.

• Монтажер. У нас это тот, кто писал сценарий, он собирает весь ролик. Видеооператор может помочь ему выполнить какие-то сложные моменты. В этот раз они были: нам надо было показать одновременную работу смарт-карты в двух мобильных операционных системах.

• Человек, записывающий закадровый голос. У нас это реальный сотрудник технической поддержки, его голос знаком нашим пользователям. Он записывает закадровый голос для ролика.

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

Маркетолог. Он смотрит финальную версию и загружает ее на YouTube-канал.

Вроде никого не забыли. Да, многое может делать один человек и для каких-то роликов достаточно только заказчика и исполнителя.

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

Сколько времени нужно на производство ролика

Со сроками тоже все интересно. Если рассказывать про обычную инструкцию, то мы понимаем примерно сколько это займет времени, с видео сложнее. Оно может совсем не понравиться и какие-то моменты придется переснимать, а потом и заново монтировать. По опыту, на ролик продолжительностью 5 минут в среднем нужно 6-8 рабочих дней, это время на весь цикл производства. И надо понимать, что иногда этот срок растягивается в два и в три раза. А бывает, когда все сразу удачно складывается и требуется меньше времени.

Что нужно из оборудования

• Компьютер. На нем производится запись необходимого материала с экрана, хранятся все файлы для видео и монтируется ролик.

• Штатив. На него можно закрепить мобильный телефон для съемки живых кадров.

• Мобильный телефон. На него, как вы уже догадались, можно снимать живые кадры. Когда есть возможность позвать в этот проект видеооператора, штатив и мобильный телефон не нужны, так как процесс съемки обеспечивает видеооператор.

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

• Монтажная программа. В ней мы монтируем и собираем видео. У нас их две: для простого линейного монтажа мы используем программу Movavi, а для более сложного Adobe Premiere Pro. Первая очень простая и быстрая в освоении. Конечно необходимо, чтобы все используемое ПО было лицензированным.

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

• Программа для обработки звука. В ней мы обрабатываем звук. Можно установить специальную, а можно использовать возможности программы Adobe Premiere Pro.

• Текстовый редактор. В нем мы пишем сценарий. Использовать можно любой, но лучше всего тот, в котором организована возможность совместной работы с документом. Например, можно использовать Microsoft Word 2016 или Google Docs.

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

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

Вроде все, сами понимаете, что если нет штатива, то это не критично. А вот, например, без монтажной программы точно не обойтись. Все оборудование собрано, начинаем снимать? Нет, сначала пишем сценарий.

Обязательно ли писать сценарий

Ответ ДА. Сценарий нужен даже, если ваш ролик длится 20 секунд. Ролики без сценариев очень отличаются, в них нет нужных акцентов и логики. А если в таком ролике еще есть закадровый голос, то это вообще веселье. Что делает человек, который записывает закадровый голос: он просто комментирует все, что видит, а так быть не должно. Здесь мы можем услышать неоправданные паузы, слова-паразиты и т.п.

Сценарий выстраивает логику повествования, дает возможность понять: где сделать паузу, выделить что-то голосом, замедлить или ускорить какие-то процессы.

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

Например, если пользователю необходимо указать какие-то конкретные значения параметров, то надо это сказать, а сами значения продублировать в субтитрах в кадре.

А вот, если мы показываем, как мигает индикатор на устройстве, то это словами комментировать не нужно, в ролике все и так будет видно.

Когда первая версия сценария написана, она отправляется на проверку заказчику. Это обязательно надо сделать перед началом съемки, так как у исполнителя и заказчика могут быть очень разные представления о содержании ролика, и важно это выяснить. Здесь не нужно торопиться, важно подождать, пока заказчик посмотрим и выдаст свои комментарии, иногда ждать приходится долго.

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

Как снимать реальные кадры или записывать закадровый голос

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

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

Мы записываем закадровый голос специальный диктофон или на диктофон мобильного телефона.

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

Мы обещали рассказать вам про наш форс-мажор, он как раз возник в процессе производства этого ролика. Что произошло? Мы получили файлы с закадровым голосом в пятницу вечером и не успели их проверить. В субботу наш технический писатель смонтировал видео с этими файлами и когда пересматривал финальную версию, обнаружил брак по звуку. Это был звук от прикосновения говорящего к микрофону, а его убрать нереально, так как он шел параллельно голосу. Что пришлось сделать? Перезаписать закадровый голос. А сами понимаете, на это нужно время. Не повторяйте наших ошибок, всегда проверяйте файла с закадровым голосом перед монтажом.

Совет 2. Обрабатывайте звук. Убирайте шумы и выравнивайте звук по громкости.

Совет 3. Думайте про свет. Плохо когда света мало, но также плохо когда его много. Не снимайте против источника света. Он должен быть либо перед объектом съемки, либо сбоку.

Естественный свет лучше искусственного, но у него есть один большой минус его нельзя контролировать. Например, сейчас может светить солнце, а через 5 минут оно спрячется за тучу или облако, и свет в кадре будет выглядеть иначе. Для того, чтобы выравнивать кадры по свету, необходимо на самом последнем этапе монтажа сделать цветокоррекцию, это можно сделать практически в любой монтажной программе.

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

Мы снимали для ролика кадры:

• Общий план: компьютер, считыватель, смарт-карта и руки человека. Так мы показали, что нужно для подготовки смарт-карты к работе.

• Крупный план: смарт-карта в ладони. Так мы показали, как выглядит смарт-карта.

• Крупный план: смарт-карта, мобильное устройство и руки человека. Так мы показали, как работать со смарт-картой на мобильном устройстве.

После того, как мы отсняли реальные кадры, начинаем снимать видео с экрана.

Как снимать видео с экрана компьютера или мобильного устройства

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

Не забывайте в таких роликах делать паузы, ведь пользователь смотрит и повторяет действия, а в отстающих ему быть не хочется.

Есть моменты, которые можно ускорить. Например, вы показываете как заполняете стандартные поля (фамилия, имя, отчество), такое пользователь сможет сделать сам.

А есть моменты, которые можно замедлить. Например, если показываете, что пользователю необходимо проверить значения полей. Здесь вам надо дать пользователю время на это.

Не забывайте про то, что в вашем ролике не должно быть каких-то личных данных (номеров телефонов, IP-адресов, адресов электронных почт и т.п.), их надо замылить.

Также мы замыливаем системную дату и время. Вы спросите зачем? У пользователя не должно быть информации о том, что вы долго снимали свой ролик, что-то записывали в два часа ночи, а что-то потом вставили из другого дня. А по системному времени он может это легко отследить, поэтому лучше его замылить.

Мы снимали для нашего ролика процедуру создания тестового сертификата через сервис ra.rutoken.ru. Это нужно, чтобы подготовить смарт-карту для работы с мобильным устройством. Ну и показали пользователю продуктовую страницу смарт-карты.

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

Теперь у вас есть реальные кадры, есть кадры, снятые с экрана, что делать дальше? Монтировать ролик?

Нужна ли музыка

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

Мы используем одну и туже музыку во всех роликах, купили ее несколько лет назад на всем известном сайте.

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

Музыку выбрали, теперь можно монтировать.

Как монтировать ролик

План монтажа. Желательно составить план монтажа, особенно это полезно, если над роликом работало несколько человек. В этом плане опишите: продолжительность каждого кадра, текстовые слайды исубтитры. Его тоже лучше согласовать с заказчиком.

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

Освещение и цвет кадра. При монтаже учитывайте освещение и цвет. Если один кадр снят в теплых тонах, а другой в холодных, то это необходимо исправить.

Редактирование голоса. При редактирование голоса необходимо вырезать: паузы, ошибки, слова-паразиты.

Текстовые слайды и субтитры. В начале видео, на заставке надпись может быть крупной.

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

Также стоит придерживаться единой палитры. Яркие цвета можно использовать для расстановки акцентов, для всего остального нейтральные. Для лучшего сочетания оттенков можно воспользоваться цветовым кругом.

Картинки. Иногда нужно иллюстрировать какие-то процессы, в этом могут помочь картинки. Как уже писали, для создания иллюстраций мы используем онлайн-редактор Readymag. Там есть готовые изображения, из которых можно составить смысловой слайд.

Мы в ролике иллюстрировали процесс использования смарт-карты в рабочей ситуации на предприятии.

На монтаж тоже нужно время. У нас на это ушел один рабочий день. Потом мы собрали первую версию ролика и отправили на проверку заказчику. Он прислал нам комментарии, мы обсудили их и смонтировали финальную версию ролика. Ее отправили нашему маркетологу, на этом этапе может возникнуть необходимость что-то исправить. Нас попросили исправить заставку, мы это сделали, и потом ролик был опубликован на нашем YouTube-канале.

Жизнь ролика на YouTube

Имейте ввиду, что для ролика еще надо написать описание и создать значок. Давайте сначала расскажем про значок. Это картинка, которая будет отображаться, пока ваш ролик не будет запущен для просмотра. К ней есть некоторые требования. Вставим сюда скриншот со страницы помощи YouTube.

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

Дальше ролик живет своей жизнью. Его можно отправлять потенциальным клиентам, пользователям, показывать на презентациях. Он может вызвать эмоции и повлиять на отношение к продукту. Не стоит бояться снимать, в интернете вы можете найти много информации про это и все необходимые программы. Надеюсь, наша статья помогла вам хоть немного разобраться в этом процессе.

Также мы открыты к диалогу, если есть вопросы пишите в комментарии.