我是经理 如何改善工作关系和与程序员的沟通？[关闭]

首先有一点背景。我是中型公司的项目经理。我刚从CS专业开始，对编程有点儿接触，但是几个月后，我知道这不是我的路，所以我转向管理。事实证明，这是个不错的决定，毕业后，我在多家公司从事软件管理工作（至今已有5年）。

最近，我们有一个非常痛苦的项目。这是最坏的情况，最糟糕的是，在我们这方面和在客户方面都存在很多错误，并且几乎没有损失就结束了。这导致了许多令人沮丧的情况，其中一种情况升级到了我们的一位高级开发人员在与我们（管理层）进行口头辩论之后离开公司的地步。这对我来说是个危险的信号：我做错了什么。（根据记录，争论是关于几个错误的时间估计）

我在许多地方搜索了答案，一个朋友向我指出了该站点。这里有很多关于管理挫折的问题。我可以理解，普遍的不良经历导致人们普遍不愿“穿着西装的家伙”。

我就是穿西装的那个人。它可能看起来并不像，但是我想要的只是一个成功的项目，而由于资源有限，它需要做出艰难的决定。那是我的工作。前述高级开发人员抱怨的事情之一是工作设备。坦白说，我不知道我们的计算机不适合工作。之后，我问了很多程序员，并且普遍的共识是我们需要更好的机器。从那时起我就解决了这个问题，但是我和程序员之间显然存在巨大的沟通差距。一些最杰出的开发人员是最害羞，最沉默的人。我知道，在面试过程中从来没有问题。人是不同的，并且在不同领域具有优势。

动力不足的PC只是众多使我认为存在通信问题的案例之一。如何在不令人畏惧和重复的情况下改善与程序员的沟通？

我希望人们不要抱怨美好的事物。如果您喜欢您的工作场所并喜欢（或至少喜欢：））您的经理，请告诉我有关他们的信息。他们在做什么对吗？同样，如果您讨厌它，请详细说明原因。我正在寻找有关改善沟通的答案，因为我认为这是我的问题，但我可能错了。

哇！感谢您的询问。从技术上讲，我想像您一样，我是管理人员，因为我花在交流和领导团队上的时间比编写代码要多得多。无论我是开发人员还是为另一位经理工作的经理，以下内容都有助于与管理层沟通：

• 为什么？ 这是一个非常重要的问题-几乎所有的事实答案都带有“为什么”的含义，并且“为什么”可能比实际问题更重要。有一些切线：
  • 开发人员为什么 -开发人员将有很多答案，这对管理人员来说绝对没有意义。我确实做到了，而进入管理层的方法之一就是非常善于向团队解释管理层可以理解的“为什么”。如果您手头没有“怪胎演说家”，则可以通过在更常见的隐喻中重申他们对“为什么”问题的答案来学习说怪胎。坚持下去，直到你们都了解并同意发生的事情。
  • 管理层为什么-您的“为什么”同样重要。为什么需要时间估算？您正在用它们做什么？如果公司太高或太低，我们作为一家公司会如何陷入困境？作为经理，您可能会对这些东西有敏锐的洞察力，但这对开发人员来说都是巫毒。诀窍是，开发人员可能不会问。管理层要求他提供一些东西，他将尽其所能做到准确，及时和周到-但是，如果他不知道“为什么”，他可能会以您不希望的方式进行优化。提供您的原因，并要求他做同样的事情-用他自己的话重述答案。

特别是关于时间的估计-我不得不做很多事情，而且我对开发团队说：“我需要这个是因为我要索要更多的钱来支付我们的薪水，我绝对会从中获利，我会相信你告诉我的，并且我将使用您的电话号码...这意味着，如果您对我低估，我们都会被搞砸，因为我将无法第二次要求钱-我们必须遵守我们的建议。” 在这种情况下，开发人员从试图向我展示他们有多自信和精明的低估变为了更接近真实期望设置的高估。

• 没有人是错的 -“为什么”问题与推论有关很长时间-问“为什么”而不是说“那太离谱了！没办法！” 保持对话畅通。有时，有人问什么和询问者问什么之间存在严重的脱节。我最好的管理人员对我的回答感到非常惊讶，当惊讶时，他们惊讶地眨了眨眼，然后问“你为什么这么说？”。他们没有立即说-“您需要更改”。为了达到竞争目标，我减少了提案的数量，但是只是在激烈地讨论了如何改变场景并为问题创建不同的上下文之后。

• 聆听周围的噪音，单词选择和单词之间的间距 -这是我喜欢并被偷来使用的一堆东西：

  • 在工作区中闲逛，做一些自己有意义的事情（不要尝试从事开发人员的工作，他们知道您不是开发人员），然后听一下。团队如何解决问题？他们有什么大问题？您将永远不会听到他们对您或整个管理层的直接评估真正的骨瘦如柴，但您可能会对问题所在的位置有很好的了解。确保您自己做的事富有成效。没有人喜欢监视，但是除非士气低落，以至于在每个人都没有撤离的情况下不能靠近他们，否则邻近的生产力应该是可以容忍的。
  • 寻找单词选择-它们通常与单词本身一样重要。当我使用特别肯定或否定的词时，我的管理层经常问我为什么在他们不熟悉的情况下选择这些词。
  • 寻找停顿，差距和肢体语言。如果您和开发人员之间有一定距离（听起来很像），他们可能不想与您矛盾或对抗。但是说“嘿，你错了”的基本本能通常会在某处显现出来。

