Как мне быть в ситуации, когда 90% моих предложений игнорируются или отвергаются?

Я работаю в компании среднего размера и работаю там уже больше года. Я состою в двух командах (TeamA и TeamB). В TeamA 15 участников (14 товарищей по команде и 1 менеджер), а в TeamB 3 члена (2 разработчика и 1 менеджер). У обеих команд разные менеджеры. Большая часть моей работы выполняется в TeamB. Мой менеджер является менеджером TeamA, но я также отчитываюсь перед менеджером TeamB, потому что я трачу 90% своего времени, работая в TeamB.

Проблема, с которой я сталкиваюсь, заключается в том, что каждый раз, когда нам нужно что-то разработать, мы обсуждаем дизайн. Почти на каждом совещании по дизайну предложенное мной решение будет отвергнуто, потому что оно требует больших усилий по написанию кода и небольшой сложности. Например: в одной ситуации нам нужно было классифицировать предметы. Мое решение состояло в том, чтобы иметь таблицу с категориями и другую таблицу ссылок, которая будет содержать отношения категории и элемента. Это было отклонено, потому что требовалось создать две таблицы (Category и CategoryItemLinkTable), и в итоге мы жестко закодировали категории для каждого элемента в таблице Item. Причина, которую мне назвали, заключалась в том, что "We will hardly ever change the categories for an item once they are set. And if we do, we will just replace it in the code everywhere."было много случаев, когда не было причин не любить решение, а просто потому, что им не нравилась идея.

Я также заметил, что другой разработчик и менеджер объединятся против моего решения и выступят против него, что не оставит мне другого выбора, кроме как почувствовать себя"I should have just kept my mouth shut and not come up with anything and do what is told."

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

Может кто-нибудь, пожалуйста, направьте меня, как мне справиться с ситуацией и преодолеть эту проблему?

Как я уже сказал, я не пытаюсь усложнить решение, но если ситуация требует, то так и должно быть. Плюс как менеджеру, почему кого-то будет волновать, сколько кода будет написано для реализации чего-либо. Это работа программиста. Не так ли?
Работа менеджера очень заботиться о том, сколько кода будет написано.
Джо, приведенный пример менее сложен и менее рискован, чем изменение жестко запрограммированных значений в нескольких местах кода.
@JoeStrazzere: Когда вы разрабатываете решение, вам нужно держать его открытым и не закрывать. Тесная интеграция каждого компонента — плохой дизайн в любом аспекте.
@DanPichelman: я не согласен. В обязанности менеджера не входит смотреть, сколько кода написано. Это проверка того, соответствует ли применяемое решение стандартам (если таковые имеются).
@Asdfg - «Когда вы разрабатываете решение, вам нужно держать его открытым, а не закрывать» - это на самом деле противоречит совету, который я читал (я думаю, от Фила Хаака), который гласил: «Когда вы делаете что-то в первый раз, можно жестко закодировать это. Когда вы сделаете это во второй раз, вы можете жестко закодировать это снова. Если вы обнаружите, что делаете это в третий раз, значит , пришло время искать обобщенное решение». Если «закрытие решения» ускоряет разработку, то это может быть правильным решением, если маловероятно, что оно изменится.
Ага, вот статья, на которую я ссылался: haacked.com/archive/2005/09/18/…
@AdamV: я думаю, что обсуждение пошло в неправильном направлении. Вопрос здесь в том, как поступить в ситуации, если вы видите, что ваш менеджер не рационален и отдает предпочтение другим коллегам.
@Asdfg - я не вижу доказательств того, что «мой менеджер нелогичен». Я даже не вижу доказательств того, что «предпочитает других сверстников». Я вижу только доказательства того, что «я не могу убедить его приложить дополнительные усилия и сложность сейчас для теоретической выгоды позже» (как указано в ответе MrFox ниже).
Ваш менеджер может принять совершенно рациональное решение взять на себя технический долг позже в обмен на что-то еще сейчас, исходя из бизнес-требований, которые они либо знают, а вы нет, либо которым они придают большее значение, чем вы. По мере того, как я продвигался по карьерной лестнице в сфере ИТ, я научился понимать, какой занозой в заднице мое более молодое и наивное «я», должно быть, было тогда для моих менеджеров. Иногда быстрый и грязный ответ. Иногда «достаточно хорошо» действительно так. Иногда, конечно, это не так , но это решает менеджер.

