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

#1 楼

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



为什么？这是一个非常重要的问题-几乎所有的事实答案都带有“为什么”的含义，并且“为什么”可能比实际问题更重要。有一些切线：


开发人员为什么-开发人员将有很多答案，这些答案对管理绝对是没有意义的。我确实做到了，而进入管理层的方法之一就是非常善于向团队解释管理层可以理解的“为什么”。如果您手头没有“怪胎演说家”，则可以通过在更常见的隐喻中重申他们对“为什么”问题的答案来学习说怪才。坚持下去，直到双方都了解并同意发生的事情。

管理层为什么-您的“为什么”同样重要。为什么需要时间估算？您正在用它们做什么？如果公司太高或太低，我们作为一家公司会如何陷入困境？作为经理，您可能会对这些东西有敏锐的洞察力，但这对开发人员来说完全是巫毒教。诀窍是，开发人员可能不会问。管理层要求他提供一些东西，他将尽力做到准确，及时和周到-但是，如果他不知道“为什么”，他可能会以您不希望的方式进行优化。提供您的原因，并要求他做同样的事情-用自己的话说答案。同样-深入研究业务的原因-开发人员经常在意，但不直接了解业务开发的工作原理-有人自愿提供此信息既有启发性，也有启发性。 />特别是关于时间的估计-我不得不做很多工作，并且告诉我的开发团队“我需要这个，因为我将要更多的钱来支付我们的薪水，我绝对会从中获利，我会相信你告诉我的，我将使用您的电话号码……这意味着，如果您对我低估，我们都会被搞砸，因为我将无法第二次要求钱-我们必须接受我们的建议。”在这种情况下，开发人员从试图向我展示自己有多么自信和聪明的低估转变为更接近真实期望设定的高估。


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

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


开放尽可能多的通信媒介-准备好亲自面对面，通过电话，通过电子邮件，通过IM聊天-建立通信流程的所有事物。人们是如此多样化，以至于只有一个窍门是行不通的。我认为，成为多格式沟通者而不是开发人员是经理的工作。
值得与您交谈如果有人告诉您有关问题和可能的解决方案，他应该并且很可能接受您是经理，因此可能会决定采用其他解决方案，或者根本没有解决方案，因为您认为这样做不值得。但是在第三次发生这种情况之后，尤其是在没有任何解释的情况下发生这种情况时，约有99％的人将停止告诉您任何事情。

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

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


他们对项目的投入和投入一样强烈（甚至更多）
我从未经历过怀疑他们是否支持我-我确定地知道，当他们站在下一级别的权威面前时，我（或我的同伴）将永远不会成为替罪羊。如果发生故障，那总是会导致团队失败。
我当时拥有对我的技能重要且合适的东西的所有权，但是我有足够的资源来扩展自己的技能并完成工作。
他们认为我既是个人又是团队的一部分-他们积极参与了解我的长处和短处，并努力帮助我发挥自己的长处并扩大我的短处。他们意识到我的个人目标，并希望尽可能多地融入他们。
当使我快乐时，他们是先行的。听到“我知道您讨厌这种类型的工作，但我需要您去做，这是永远不会发生的事……”，这确实有其价值。
总是有一周的时间（也许暂时无法解释）
几乎没有任何指责，但反馈不断，状态不断，对个人工作的认可度很高。
总是存在着真理。如果有些事情是敏感的并且无法讨论，他们说是空白。如果不确定，他们会给您一定的信心。

#2 楼

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

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

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

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

#3 楼

这里有很多好东西，但我觉得有必要说以下话。.
..很抱歉，很苛刻..但是这需要说：


5多年的PM，并且不知道开发人员需要哪种PC，简直令人发指。 />我认为您遇到的是信任问题，而不是沟通问题。没有人会告诉我们出了什么问题，因为他们不信任您会使用该信息做什么，甚至可能会担心会被他们利用。告诉您所有这些问题的开发人员之所以这样做，是因为这样做没有任何后果，因此他退出了。我认为在您的下一个项目中，您应该将一小部分时间用于开发。球队。每周说8个小时，在团队领导下担任Jr开发人员。

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


“如果你不做某事，我们将失去最好的人”


应该是红色标记＃2。

#4 楼

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

您承认自己有问题，所以这是一个不错的开始。



