我是5位以上开发人员的团队负责人。我有一个开发人员（我们称其为A），他是一名优秀的程序员，并且编写了清晰，易于理解的代码。但是他管理起来有些困难，有时我想知道他是否真的表现不佳。

1. 我们公司要求开发人员在我们使用的错误跟踪器中指示工作进度，而不仅仅是监视程序员，而是让利益相关者随时了解进度。问题是，一个在完成时（也许3周后，首先在工作），这每个人都留下想知道什么是在开发一周的中间去上只更新任务进度。尽管反复探测，他还是不会改变习惯。（没关系，开发人员也讨厌文书工作，我也这样做）
2. 最近2-3个月，他经常因各种事件而休假-生病或不得不参加很多个人活动等。（没关系，坏事连连发生。这只是一个巧合）
3. 我们为每个月定义冲刺或路线图。在sprint的开始部分，我们将讨论每个开发人员在sprint中必须完成的工作量，并且开发人员可以设置每个任务所需的时间。他通常将无法完成所有这些任务。（没关系，开发人员通常会由于他们的过错而错过最后期限）。
4. 我在新加坡工作。不确定是否重要。是的，众所周知亚洲人比较沉默寡言，但这有关系吗？

如果仅上述事件中的一两个发生，我不会觉得A的表现不佳，但是它们同时发生。所以，我有感觉，那一个是执行下和maybe--上帝保佑---懈怠。

这只是基于我作为程序员的多年经验而得出的一种感觉。但是我可能是错的。

众所周知，要衡量程序员的工作非常困难，因为并非所有两个任务都是一样的，并且缺乏衡量程序员对公司的承诺的标准目标。很难断定程序员是在做他的工作还是在懈怠。您所能做的就是信任他们-是的，信任并赋予他们自治权是程序员工作的最佳方式，我知道，所以不要开始讲解为什么需要信任程序员，谢谢大家很多 -但是如果他们滥用您的信任，您知道吗？

结果：

关于他对他的表现的看法，我与他直接交谈。当我建议我感到他没有达到最佳状态时，他很愤慨。他觉得这是一种完全不公平的感觉。然后我回答说这就是我的感觉，我不知道我的感觉是否正确。他将一无所有，并立即结束了讨论。

在他离开之前，他说他“会努力向公司付出更多”。他的反应使我大吃一惊。我确信我在某些方面冒犯了他。不过，我不太确定这是否对我来说是如此正确，以至于他如此坦率。

我的问题是：如何判断您的程序员表现不佳？当然，有经验丰富的团队负责人在这方面比我更了解吗？ 

额外说明：

1. 我讨厌微观管理。因此，我们在软件流程中所需要的就是Sprint（优先级和任务分配，并在月底检查完成的工作量）。开发人员每天都需要更新任务。
2. 没有站立会议，或其他任何形式的会议。主要是因为我们有在家工作的自由，每个人都珍惜这种自由。
3. 尽管我是确定截止日期的人，但是开发人员将提供每个任务的预算，然后我将根据该预算确定进入特定冲刺的任务。如果他们不能在冲刺结束时完成任务，我将把他们推到下一个任务。因此，从理论上讲，一个人在整个Sprint中只能执行1或2个任务，然后将剩余的99个任务推到下一个Sprint，但只要证明了这一点，他就可以了-以日常工作进度更新的形式

这应该是一个非常容易解决的问题。

与他第二次见面。告诉他，您接受您的错误可能是您对现实的理解。然后用“但是，如果是这样，那么我们需要共同努力以改善我的看法”。最后挑战他解决这个问题，这样他就不会感到微观管理。

这确切的事情很久以前就发生在我身上。对我来说，问题是我不喜欢有人认为我只是因为做我的工作而寻求额外的荣誉。这很公平，但是任何员工及其直属经理之间都必须有定期的反馈循环。

如果没有，那么您会遇到这些问题。

定期的，计划的1：1s是个好主意。而且，正如人们指出的那样，站立式站立不需要与在家工作正交。但是它们必须涉及三个问题：您昨天做了什么？您今天打算做什么？而大多数人却忘记了……是什么（如果有的话）使您无法自拔？