Ответы (5)

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

  • Часы работы; настоящее или будущее
  • Потерянная или полученная производительность; настоящее или будущее
  • Созданные/исправленные ошибки
  • и т.д.

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

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

Возьмем ваш пример, когда менеджер хочет меньше строк кода и более простой дизайн БД в пользу жесткого кодирования. Да, жесткое кодирование — теоретически плохая идея, но если вероятность того, что оно когда-либо изменится, близка к нулю, и они достаточно хорошо знают бизнес, чтобы сделать такую ​​оценку, то это может быть правильным подходом. Преимущество их решения заключается в том, что нужно писать меньше кода, меньше кода поддерживать, меньше вещей тестировать и меньше вещей, которые могут пойти не так. Это абсолютно правильное решение в некоторых контекстах.

Итак, мое предложение вам на будущее:

  1. Проанализируйте свои дизайнерские идеи в контексте ценности для бизнеса. Вы можете обнаружить, что ваша первоначальная интуиция неверна для данной ситуации.
  2. Если нет, представьте свои идеи, подкрепив их ценностью для бизнеса.
  3. Если и когда ваши идеи отвергнуты, поймите причины отказа. Помните об этих причинах в следующий раз, когда будете выполнять шаг 1.
  4. Наконец, не думайте об идеях как о «моей идее» или «его/ее идее». Это приводит ко всевозможным проблемам с эго. Думайте о них как о «подходе А» или «подходе Б» и попытайтесь понять, почему компания, в которой вы работаете, продолжает идти по другому пути, чем вы ожидаете.
Если я принимаю ваш ответ таким, какой он есть, то никому не нужно изучать/понимать шаблоны проектирования, не нужно тратить время на разработку решения. Просто позвольте менеджеру принять решение и уйти оттуда, потому что он «хорошо знает бизнес». я полностью не согласен
@Asdfg, тогда вы неправильно поняли мой ответ. Вы должны использовать шаблоны проектирования, когда это уместно. Когда уместно? Когда это добавляет ценность для бизнеса (что происходит в большинстве случаев). Поэтому, если программирование с использованием шаблонов проектирования делает ваш код более удобным для сопровождения и более легким для отладки, вам следует использовать именно эти аргументы. Однако, если ваши шаблоны проектирования — это просто интеллектуальная мастурбация, которая без необходимости усложняет кодовую базу, то это снижает ценность для бизнеса. В любом случае, в конце концов, все, что имеет значение, — это ценность для бизнеса. Стиль кодирования — это средство для достижения цели, а не самоцель.
Хотя это хороший ответ общего назначения, в среде разработки программного обеспечения на самом деле считается плохой практикой жестко связывать такие вещи, как имена категорий, с вашим исходным кодом. Эти вещи должны исходить либо из таблицы базы данных, либо из файла конфигурации. Вы также можете получить критику от парней из ISO 9000, если они когда-нибудь решат проверить вашу работу.
Однажды я потратил много времени, споря, почему мы не должны тратить целую вечность на создание действительно абстрактной модели, которая могла бы поддерживать любое облачное хранилище для файлов, когда мы знали, какое из них мы собираемся использовать, и очень маловероятно, что оно изменится. Когда он изменится, самое время потратить время на его абстрагирование и использование лучших шаблонов проектирования. Некоторые шаблоны проектирования определенно являются пустой тратой времени в некоторых ситуациях.

Я не знаю, какое соотношение вы ожидаете или количество предложений, которые вы делаете, но вы не упоминаете 10%, которые они принимают. Может быть, у них есть что-то общее, чего нет у отвергнутых?

