Так?)

К счастью, нет) на этапе разработки часто что-то меняют, после задач на документирование редко, но бывает

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

Недавно читала статью на ДОУ и прям так сильно она мне с моим опытом и чувствами в данный момент срезонировала

«Стал …, потому проявлял больше интереса, чем другие люди в компании.  Мне было скучно, я хотел что-то улучшать, совершенствовать »
«В определенный момент понял, что дальше работать на этой должности мне неинтересно: я не знал, как правильно делать многие вещи, а делать неправильно и постоянно учиться на своих ошибках не хотелось.  И вообще мне не очень нравится работать с людьми в условиях, когда они мои подчиненные.
В конце концов, я перешел в большую компанию.  Там мне платили примерно так же, как за работу технического директора в предыдущей компании, но я просто работал разработчиком (исполнителем).»

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

Кстати, а грейды для техрайтера с перечнем владения определёнными скилами по уровням есть в общем доступе? (Не размытые, а четкие)

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

«В Google работают инженеры высокого уровня.  С одной стороны, приятно, что даже Джуниор, которые только пришли в компанию, можно поручить задачу и знать, что ее сделают, чрезмерного контроля не надо.  С другой стороны, время от времени появляется синдром самозванца: кто я такой, чтобы быть здесь, все умнее меня, они меня «вычислят» ... В компании даже есть внутренние документы, как бороться с этим чувством, потому что оно возникает  у всех, когда человек видит вокруг себя столько умных коллег»

https://dou.ua/lenta/interviews/savka-about-work-in-google

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

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

заколдованные обновления какие-то)

Если не научиться не напрягаться в такие моменты, то можно довольно быстро сойти с ума или делать двойной или более объём работ. Оно тебе надо?

+++ про ценность.
Ну и если техпис, придя на новое место, обнаруживает, что упомянутая Михаилом "процедура по внесению изменений" не документирована, а существует только в виде воркфлоу Джиры (и это ещё неплохо), тот техпис должен эту процедуру записать и согласовать с участвующими коллегами :)

Если напоминания о висящих задачах происходят через устный разговор - что-то не то с вашей тикетницей, кажется

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

вторую половину сообщения вообще не понял, сорян)

и тебя это тоже не напрягает?

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

Эх, не прошёл мой кек

Вот про грейдовую систему техписа тоже было бы интересно послушать опыт коллег. Особенно на уровне руководителя отдела документирования (выстраивание процессов, стандартизация и прочее). У нас она есть, но для техписа она непонятна как применить. Если по аналогии с инженерными должностями, то это улучшение процесса документирования, онбординг новых сотрудников. Было бы интересно послушать опытных людей как они строили себе карьеру до сеньоров:)

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

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

Карьера до сеньора делается просто.
1. Устраиваешься единственным техписом в растущую контору.
2. Ждёшь, когда количество задач и бюджет конторы вырастут достаточно, чтобы нанять второго и третьего техписа.
3. Профит!
Ну, если только между п. 1 и п. 2 не зарекомендуешь себя как человека, которому нужен руководитель поближе, чем нынешний.

>Чем вы самостоятельнее и чем меньше вас нужно менеджить, тем вы ценнее на рынке труда.

Но здесь-то техрайтера как раз не нужно менеджерить. Тут наоборот она проявляет инициативу. Переживает за документацию. Думает о процессах. Исследует чужой опыт. Человек в высшей степени заинтересован в качестве своей работы.

Не понял фразу про "руководителя поближе"

когда принимается решение, какого техписа будут нанимать вторым - того, кто придёт в помощь, или того, кто должен стать руководителем нынешнего.

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