Size: a a a

technicalwriters

2020 November 28

M

Maeg in technicalwriters
Sirius
Следить самому за трекером... это утопия, ведь много комментариев связанных просто с разработкой/тестированием.. то есть это или просто размышление или пишут не, не работки или что они добавили но просто называют это словами какой-то папки/функции понятной вероятно только из контекста просмотра всего кода (не всегда понятно из темы задачи вообще где это)
И таких задач от 12 направлений одновременно просто масса
Не обязательно следить за всем трекером. Может быть, есть возможность настроить себе выборку или даже автоматические уведомления на определённые события: например, заведение задачи на разработку нового функционала.
Ну и в идеале каждый крупный релиз должен проходить тестирование по документации: Release Notes даже для внутреннего пользования очень полезно, например
источник

M

Maeg in technicalwriters
Но багфиксы, да, очень полезно самой мониторить :( всю эту огромную массу :(
источник

M

Maeg in technicalwriters
Sirius
иногда кажется что руководство заботит только фидбеки оставлены в соц сетях, площадках фидбека о сервисе, написание лично, оставление фидбека через форму..
Вот оттуда черпается иногда вдохновение «кого поругать» или «что добавить»

Пока ещё там никто не писал о плохой документации) поэтому может и не верят когда об этом говорят «изнутри»

А кто может быть союзником? Кажется все стараются уйти от этого будто его лично и его круга вопросов не касается 😅
Союзники - QA, конечно. Раз техпис в конторе есть, то и тестеров должно быть в количестве
источник

EN

Ekaterina Noskova in technicalwriters
Sirius
Привет, а что вы делаете когда команда разработки (во главе с теми кто дал задание что-то изменить/добавить в существующем интерфейсе)
напрочь отказывается/забывает сообщать об этом техническому писателю.

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

И вот об этом узнаешь только от команды поддержки, которые идут к тебе с таким большим возмущением (портя немного нервы). Потому им сообщил клиент, пожаловавшись.. (они тоже узнали только от клиентов)

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

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

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

В общем мне даже сложно определить главную проблему, кто виноват в этой всей схеме :) ну чтобы оттуда начинать разматывать клубок и решать сложившуюся проблему.
недавно читала книгу creating documentation in agile environment, там рекомендуют завязаться на dod команды - в критерии приемки задачи добавить пункт, что для задачи определен documentation impact - нужна дока или нет и если нужна, создавать задачу на техписа. так у вас бэклог копится и не теряется то, что нужно описать. в трекере для этого заводится отдельное поле, по которому можно фильтровать задачи
источник

MS

Maria Shabanova in technicalwriters
Maeg
Союзники - QA, конечно. Раз техпис в конторе есть, то и тестеров должно быть в количестве
У нас тестеров что-то около ноля
источник

MS

Maria Shabanova in technicalwriters
Сама всё отслеживаю, иногда да, на какие-то изменения случайно натыкаюсь =/
источник

MS

Maria Shabanova in technicalwriters
Особенно техдиректор любит что-то накодить и никому не сказать, а страдает весь отдел разработки
источник

M

Maeg in technicalwriters
Ekaterina Noskova
недавно читала книгу creating documentation in agile environment, там рекомендуют завязаться на dod команды - в критерии приемки задачи добавить пункт, что для задачи определен documentation impact - нужна дока или нет и если нужна, создавать задачу на техписа. так у вас бэклог копится и не теряется то, что нужно описать. в трекере для этого заводится отдельное поле, по которому можно фильтровать задачи
О, да, кстати про критериям приёмки отлично работает!
Ну и в трекере когда создают задачу на разработку или закрывают баг, можно ввести галочку "требуется документирование" - и чтоб обязательно ручками ставили, а не мимо пролистывали 😈
источник

EN

Ekaterina Noskova in technicalwriters
источник

M

Maeg in technicalwriters
Maria Shabanova
У нас тестеров что-то около ноля
Это сколько вас на 12 продуктов?
источник

ДБ

Данил Боровков... in technicalwriters
Maria Shabanova
Особенно техдиректор любит что-то накодить и никому не сказать, а страдает весь отдел разработки
Ну так по коммитам же видны изменения. Диффы посмотреть. Или вообще в Гите настроить триггер на событие?
источник

MS

Maria Shabanova in technicalwriters
Maeg
Это сколько вас на 12 продуктов?
Почему на 12?
источник

