Comments 29
Иван и Елена, спасибо за отличную статью! Многие моменты знакомы до боли, ну и конечно же, всегда приятно узнать, как работается нашим коллегам по цеху в других отечественных компаниях :-)
Нет, ну как Ваня написал «различных программах, от простых (например, Word)» — я понимаю:) (меня от написания примерно такой же фразы о Studio останавливает только врожденная деликатность понимание того, что я вряд ли использую хотя бы 10 процентов ее возможностей:))
Но как Лена-то это пропустила:)?
Но как Лена-то это пропустила:)?
*ушёл проверять, не было ли в черновике поста красного курсива*
Пишет Лена :)
«В защиту Вани скажу, что написала это сама Лена, т.е. я Попыталась кратко сказать о многом и не получилось. Понятно, что Word не так прост как кажется. Но изучить его основные функции, покрывающие 95% потребностей, достаточно просто. Практически любой умеющий писать человек сможет научиться создавать документы в Word за несколько минут\часов. А при работе в VisualStudio требуются дополнительные знания и умения. Надо понимать что такое код, проект, компиляция, и т.п. Нужно уметь разобраться, почему проект вдруг перестал собираться, понимать, как твои правки в одном месте, могут поломать что-то в другом, и т.д. Т.е. для освоения даже того минимума, что нужно нашим техписам, требуется больше усилий. Вот это хотела сказать, говоря про простые и сложные программы»
«В защиту Вани скажу, что написала это сама Лена, т.е. я Попыталась кратко сказать о многом и не получилось. Понятно, что Word не так прост как кажется. Но изучить его основные функции, покрывающие 95% потребностей, достаточно просто. Практически любой умеющий писать человек сможет научиться создавать документы в Word за несколько минут\часов. А при работе в VisualStudio требуются дополнительные знания и умения. Надо понимать что такое код, проект, компиляция, и т.п. Нужно уметь разобраться, почему проект вдруг перестал собираться, понимать, как твои правки в одном месте, могут поломать что-то в другом, и т.д. Т.е. для освоения даже того минимума, что нужно нашим техписам, требуется больше усилий. Вот это хотела сказать, говоря про простые и сложные программы»
О, вот как раз в плане «как твои правки в одном месте могут поломать что-то в другом» Word себе равных не знает:)
Что до остального — На самом деле «простота» Word'а исключительно кажущаяся:) Даже на уровне «создавать документы». В классическом случае человек быстро делает какой-то документ, а потом долго удивляется, почему это у него шрифт не тот, и списки появились (ну или пропали:)).
А что до сравнения со Студией — тут, скорее, действительно дело в некоторых дополнительных знаниях, которые нужны. Если же использовать Word не для печати записки на полстранички, то тут и дополнительные знания могут понадобиться, и про простоту придется забыть:)
Я до того момента, как начал работать техписателем, думал, что Word я знаю, ну, скажем, неплохо. С тех пор моя оценка своих знаний стала заметно ниже:)
Что до остального — На самом деле «простота» Word'а исключительно кажущаяся:) Даже на уровне «создавать документы». В классическом случае человек быстро делает какой-то документ, а потом долго удивляется, почему это у него шрифт не тот, и списки появились (ну или пропали:)).
А что до сравнения со Студией — тут, скорее, действительно дело в некоторых дополнительных знаниях, которые нужны. Если же использовать Word не для печати записки на полстранички, то тут и дополнительные знания могут понадобиться, и про простоту придется забыть:)
Я до того момента, как начал работать техписателем, думал, что Word я знаю, ну, скажем, неплохо. С тех пор моя оценка своих знаний стала заметно ниже:)
По-моему техническая справка — как комментарии в коде. При хорошем дизайне продукта, нужда в ней стремиться к нулю.
Учитывая, что в большинстве справок/документаций разобраться еще сложнее, чем в самой программе.
Учитывая, что в большинстве справок/документаций разобраться еще сложнее, чем в самой программе.
Если продукт большой и сложный, например, какая-нибудь ERM, мануал часто бывает нужен не только для того, чтобы пояснить, как работает тот или иной элемент интерфейса (что действительно очевидно при хорошем дизайне), а чтобы исчерпывающе описать все возможности продукта, даже если на деле ими никто никогда не воспользуется…
Ну и наличие вменяемой справки у продукта — это просто хороший тон.
Ну и наличие вменяемой справки у продукта — это просто хороший тон.
Справка, ко всему прочему – юридически важная часть продукта. Она описывает разумные ожидания от функциональности продукта. Во многих странах Европы разработчику могут учинить иск за нанесение вреда бизнесу из-за того, что программа не сделала что-то или сделала не так. Европейские законы отменяют любимый всеми пункт в лицензионном соглашении, который обычно пишется всеми заглавными буквами, про то, что разработчик ни за что не отвечает. Отвечает, да еще как.
Я тоже почти никогда не пользуюсь справкой. Но иногда пользуюсь, и каждый раз радуюсь, что она есть. Гугл не всегда помогает, к сожалению.
Я тоже почти никогда не пользуюсь справкой. Но иногда пользуюсь, и каждый раз радуюсь, что она есть. Гугл не всегда помогает, к сожалению.
Любопытно, никогда о таком не слышал… Расскажите про такие случаи подробнее, или может быть ссылок накидаете? Хочу почитать, т.к. сам продаю ПО в Европу.
Ссылки накидать не смогу, потому что не в интернете вычитал. Знаю от наших европейских юристов: в некоторых европейских странах (в этот список точно входят Германия и Италия) разработчик ПО может нести ответственность за урон, нанесенный клиенту проблемой в ПО. Размер ответственности зависит от того, как разработчик реагировал на информацию от клиента о потерях. Смысл в том, что за ошибку в ПО вас не могут наказать. А вот если вам сообщили об ошибке, и указали на то, что она наносит существенный урон, а вы не предприняли адекватных мер с точки зрения суда, то вас могут обвинить в намеренном нанесении ущерба. Поэтому с европейскими клиентами шутить нельзя: если выяснилась какая-то значимая проблема, надо ее стараться быстро исправить и выслать обновление. У нас ни разу до суда не доходило, но был случай на моей памяти, когда чрезмерно нервный клиент начал угрожать судом, даже несмотря на то, что мы делали все возможное, чтобы быстро решить его проблему.
Понятное дело, когда у вас есть документация, то вы можете сослаться на то, что клиент знал об определенном поведении продукта, которое он почему-то считает ошибочным. Тогда это его проблемы. А если документации нет, то тогда любое неверное понимание клиентом того, что можно, а что нельзя делать с помощью вашего продукта, может стать вашей проблемой.
Понятное дело, когда у вас есть документация, то вы можете сослаться на то, что клиент знал об определенном поведении продукта, которое он почему-то считает ошибочным. Тогда это его проблемы. А если документации нет, то тогда любое неверное понимание клиентом того, что можно, а что нельзя делать с помощью вашего продукта, может стать вашей проблемой.
Соглашусь с предыдущим комментарием.
А также хочу добавить о пользе онлайн-справки. Это дополнительный источник трафика на сайт + не нужно писать много никому не нужных кривых SEO-статей. Получается сразу можно 2 зайцев убить — и пользователи смогут получить необходимую инфу онлайн, и поисковые системы проиндексируют.
А также хочу добавить о пользе онлайн-справки. Это дополнительный источник трафика на сайт + не нужно писать много никому не нужных кривых SEO-статей. Получается сразу можно 2 зайцев убить — и пользователи смогут получить необходимую инфу онлайн, и поисковые системы проиндексируют.
Так вот какие люди нужны, чтобы не видеть описаний к настройкам биоса вида
АБЫРВАЛГтм — включает или отключает функцию АБЫРВАЛГтм
И где набраться таких суперменов-технописалетей…
Здесь есть парочка: alconost.com/help
Как всегда, нужны не технописатели а просто личности.)) Им по барабану кем работать, они везде нужны)
Это вполне обычная и очень распространенная профессия. Можете посмотреть на Амазоне, сколько книг издается по Technical Writing.
Спросили DM’а, долго ли менять. «Нет, – говорит, две строчки закомментировать и две расскоментировать». Обрадовались все, кроме технических писателей. /.../ Для одного языка получилось 49 правок. На количество языков умножьте сами
Как раз приведенный пример демонстрирует, что в данном случае в коде все было значительно лучше организовано, чем в документации. Непонятно, что мешает автоматизировать сборку документации, чтобы при таких минорных изменениях она адаптировалась так же просто, как и код. В конце концов вокруг нас куча средств автоматической сборки и конфигурирования, да и соответствующий велосипед не выглядит такой уж неподъемной задачей.
Так а история то чем закончилась? Подозреваю, что оставили как есть, но «пользователь номер один» тоже разные бывают.
Как вы думаете, кто лучше всего знает продукт? … По крайней мере, в случае большого проекта.…
Так кто же тот самый человек, который знает все? Это технический писатель.
В случае БОЛЬШОГО проекта на проекте работает несколько тестировщиков и несколько технических писателей, поэтому никто из них не знает продукт целиком.
Так кто же тот самый человек, который знает все? Это технический писатель.
В случае БОЛЬШОГО проекта на проекте работает несколько тестировщиков и несколько технических писателей, поэтому никто из них не знает продукт целиком.
Техпис … должен придумывать названия новым фичам на основе неполных описаний разработчиков.
Это как же у вас устроен процесс управления продуктом, что названия фич придумывают разработчики с техписами, а не человек, знающий рынок и пользователя?
В целом ваша роль «главного» какая-то хлипкая — хочет он, видите ли :)
Это как же у вас устроен процесс управления продуктом, что названия фич придумывают разработчики с техписами, а не человек, знающий рынок и пользователя?
В целом ваша роль «главного» какая-то хлипкая — хочет он, видите ли :)
И говорят нам пользователи (вернее даже один пользователь, а еще вернее, пользователь номер один): «А верните-ка нам две команды, ну, никак не можем без них жить. Да, заодно удалите два лишних сценария».
И ещё чудесатее — оказывается, у вас продуктом управляет не руководитель продукта и даже не маркетолог, а избранные пользователи. Офигеть. best practice прям, что ж вы молчите, не хвастаетесь на product camp'ах об этом ?! %)
И ещё чудесатее — оказывается, у вас продуктом управляет не руководитель продукта и даже не маркетолог, а избранные пользователи. Офигеть. best practice прям, что ж вы молчите, не хвастаетесь на product camp'ах об этом ?! %)
Техпис проверяет целостность разных частей интерфейса и их соответствие друг другу.
А peer review в команде проектировщиков у вас для этого нет? А разделения — старший проектировщик / проектировщик?
А peer review в команде проектировщиков у вас для этого нет? А разделения — старший проектировщик / проектировщик?
Вы правда думаете, что читатели Хабра не могут посчитать 22 x 49 в уме? :)
Нисколько не хочу приуменьшить роль Ивана и Елены в их компании, но просто по факту статья отражает положение дел в отдельно взятой фирме с конкретным распределением ролей и организацией бизнес-процессов.
В реально крупных компаниях, занимающихся программными продуктами, все обстоит совсем по-другому. Как и положено, чем крупнее фирма, тем более раздробены роли каждого.
Например в той фирме, где работаю сейчас я, всё ПО и вся документация к нему изначально создаются на английском языке (а не на русском, как в ABBYY). По мере создания ПО те строки, которые отмеченны, как подлежащие переводу, попадают к переводчикам (в каждой стране и в каждом регионе — свои партнёры по переводу). При этом переводчики зачастую переводят «в слепую», ибо продукт вообще не готов и его нельзя ни поставить, ни как-либо посмотреть. Параллельно с этим создаётся вся необходимая документация (разумеется, включая User Manual) — создаётся именно Техническими Писателями, но создаётся она опять-таки только на английском языке и для той первоначальной версии, которая соответствует техническому заданию. Еще одна особенность — документация верстается так, чтобы все термины и названия элементов интерфейса подтягивались автоматически при вёрстке из DB переводов. Затем, когда продукт выходит на стадию тестирования, помимо команды тестировщиков, его смотрит и региональный технический менеджер в каждом из регионов.
И вот тут-то и начинается самое интересное. В зависимости от региона, требования к продукту могут меняться (например, в РФ запрещён импорт криптостойких несертифицированных решений, поэтому для РФ такой код должен исключаться из ПО). Да, подобные вещи, разумеется, должны бы учитываться на этапе проектирования, но мы помним, что фирма очень крупная, и не всегда все можно решить заранее. Вот и приходится «резать по живому». Но это самая малая из возможных бед. В разных языках длинна слов — различна. Не мне рассказывать, что русские фразы в большинстве своём длиннее английских. Региональному менеджеру приходится при этом играть роль и корректора (исправлять кривой перевод), и технического писателя (подбирая наиболее подходящий по смыслу, но более лаконичный перевод), и дизайнера интерфейсов (писать письма ДИ типа: «А нельзя ли здесь расположение кнопок поменять, снять „bold“ с комментария и чуть расширить текстовый блок, т.к. при любом раскладе нам нужно минимум 3 строки, а не 2»). Очень часто, после того, как проходит этап review, на котором локальные менеджеры должны были исправить перевод, вся документация ребилдится заново, дабы подхватить внесенные в перевод интерфейса исправления. И эта документация проверяется менеджежером еще раз, уже на предмет соответствия интерфейсу.
Так что в рамках нашей фирмы вот этот региональный менеджер и правит документацию, и исправляет перевод, и корректирует интерфейс, и разумеется, параллельно еще и тестирует продукт по ходу дела.
Но если вернуться к теме топика и заданному в его начале вопросу — «Кто лучше всех знает продукт?» — то я не буду утверждать, что это именно многорукий и такой универсальный локальный менеджер. Во-первых, он не в курсе происходящего в других регионах, а во-вторых, он видит только текущую версию, которую ему передали для проверки и тестирования. Я бы сказал, что лучше и полнее всех знает продукт только его Системный Архитектор. Это тот, кто отвечает не только за реализацию текущей версии (это, как мы помним, делает DM), а кто изначально составлял техническое описание продукта для выработки из него ТЗ, кто сейчас по информации, поступающей от аналитиков, корректирут Product Strategy, кто взаимодействуя с PM, определяет текущую конфигурацию продукта с прицелом и «на сейчас», и на длительное будущее.
В реально крупных компаниях, занимающихся программными продуктами, все обстоит совсем по-другому. Как и положено, чем крупнее фирма, тем более раздробены роли каждого.
Например в той фирме, где работаю сейчас я, всё ПО и вся документация к нему изначально создаются на английском языке (а не на русском, как в ABBYY). По мере создания ПО те строки, которые отмеченны, как подлежащие переводу, попадают к переводчикам (в каждой стране и в каждом регионе — свои партнёры по переводу). При этом переводчики зачастую переводят «в слепую», ибо продукт вообще не готов и его нельзя ни поставить, ни как-либо посмотреть. Параллельно с этим создаётся вся необходимая документация (разумеется, включая User Manual) — создаётся именно Техническими Писателями, но создаётся она опять-таки только на английском языке и для той первоначальной версии, которая соответствует техническому заданию. Еще одна особенность — документация верстается так, чтобы все термины и названия элементов интерфейса подтягивались автоматически при вёрстке из DB переводов. Затем, когда продукт выходит на стадию тестирования, помимо команды тестировщиков, его смотрит и региональный технический менеджер в каждом из регионов.
И вот тут-то и начинается самое интересное. В зависимости от региона, требования к продукту могут меняться (например, в РФ запрещён импорт криптостойких несертифицированных решений, поэтому для РФ такой код должен исключаться из ПО). Да, подобные вещи, разумеется, должны бы учитываться на этапе проектирования, но мы помним, что фирма очень крупная, и не всегда все можно решить заранее. Вот и приходится «резать по живому». Но это самая малая из возможных бед. В разных языках длинна слов — различна. Не мне рассказывать, что русские фразы в большинстве своём длиннее английских. Региональному менеджеру приходится при этом играть роль и корректора (исправлять кривой перевод), и технического писателя (подбирая наиболее подходящий по смыслу, но более лаконичный перевод), и дизайнера интерфейсов (писать письма ДИ типа: «А нельзя ли здесь расположение кнопок поменять, снять „bold“ с комментария и чуть расширить текстовый блок, т.к. при любом раскладе нам нужно минимум 3 строки, а не 2»). Очень часто, после того, как проходит этап review, на котором локальные менеджеры должны были исправить перевод, вся документация ребилдится заново, дабы подхватить внесенные в перевод интерфейса исправления. И эта документация проверяется менеджежером еще раз, уже на предмет соответствия интерфейсу.
Так что в рамках нашей фирмы вот этот региональный менеджер и правит документацию, и исправляет перевод, и корректирует интерфейс, и разумеется, параллельно еще и тестирует продукт по ходу дела.
Но если вернуться к теме топика и заданному в его начале вопросу — «Кто лучше всех знает продукт?» — то я не буду утверждать, что это именно многорукий и такой универсальный локальный менеджер. Во-первых, он не в курсе происходящего в других регионах, а во-вторых, он видит только текущую версию, которую ему передали для проверки и тестирования. Я бы сказал, что лучше и полнее всех знает продукт только его Системный Архитектор. Это тот, кто отвечает не только за реализацию текущей версии (это, как мы помним, делает DM), а кто изначально составлял техническое описание продукта для выработки из него ТЗ, кто сейчас по информации, поступающей от аналитиков, корректирут Product Strategy, кто взаимодействуя с PM, определяет текущую конфигурацию продукта с прицелом и «на сейчас», и на длительное будущее.
Sign up to leave a comment.
Переводим с программистского на русский