质量圈子：开会讨论有关公司运营各个方面的质量水平的小组。
士气提高：员工的士气高涨是实现长期效率和生产力的关键一步，并且改善将其设置为实现以下目标的基本任务保持与员工士气的持续联系。
团队合作：强大的公司是指将每一步都团结在一起的公司。 Kaizen旨在帮助员工和管理层将自己视为团队的成员，而不是竞争对手。
个人纪律：如果团队中的每个成员都不坚强，团队就不可能成功。每个员工对个人纪律的承诺将确保团队保持强大。
改进建议：通过要求团队中每个成员的反馈，管理层可以确保在问题变得严重之前对所有问题进行研究和解决。

（源代码）

如果您对此进行长期研究，则强调团队合作和反馈是不变的。

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

所以，我的第一个建议是：

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

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

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

#5 楼

阅读此内容：

http://agilemanifesto.org/




过程和工具上的个人和交互
工作软件比全面文档
客户通过合同谈判进行协作
响应计划变更




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


遵循了一个明显中断的过程，得出了导致“死亡行军”的逻辑结论。这反过来导致争论和辞职。
创建过多的，低价值的，未使用的文档。
参与复杂的变更控制a / k / a合同谈判。每个用户更改都需要精心设计的“质量”和“优先化”更改的仪式。确实，这一切都是为了“冻结”-防止更改。
按照计划进行，无论后果如何。一些组织重视及时交付已损坏（甚至无用）的软件。重要的是计划，而不是业务问题的解决方案。

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

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

#6 楼

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

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

如果他们信任您并且不必担心被当当，他们很可能甚至会告诉您毫无吸引力的真理。 br />
我是团队负责人，我的团队信任我。我保护他们。我要全力以赴，并与他们分享名声。我们的管理层保护着我。这提高了士气。我们有一个非常艰苦的项目，一个几乎是邪恶的客户，几乎不可能完成，但最终还是做到了，因为我们以坦率和开放的方式谈论一切。

#7 楼

拍！拍！拍！您当然应该是一个好人，因为您公开露面，想知道如何做才能使您的工作变得更好。我带领团队担任高级成员时亲自采用。



管理人员不仅仅是管理人员。

一个低调的团队成员表达他们的想法和疑虑。尽一切可能
。采取建设性态度。

永远不要通过分裂政治来背叛团队成员。这样
反响会更快，更安静。

不会。和您的团队在一起时，切勿脸上露出鬼脸，请随便吧。这真的很困难。

真诚地感谢获奖者的出色工作。在相同的广度下，非常轻柔地从战术上将没有错误的工作批评为负责任的人，孤立地，公开地对负责的人进行批评。


鼓励每个人的主人翁精神和领导才能。这会提高人的士气和奉献精神，因为他会感到受到尊重。

不时与您的团队交流。这个
增加/增加团队成员之间的联系。

祝您好运：)

#8 楼

总的来说，那些能够并会解决这种情况的人感觉不到自己的抓地力时，战es里的家伙就开始发mu。当他们甚至不觉得自己可以在不冒着在公司任职风险的情况下受苦时，情况就更糟了。如果有机会，我们喜欢我们的工作，并希望做得好。但是，Theory-Y工作场所的不利之处在于可能不会立即发现问题，因为想要做得好却不想大张旗鼓的人们会找到解决该问题的方法，或者干脆忽略它。这导致了被压抑的挫败感，最终使整个团队的面孔大为震惊。由Theory-X经理经营的商店可能会早些抱怨。员工只是为了赚钱而已，因此，如果工作比平时糟透了，他们就会抓紧。工作，它们是您最好的资产。与他们交谈。您可能会安排每周30分钟的“双向”计划，其中的潜在客户会为您提供有关项目日常工作的最新信息和最新消息，并向他们提供业务方面的最新消息并与他们一起计划以解决问题在它们成为严重影响团队的问题之前。

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

谈论敏捷；我的第一份工作是在一家小公司工作，而“小”是指整个公司无法派遣垒球队。我刚开始时有四个程序员，而在我离开之前，这个数字已经减少到两个。该公司的创始人，总裁，首席执行官和95％的利益相关者用拳头统治了它，而他是组织中唯一的计划制定者，这意味着没有多少。老板是个工作狂，他希望其他所有人也一样。您必须付出的一切都不会超过他的期望，为此，他向为他工作了十年的人支付了入门级的薪水。为另一家做事非常不同的公司工作；他们练习了SCRUM Agile的基本方法，包括每日站立，结对编程，冲刺团队和回顾。在每次冲刺开始时，每两周有一天，我们除了计划接下来的两周的工作外，什么也没有做。在另一天的大部分时间里，我们什么也没做，只是回顾了自己所做的事情，并找到了改进团队的方法。微软MVP是我旁边的开发人员，可以完成工作，并鼓励和补充我的工作。

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

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