• 开放尽可能多的通信媒体 -准备好亲自面对面，在电话上，通过电子邮件，通过IM聊天-可以建立通信流程的所有事物。人们是如此多样化，以至于只有一个窍门是行不通的。我认为，成为多格式沟通者而不是开发人员是经理的工作。

• 使它值得与您交谈如果有人告诉您有关问题以及可能的解决方案，那么他应该并且很可能接受您是经理，因此可能会决定采用其他解决方案，或者根本不采取任何解决方案，因为您没有认为它值得麻烦。但是在第三次发生这种情况之后，尤其是在没有任何解释的情况下发生这种情况时，约有99％的人会停止告诉您任何事情。

这对我来说是很难的，但是在我能做到的时候却表现出色-请注意内向和外向的区别。您很有可能是一个外向的人-这就是为什么您的工作看起来不错而发展职位却不那么出色的原因。在大多数情况下，开发人员都是性格内向的人。“性格内向”并不意味着“无法沟通”，而是意味着他们的方式，过程和速度都大不相同，并且不存在持续沟通的冲动。在时间和安静（但并置）的空间中进行计划，以使内向的想法浮出水面。我很多性格内向的朋友告诉我，他们只是在等我“闭嘴5分钟”，这样他们才能提出想法并做出回应。这里'外向型人应该了解的关于书呆子洞穴中内向型和兰德的五件事-一个特别适合开发者的例子，说明对内向型人有好处。顺便说一下，兰德斯非常棒。他本人是个极客，所以他以开发人员为中心来解决这个问题，如果这不是您的风格，可能会推迟，但他很有趣，并且对团队开发有一些非常好的见识。

我认为我最喜欢的经理最喜欢的第一件事是：

• 他们对项目的投入与我一样坚定（如果没有更多的话）

• 我从不怀疑他们会支持我-我可以肯定地知道，当他们站在下一级别的权威面前时，我（或我的同伴）将永远不会成为替罪羊。如果存在故障，那将永远是一个组故障。

• 当时，我拥有一些重要且适合我的技能的所有权，但我拥有足够的资源来扩展自己的技能并完成工作。

• 他们将我视为个人，也是团队的一部分-他们积极参与了解我的长处和短处，并努力帮助我发挥自己的长处并扩大我的短处。

• 他们意识到我的个人目标，并有兴趣尽可能地融入他们

• 当让我开心不能或不会成为优先事项时，他们是先发制人。听到“我知道您讨厌这种类型的工作，但我需要您去做-这是永远不会发生的事情...”，这确实具有真正的价值。

• 总有一个星期的时间（也许不是在瞬间）来解释大局

• 几乎持续不断的反馈和状态，没有指责，但对个人工作有足够的认可。

• 总有真理。如果某些事情是敏感的并且无法讨论，他们说是空白。如果不确定，他们会给您一定的信心。

首先是简单的部分：您的帖子中有一个技术性的危险信号：我对您提到“错误的估计” 感到不安 -这是一个估计，不能误解，这就是为什么将其称为“估计”。可能会有一点偏差，可能会有很多偏差，这就是为什么将其称为“估计”。如果您将估算作为福音，那将是“您的”开发人员所面临的主要问题之一。

但是，我100％同意您与开发人员沟通的困难。几年前，作为项目管理培训的开发人员，我得到了启示。在建立开放的讨论氛围之后（在这里有管理人员），我看到我的一些开发人员绝对反对管理。一切错误都是开发商在开发人员眼中的错。最重要的是，管理层对当天提出的几乎所有重大问题一无所知。开发人员以为一切都如此明显，以至于管理层不可能错过它，而管理层则以为开发人员会告诉他们他们需要什么。

因此，恕我直言，答案的第一部分必须是让您的开发人员知道您不通心，实际上在技术方面可能完全是愚蠢的。您要依靠，依靠并信任他们及时地找到您。您在那里的目的是使他们的生活更轻松，而不是更艰难。

无论您做什么，都不要问他们您实际上不希望知道答案的问题-指上面的“错误估计” ；-)。那是开发商的k石。

这里有很多好东西，但是我觉得需要说以下。

• 担任5年的PM，并且不知道开发人员需要哪种PC，实在令人难以置信。
• 要让开发人员因为工作条件恶劣而辞职，这是您的第一个真正的危险信号，真是太疯狂了。

我认为您遇到的是信任问题，而不是沟通问题。没有人会告诉我们出了什么问题，因为他们不相信您会用该信息做什么，甚至可能会担心会被他们利用。告诉您所有这些问题的开发人员之所以这样做，是因为这样做没有任何后果，因此他退出了。

