Когда противостоять хорошему руководителю проекта или боссу

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

Когда и как (если вообще) мы должны выражать разницу во мнениях?

Предположим, вы думаете, что ваш начальник неправ. У вас есть три варианта

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

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

Относитесь к нему точно так же - мягко и уважительно, когда высказываетесь против

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

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

Разве это не пример старой или агрессивной или пассивной ошибки?

Классический третий вариант - настойчивость, которая допускает конструктивную критику и вежливые разногласия.

Не менее важно - принимать конструктивную критику (не обязательно соглашаясь с ней) и принимать разумные разногласия (не зацикливаться на состязании «кто прав, а кто неправ»).

http://en.wikipedia.org/wiki/Assertiveness

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

Кстати, «Навыки людей» Роберта Болтона - хорошая (и довольно дешевая) книга для таких вещей, как умение слушать, уверенность в себе и многое другое.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

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

"Как ваш метод / способ / архитектура решают проблему х?" Если этого не произойдет, скажите что-то вроде: «Ну, как насчет того, чтобы решить проблему х?»

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

Хотелось бы привести более конкретный пример, но я думаю, что вы сможете понять эту идею.

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

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

Надеюсь, это поможет.

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

Это не конфронтация. Это не враждебно. Это не воинственный или злой. Это обсуждение различных подходов, затрат и выгод.

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

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

Нет ничего плохого в том, чтобы сомневаться в каких-либо решениях или конкретной архитектуре дизайна / программного обеспечения. Если только вы не начали свою первую работу, в этом случае вы будете ошибаться в 99% случаев, потому что вам не хватает некоторых частей общей картины .

Когда вы (и / или команда) расходятся во мнениях, спросите руководителя проекта, есть ли у него время для его обсуждения, или, возможно, даже запланируйте небольшую встречу (15-30 минут). Высказывайте свое мнение с уважением и слушайте, почему он принял решение иначе. Если я увижу, как вы его описали, он будет рад обсудить и поделиться своими взглядами на проблему. Он не скажет «потому что я так сказал» (такие люди существуют, к сожалению). В этом случае просто проигнорируйте свое собственное мнение, если вы хотите сохранить свою работу, или откажитесь от нее и уйдите на другую работу, потому что вы станете несчастными.

Хорошая дискуссия может закончиться несколькими способами:

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

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

Просто поднимите это!

Наиболее цивилизованно и четко, я могу сказать: «Я обеспокоен этим аспектом, что вы думаете об этой потенциальной проблеме?»

Я положу мяч на его корте, чтобы обучить меня.

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

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

Вы должны быть осторожны с одной вещью: убедитесь, что в большинстве случаев у вас есть реальные технические, обоснованные причины сомневаться в предложенном проекте. «Чувствуется, что это неправильно», как правило, недостаточно, и это не способствует конструктивному обсуждению. Если это случается слишком часто, у вашего босса не будет другого выбора, кроме как замкнуть «дискуссию» (которая является фактом, поэтому не совсем дискуссией) и сказать «извините, ребята, но вы будете делать то, что я предложил, пока не сможете продемонстрируйте фактами, почему какая-то другая идея явно лучше ".

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

На мой взгляд и как я вообще веду себя со своим боссом

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

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

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

Удачи.

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

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

Раз поговорить с ним он может только:

а) Согласен с вами: проблема решена!

б) Отвергните их и объясните, почему: возможно, в конце концов, именно вы ошибаетесь.

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

У меня вопрос: когда и как (нужно ли?) Выражать различия во мнениях.

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

Настоящий ключ здесь - когда и как.

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

2-я «Как»: если вы идете к старшему человеку, убедитесь, что все ваши утки подряд поддерживают ваши мысли. Вы не можете просто зайти в офис высокопоставленных лиц, говоря: «Все веб-формы должны быть остановлены, и мы должны сделать MVC!». Когда спросили "Почему?" и вы говорите: «Ну, это то, что все делают, и это во всех журналах», это не будет далеко идти. Будьте готовы к обсуждению вопросов и ответов, а также к тому, чтобы вас спросили об обосновании ваших мыслей об архитектуре, кодировании, дизайне, передовых практиках и т. Д. Если у вас есть примеры работающего кода для обоснования (то есть небольшой тестовый набор, чтобы доказать мысль), это может помочь также. Здесь важно не вступать в битву эго и не позволять эмоциям расти.

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

Удачи!

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

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

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

1. Один подход / дизайн может быть просто правильным или неправильным, как в математике 2 + 2 = 4, а не пять. В случае, если это не так, вам нужно как можно скорее найти правильное решение, основанное на фактических возражениях.
2. Безусловно, большинство тем в проектировании систем - это возможные подходы, которые не являются исключительными. Также работают и другие альтернативы, выбор которых зависит от опыта, вкуса, предвзятости, общей картины и т. Д. Чтобы не упустить возможный лучший подход, обычно проводятся презентации и обсуждения, когда разработчикам предлагается высказаться и поделиться своим мнением. Но также имейте в виду, что существуют периоды для обсуждений и периоды для реализации, в гибком программировании эти этапы четко определены.