就是说，您应该尝试阻止团队成员从不合作的情况。我以前在这种情况下工作过，它在团队内部和外部都产生了不信任感。大家有一天有规律地进入办公室。召开例行会议，人们可以就改进流程或其他方面发表一些想法。

不要使其成为行报告事件。使其有机会进行交谈。您会惊讶于所学内容。如果可能的话，将其变成社交活动，在工作时间喝几杯作为结合练习。

这里有很多很棒的建议，我也不想从中脱颖而出，所以我将其作为一个单独的答案发布。

首先，对我（以及其他人而言）显然，您还没有发现问题的根源。您正在盯着一种症状并试图治愈它。您需要找出导致您自己与该开发人员之间如此巨大摩擦的原因。也许您太有权威了（我的产品负责人最近形容自己对一个项目具有“无限的力量”，这对我来说是冒犯性的，即使她说了笑也是如此）。也许他有严重的家庭问题（会一直解释失业的原因）。有一个根本的问题在这里，直到你找到它，这将不会是固定的。

接得好！

如果他的表现可以更好，那您确定就好了。但是请记住，如果相比之下，他的不良表现仍然是良好的表现，那么您需要谨慎行事，以免失去一名优秀的开发人员。优秀的开发人员很难得到，优秀的开发人员需要一系列非常具体的东西。也许看看在乔尔测试，看是否得到满足他的需求。

找到问题的根源

如果他对所从事的工作不满意，则只能通过确定问题的根源来解决。让我清楚一点，您说您的程序员编写了不错的代码。这意味着他喜欢编程。根据您对会议的描述，很明显他在工作上感到沮丧，并且您可能是对的，他的表现低于应有的水平，但不要假设。请记住，许多程序员只是没有社交技能。

你都不完美

请记住，有时您会遇到人格冲突，尤其是性格内向的人。如果事实证明这是人格冲突，请考虑您愿意为提高绩效而走多远（请参阅1）

说的全部

我写了一篇有关管理程序员的博客文章。我认为您应该阅读它。

http://deltreey.blogspot.com/2012/07/managing-programmers.html

我不能足够强调那篇文章的最后一部分。

如果您的开发人员有任何优势，他们都想编写代码。

您的程序员即使放松下来，也不想放松下来。您必须找到这个问题的根源，而它可能是根本无法解决的问题，必须放手，但无论如何，您都无法做出明智的决定。

当您感觉某人像您描述的那样“有点难以管理”时，为了更好地理解一个人的表现以及是否存在影响开发团队成员生产力的问题（客观的或主观的），请考虑与您的人建立常规的1：1的实践团队成员，如《更新，发泄和灾难》的精彩文章所述：

...我并不是说每1：1都是曲折的事情，以发现深层隐藏的突发灾难，但是您确实想创建一个每周一次的场所，不满可能会悄然出现。1：1是您每周进行一次预防性维护的机会，同时还可以了解团队的健康状况。

...围绕1：1s成功方案的声音是寂静。在1：1期间发生的所有聆听，提问和讨论都是管理上的预防性维护。您会看到对项目的兴趣何时开始减弱，并在对工作不满之前采取行动。您会听到两名员工之间的紧张关系，并在会议上大声疾呼之前进行讨论。您对于健康的1：1s文化的奖励是明显缺乏戏剧性。

_{提到的文章的一个很强的优点是它是独立的，在某种意义上，除了解释好处之外，它还提供了一组实用的建议，基本上使人们可以开始练习常规的1：1，而无需挖掘其他来源（尽管寻找您知道其他信息不会受到伤害）。}

显然，这里存在一个主要的沟通问题。他可能做得很棒，但是如果您感觉自己不知道他在做什么，那么这本身就是一个问题。而且，如果您不知道他在做什么，那么他的同事可能也不会。当他确实签入他两周大的代码时，这可能会引起问题。尤其是当有人在类似区域工作时。

您总是可以建议他更定期地签入/提供更新，以最大程度地减少此类冲突。这样可以使您在帮助团队方面提出自己的要求，而不是“我不知道您在做什么”。