#9 楼

改善关系：
刚刚有一个艰苦的项目？之后让他们休息一下。休假时间放松一下，喘口气。编码员的人权法案这些都是必须的。基本的东西应该不用多说。如果您违反了这些规定，则表示您正在滥用代码猴子。Joel测试我同意其中的大多数。但是有些确实取决于。如果您错过了一些东西，那么可能会使程序员的生活变得更加艰难，那就是必须要付出的努力。因此，您可以争取完成，但是您必须意识到，偷工减料会招致技术债务，这将需要花费更多时间来解决。如果该日期在项目结束之前到来，则说明您真的搞砸了。有空的日子可以编码他们想要的东西。从RSA视频。记得这个名字，但是提到的公司在他们的网站上对此做了简短的解释。对我来说似乎是个好主意。在大多数商店中，有些事情是众所周知的，但是没有人有时间修复，这不是高度优先事项。这使他们能够解决技术债务。还可以让他们炫耀自己的绝妙想法。

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

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

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

#10 楼

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

祝你好运。

#11 楼

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

#12 楼

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


我不必浪费太多时间来证明为什么更改需要这么长时间或无法实施。从技术上讲，任何变更都可以实施，而高层管理人员通常要求以任何方式实施。但是至少在这种情况下，您的直接经理会在您​​身边，要求更多时间（而不是将您逼到尽头或让您精疲力尽）。情况（WTF黑客，生产问题等）。通常，非技术人员往往将这种情况归咎于开发人员，而好的经理则了解实际情况并支持他/她的开发人员（不仅知道或愿意以这种方式成为好人）。知道我的工作和绩效应由合适的人来评估。喜欢很低。在这种情况下，您最好迅速升职，并请其他人担任直接经理。抱歉，我在这一段中听起来很不好，但是我就是这样看的。你似乎是一个好人，应该得到一些真理。

#13 楼

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

我经常看到的是，价值体系存在实质性差异以及管理人员和开发人员之间采用的操作方法/方法。不幸的是，在最高管理者列表中，相同的值并不是很高。这不可避免地导致了巨大的冲突，特别是如果中层管理人员（您和我）决定完全担任高层管理人员。从我的角度来看，唯一的出路是在团队中站稳脚跟，一路支持他们，并通过公开交流，最重要的是，按照自己的话说，建立信任关系。 （这通常与您从最高管理层那里获得的相反，在最高政治上，政治完全压倒了诚意）。

同时，您自己需要保持运作，因此必须找到一种沟通方式高级管理人员以他们理解和玩游戏的语言。这是中层管理人员的真正挑战。

#14 楼

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

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

#15 楼

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

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

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

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

#16 楼

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

#17 楼

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

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

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

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

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

#18 楼

您多久与开发人员交谈一次？我不是说项目状态会议，关于可交付成果的问题或带给他们的其他主题-您多久与一位程序员坐下来，询问他们的进展情况，并只是倾听。 />还有很多其他答案都非常好-您应该研究敏捷开发。您需要开发人员学习和发展自己的角色。但是，如果您实际上没有听开发人员在说什么（或没有在说什么），那么您首先需要注意这一点。

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

#19 楼

简短而甜美。用Excel来完成您的工作-这将促进沟通。 ..阅读，重新阅读，甚至可以学习PeopleWare

#20 楼

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

这里有个主意：发送您的I.T.员工参加您当地社区大学的交流研讨会-当然，这是由公司支付的。

请确保a）研讨会享有良好的声誉，b）不要将您的员工聚集在一起。他们将倾向于团结在一起，而不是与其他班级成员打成一片，这不仅降低了研讨会的价值，而且给其他研讨会带来了干扰。 ，但这是我认为大多数学术路径都缺少的主题。

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

只是我的2位：)

#21 楼

