Techwriters Pages

Рубрика «Завлекательные тексты»

В троллейбусе попалось премилейшее: реклама, которая не просто продаёт, а меняет и романтизирует образ профессии 🥰

Боюсь, загадку женщины теперь можно будет разгадать только на конечной остановке 😁

Философия в каждом дне...

Какая сегодня?🤔😈

🥺 Ностальжи

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

Грустно — заранее заехала попрощаться. Заняла привычную уютненькую Восточную, и вдруг кап-кап с резного красавца-плафона прямо мне на стол... 💧
На улице ливень, что ж... Но этажей 7, а я на 5-м... Что за персональная питерская туча? 🧐🌧

Погрустили немного на пару с восточным красавцем 😢 и разошлись по своим: я — за мастером, а он — светить дальше, уже другим...🥺🌤

Любимки, мне будет вас не хватать! ❤️

🍸 Рюмочная — неизменный выбор для понедельничного утра. Стулья с жёсткими деревянными сиденьями и холодной металлической спинкой категорически бодрят безо всякого кофия.

🌃 Барная улица — как мечта о вечере пятницы: обязательна к посещению по средам и после обеда.

🎲 Казино — о, да! Когда горы уже свёрнуты, а море не по колено — по щиколотку. И ты весь такой на адреналине посреди этого моря-лужи, волосы по ветру, рубаха на распашку... Для отчаянных или отчаявшихся 😎🙃

🏰 Эрмитаж — почувствовать себя монархом посреди огромного дворца 😎 Вместе с ЧСВ обостряет одиночество — для тех, кому мало «интроверт среди интровертов».

🏔️ Шале — ютиться в кресле на фоне альпийских лугов — лучший выбор для знакомства с новыми членами команды и худший для встреч по следам "всё сгорело" 🔥🧑‍🚒

📚 Библиотека — если нужны проблемы со связью... потому что «Тишина должна быть в библиотеке!» 😁

🚢 Морская — что может быть лучше кают-компании долгим осенним или зимним вечером? 🌊 Идеально для неспешных серьёзных бесед и размышлений ☕️

☁️ Облачная — для поэтического настроения: сидеть на ☁️ , свесив ножки вниз, и фантазировать о светлом..✨

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

Возможно, я и дизайнер вдохновлялись чем-то одним 😆😛

🤔 Что общего между разработкой документации и печатных плат?

Какие только вопросы не лезут в голову после ice-breaking... 🙈

Когда-то мне нравилось разводить платы... СТОП! Почему нравиЛОСЬ? Я бы и сейчас с удовольствием! 😉🎨

Если вдуматься, предыдущее любимое дело во многом схоже с нынешним:

🔬 Внимание к деталям
Нельзя просто взять и написать нарисовать: нужно учесть миллион мелочей, не упустить ни одной. Иначе не заработает или заработает не так, как задумано, — придётся резать и переразводить.

🧠 Аналитика, логика, структура
Сначала продумываем компоновку и последовательность размещения компонентов или логических блоков, затем рисуем. При этом в схожих блоках повторяем последовательность и рисунок. Это похоже на повторение определённого порядка слов в однотипных предложениях или логики изложения. И там, и там есть свой ритм и строй.

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

📦 Компактность и ёмкость
Да, вместо «Пиши — Сокращай» тут «Рисуй — Сокращай». Размеры плат, как правило, сильно ограничены по габаритам. Поэтому нужно рисовать компактно, при этом не нарушая технические требования. Никакой воды и пустот!

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

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

🌍 Иностранные языки
Локализации нет, но можно попутно изучить английский (пока читаешь спецификации) и немного китайский (когда получаешь готовые изделия) 😊🙈

🎨 Творчество
Как ни крути, ты художник: тут есть свобода и красота!

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
📝 Резюме:
Если нужен техпис и в поле зрения появился спец с «железным» бэкграундом али какой инженер-конструктор, который не вдруг захотел в документацию, — можно смело брать! 😉

Ну и заметочка на случай, если наскучило писательство... ☺️📝

ОБ иРИСКАХ, ИЛИ ПОСТПАСХАЛЬНОЕ 🐣

Пасха давно уж отгремела, а я только добралась до поста... такая весна... 🤷‍♀️🚀

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

Хорошо, что дальновидно был припасён готовый магазинный куличик 💅

Яйца тоже не задались 😅🤦‍♀️ Оказывается, и такое бывает: новая краска не ложилась, а овальные норовили укатиться со стола. В сухом остатке — всего три приличных яйца. Негусто.