就我个人而言，我永远不会聘请一位在他的背景上没有开发经验的项目经理。我认为在您的下一个项目中，您应该将一小部分时间用于开发。团队。每周说8个小时，在团队领导下担任Jr开发人员。

这确实会让您对开发团队的动力敞开怀抱，因为现在，您甚至不属于该团队，而是局外人。开发人员的离职令您震惊，这一事实证明了这一点。团队中的每个人都知道他不高兴。他们中没有一个告诉你：

“如果您不做任何事情，我们将失去最好的人”

那应该是红旗2。

作为经理，我确定您听说过kaizen，这是丰田生产系统的宗旨之一，意味着持续改进。

您承认自己有问题，因此，这是一个很好的开始。

改善有五个主要要素：

• 质量圈：开会讨论有关公司运营各个方面的质量水平的小组。

• 改善士气：员工的士气高涨是实现长期效率和生产力的关键一步，并且kaizen将其设置为与员工士气保持持续联系的基本任务。

• 团队合作：强大的公司是将每一步紧密结合在一起的公司。Kaizen旨在帮助员工和管理层将自己视为团队的成员，而不是竞争对手。

• 个人纪律：如果团队中每个成员都不坚强，团队就不可能成功。每个员工对个人纪律的承诺可确保团队保持强大。

• 改进建议：通过要求团队中每个成员的反馈，管理层可以确保在所有问题变得严重之前就对其进行研究和解决。

（来源）

如果您仔细研究一下这些要素，那么就需要强调团队合作和反馈。

例如，您说您有一个关于时间估计的论点。您负责这些时间估算吗？您是否与团队讨论此事？抱歉，但是我已经看到经理们只是从他们的职位中提取了一个数字。一件重要的事情：永远不要讨价还价，您的团队会给您带来回报。许多管理人员认为，如果他们能在更短的期限内完成工作，他们的团队会更加努力。这是个谎言。九个女人一个月内不能生孩子，记住这一点。

因此，我的第一个建议是：

听：从给团队的一封简单电子邮件开始：“开发团队向管理层反馈有关管理绩效的最佳方法是什么？”。与团队进行迭代并达成共识。您的任务是允许团队开发出色的软件，而不是随心所欲。请记住这一点。

诚实和忠诚：如果在您提出问题时没有人回答，那是因为他们不相信您会听，或者更糟糕的是，他们相信您会因此而惩罚他们。所以说实话。如果有人说你很烂，请以此为反馈，不要报仇。了解他们的原因，加以改进。

最后，尽管我在这里看到了一些批评，但我还是建议您阅读一本书，名为“神话中的人月：软件工程论文集”。这本书讲述了Fred Brooks在管理OS / 360的开发中的经验。尽管这里和那里可能有些过时了，但这是了解复杂软件的开发过程如何工作的开始。S.Lott引用了《敏捷宣言》，虽然我并不特别喜欢它，但也值得一读。

读这个：

http://agilemanifesto.org/

• 个人与流程和工具之间的互动

• 工作软件胜于完整的文档

• 客户合作而非合同谈判

• 响应计划变更

在许多情况下，组织（即您的老板）要求您

• 遵循一个明显破碎的过程，得出导致“死亡行军”的逻辑结论。这反过来导致争论和辞职。

• 创建过多的，低价值的，未使用的文档。

• 进行复杂的变更控制a / k / a合同谈判。每个用户更改都需要精心设计的“质量”和“优先化”更改的仪式。确实，这都是关于“冻结”的-防止更改。

• 遵守计划，无论后果如何。一些组织重视及时交付已损坏（甚至无用）的软件。有价值的是计划，而不是业务问题的解决方案。

可能这不是您的个人沟通技巧。

可能整个开发“环境”或“方法论”都被致命地破坏了，而不良感受只是一般不良行为的征兆。

对我来说，这听起来像您从未在轻松的气氛中与开发人员交谈过。您与他们的对话仅仅是官方性质的？这太糟糕了。

您为什么不亲自了解他们，从而了解公司，他们的工作场所和项目的利弊？通过对他们的工作表示真诚的兴趣和赞赏，尊重他们并赢得他们的尊重。

如果他们信任您并且不必担心会被当当，他们很可能甚至会告诉您毫无吸引力的事实。

我是团队负责人，我的团队信任我。我保护他们。我要全力以赴，并与他们分享名声。我们的管理层保护着我。这提高了士气。我们有一个非常艰苦的项目，一个几乎是邪恶的客户，几乎不可能完成，但最终还是做到了，因为我们以坦率和开放的方式谈论所有事情。

拍！拍！拍！您当然应该是一个好人，因为您公开露面，看看可以做些什么来使自己的工作更好。

请在下面找到我在一位伟大的经理中目睹的一切，并在我带领团队担任高级成员时亲自采用。