只是为了从已经提出了一些答案的建议中做出答案。迈克尔·洛普（Michael Lopp，又名兰特）一直在他的博客《安息的兰德斯》（Rands in Repose）和《管理人类》（Managing Humans）一书中写到关于管理开发人员和“吸引他们的头脑”。这本书包含了他在2007年之前发布的帖子中大部分经过编辑的内容，并提供了一种赶上他博客中与管理相关的部分的好方法（他还谈论例如赌博，以及是否要阅读那是另一回事）。他的写作通常很棒，而且常常很幽默，因此阅读他的风险很小。

#22 楼

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

#23 楼

我参加晚会很晚，但是只看到了这个问题。

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

G子永远不会告诉西装的全部真相。兰德斯（Rands）在脱氧核糖核酸（DNA）中说了这一点，但没有直截了当地谈及，他的话题不同。您代表公司的利益。您不代表工程师。如果您这样做了，就不会在他们的支票上签名，他们会在您的支票上签名。

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

因此，管理任务的一部分是为工程师提供解决问题的方法，而不会引起公司政治和职业反弹。毕竟，加薪很高兴，还有其他一些公司，如果这家公司不适合的话。

#24 楼

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

#25 楼

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


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

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

#26 楼

阅读几本伟大的小说，这些小说可以洞悉技术人员的观点：
道格拉斯·库普兰（Douglas Coupland）的微型农奴制-http://en.wikipedia.org/wiki/道格拉斯库普兰（Douglas_Coupland）

大教堂和集市，埃里克·雷蒙德（Eric Raymond）-http://en.wikipedia.org/wiki/ Cathedral_and_the_Bazaar


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

#27 楼

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

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

这可能是由于两个原因。

他们认为您无权解决问题。但是，我认为这不太可能，因为那时您可能会知道，开发人员也会向您抱怨。以下更多内容

当他们遇到问题时，请告诉他们-我喜欢解决方案，而不是问题。
您会很好地倾听他们的意见，然后指派他们解决问题。您让他们鼓舞性地谈论赋予他们解决问题的责任是多么荣幸。随着时间的流逝，您的家伙明白，当他们遇到问题时，他们最终会付出额外的工作，因此他们不会遇到问题。
您否认这是一个问题。您为此给出令人信服的理由。但是随着这种情况的不断发生，随着时间的流逝，你们的家伙们发现，解决问题毫无意义。您说这种事情偶尔发生，而且无能为力。如果这是一种模式，那么您的家伙就会再次理解它。

#28 楼

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

对我来说，最糟糕的做法通常是扮成“好”-通常经理他们自己，或者BA或其他人编写规范，开发人员必须在事先约定的时间范围内解释和实施。

如果它是定制的解决方案，那么即使开发人员也常常不知道将花费多长时间，并且通常客户也不知道最适合他们的线索。这就是为什么迭代式开发很棒。虽然不是大多数交易都这样完成，但是好经理会像上面那样努力工作。它们可能最适合于具有明确要求，特别是明确技术要求的问题。也许您需要开发人员，他们是更好的沟通者，并希望致力于解决业务问题，而不是纯粹的技术问题。

#29 楼

让团队保持快乐很容易

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

如果您的项目需要深夜，团队郊游是个好主意（可能是一些游戏计划）和周末的工作，您认为您实际上并没有为团队增加很多价值，但还是可以抽出一些时间吃点东西，并赞赏团队的努力，如果可能的话，安排一些PTO临时团队，是一个好主意

与每个团队成员每两个月进行一次1：1的交流，以确保他们感到舒适。从技术上讲也是一样。

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

#30 楼

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

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

“当类似的事情简化为工具包时（例如， ，价值流图，KPI板，单元格，看板）。 br />今天，敏捷运动就像是精益运动（请参阅Jeff Sutherland的课程及其对Deming的荣誉http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will- ，它比Waterfall更好，但是与Deming的原始教义相比仍然相距甚远，因为大师们并没有重新阅读Deming的原文，而是只是重新包装了他，几乎没有引用他的全部14条原则管理部门，并出售本身没有多大价值的工具和研讨会。

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

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

另一件事是，我通过阅读技术文章来尝试使人们对该领域的发展有一个总体了解，例如新框架，新体系结构范例。我将参加一些集成测试，亲自编写一些文档（有些程序员讨厌我为他们做的事，他们当然会为我提供核心知识），而我实际上可以为帮助团队做任何事情。

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

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