index0h

Есть должность / роль: product owner / product manager. В задачи специалиста входит: мониторинг рынка, поиск решений / идей и выставление продуктовых требований (в виде брифов например) для отдела разработки.
Если очень грубо говоря: это специалист, который отвечает на вопрос "что делать?".

> Компании на Java имеют правильную культуру разработки

Культура развивается для решения бизнес задач. Вне зависимости от стека.
Например у вас конвеер сайтиков, для бизнеса критична скорость разработки, со стороны девов будет одноразовый говнокод.
Если же у вас например платежный процессор, тут для бизнеса критично качество. Тут будет и архитектура и покрытие тестами и куча модных слов.

> Перспектив для хорошей ЗП гораздо больше

В среднем по больнице зп на яву выше, чем у той же пыхи. Но все определяется вашим умением продать свое время на собесе.

> Порог вхождения выше, следовательно проекты интереснее и карьера в течение 5 лет сложиться лучше

Порог вхождения ни как не связан с интересностью проектов. Как сложится ваша карьера зависит только от вас.

> куда двигаться дальше

Не распыляться, выберите один стек и станьте в нем крутым спецом.

Ищите крупную продуктовую компанию, а не аутсорсный бодишоп. Не связывайтесь с гос. сектором и телевидением. Ищите контору с крупным собственным продуктом, бизнес которой построен не на его продаже/внедрении.

Почти не пользуемся Trello, а юзаем гугл доки для задач.

В гуглодоках хратить широкое описание задачи допустимо, если например это спецификация некого протокола. В задаче же должна быть ссылка на эту спецификацию.
Донесите до руководства выше вас и TL и PM, что задачи, кроме таск менеджера - не должны браться в работу. В крайнем случае заводите задачи самостоятельно и отправляйте ссылки на них постановщику, TL и PM. Если это будет восприниматься в штыки PM/TL - валите от туда, если же какими-то другими постановщиками - отправляйте их к TL/PM с указанием, где оформляется задача и как. Так чисто между прочим вот этот вот все - задача вашего PM-а.

Не всегда удается убедить, что на реализацию нужно больше времени.

Фиксируйте ETA задачи перед тем, как брать ее в работу. Уведомляйте об этом постановщика И TL-а. Если вдруг возникнут вопросы до реализации - спросите, на каком основании выставлялось ETA постановщиком, опираясь на кодовую базу. Во время реализации - фиксируйте возникшие трудности в теле задачи. Если ETA сильно увеличиться - обязательно уведомьте об этом TL-а и постановщика. Если вопросы возникнут в конце - ссылайтесь на комментарии и уведомления.

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

Это входит в ваши обязанности? Если нет - отправляйте к гуглу. Безусловно, человеком тоже надо быть и помогать по мере возможности, но не во вред вашим основным обязанностям. Если вдруг этого от вас потребует руководство - не вопрос, заводите maintenance задачу и логгируйте в нее потраченное время.

Периодически (пару раз в неделю) орут матом менеджеры (не на прогеров, а друг на друга или просто так).

It's ok

Не хватает тестеров и некоторые задачи очень долго не тестируются.

И чо? Это ваша проблема что ли? Если конкретно ваша задача долго тестируется и вопросы к вам - отправляйте в отдел тестировщиков.

помогаю с переходом на Жиру (на Трелло ругается наш менеджер), настраиваю там все...

Вообще говоря это прямая задача вашего PM-а и админов.

Это правда не особо нормально или я много хочу?

То, о чем вы тут писали - называется технический процесс. Да, в вашей компании он не очень.

Информация из книг, по большей части, выветрилась

Потому, что

за ненадобностью

Нормально ли это, или ощущение, что я деградирую, правдиво?

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

Возможно, стоит перечитать книги или взяться за новые(но зачем, если я не смогу применить знания в работе?

Книги по конкретным технологиям, по языкам например - заново перечитывать не стоит, информация вероятнее всего там уже устарела)). По более общим "глубинным" вещам - вполне имеет смысл.

На пет проекты нет времени, учеба+работа+3 часа на дорогу съездают все время

Вы должны понимать, зачем делать пет проект. Это важно. Многие думают, что "вот напишу свое супер крутое решение и придет гармония в этот мир". Увы, это не так, вероятность что вы будете использовать свои же наработки на работе - довольно низкая еще и пропорционально зависит от вашего "веса" в компании.