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

Я много лет работаю у одного и того же работодателя. В течение последних 6 лет я работал над двумя проектами: Проект А, где я был членом команды в течение короткого периода времени, а затем стал руководителем команды, а также принимал все архитектурные решения. Проект А среднего размера, максимум около 6 разработчиков; Проект Б, где я был либо членом команды, либо руководителем группы, но не имел никакого влияния на архитектурные решения. Проект B — это большой проект, над которым работает множество команд, разработчиков и тестировщиков. В проекте А канбан использовался без каких-либо строгих ограничений по времени, а в проекте Б применялся скрам.

Я работал над проектом А, затем над проектом Б, затем снова над проектом А, и теперь мне сообщили, что меня скоро назначат на проект Б.

Однако я не очень этому рад. Когда я работал над проектом Б, это был почти кошмар, очень напряженный опыт. В этом проекте было несколько проблем. Прежде всего, как тимлид, я отвечал за выполнение спринта, но у меня не было на это средств. Проблемы Jira не могли быть закрыты до того, как тестировщики их протестировали, а тестировщики не могли протестировать их до того, как соответствующий код был перенесен в среду QA, а из-за реализации CI код был перенесен в среду QA только тогда, когда код был объединен в dev ветке, но мне не дали права на слияние с dev, поэтому мне пришлось умолять архитекторов решений или других руководителей команд объединить запросы на включение из моего времени в dev, и они всегда откладывали этот процесс, и это действительно блокировало.

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

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

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

Короче говоря, мне не очень нравилось работать над этим проектом Б, поэтому, когда я вернулся к проекту А, я почувствовал большое облегчение, поскольку никто не унижал меня в этом проекте, и у нас был реализован действительно лучший процесс.

Мне сообщили, что скоро меня назначат на проект Б, и я чувствую, что у меня нет выбора. Мне пообещали, что все серьезные вопросы в организации проекта были решены, так что теперь разработчики не переутомляются, имеют прямую связь с клиентами. Единственный выбор, который у меня есть, это либо попытаться подтвердить, что организация Проекта Б действительно изменилась, и мне понравится работать над Проектом Б, либо уйти.

Поэтому мне интересно, стоит ли мне попробовать поработать над проектом Б, или это не стоит того, и я должен уйти?

Есть ли основания полагать, что обещание о решении проблемы, с которой вы столкнулись / на которую жаловались ранее, не соответствует действительности?
И вы говорили с кем-нибудь по проекту Б, чтобы подтвердить это?
Вы пытались отклонить неясные запросы JIRA и потребовать для больших изменений надлежащий документ с требованиями, контролируемыми источниками, на который можно ссылаться в заявке.
Я еще не разговаривал ни с кем, работающим над проектом B, кроме человека, который сейчас является архитектором решений в проекте B и который сообщил мне, что хочет, чтобы я переназначился на его проект.
Также хороший вопрос, есть ли какая-то логическая и рациональная причина не доверять обещаниям. Я не могу найти никакой разумной причины прямо сейчас, просто прошлый неудачный опыт и мое внутреннее чутье говорят мне, что я должен быть осторожен.
Я хотел бы отклонить неясные запросы JIRA, но наши архитекторы решений, менеджеры проектов и координаторы проектов подталкивали нас к достижению какого-либо результата любой ценой, поскольку это был первый очень крупный проект, выигранный работодателем, поэтому мы ожидали, что мы добьемся результатов, даже если не было макетов, неясных и расплывчатых требований и прямого общения с клиентами.

Ответы (2)

Мне пообещали, что все серьезные вопросы в организации проекта были решены, так что теперь разработчики не переутомляются, имеют прямую связь с клиентами. Единственный выбор, который у меня есть, это либо попытаться подтвердить, что организация Проекта Б действительно изменилась, и мне понравится работать над Проектом Б, либо уйти.

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

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

  • Если все так, как обещают, это хорошо.
  • Если все окажется не так, как было обещано, то у вас есть более серьезная проблема, чем культура работы для этого проекта, это ложное обещание, данное вам относительно ожидаемых изменений. В этот момент вам следует подумать о том, чтобы уйти от работодателя.
Согласитесь, ложное обещание было бы большей проблемой, чем культура работы
Ложные обещания также чрезвычайно распространены в отрасли, и я осмелюсь сказать, что в большинстве случаев обещания улучшения процессов и рабочей среды в VAST являются чушью. Особенно, если не менялись люди в руководстве команд.

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

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

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

Один из подходов: делайте то, что вы делали раньше: защищайте свою команду и делайте все возможное.

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

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

Мне обещают, что я ПОЛУЧУ право слиться с dev прямо сейчас