• 中号 entor比管理更多。
• 一个 llow团队成员表达他们的想法和顾虑。全力以赴。以建设性的。
• ñ有史以来玩分裂政治背叛的团队成员。事与愿违，事半功倍。
• 一个手指不能。当您与团队一起时，切勿脸上露出鬼脸，请随便吧。这真的很难。
• 摹 enuinely和坦然欣赏他/她的好工作的赢家。同样，对于负责任的人，要孤立地，不公开地非常轻柔地从战术上批评不是人为有错的工作。
• Ë ncourage所有权和领导权的每一个人。这会提高人的士气和承诺，因为他会感到被尊重。
• [R与您的团队在一段时间OAM左右一次。这引起/增加了团队成员之间的联系。

祝你好运，真诚的努力:)

总的来说，那些能够并会解决这种情况的人感觉不到自己的抓地力时，战es里的家伙就开始发mu。如果他们甚至不觉得自己可以在不冒自己在公司地位的情况下受苦，那就更糟了。

我是一个理论型的家伙，大多数“知识工作者”倾向于 如果有机会，我们喜欢我们的工作，并希望做得好。但是，Theory-Y工作场所的不利之处在于可能不会立即发现问题，因为想要做得好却不想大张旗鼓的人们会找到解决该问题的方法，或者干脆忽略它。这导致了被压抑的挫败感，最终使整个团队的脸都炸了起来。由Theory-X经理经营的商店可能会早些抱怨。员工只为赚钱而奋斗，因此，如果工作比平时糟，他们就会抓狂。

至于您能做什么，在年长者和负责人的环境中，他们是您的最佳资产。跟他们说话。您可能会安排每周30分钟的“双向”计划，其中的潜在客户会为您提供有关项目日常情况的更新和关注，并向他们提供业务方面的更新并与他们一起计划以解决关注的问题在它们成为严重影响团队的问题之前。

在敏捷中，每个“冲刺”或“迭代”（这是一个开发工作单元，通常持续一到三周）的结尾，从最初级的成员到PM，整个团队都有一个“回顾性的” ”。他们回顾所做的事情，正确的事情，不正确的事情，并确定要继续做的事情和要改变的事情。格式有多种，您可以发明自己的格式，但是复古的结果应该是人们感觉到自己的声音被听到了，结果一切都会改变。

谈论敏捷；我的第一份工作是在一家小公司工作，而“小”是指整个公司无法派遣垒球队。我刚开始时有四个程序员，而在我离开之前，这个数字已经减少到两个。该公司的创始人，总裁，首席执行官和95％的利益相关者用拳头统治了它，而他是组织中唯一的计划制定者，这意味着没有多少。老板是个工作狂，他希望其他所有人也一样。您必须付出的一切都不会超过他的期望，为此，他向为他工作了十年的人支付了入门级的薪水。

我离开了那家公司，开始为另一家做事非常不同的公司工作。他们练习了SCRUM Agile的基本方法，包括每日站立，配对编程，冲刺团队和回顾。在每次冲刺开始时，每两周有一天，除了计划接下来的两周的工作之外，我们什么也没做。在另一天的大部分时间里，我们什么也没做，只是回顾了自己所做的事情，并找到了改善团队的方法。我旁边有一些开发人员，他们是Microsoft MVP，可以完成工作，并鼓励和补充我的工作。

晚。和。天。主要区别？首先，我不希望自己为这个项目而自杀。敏捷的基本宗旨是可持续发展。其次，我在决定如何进行工作方面有发言权。我必须做这项工作，但是如果我对下一次冲刺将要发生的事情感到“烧心”，我可以发表自己的意见，并且可以听到并给予重视。如果我觉得有更好的方法，我可以这么说，这会很有趣。

至于寻找解决方案和解决问题，您必须注意不要看起来像是从上到下地工作。对于计算机；说您的RMR（经常性每月收入）仅允许公司每两周升级四台计算机。前四台计算机不应该全部交给领导和上级。他们应该去电脑速度最慢的人。如果您向团队提供奖金，请不要仅仅将其赠送给“我们宝贵的前辈和领导，没有他们，这是不可能的”；开发团队中的每个人都实现了它。如果大三学生有什么抱怨，请听他说。仅仅因为他是一个大三生并不意味着他什么都不知道。

改善关系：
刚刚有一个艰苦的项目吗？然后让他们休息一下。休假时间放松身心，喘口气。
编码员的权利清单这些都是给定的。基本的东西应该不用多说。如果违反这些规定，则表示您正在滥用代码猴子。
乔尔测验我同意其中大多数。但是有些确实取决于。如果您缺少某些功能，那么可能会使您的程序员的生活变得更加艰难，而这实际上是必须的。
技术债务。因此，您可以争取完成，但是您必须意识到，偷工减料会招致技术债务，这将需要花费更多时间来解决。如果该日期在项目结束之前到来，那么您真的搞砸了。
RSA动画：动机这是一个奇妙的地方，确实显示了如何激励知识工作者。
有空的日子可以编码他们想要的东西。从RSA视频。不记得这个名字了，但是提到的公司在他们的网站上对此做了简短的解释。对我来说似乎是个好主意。在大多数商店中，有些事情是众所周知的，但是没有人有时间修复，这不是很重要的事情。这使他们能够解决技术债务。这也让他们炫耀自己的绝妙想法。