我知道站起来会引起很多仇恨，但实际上并不一定要在同一个房间里举行。每天一次快速呼叫或群Skype更新非常快速，并使每个人都在同一页面上。

我目前正在印度与爱尔兰的一个团队一起工作，我无法想象没有每天与他们交流，或者我大概知道他们每个人在干什么，或者我很快就能找到他们。

无意义

每日状态更新毫无意义。让人们报告“今天我完成了2.5％”，“今天我完成了3.74％”是荒谬的。

它对利益相关者没有任何价值，并且使工作人员感到烦恼。

让他们不受干扰地工作。

无根据

您认为开发人员A表现不佳的原因是什么？如果他/她的工作按时完成，那就足够了。

您说您讨厌微管理，但您所描述的恰恰是那样。

我们公司要求开发人员在我们使用的错误跟踪器中指示工作进度，而不仅仅是监视程序员，而是让利益相关者随时了解进度。...开发人员每天都需要更新任务。

这是毫无意义的（见上文）。您的团队没有准备汉堡，而是在设计技术解决方案。进展不是线性的，也不容易衡量甚至估计。即使是这样，此类日常测量或估计也没有任何价值。

危险的

重新检查您的“感觉”基础，即开发人员A“表现不佳”。您认为他/她可以做得更好，但是基于什么证据呢？

不开心！=表现不佳

如所述继续进行，并且在某个时候，开发人员A可能会决定他/她的价值被低估了，给了公司足够的钱，并将找到另一家公司。从员工那里榨取最后0.01％的努力远比留住他们长期的工作重要。

开发人员可能不愿意记录自己的工作并更新状态，但这是成为专业开发人员的一部分。我建议您尝试向他指出，他对问题日志的最新更新导致对他的工作的不必要的负面看法。如果他没有发现沟通失败是一个绩效问题-那么，你就是他的团队负责人；告诉他是的。

关于估计-这是一个经典问题。我建议阅读Steve McConnell撰写的“软件评估-揭开妖术的神秘面纱”。在这种情况下，您给人的印象是大多数开发人员都低估了。奇怪的是，这是正常现象，很少解决。我建议您在估算过程本身上遇到问题，而不是这个人。

尝试“闭合”估算，评估和改进的循环。然后，如果您的开发人员按时进场，而这个人却没有，那么您可以考虑对他采取什么措施。

最后，举行站立会议。即使是通过即时消息。您只需要每个人都知道“我做了什么，我今天在做什么，任何问题”。如果有问题，请将其脱机以供以后讨论。这就是我之前所做的，并且对于那个团队来说是成功的。

第一件事，你的冲刺为什么那么长？冲刺绝对不能超过两周。我认为您的大部分问题都在那儿。我建议您尝试缩短冲刺时间，然后再次分析您的问题。

那代码签入呢？他是否一直在检查代码？我个人认为程序员并不是真正的管理人员，您尝试管理的次数越多，他们就会越受挫败。实际上，我不喜欢执行这些更新任务，这可能就是为什么要使用PM和Leads的原因。但是同时，我会在Scrum会议或我们见面时提供状态。现在，当您确实分配任务时，它们是提交到时间线还是由您为其分配时间线？

因此，我唯一可以判断某人是否表现不佳的方法是将已提交的时间表映射到已完成工作的百分比。当然，现在，如果有人说他要花两天的时间写出一个将两个数字相加的方法，您就会知道存在问题，因此时间表应该是现实的，并且双方都同意。

采取这种方式-如果您可以在一小时内编写一段代码，请给他一个小时+一些缓冲区。如果他在那段时间内为您提供服务，那么我认为你们做的很好。如果不是，请向他询问，然后再由您决定他是否提供合理的解释。

您可以做的一件事是将XPlanner之类的内容与版本控制工具集成在一起。

我认为编程专业与其他专业没有内在的区别。您可能需要随心所欲。

