Почитал комментарии коллег. Местами они правы. Но при этом не стоит и забывать: 1. Большая зависимость от направления разработки (коммерческая или ин-хаус) 2. Не всегда правки приводят к генерации новых багов, порой хот-фикс превращается в легаси и "исторически так сложилось". Не новый баг, а просто кусок не поддерживаемого куска кола и тех.долга 3. Большая зависимость от размера команды на конкретном продукте. 4. Всегда есть категория пользователей, которая считает, что имеет право вмешиваться в процесс разработки и дизайна на правах "владельца системы" или "заказчика". Ну и Вишенка на торте - "ИИ нас заменит". Нет, не заменит. Он заменит/л "джунов", а потеря рынком джунов приведет к потере синьоров

Так требуйте скрины или логи. Скажите: «Я и пальцем не пошевелю, пока мне не предоставят необходимую информацию». Проект с нуля сами писали? Что-то багов у вас много, и они плодятся. Я так понимаю, вы не проверяете свои правки, потому что «тестовый стенд решил отдохнуть». Отсюда все проблемы и грабли. Требуйте доступности тестового стенда в любое время дня и ночи! Правки вслепую потом приводят к таким проблемам. Нет стенда - нет правок.

А может причина в том, что отсутствует четкое и согласованное заказчиком ТЗ? К тому же, вы позволяете себе вносить правки в код по просьбе тестировщика. Правите одно, а другое сыпется. Консистентность была в версии 1, а после вашей правки она нарушилась. Вам задания должен заказчик выдавать. Результаты тестирования сдаются оптом, ошибки правятся оптом. И только после адекватной проработки аналитиком и архитектором. Каждый возврат вы должны обосновывать, как минимум - “сделано четко по согласованному ТЗ”, а для этого, неожиданно, нужно так и делать. Вы сами соглашаетесь работать в таких условиях, при этом не умея объяснить почему этого делать нельзя. Вы можете быть бесконечно компетентным разработчиком, полностью вовлечённым и болеющим за проект, но пока не начнёте соблюдать организационную гигиену сами и не заставите ее соблюдать тех, кто выдает вам задания, будете страдать. Вы работаете в жутко бюрократизированной компании, так соответствуйте! Бюрократия поможет вам прикрыть вашу пятую точку, если вы будете пользоваться ей правильно.

Примите слова искренней поддержки! Держитесь!

От себя добавлю момент - бывало такое, что накидывают как на вентилятор - не думая, и слушать не хотят, что контент должен не разработчик формировать. Разработчик даёт только инструменты и время его - дороже, чем у контент менеджера.

По своему давнему-давнему личному опыту говорю. Реализовал - не довольны, что не наполнено. Наполнил реальным, а не тестовым контентом (речь о данных, а не о контенте сайта конечно). Прилетает - не сделаны следующие задачи - почему?

Вывод - собираем чемодан и пусть "рукоЙводители" сами думают что им делать с таким подходом.

А почему у вас нет прослойки между разработчиком и тестировщиком?

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

При должном уровне проработки с заказчиком, детальном проектировании и прототипировании и согласовании, затраты на разработку стремятся к минимальным, а с учетом AI в принципе способны свестись к рефакторингу.

Сама формулировка 'виноват разработчик' обычно маскирует разрыв между ожиданиями и исходными данными. Если задачи заходят сырые, код просто проявляет оргболь. Полезнее фиксить входной контракт: acceptance criteria, ownership и review до старта. У вас это уже формализовано?

Всегда виноваты линейные работники !!! Это каскад и внизу всегда виноваты , ни кто не хочет брать вину на себя

Просто нужен Gemini , который всё будет делать сильно быстрее. 🥺

Обычно во всем виноват продакт )))

С подключением, коллега) все уг стекается к конечному исполнителю и всегда виноват конечный исполнитель - в нашем случае разработчик. А на этапе проектирования и проработки - та кто там нас слушал, погнали и побыстрее в прод. Сейчас еще ИИ типа, надо еще быстрее "код ничего не стоит"

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

Вам могу только пожелать сил и терпения подсвечивать пробелы в процессах и добиваться их изменения 🙏

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