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

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

Об одной из таких профессий в сегодняшнем выпуске.

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

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

Делай проще, чтобы поняли, да и сам думай меньше, задачу закрыть надо…

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

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

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

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

В сегодняшнем выпуске затрагиваю такую тему, как тестирование удобства использования (usability testing) пользовательской документации.

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

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

В сегодняшнем выпуске представляю аудио-версию моей небольшой работы «Как написать понятную инструкцию. Опыт инженера».

В сегодняшнем выпуске представляю вторую часть записи беседы с профессиональным переводчиком Иваном Чаплыгиным, автором книги «Думай о смысле. Будни переводчика IT-текстов».

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

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

Осознал я свою ошибку после прочтения одной интересной книги о буднях IT-переводчиков и совершенно под другим углом посмотрел на эту замечательную профессию. Кстати, в работе технических писателей и переводчиков очень много общего.

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

В сегодняшнем выпуске представляю запись беседы с профессиональным переводчиком Иваном Чаплыгиным.

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

В эти моменты мы задаёмся примерно такими вопросами: Почему меня не понимают? Как объяснять так, чтобы меня понимали?

Сегодня немного порассуждаю на эту тему и постараюсь найти нужные ответы.

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

Но под Новый год случилось чудо! Я нашёл такого эксперта, который может помочь мне донести нужную информацию до инженеров.

В сегодняшнем выпуске представляю запись беседы с Ариной - техническим коммуникатором с 20-летним опытом работы в IT.

Абсолютное большинство инженеров вообще не интересуются навыком письма. Обычный ответ в этом случае: “Я только код пишу, мне этого достаточно.” И это печально, если честно.

Сегодня предлагаю немного порассуждать над вопросом - нужен ли инженерам навык письма или достаточно иметь только технические знания?

Diátaxis - подход структурирования и организации технической документации, который значительно упрощает работу с документацией как её разработчикам, так и читателям (пользователям). В сегодняшнем выпуске представлен краткий обзор данного подхода.

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

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

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

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

Переход российских компаний на парадигму “документация как код” в части создания и сопровождения технической документации, а также для чего нужны и как написать понятные сообщения для git-коммитов.

Небольшое дополнение к выпуску о едином источнике правды документации.

Отзыв на книгу Уильяма Зинсера “Как писать хорошо. Классическое руководство по созданию нехудожественных текстов”.

Как развивалась техническая документация? Что такое единый источник правды? Ответы на эти вопросы в данном выпуске подкаста.

Сколько русскоязычных подкастов о технических коммуникаторах Вы слушаете? Ну, хотя бы знаете, кто такие технические коммуникаторы?

Ладно, расслабьтесь. Послушайте первый выпуск и всё сразу поймёте.