为了爱上帝，请尝试每周工作40小时。还有，flextime。Flextime可以弥补整个废话。至少对我来说。

改善程序员与老板之间的沟通
对我而言，这更难。整件事都更像是老板的技能，而不是程序员的重点。我可以说一些基本的东西，例如时间估算仅仅是估算。如果将它们冷冻，在水上行走和满足要求很容易。也许要求害羞的程序员在代码审查之类的事情上介绍他们的项目。实践使完美，是吗？但是我要向其他人的建议鞠躬。

“同样，如果您讨厌它，请详细说明原因。”
嗯，这将打开这里的闸门。如果我没有使用显然可以链接到我的openID，我可能也会发泄。如果您确实想要列出不该做的事情的庞大清单，请在更适合匿名张贴的论坛上提问。

我一直发现，总的来说，人们对您的待遇不会比您对他们的待遇更好（尽管他们对您的待遇可能会更差）。我个人（我是开发人员）以诚实回应诚实，尊重他人，信任信任等等。您应该在中立的气氛中与您的团队进行非正式的交谈，并告诉他们您刚刚告诉我们的内容。在有毒的“我们对他们”环境中被遗忘的一点是，它们都应该是“我们”。管理层和工人都需要知道这一点，而企业必须对此予以支持。

祝好运。

现在，您不仅拥有接受反馈，而且根据反馈采取行动的可靠记录。您已经证明自己在高层决策者中具有影响力，并且可以为团队完成工作。那有很大的不同。程序员会比较内向，但是我们喜欢谈论编程。非正式的环境很好，但是每个人仍然需要专业。让人们发泄一些声音，但要确保讨论富有成效，而不仅仅是just之以鼻。

根据我的经验，对我来说，喜欢或不喜欢我的经理的最重要因素是他/她是否了解总体发展并了解我正在做的工作。这里列出了一些积极的结果：

• 我不必浪费太多时间来说明为什么更改需要这么长时间或无法实施。从技术上讲，任何变更都可以实施，而高层管理人员通常要求以任何方式实施。但是，至少在这种情况下，您的直接经理会站在您身边，要求更多时间（而不是将您逼入或使您精疲力尽）。
• 我知道在遇到恶劣情况（WTF hack，生产问题等）的情况下，我有更好的机会得到支持。通常，非技术人员往往将这种情况归咎于开发人员，而好的经理则了解实际情况并支持他/她的开发人员（不仅仅是知道或愿意以这种方式成为好人）。
• 我知道我的工作和表现将由适当的人进行评估。

我认为，如果您不再进行编程，并且通常在紧张的项目进度或预算内，那么开发人员喜欢的机会就很少。在这种情况下，您最好迅速升职，并请其他人担任直接经理。抱歉，我在本段中听起来不太好，但这就是我的看法。你似乎是一个好人，应该得到一些真理。

我也是穿西装的人之一，已经服役超过15年了。我刚开始时是一名软件开发人员，有机会时我仍然在编写代码。所以我想我可以为双方交谈，并且在这些情况下我有一些经验。我还拥有由员工选举产生的证书，例如“年度员工”，这使我对处理这些情况充满信心。

我经常看到的是，管理层和开发人员之间在价值体系和操作方法/方法上存在实质性差异。

对于许多开发人员而言，诚意，诚实和其他灵活的工作环境非常重要。不幸的是，在高层管理人员列表中，相同的值并不是很高。这不可避免地导致了巨大的冲突，特别是如果中层管理人员（您和我）决定完全担任高层管理人员。从我的角度来看，唯一的出路是在团队中站稳脚跟，一路支持他们，并通过公开交流，最重要的是，按照自己的话说，建立信任关系。 （这通常与您从最高管理层那里获得的收益相反，在最高管理层中，政治完全压倒了诚意）。

同时，您自己需要保持运转，因此您必须找到一种以他们理解和玩游戏的语言与高层管理人员进行交流的方法。这是中层管理人员的真正挑战。

我相信，随着开发人员的幸福，生产力都可以归结为小事。数学对管理来说非常棒。早上给我一个甜甜圈（-25美分），我整天要加倍努力（+美元）。这并不是说我们不满意时会通过缓慢的工作来积极地节俭，而是我们正在极其复杂的系统上工作，而对某些事情感到沮丧则很难集中精力。生气时，我们不编写太多代码可能真的更好。