M

Maeg in technicalwriters
Maria Shabanova
Почему на 12?
Ну вы писали про 12 направлений. То есть продукт один, а 12.. локализации?
источник

MS

Maria Shabanova in technicalwriters
Я такого не писала)
источник

MS

Maria Shabanova in technicalwriters
Я отвечала на то, что если есть техпис, то есть и тестеры. Нету.
источник

M

Maeg in technicalwriters
А, я автору исходного вопроса. Перепутала вас, извините :)
источник

MS

Maria Shabanova in technicalwriters
:)
источник

А

Александр Мокрушин... in technicalwriters
Ekaterina Noskova
недавно читала книгу creating documentation in agile environment, там рекомендуют завязаться на dod команды - в критерии приемки задачи добавить пункт, что для задачи определен documentation impact - нужна дока или нет и если нужна, создавать задачу на техписа. так у вас бэклог копится и не теряется то, что нужно описать. в трекере для этого заводится отдельное поле, по которому можно фильтровать задачи
Никто лучше писателя не определит, влияет ли задача на документацию.
Документирование можно сделать последним этапом процесса. Писатель решает описывать или закрывать задачу
источник

S

Sirius in technicalwriters
Maeg
Не обязательно следить за всем трекером. Может быть, есть возможность настроить себе выборку или даже автоматические уведомления на определённые события: например, заведение задачи на разработку нового функционала.
Ну и в идеале каждый крупный релиз должен проходить тестирование по документации: Release Notes даже для внутреннего пользования очень полезно, например
Выборку по каким критериям? У нас в данный момент открыто 870 задач «сделать», 213 задач «починить» и 120 задач «запрос на новую фичу» это только что касаемо отдела разработки.

12 направлений - это 12 микросервисов и подразделов базы знаний и апи.
Это 12 «продуктов» а не «категорий задач.

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

Те то таски никогда не заканчиваются. А именно описание нового функционала (без ТЗ и QA, у продакта времени описывать, говорят ну ты посмотри - если что, спросишь. а у вторых чаще всего нет времени отвечать или ещё чаще они это ещё не проверили. Говоря что мои запросы слишком «вычурные».

Но это не я придумала, это из анализа прошлого опыта как ещё может использовать продукт пользователь)

И я, сначала участвую с дизайнерами в UX (но как-то выборочно, не по всем микросервисам; кто-то «сам» - и вот там где «сам» - о том я и не знаю) потом пишу ТЗ на статью, потом тестирую, потом пишу, потом перевожу, потом «подрабатываю» локализатором и в общем слежу чтобы было опубликовано на всех языках.

По апи по разному молодые ребята описывают все, начиная что означает каждый параметр ввода вывода, заканчивая примером запроса и ответа.
А от «старых» только сами эндпоинты получаешь, на вопросы или игнор или бурчат отвечая так что в итоге больше вопросов или отвечают «чтобы было». В итоге это ещё дополнительное время, чтобы вообще «подобрать» тип и формат данных - ведь это может быть объект, а может быть массив.. может быть обязательный или необязательный...  юрл может быть енкодед, может быть нет, запись может быть /{id} а может быть /?id={id}.. в общем протестировать и аккуратненько все на сайте с описанием и примерами выложить что у меня вышло

У меня есть и собственный план по изменениям - но до него вообще не доходят руки.
Как ушёл человек, который занимался UX райтингом и локализацией это все перешло на плечи тех райтер.
При попытке попросить человека
Или покорректнее давать ТЗ отвечают не видят необходимости. Как есть так и ок.

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

S

Sirius in technicalwriters
Ekaterina Noskova
недавно читала книгу creating documentation in agile environment, там рекомендуют завязаться на dod команды - в критерии приемки задачи добавить пункт, что для задачи определен documentation impact - нужна дока или нет и если нужна, создавать задачу на техписа. так у вас бэклог копится и не теряется то, что нужно описать. в трекере для этого заводится отдельное поле, по которому можно фильтровать задачи
Спасибо за рекомендацию! Думаю нужно и мне прочитать

А есть вообще «шаблон» как должно выглядеть ТЗ «идеальное» на техрайтера?
Я уже исходя из опыта что-то пишу, но не знаю насколько это верно по стандартам, может его вывели и получится все таки прочить делать «по правилам» если это облегчит жизнь)
источник