Про али похожие отзывы.

В озоне друг работает программистом, там слишком часто набирают техписов. Когда спросила - почему? Разъяснил что в озоне часто набирают «мясо», а потом происходит сокращение.

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

Работаю уже в 4-м проекте и 3-й компнии за 2,5 года (до этого был большой перерыв). В 3 проектах до меня техписа не было. Прихожу, все тексты причесываю, включая UI, продумываю, как это локализовать, или наладить сбор инфо, чтобы все не оставалось все в головах старших разработчиков. Прошла множество курсов, хорошо разбираюсь в API.

но большинство задач не удается довести до конца, потому что они “неважные”, а вся команда занята важным. Причем начальству все равно, что я временами сижу без дела. Точнее, я все равно инициирую то то, то это. Но это все «вычесывание блох».

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

Я так понимаю, здесь нет тех, кто переквалифицировался?

Весной пыталась устроиться бизнес-аналитиком, но, возможно, опыта не хватило (работала в команде аналитиков и совмещала их задачи с мануалом и API). Кроме того, периодически встречаю вопли и техписов, и техподдержки, и тестеров. BA в некоторых проектах тоже весьма странную роль играют. Типа идти и некуда.

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

Нравятся встречи в более зрелом из нынешних проектов, где менеджер, старшая тестировщица, старшая разработчица и я довольно продуктивно обсуждаем, как записать то и то. Но этот  проект сокращают. И остаются эджайл и какбэ эджайл, которым не до внятных текстов и даже requirements. В опчем, мне, лингвисту, который может и в Oracle EBS настройку проверить, и в Постмане вызовы сделать, и SQL знает, - как будто ваааще нет места во всем этом.
...В нынешнем проекте пытаюсь найти общие задачи с нашей шведской техподдержкой - они 7 лет на проекте, много знают, их знания можно конвертировать в тексты.
Нравится BA, UX design - но везде, где я работала, командам было не до этого. Ппц сколько всего «неважного», да?

Вам надо на работу прямиком к @factorized Таких проблем не будет! :)

спасибо) ник совпадает с названием компании? приведите примеры, почему вы так считаете. можно в личку.

Но то что я после такого опыта могу пойти подрабатывать тестировщиков и дизайнером впридачу это я уже поняла
Авось и продактом когда-то чего-то своего)

Но пока хотелось остановится на том, на что пришла.

В общих чертах.

Когда я был единственным тех писателем на проекте/в компании, то старался разделять, как задачи, так и время.
Приведу пример: условно, с 8 до 10 я занимаюсь более приоритетной задачей и меня не нужно отвлекать никакими «срочно», «бросай всё», с 10-12 задачи с более низким приоритетом, дальше отвечаю на вопросы или выполняю всякие «мелочи», текучку, сюда же орг моменты, потом другой вид задач и тд.
В самое продуктивное время лучше выполнять наиболее важные задачи.
Методологий Scrum, Kanban касаться не будем, ибо рискуем до утра дискутировать.

Инициатором в формализации процессов выступаете Вы. У Вас должно быть чёткое понимание на какие ситуации и как  реагировать или не реагировать.
Суть в том, чтобы постараться вписаться в текущие процессы/процедуры компании мягко и обойтись «малой кровью.»

Хороший Вы сотрудник: за троих работаете.
Требуйте пересмотра финансового вознаграждения. :)