Хорошо, что на всякий случай были куплены перепелиные🥚— они всегда получаются. Да и краска с прошлого года осталась — проверенная 💅

В итоге цель, конечно, достигнута, но потрачено много ресурсов: времени, продуктов, денег... И это при том, что подготовка началась заранее!

Ситуацию спасли проверенные инструменты и ресурсы, а также готовое решение в виде готового кулича)

Выводы:
• Не вводить новшеств при ограниченных ресурсах.
• Учитывать риски и подстраховываться, где возможно.

Вот такой риск-менеджмент на примере куличей 😁

В проектном менеджменте на этапе инициации проекта есть шаг, на котором продумывают всевозможные риски:
- Что может пойти не так?
- Насколько это серьёзно?
- Что с этим можно сделать?

Если риск можно нивелировать — принимаем меры. Если нельзя — закладываем буфер по времени и мониторим ситуацию 👀

Д. Канеман, например, предлагает участникам перед стартом представить, что проект провалился, а затем за 5–10 минут рассказать, почему это произошло 🤔

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

ПРИМЕРЫ РИСКОВ ДЛЯ ДОКУМЕНТАЦИИ

✔ Сложности с техресурсами: нет доступов к макетам, репозиторию, программам и т. д.
Что делать: заранее получить доступы или заложить на это время.

✔ Нехватка людей: отпуск, больничный, увольнение.
Что делать: отпуска учесть, а больничные заложить в буфер 👥

✔ Сложности с экспертами: не отвечает на вопросы, медлит с ревью.
Что делать: закладывать время на проверку каждым экспертом 📝, учитывая индивидуальные особенности, предупреждать заказчика, искать альтернативного ревьюера и, где возможно, проверять самостоятельно.

✔ Нюансы с ИБ/юристами/PR: если есть рискованные моменты, уточнять по ним как можно раньше.

✔ Изменился контекст задачи: нужно переписать.
Что делать: уточнять, на каком этапе разработки сейчас функциональность — возможно стоит подождать.

✔ Нехватка компетенции: требуется время на исследование.
Что делать: привлечь эксперта или исследовать самостоятельно.

✔ Технические сложности: нестабильная работа инструментов.
Что делать: чинить заранее, искать альтернативу или закладывать буфер времени ⏱️

⭐️ Идеальная задача

Лучшее начало недели — это идеально поставленная задача! 🚀

Составила общий чек-лист, что спросить у заказчика нового документа. Можно скинуть ему перед встречей или попросить заполнить онлайн, а затем обсудить.

Для небольших задач пунктов будет значительно меньше, но в любом случае всегда остаётся формулировка по SMART, плюс добавляются другие требования в зависимости от контекста.

1️⃣ Цель и содержание

* Какой тип документа нужен? (Инструкция, описание функциональности, спецификация и т. д.).
* Зачем нужна документация? Какую проблему решает или какой процесс описывает?
* Как мы поймём, что проблема решена? По каким критериям будем оценивать результат?

2️⃣ Аудитория и формат

* Для кого пишем? (Разработчики, клиенты, поддержка, юристы).
* Куда это поедет? Документация внутренняя или будет передаваться вовне?
* Где опубликуем? (Confluence, публичный сайт, сайт партнёра, FAQ).
* А если не публикуем? Как будем передавать и в каком формате?
* Нужен ли перевод? На какие языки и для какого масштаба аудитории?

3️⃣ Жизненный цикл и поддержка

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

4️⃣ Детализация и референсы

* Что хотелось бы видеть внутри? Опиши желаемый образ результата, структуру. Если есть примерное понимание или референсы — приложи их.
* Нужно дополнить FAQ?

5️⃣ Сроки и этапы

* Когда нужно отдать черновик на согласование?
* Когда deadline финальной версии?
* Что делаем, если сроки горят? Какой MVP документа?
* Какие есть риски по срокам? От чего зависим, кого ждём и где можно это отследить?

6️⃣ Ревью и консультации

* Кто должен проверить документ перед публикацией? (Разработчик, PM, редактор, дизайнер, тестировщик, юрист, PR, ИБ и др.).
* Кто сможет консультировать техписателя? Как часто и в каком формате?
* Кого нужно оповестить об изменениях кроме ЦА, например, смежные подразделения?

7️⃣ Технические ресурсы

* Есть ли доступ к тестовому стенду или репозиторию?
* Какие исходные материалы уже есть (тех. решение, спецификации, макеты)?

8️⃣ Контекст продукта, если о нём пока мало информации

* Название и направление (B2B, B2C, IT2IT).
* Стадия разработки.
* Основные функции и назначение.

