Само собой. Но, что поделать. Хотим мелочь но красиво, можно и самому, хотим масштаб, при котором допустимы потери - делегирование.

проблемы с делегированием это trust issues наверное

и "один я д'артаньян"

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

Я за подход, когда все могут делать все в команде, если потребуется: и внутренние технические описания, и апи, и пользовательские доки, но есть естественное бизнесовое деление и специализация/предпочтения. UX райтеры у нас это вообще отдельная команда, мы с ними только шарим общий стайлгайд и некие договоренности, но активно не взаимодействуем

Прям кроссфункциональная команда, agile и вот это всё:)

Не люблю Райкина, но его монолог про разделение труда в создании костюма хорош

браво) у меня прямо некоторые вопросы отпали)
https://www.youtube.com/watch?v=WEV81jZBzDM

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

> есть естественное бизнесовое деление и специализация/предпочтения

а можно тут подробнее?)

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

или такое углубление мешает выполнению своим функциям (например ты больше заботишься о продукте чем об определенных тонкостях предоставления информации. ты уже не объективен)
ну и есть же тех райтеры которые работают не на одну продуктовую компанию, а на аутсорс, как softserve к примеру. у них каждые 3 недели или месяцы могут менятся продукты

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

у меня это и аналитика (поиск задач/потребностей/составление кейса) и ux (снова поиск и попытка придержаться общего стиля) и сам техрайтинг (который прыгает от сверх простого "нажмите последовательно 10 кнопок" до сложного разбора частей скрипта и его работы). инструменты работы примерно одинаковы на этапах сбор информации/тестирование/сбор фидбека/улучшение, но не на этапе собственно самого письма (когда результат на "бумагу" передаешь)

Это значит, что некоторые члены команды разбираются чуть лучше в разных частях бизнеса (например, один сработался с командой социальных интеграций и описывает их апи  и внутренние доки обычно, но другие тоже могут если надо, второй с командой buyer experience чаще работает, третий с командой поиска и тд), у нас это называется домены, в среднем все во всем, но есть предпочтения, которые я учитываю, есть возможность в любой момент переключиться в другой домен

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

Спасибо за ответ

Я тут набросал тестовое задание для техписателя нам в команду. Впервые придумываю тестовое задание, хочу обратной связи. Можете поревьюить? Пишите в личные сообщения, я вам пошарю ссылку. )

👋

Привет :)

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

меня все еще улыбает тестовое задание, которое составил наш дизайнер и ейчар, когда только ввели должность тех райтер несколько лет назад.
по большем части потому, что я достала отдел маркетинга своими задачами и сообщениями о том что нужно исправить работая в другом отделе. сама я не хотела переходить ( но спойлер, я все равно туда влазила на 10%, потом на 20%, потом на 50 и собственно на 100% через некоторое время и после того как 3 человека сменилось)
https://monosnap.com/file/RUpTZSFtNCeCOloEaQrk5nTNQ8uHWv

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

как максимум
а) изначально были поданы неверные данные, пример кода с ошибками, на основе неофициальной библиотеки которую даже наши не тестировали (но так как человеку дали ориентироваться в этом, возможно побоялся бы сказать и поверил, что все верно, то он дурак)
б) такая задача в этом разрезе невыполнима даже главному разработчику-интегратору (а я ему давала это задание).
в том плане что нет 100% правильного решения (а значит и нет особо ключевых показателей, соответствует результат требованиям или нет), которое бы удовлетворило всех.
это слишком узкая область. много факторов играет роль, начиная с того, к какой системе подключают (архитектура и уровень доступа если это готовые решения crm/cms могут быть разные), одну и ту же задачу можно выполнить по разному и каждый след разработчик будет хейтить такой-то подход

ну то что тут было минимум данных это объяснимо, у нас и сейчас такие задачи. ведь нужен был 100% самостоятельный человечек на должность)

Смотрите, какое чудо я нашёл
https://supermodel.io/schemaorg/WebPage?view=graph

https://habr.com/ru/company/flant/blog/514830/ похоже на нее

Вам тоже некая Августина шлёт вхолодную офферы разработчика документации?

ммм нет

Побанил в чате, на случай если она просто по участникам чата спамит