Вы должны понимать, что просите внести изменения в то, как все делается.

  1. Чем дальше от нормы ваши предложения, тем меньше вероятность того, что они будут приняты. Начните фокусироваться на небольших изменениях.
  2. Имейте доказательства проблем, вызванных предыдущей практикой. Пример того, как кто-то должен вернуться и изменить один и тот же код/данные в нескольких местах и ​​пропустить некоторые из них, является хорошим аргументом. Возможно, это вызвало ошибку в программе и вызвало много звонков в службу поддержки или вызвало проблемы у менеджера.
  3. Убедитесь, что вы признаете решения других людей. Вы не хотите быть человеком, который не согласен со всем, поэтому никто не принимает вашу сторону. Плохая репутация и впечатление могут быть сформированы лишь в нескольких случаях.
  4. Это не соревнование, чьи идеи используются чаще всего, так что перестаньте вести счет.

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

Мои предложения отклоняются примерно в 95% случаев. Это нормально, и я совершенно счастлив ошибаться. Я делаю предложения, которые я почти уверен, что глупы в отношении сложных вопросов, потому что довольно часто это приводит обсуждение к более ясному результату.

Вы здесь не потому, что вы правы в 100% случаев — вы здесь для того, чтобы внести свой вклад в процесс. Не расстраивайтесь из-за того, что люди отвергают ваши идеи.

Когда мои идеи отвергаются, я спрашиваю об одном: почему? Если они не могут объяснить мне, почему их идея лучше моей, у меня с этим проблемы.

Подводя итог: продолжайте предлагать идеи, пока вас не попросят остановиться.

Один из лучших способов учиться — высказать свое мнение и получить обратную связь.

Здесь есть две вещи, на которые следует обратить внимание.

  1. «Должны ли» быть приняты ваши предложения
  2. Работа с повторением этого сценария

2 гораздо важнее 1

Вкратце: сделайте шаг назад, проявите стратегический подход, разорвите цикл вводом информации от B

Почему это продолжается?

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

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

Вам нужно поговорить с боссом Б об этой повторяющейся сцене. Попросите о встрече с ним/ней, пригласите их на обед, что угодно. Вам нужно быть спокойным и восприимчивым, а не агрессивным и обороняющимся; ваша цель — начать работать с Б до точки, когда 50% ваших предложений будут приняты. Этот разговор — единственный способ узнать, есть ли предубеждения против ваших предложений (например, потому что вы моложе или старше и т. д.) — вам могут не сказать об этом прямо, но вы сможете проанализировать ответы на ваши предложения. вопросы, чтобы увидеть, есть ли простая причина или нет.

Мои предложения должны быть приняты?

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

Скорее всего какая-то комбинация. Если, как и я, вы были младшим членом команды, но лучше видели решения технических проблем, то вы, вероятно, немного дискредитируете себя за то, что являетесь младшим, но также чаще, чем вы думаете, не попадаете в цель. Другие соображения, которые вы, возможно, не принимаете во внимание, — это принцип YAGNI («Я тебе это не понадобится»), который противостоит бесконечным шаблонам, чрезмерному усложнению вещей путем добавления слоев абстракции, которые не окупятся, или иногда предполагая, что ограничения, которые вам даны, более важны, чем время, которое вы тратите на решение проблемы (заманчиво попытаться выглядеть блестяще, соблюдая все ограничения, но позволяя значительно увеличить сложность решения).

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

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

Измените свой подход

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

Подходить к команде нужно стратегически. Помните главное правило трудоустройства: вы здесь для того, чтобы ваши начальники выглядели хорошо . Это не обязательно должно быть вашей личной целью, но знайте, что это решающий фактор в их мнении о вас. Так что ведите подробные заметки о своих идеях, чтобы потом (на личной встрече с начальником Б) подчеркнуть, насколько ваше предложение было бы уместным. Поддерживайте хорошие отношения с боссом B и встречайтесь с B, чтобы работать над улучшением коэффициента успеха; Лучшее понимание того, почему ваши идеи отвергаются, поможет вам сосредоточиться на правильных вещах и не предлагать то, что не будет принято.

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

Поговорите один на один с менеджером и спросите его напрямую.

Есть личные проблемы?

Следует ли вам изменить тип внушений, которые вы даете?

Как мне быть в ситуации, когда 90% моих предложений игнорируются или отвергаются?
СпросиСетьПолитика конфиденциальности1y, 0v