🎯 В результате должна появиться задача по принципу SMART

__S__pecific (конкретная),
__M__easurable (измеримая),
__A__chievable (достижимая),
__R__elevant (актуальная для бизнеса),
__T__ime-bound (ограниченная по времени).

💡 Пример

Написать пошаговую инструкцию для сценария первичного платежа с примерами и UML-диаграммами. Опубликовать в Confluence (раздел «Платежи»). Первый черновик показать разработчику. После согласования отдать на ревью PM и техподдержке. После их согласования — опубликовать.

Срок готовности черновика: 10.04.26
Deadline публикации: 15.04.26

За консультациями обращаться:
Тестовый стенд и доступы:
Полезные материалы:

❗Срочно в номер❗Техписатели окружают Казанский собор 🏛❗

Вписалась в традиционный флешмоб TechWriters Days — сфотографировать Лисёнка-маскота в рабочей обстановке.

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

Прошлись по новому офису, сделала пару кадров с красивыми видами, выложила пост... Вдруг — сообщение ✉️

Как оказалось, сфотографировала я не только Рыжего на фоне Казанского 🦊🏛, но ещё и соседний БЦ, где трудится коллега по цеху.

Это уже третья известная мне редакция рядом с собором. Осталось найти коллегу с восточной стороны, и кольцо окружения сомкнётся 😊😛

Переименуем сквер в Техписательский или Ё-сквер, по утрам будем чинно выгуливать своих Лисят вокруг фонтана 🧐🦊⛲ , пить кофий ☕ на лужайке и обсуждать такое важное Слово!

🍬О важности фантиков🍬

Один семилетка тут выдал..

Деловито выложил на стол две шоколадки и заявил:
- У меня гипотеза!💡
- Какая? 🧐🫣
- Шоколад в упаковке коричневого цвета — более горький, чем в синей, потому что упаковка темнее и, значит, там меньше молока..🥛🍫

Тааак, подумала я.. Немного подчистить формулировку:
"Я как любитель шоколада ожидаю, что шоколад в более темной упаковке и т.д."
и можно смело рекомендовать на младшего менеджера продукта..😁

По фото заметно, что начинающий ПМ успел проверить гипотезу только на синей шоколадке, до коричневой так и не добрался 😁

Но эта история напомнила мне о другом: как важно, чтобы упаковка соответствовала содержимому. Иначе клиент, увы, может просто не добраться до продукта 🤷‍♀ — встречают по одёжке.

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

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

Поэтому помним о фантиках 🍫 и наводим красоту 😊💅🏻

🎂🎈Итоги личного года 🎈🎂

Нынче модно, и я не отстаю)
В честь дня рождения подвожу небольшие итоги техписательского года — минутка хвастовства:

✔ +4 продукта в копилку документации:
• 2 — внутренние описания API и сценариев с нуля
• 1 — публичное SDK с нуля
• 1 — публичная пользовательская документация и API для mister big продукта — обозначу его 🐘🙂
✔ +11 продуктовых команд со всеми вытекающими: новые люди, выстраивание коммуникаций, распределение зон ответственности и синхронизация по задачам. Тут арифметика не бьётся с предыдущим пунктом — во всём виноват 🐘😁
✔ Подготовка к выходу стажёра и эпичный облом в итоге 😅🤦‍♀️
✔ Наставничество.. а было ли оно?) формально зачтём 🥸
✔ Переезд в новую команду и офис 💃😵‍💫
✔ Грейдап до senior 🆙
✔ Организация поездки для команды в сочинский коворкинг 🏄‍♀️
✔ Курс по документации API — пройден👩‍🎓
✔ Каналы в ТГ и МАХ — начало положено 🫣
✔ Намёки на внутреннее комьюнити.. 🤞🤞

Сплошные софты получились))) По хардам итогов сильно меньше:

✔ благодаря коллегам с соседнего департамента познакомилась с Figma, и.. у нас случился контакт 💘😍
Чем дальше, тем больше нравится — осваиваю 🥰
✔ один из продуктов принёс с собой новый репозиторий — теперь приходится смотреть в код и swagger. Неожиданно пригодились давно зарытые знания, и это очень радует)

С любопытством двигаюсь дальше — в новый личный год. Конечно там будет по-другому, предполагаю, что меньше нового и больше глубины. Но самое главное — там точно не будет скучно 🙃💃

И вам желаю, чтобы ваш личный год, независимо от того, когда он начинается, принёс новое хорошее и был ровно таким, как вам хочется: подходящим по темпу, задачам, наполненности и обстоятельствам 💫