Вы пишете документацию, статьи или другие тексты? Тогда наверняка у вас есть проверяющие. Я уверен, что вы нежно и трепетно любите своих проверяющих. Вы, скорее всего, с нетерпением ждёте, когда они пришлют вам свои правки и комментарии. Благоговейно изучаете и перечитываете крупицы мудрости, которыми проверяющие благосклонно поделились с вами. Лучшие из комментариев вы записываете в специальную тетрадочку или даже распечатываете и вешаете их на стену... Кстати, если серьёзно, то я иногда так и делаю. Положим, до распечатывания цитат я ещё не дошёл, но вот специальная «тетрадочка» у меня уже есть. Точнее, текстовый файл.
Часто мне самому приходится выступать в роли «сурового проверяющего» и вычитывать документацию и тексты, которые пишут технические писатели. При этом я вижу и анализирую комментарии, которые оставили к этим текстам другие проверяющие. Я начал коллекционировать самые фееричные комментарии. Делаю я это для того, чтобы иметь перед глазами антипример — как ни в коем случае нельзя писать комментарии к чужим текстам.
Мои вредные советы — своеобразная квинтэссенция этих записей — тщательно отобранные, систематизированные и дистиллированные советы для проверяющих. Практическое руководство по доведению до белого каления ваших технических писателей и авторов.
Дисклеймер. Все совпадения фрагментов этого текста с реальными комментариями в вашей документации совершенно случайны. При написании этого текста не пострадал ни один проверяющий.
1. Пишите комментарии как можно более эмоционально и расплывчато: «Да неужели?!», «Вот это да!», «Жесть». Это оживит процесс общения.
2. В общих комментариях обязательно напишите: «Весь документ надо переписать заново!». Даже если в замечаниях к тексту на несколько сотен страниц вы исправили только пару незначительных ошибок. Это будет держать писателя в тонусе.
3. Вместо того, чтобы объяснить, как исправить ошибку, задайте техническому писателю вопрос: «Разве это так работает?».
4. Ещё лучше напишите комментарий, состоящий из одного знака вопроса. Или просто напишите: «Это не так». Писателю будет интересно догадаться, как же всё устроено на самом деле.
5. Если вы не профессиональный редактор или корректор, то старайтесь как можно чаще исправлять стилистику текста. Давайте писателю советы о том, как лучше составлять предложения.
6. Пишите комментарии вроде «Это надо обязательно проверить». Писатель любит развлечься тестированием системы.
7. После того, как писатель наконец протестировал систему и удостоверился, что всё было указано правильно, напишите, что этот комментарий вы написали «Для себя».
8. Присылайте комментарии за полчаса до срока отгрузки документа заказчику. Писателю будет полезно потренировать важный навык стрессоустойчивости.
9. Никогда не берите на себя ответственность за правильность предоставленной информации. В каждом комментарии используйте слова: «кажется», «наверное», «вроде». Документ пишет писатель, он и будет отвечать.
10. Никогда не сообщайте писателю о важных изменениях в логике работы системы, внесённых в ходе разработки. Технический писатель должен самостоятельно просматривать сотни заявок и выискивать те, что относятся к теме документа. Если не нашёл — сам виноват. Сообщите ему об этом при проверке документа: «Это уже давно не так!».
11. Ещё лучше вообще не заводить заявку. Технический писатель должен сам догадаться, что кнопка теперь работает по-другому. Интуиция — его профессиональное качество. Вообще, лучше поменьше письменно фиксировать информацию о работе системы. Писать — это дело писателя.
12. Настаивайте на том, чтобы писатель использовал жаргонные термины в тексте: «Так все говорят, заказчику будет понятнее».
13. Чем больше людей проверяет документ, тем лучше. Писателю будет интересно решить логическую задачу по совмещению противоположных друг другу исправлений.
14. Не вносите комментарии прямо в проверяемый документ. Каждое замечание к тексту лучше присылать отдельным сообщением в мессенджере. Нашли ошибку — сразу отправляйте её писателю. Ему будет интересно отвлечься от другого документа, над которым он сейчас работает.
15. Почаще вставляйте комментарий: «Это надо переписать!». Писатель — профессионал своего дела. Ему будет очевидно, что именно не понравилось проверяющему в выделенном фрагменте текста.
16. Никогда не проверяйте документ до конца. При повторной вычитке находите ошибки в уже проверенных частях. Чем больше итераций проверки, тем интереснее и замысловатее.
17. После нескольких итераций исправлений одного и того же места в тексте вернитесь к первоначальному варианту. Напишите, что «Так стало гораздо лучше».
Ещё почитать:
Комментарии (9)
voldemar_d
30.04.2024 03:45По поводу "это так не работает", "это не так" и пункта 6 - а что, техписатель пишет документацию по программе, не запуская её сам и не проверяя, как она работает? Или ему присылают скриншоты, и он по ним сам догадывается, как программа работает, и что делают все кнопки в ней?
Про пункт 5 - есть какие-то критерии оценки, имеет ли кто-то право писателю делать рекомендации по поводу стиля? Может, надо сначала предъявить кучу сертификатов с регалиями, по которым техписатель сразу поймёт, следовать рекомендациям проверяющего или нет?
Документ пишет писатель, он и будет отвечать.
Разве это не так?
dih81
30.04.2024 03:45+5"Так не работает" - обычно логику поменяют, техписов не уведомят, а ревьюер или представления не имеет, какая версия/итерация описана, или и есть тот, кто не уведомил.
Есть. Если ревьюер не в теккоммс и нет профильного (филологического) образования и/или нет аргументации по предлагаемой стилистической правке - идет лесом, включая ПМов.
voldemar_d
30.04.2024 03:45обычно логику поменяют, техписов не уведомят
В смысле, им не дают актуальную версию программы, они работают в старой и ее описывают в документации?
Если ревьюер не в теккоммс и нет профильного (филологического) образования
Не смешите мои тапочки. У меня нет филологического образования, но я встречал достаточно филологов, за которыми приходилось исправлять ошибки как грамматические, так и стилистические. Образование вообще не является гарантией того, что человек умеет связно излагать свои мысли, не то что обращать их в письменный вид.
dih81
30.04.2024 03:45+1В смысле, им не дают актуальную версию программы, они работают в старой и ее описывают в документации?
Не всегда версионность есть. А так, да, поменяли логику в фиче, UI, дизайн - а техписа не уведомили. Техпис описал предыдущую итерацию и работает над другим разделом. Сплошь и рядом, к сожалению, и на условном Востоке, и на условном Западе.
Не смешите мои тапочки. У меня нет филологического образования, но я встречал достаточно филологов, за которыми приходилось исправлять ошибки как грамматические, так и стилистические.
Ну, с таким подходом вы, наверное, и стоматологам советуете, как зубы лечить. Наличие некомпетентных специалистов до какой-то степени оправдывает подход "да кто ты такой, вот так надо", но это не должно быть нормой. Опять же, зависит от применяемых стандартов. При документировании по ГОСТам и ЕСКД не требуются какие-то специфичные языковые навыки, грамотности и аккуратности достаточно, насколько помню по давней работе.
По большому счету, претензии техписов всегда сводятся к двум моментам:
Давайте полную и актуальную информацию, не за день до дедлайна.
В случае критики, обозначьте конкретные недостатки критикуемого материала - чего не хватает, что неверно. А уж если есть дополнительные (внутренние) источники информации - отлично, поделитесь, техпис будет признателен вам за это.
voldemar_d
30.04.2024 03:45Стоматологам я, конечно, ничего не советую. Но бывают грубые стилистические ошибки, грамматические и прочие, которые очевидны грамотному человеку. Так получилось, что я определенное количество лет вычитывал документацию за техписателями, хоть я и программист. Когда пропущена запятая, тут всё понятно, а если ошибка фактическая или стилистическая, я всегда писал рекомендации, как написать лучше.
jvsg6
30.04.2024 03:45+3В прошлом занимался написанием отчетов. При прочтении собрал 13 из 17 пунктов, которые встречал:)
У меня встречался еще комментарий - "Переформулировать". Обычно выделялось 10-15 строк и помечалось данным комментарием, без дополнительных разъяснений.
dih81
30.04.2024 03:45Так пусть техпис гадает, ему ж больше делать нечего. Его ж работа писать, не ревьюера, тем более если ревьюер из начальства, у него ж время в 10 раз дороже.
Dmitri-D
из реальной жизни - бываеи, что нет никакой документации по коду, который надо существенно изменить. Программист был в коме когда писал его или уже ушел, или он записал ролик, один, и считает свой долг по документированию исполненным чуть больше. чем полностью. Начинается reverse engineering - тоже своего рода прокрастенация и это затягивает не хуже чем "это надо проверить", тем более, что, как правило, такой подход подразумевает, что надо проверить всё. И надо бы уже что-то начать делать по изменениям, но еще есть столько всего попроверять. Вдохновение, наверное, не приходит.