但是，估算必须自己解决。除了不切实际的估计，我可以给我一个甜甜圈来解决我遇到的每个问题。对开发人员的看法是对还是错：开发人员可以通过更短的估算来获得一切收益（就像一条新船），而开发者则可以失去一切（像一个月的睡眠）。尽管管理是负责的，所以他们每次都赢得预估战。我认为估算系统在开发人员确定截止日期时效果最好（我们很难给出准确的估算，经理人怎么会这样？），但是管理层会积极地激励他们变得雄心勃勃，但要理解到没有开发人员会为此而烦恼有点不对劲。

考虑一下您对程序员可能会有疑问，意见或关注的反应。是否有一个“您现在想要什么？” 或“你为什么要为此烦我？” 怎样的回应？您在鼓励开发人员表达关注和评论方面做得如何？但是，这仅仅是一个起点。

其次，请注意您在哪里进行这些讨论。我怀疑如果我知道我的经理在听完整个事情的范围之内，我会很乐意与下一个立方体的人讨论我的工作机器。如果您希望人们给出公开而诚实的反馈，则必须有一定的隐私权，让他们知道他们的答案不会被公开广播或对他们不利。

第三，考虑一下您拥有什么样的情商技能。 项目经理的情商：安东尼·梅尔西诺（Anthony Mersino）所需要的人际交往技巧，这是我昨天从《午餐》和《情商》中获得的书本推荐。如果您真的想深入了解心理学，这里可以使用各种性格特征工具，例如，九型人格，社交风格和MBTI。

最后，考虑一下您公司的文化是什么。地毯下面是否藏有错误？抱怨是否真的很容易使某人陷入困境？哪些行为会得到奖励或鼓励，哪些行为是可以容忍和接受的？尽管其中一些是观察性的，但其中一些可能还需要进行一些对话，这些对话应该在办公室之外或在不太可能被窃听的房间中进行。您可能一开始会重复使用它。如果您尝试建立一种新的实践并让人们参与其中，如果这种文化主要是每个人都知道要“吸纳”这种文化的话，那不是一件坏事。这可能比其他答案更敏感-但这就是我的意思

开发人员是否觉得您是他们的拥护者？我的意思是说，他们知道他们可以随时与您分享他们的担忧/挫败感而不会受到殴打？他们觉得您为他们而战吗？他们觉得您欣赏他们的工作吗？他们是否觉得您真的希望他们在事业上取得成功？

如果他们感到赞赏，您可能会获得更好的沟通。

作为一名开发人员，我是一个主要的书呆子，缺乏社交技能，对此我并不表示歉意。毕竟，我是才华横溢的人，而您是因为我的才华而雇用我的。如果您需要社交蝶舞来完成工作，那么您将拥有一个充满项目经理而非开发人员的房间。

我知道有些开发人员在社交方面非常精明，但是我认为其中位数倾向于内向的书呆子。

当有人要求我做某事时，我绝对不会做出任何推论，而是完全按照要求做。在某些项目经理看来，我总是会遇到问题，因为他们希望我对他们的项目做出推断，而我绝对不会这样做，因此有时事情并没有像他们期望的那样发生，即使结果确实如此他们已要求。我认为某些项目经理会发生这种情况的原因是，他们没有提供高质量的HLD，BRD，并且在项目管理的社会方面而不是在黑白方面过分重视。

我认为这是世界碰撞的地方。我认为在项目管理的世界中，社交技巧和个人坦率的素质是重要因素，但对像我这样的开发人员而言，这绝对没有任何意义。我对这件事或那个任务的重要性并不满意。我什至不想出去吃午餐或像这里有些人建议的那样喝啤酒。

我真正想要的是优质，高质量的HLD和BRD。我希望可以实现时间表和期限，并且如果引入了新的设计或计划，我希望可以重新调整时间表和期限。我从事的项目似乎在不断变化着需求-对我来说，这是我要处理质量欠佳的项目领导的危险信号。作为开发人员，最糟糕的事情是每天带给我新的项目需求，尤其是在我们已经有了进度表或做出进度承诺之后。当提出新要求而又不按时完成补偿时，这是无法忍受的。工作更多的时间，工作到很晚，我对此没有任何问题，但这并不是开发中总是定量的。进行某些更改可能需要几个小时，为了进行适当的研发，测试，质量检查等，某些更改可能需要数周的时间。这并不总是像烤蛋糕一样，有时对需求的单项更改可能就像更改整个配方一样。我目睹了项目经理崩溃并且在电话会议上大发脾气，因为他们的截止日期不允许额外的开发，但是他们要求的开发不在他们最初的项目要求之内。

我只能给出自己的个人偏见和经验作为示例，所以请不要推断我是代表所有开发人员发言。我只是从自己职业的缩影中看到这些东西，但这篇文章描述了导致我丢下这条毛巾的确切条件。

您多久与开发人员交谈一次？我的意思不是项目状态会议，关于可交付成果的问题或带给他们的其他主题-您多久与一位程序员坐下来，询问他们的情况，并只是倾听。

许多其他答案确实很好-您应该研究敏捷开发。您需要开发人员学习和发展自己的角色。但是，如果您实际上没有听开发人员在说什么（或没有在说什么），那么您首先需要注意这一点。