我个人认为A一次连续几周拒绝提供更新很奇怪。我是一名在家工作的程序员，我和我的雇主之间存在一个隐性合同，我需要每天提供有关自己进度的最新信息。这些不是“官方”更新，只是一封简短的电子邮件或IM，让他知道要付款的软件正在发生什么。更新花费不到一两分钟的时间来编写，并为我们俩提供了关闭的机会。对于错误修复，我将在当天结束时将票证标记为在我们的错误跟踪器中已解决。尽管我享受一个轻松的工作环境并且很少的文书工作，但对我来说，这些程序并不困难。

我敢肯定，即使是偶然的更新也将不胜感激。您的帖子听起来非常非常宽容。如果您一直怀疑他在长时间内放松，则无需其他借口就可以解决他。

即使是通过Skype或在聊天室中，也可以进行每日站立，但如果您将其视为对利益相关者的更新，则不是这样。当整个团队每天检查一次他们正在做的事情，遇到的挑战以及下一步的计划时，您将获得多个胜利：

• 无论您是出于好还是坏原因浪费时间，花费太长时间都会变得更加透明，这会鼓励您的开发人员在需要时寻求帮助，而不必过度从事可能不需要进行的研究或解决问题的挑战，而其他团队的意见将帮助他们更快地解决问题。

• 作为经理，您可以看到人们最常遇到障碍的地方，这可以帮助您更好地估计并可能解决浪费时间/金钱的根本性问题。

• IMO，当他们看到每个人有时甚至需要完成相对简单的事情通常需要多长时间时，它确实有助于团队更好地估计欠佳。

• 当团队成员告诉您他们下一步打算做什么时，通常会提醒您需要重新安排优先事项。

因此，请忘记“完成百分比”。只是要使每个人都像其他人一样对自己诚实，在他们获得更多经验时做出更好/更可靠的估计，并给人们更多动力，使他们在不加思索的情况下进行报告麻木的练习，将一些数字放在您真正无法做到的事情上。

听起来高层管理人员了解截止日期并不总是会受到打击。每天站立起来会给您带来更多的弹药，因为您将对为什么它们没有受到打击有更具体的想法。

而且不要做第一件事。IMO总是错的。人们需要时间让自己的牙齿重新陷入问题，才能更可靠地报告所有问题，IMO。

在我看来，敏捷的工作不仅仅是沟通，更不是问责制，而仅仅是设定目标，而不是任何事情。我可以带走或离开的其余部分，尤其是Scrum，我已经将其视为高管/利益相关者的蛇油。

表现不佳？

强度在一个人的职业生涯中起伏不定。如果他的身价超过其花费，请与他交谈，并尝试使他的工作更轻松。否则开始寻找替代品。

通讯

不要依赖每周的会议。大多数人不会做一个完整的头脑风暴。安排更多的1：1。询问他们情况如何，您可以做得更好，以及您认为他们可以做得更好。有时候，没有什么可谈的，但是没关系。通过拥有更多的1：1，您增加了他们记得提某事的可能性。

拥有更持久的沟通方式

如果您不觉得这很麻烦，则可以从人们那里获得更多信息。如果他们都是远程的，请他们使用具有记录功能的聊天程序，例如Hipchat或IRC。拥有更持久的沟通方式会鼓励人们多说话。以身作则，经常交谈，以鼓励他人也这样做。至少每天一次，让人们说出他们的项目所在地。有时，仅通过聊天，您就可以了解事情的进展情况。

源代码控制

让每个人每天都检查他们的代码。如果您使用的是git，请让他们推送到公司存储库中自己的分支。通过查看提交，您可以知道它们的状态。

将手段与目标分开

利益相关者要更新吗？自己与利益相关者打交道。担任经理的部分工作是充当保护伞，以便您的编码人员可以专注于他们的工作。查看聊天记录和提交，然后编写有关运行情况的摘要。

这些是我的建议：

1. 创新：想象力和创造力曾经用来降低成本并改善当前状况。

2. 公司：愿意帮助他人实现目标

3. 主动权：尝试非常规的工作和任务。

4. 出勤：缺勤或迟到，低于标准。

5. 警觉性：能够快速了解​​新信息和新情况

6. 准确性和质量：代码审查，按时交付，发布率）。