一对一的良好参考-http: //www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

简短而甜美。在您所做的工作中表现出色-这将促进沟通。

优秀对您的开发人员意味着什么？..阅读，重新阅读，甚至可以学习PeopleWare

以上帖子中的所有很棒的主意和评论！

这是一个主意：将您的IT员工派到您当地社区大学的交流研讨会上，当然，这是由公司支付的。

确保a）车间享有良好的声誉，b）不要将您的员工派遣到一起。他们将倾向于团结在一起，而不是与其他班级成员打成一片，这不仅降低了研讨会的价值，而且对其他团队造成了干扰。

面向团队的高效沟通是任何人都可以学习的技能，但我认为这是大多数学术途径所缺乏的主题。

这个想法绝非万能药，但它是解决难题的一个很好的基础。您的同事不仅将学会彼此之间更好地沟通，而且好处是，他们也将开始更好地理解和尊重您的工作（沟通是PM的核心）。

只是我的2位:)

只是为了从已经提出了几个 答案的建议中做出答案。Michael Lopp（又名rands）一直在他的博客Rands in Repose和一本书《Managing Humans》（书籍资源）中写过关于开发人员的管理和“ 深入人心 ”的文章。这本书包含了他在2007年之前发布的帖子中大部分经过编辑的内容，并提供了一种很好的方式来赶上他博客中与管理相关的部分（他还谈论例如赌博，以及是否要阅读那是另一回事）。他的写作通常很好，而且常常幽默，因此阅读他的风险很小。

带队去喝啤酒（您正在购买）。

我参加聚会迟到了，但是刚刚看到了这个问题。

我看不到很好解决的一件事是：

咕unt声永远不会告诉诉讼的全部真相。兰德斯（Rands）在DNA中说过这一点，但没有直面解决，他的话题不同。

您穿着西装，在支票上签字。您代表公司的利益。您不代表工程师。如果您这样做了，那您就不会在他们的支票上签字，他们会在您的支票上签字。

对于您或工程师而言，这当然不是新闻。但是，当工程师知道会带来某些问题-问题-他的工作场所会引起重大冲突时-风险/报酬的折衷不利于工程师。工程师得到报酬来生产产品，而不是开始工作场所文化斗争。参与其中是快速完成工作的捷径。

因此，管理任务的一部分是为工程师提供一种解决问题的方法，而又不会引起公司政治和职业反弹。这是不错的加薪，毕竟，还有是其他公司，如果一个人不感到相投。

令我惊讶的是，没有人提到这本出色的书，它正好处理了您的问题和主题-DeMarco和Lister撰写的“ Peopleware：生产性项目和团队”。社论：软件开发的主要问题是人为的，而不是技术上的。如果您遇到这种情况，对亚马逊的前三篇评论就足以说服我购买这本书。

这里的许多答案都有很好的观点，但是我只想提供一些可能有用的资源。我遇到过一些情况，要么由于陷入混乱而陷入困境，要么由于相关人员之间的沟通而非常有效地解决了。三本书帮助我个人提高了沟通技巧，尤其是在压力很大的情况下，很多情况下：

• 艰难的对话：如何讨论最重要的事情
• 至关重要的对话：赌注很高时进行交谈的工具
• 至关重要的对抗：解决诺言，违背期望和不良行为的工具

通过阅读您的问题，我认为您看到了交流的价值。我个人认为，对于经理或领导者而言，沟通比业务或技术技能更为重要。您领导的人员应该具有完成大部分项目所需的硬技能。一个好的技术主管或项目经理应该能够专注于沟通，无论是在团队内部还是在团队与客户之间，还是团队与业务实体之间（甚至是这三者的结合）。

阅读几本伟大的小说，深入了解技术人员的观点：

• 黑客，史蒂文·利维（Steven Levy）-http: //en.wikipedia.org/wiki/Steven_Levy
• 微型农奴，道格拉斯·库普兰-http: //en.wikipedia.org/wiki/Douglas_Coupland
• 大教堂和集市，埃里克·雷蒙德（Eric Raymond）-http: //en.wikipedia.org/wiki/大教堂和集市

这些与任何有关管理的典型回忆录一样重要（Drucker等）。

多年来，我担任过各种角色-开发人员，高级开发人员，技术主管等。

从您的问题出发-很明显，您的开发人员不会告诉您一些事情，因为他们认为您无法提供帮助。

这可能是由于两个原因。

1. 他们认为您没有能力解决问题。但是，我认为这不太可能，因为那时您可能会知道，而且开发人员也会向您抱怨。
2. 当开发人员遇到问题时，您会执行以下一项或多项操作：
   • 当他们遇到问题时，您要告诉他们-我喜欢解决方案，而不是问题。
   • 您会很好地倾听他们的意见，然后指派他们解决问题。您让他们鼓舞性地谈论赋予他们解决问题的责任是多么荣幸。随着时间的流逝，您的家伙会明白，当他们遇到问题时，他们最终会付出额外的工作，因此他们不会遇到问题。
   • 您否认这是一个问题。您为此给出令人信服的理由。但是随着这种情况的不断发生，随着时间的流逝，您的家伙们发现没有问题可以解决您。
   • 您说“是的，我了解”。您说这种事情偶尔发生，而且无能为力。如果这是一种模式，那么你们又可以理解。

如果是以上任何一项或全部，则需要对其进行纠正。

我最讨厌的事情是人们介于我，开发人员和最终用户之间。最好的经理让我做到这一点，并更改我们的解决方案以匹配我认为用户想要或可以做到的事情。

对我而言，最糟糕的做法通常是打扮成“好”-通常经理自己，或者BA或某人编写规格，开发人员必须在事先同意的时间范围内解释和实施。

如果是定制的解决方案，那么即使开发人员通常也不知道需要多长时间，并且客户通常不知道什么是最适合他们的。这就是为什么迭代式开发很棒。虽然不是大多数交易都这样完成，但一个好的经理会像上面那样努力工作。

最后，一些开发人员不擅长交流，也无法与客户建立联系。它们可能最适合于具有明确要求，特别是明确技术要求的问题。也许您需要开发人员，他们是更好的沟通者，并希望致力于解决业务问题，而不是纯粹的技术问题。

让团队保持快乐很容易

尝试听他们很多次，他们的问题也有答案。我会鼓励团队成员提出问题和可能的解决方案。

团队郊游是个好主意（可能是一些比赛计划）

如果您的项目需要一些深夜和周末的工作，并且您认为您实际上并未为团队增加很多价值，那么花点时间吃些东西并感谢团队的努力是一个好主意，如果可能的话安排一些动力输出轴

与每个团队成员每两个月进行一次1：1的交流，以确保他们感到舒适。

最后但并非最不重要的一点是，从功能上和某种程度上从技术上理解项目对于您来说可能是个好主意。

如果您还有其他问题，请告诉我

我也是（法语，请原谅我的英语）软件经理，他本人具有科学工程背景，但最初并不专门具有IT软件背景。因此，一开始我对编码没有特别的兴趣，但是我一直是戴明学校的统计质量工程师，尽管后来他们假装是从戴明继承的，但与随后的每个“现代”学校的教学方式都有很大的不同。最坏的是6 sigma，精益更好，但是不幸的是，这是怎么回事http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say：

“最初，六个标准差源自摩托罗拉的丰田质量管理（TQM），以达到六个标准差的质量水平，然后通过Allied Signal和GE，它根据统计数据演变为黑带项目，成为降低成本的计划-每个项目需要明确的投资回报率。换句话说，我们将计划从领导哲学贬斥为一系列一次性项目以削减成本。这是对原始版本的完全混蛋，它很少导致持久的，可持续的变革，因为缺少领导和文化。

“当简化成工具箱时，类似的事情发生了（例如，价值流图，KPI板，单元，看板）。

“精益和六个西格玛绝对不能反映出优秀的日本公司或其像戴明这样的老师的初衷。”

如今，敏捷运动就像是精益运动（请参阅Jeff Sutherland的课程以及他对Deming的荣誉http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum /），它比Waterfall更好，但与Deming的原始教学法相去甚远，因为大师们并没有重新阅读Deming的原始包装，而只是重新包装了他，几乎没有引用他的全部14条管理原则，并出售本身价值不高的工具和研讨会。

现在，在软件领域，问题是一方面有人知道一般性原则，但对如何真正应用这些原则没有真正的想法，另一方面，正在编写软件但却忽略了这些原则的人却因为他们只是在听而已假冒大师在不告诉他们真正原理的情况下向他们出售了工具，实际上他们应该构建自己的管理工具。

因此，对我来说，软件项目经理应该努力更深入地进行软件编码的日常操作，而不仅要在Microsoft Project中进行规划（或使用Agile的分解图）或在Powerpoint中向高层管理人员进行漂亮的演示，而且还应具有一些价值开发人员团队。当开发团队遇到问题时，即使是技术问题，项目经理也可以帮助您确定诊断方向。他可以查看代码，即使他不了解微小的细节，也可以提出一些幼稚的问题，这些问题可能会使开发人员意识到他们没有想到这个线索（我有很多个人示例，但是它太长了，所以我会而不是在我的博客上写文章）。

另一件事是，我试图通过阅读技术文章来对新技术，新架构范式等领域的发展有一个总体认识。我将参加一些集成测试，亲自编写一些文档（有些程序员讨厌这样做，所以我会为他们做，他们当然会为我提供核心知识），而我实际上可以为团队提供帮助。

总的来说，开发人员觉得他们正在努力工作，这是事实，经常，我确实告诉他们我通过保持抽象而在做轻松的事情，尽管如此，我还是在需要时尝试提供具体帮助-因为微管理也不好，因为它会产生干扰感。

结论是：消除与开发人员的口号（实际上这是Deming的14项原则之一），向他们表明您确实关心项目的具体软件，而不是文档或与高层管理人员会面。