如何向管理层证明平庸的开发人员正在伤害团队
我在一家小公司处于“管理”开发团队的不稳定地位。我说“管理”是因为尽管我分配工作并就他们的表现提供反馈，但我实际上无法对个人进行纪律处分。
我的团队中的一些人我不知道该怎么办，他们无法独立工作，需要大量的帮助，如果留下来，通常会对项目造成严重破坏，通常会导致失败。当失败确实发生时，我只能挽救项目并推动它（有时一瘸一拐地）冲过终点线。
这些开发人员不仅缺乏编程概念的技能，而且普遍缺乏用代码制定问题解决方案的能力。像编写循环这样简单的事情对他们来说都是困难的，更不用说设计和实现问题的解决方案了。
我们尝试过结对编程，愿意支付课程费用、购买书籍、在工作日分配时间进行培训，甚至花一整天的时间来培训团队。
另一位高级开发人员和我不知道该怎么办，但我们的生产力由于必须每天与这些人打交道而受到限制。管理层强迫我们给他们工作，他们的主要抱怨是事情做得不够快。
除了我和其他高级开发人员之外，我们的管理团队没有直接与任何开发人员合作。管理层是非技术性的，他们相信每个开发人员都是平等的，而且我们显然需要更多的人参与这些项目来更快地完成它们。
我已经在准备一份包含“人月神话”和“代码完成”部分的文档，发送给管理层，希望能用统计数据说明真正阻碍我们的是不得不让平庸的人经历开发周期。
还有哪些其他资源？书籍、文章、一般建议，任何东西都会有帮助。
I am in the precarious position of "managing" a team of developers at a small company. I say "managing" because although I assign work and provide feedback on their performance I have no recourse in actually disciplining an individual.
Some of my team I don't know what to do with, they are unable to work on their own, require massive amounts of hand holding and when left along generally wreak havoc on the project usually to a point of failure. When failure does occur I am left to salvage the project and push it (some times limping) across the finish line.
These developers not only lack skills with programming concepts, but generally ability to formulate a solution to a problem in code. Simple things like writing loops are tough for them let alone designing and implementing a solution to a problem.
We have tried pair programming, offering to pay for classes, buying books, allocating time during the work day to training and even taking whole days to train the team.
The other senior developer and I do not know what to do, but our productivity is being throttled with having to deal with these individuals day to day. Management is forcing us to give them work and their major complaint is how things aren't getting done quickly enough.
None of our management team works directly with any of the developers other than myself and the other senior developer. Management is non-technical and believes every developer is created equally, and that we obviously need more people on these projects to get them done faster.
I am already preparing a document with sections from "The Mythical Man Month" and "Code Complete" to send to management to hopefully illustrate with statistics that what is really hindering us is having to drag the mediocre folks through the development cycle.
What other resources are out there? Books, articles, general advice anything would be helpful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
您提到您为您的团队“提供有关他们表现的反馈”。
所以：
You mentioned that for your team you "provide feedback on their performance".
So:
Peopleware 是另一本应该加入你的书单的书。
然而，当我读到它时，我觉得它不实用，因为公司里没有人愿意尝试它的建议。
Peopleware is another book that should join your list.
However, when I read it I did not find it practical because no one in the company wanted to try its recommendations.
听起来你走在正确的道路上。
如果你向他们展示数字，他们会更清楚地看到事情——创建一个编码任务，并将其交给几个不同的程序员，让他们自己完成。让它可以自己测试。
详细记录每一次需要多长时间，代码产生多少缺陷。
向高层管理人员展示这些数字，他们现在应该被说服了。
Sounds like you are on the right way.
If you show them numbers tough, they will see things clearer - create a coding an assignment and give it to several different programmers to each work on by themselves. Make it testable by yourself.
Keep details of how long each one takes, how many defects the code produces.
Show the numbers to upper management, they should now be convinced.
这本书
是一个很好的资源，可以帮助学习最佳实践。
要求每个开发人员通过讨论阅读和学习这篇文章可能会有所帮助，但最重要的是量化结果。计算一下你自己和团队其他成员的工资，然后计算你需要花费多少额外时间来修复其他人的错误，以及开发人员一开始搞砸事情所增加的成本。
然后展示由更优秀的开发人员组成的团队如何提高投资回报率。
The Book
is a good source that can help to learn best practices.
Requiring each developer to read and learn this with discussions could help a little but the biggest thing is to quantify the results. Take salaries of yourself and the rest of the team then calculate how much extra time you have to spend fixing others mistakes with the added cost of the developers messing up things to begin with.
Then show how a team of better developers can improve ROI.
保持报告简洁。不要说得罗嗦。换算一下他们在这件事上损失了多少钱。
Keep the report concise. Do not make it wordy. Put it in terms of how much money they're losing on this one.
我们现在有一个工具可以测量代码模块的复杂性。它在我们的 PL/SQL 模块上运行，但我相信其他环境上也有可用的工具。
整个过程中有各个部分，但当我们的几个关键模块被标记为“不可测试”时，这让管理层大开眼界。
我们结合了一个影响分析工具，帮助突出重复的功能，并将这一切打包为“技术债务”的评估。
由于我们可以逐个模块地呈现这一点，因此很容易识别肇事者（我们做到了，但没有报告）。事实上，该组织更注重未来的改进，而不是相互指责。
（顺便说一句，所有代码现在都已提交供审查，并且必须提供随附的代码分析。这里的情况肯定会变得更好。）
We have a tool now that measures the complexity of our code modules. It runs on our PL/SQL modules, but I believe that there are tools available on other environments.
There are various sections throughout, but it was quite an eye-opener to management when several of our key modules were marked as 'untestable'.
We combined with an imact analysis tool that help highlight duplicate functionality, and approached packaged this all up as an assessment of 'technical debt'.
As we could present this on a module-by-module basis, it would have been easy to identify the perpetrators (we did, but didn't report it). As it was, the organisation was more geared to improvement going forward than finger-pointing.
(As an aside, all code is now submitted for review, and an accompanying code-analysis must be supplied. Things are definately getting better here.)
除非你对管理层有很好的支持，否则这是不可能的。根据我的经验，如果你试图强迫它，你可能会遇到麻烦。
This is simply not possible unless you have good traction with the management. In my experience, if you try to force it, you might get into trouble.
只是一个想法。
我假设您使用 SVN 等源代码版本控制系统。因此，制定审查提交并拒绝不良提交的政策。然后向其他经理展示被拒绝的提交的统计数据，以证明平庸的开发人员对公司来说代价高昂。
Just an idea.
I assume you use the source version control systems like SVN. So make the policy of reviewing commits and rejecting bad ones. Then just show the other managers statistics of rejected commits to prove that mediocre developers are much expensive for the company.
这是给您的另一个想法：
不要修复它们损坏的东西。通过电子邮件将其发回进行返工，告诉他们出了什么问题以及如何修复（仅一般性术语）和抄送管理。请务必准确记录这将如何影响您的最终期限，以便管理层理解。这会为您创建性能问题的文档，其中一些问题在必须解决自己的混乱情况时可能会不再那么糟糕。
Here's another idea for you:
Don't fix what they break. Send it back for rework in an email by telling them what is wrong and how to fix (only in general terms) and cc managment. Make sure to note for managment's understanding exactly how this will impact your final deadline. This creates the documentation of performance problems for you and some of them mayl stop being as bad when they have to fix their own messes.
有趣的是，没有人告诉你，也许你缺乏管理技能。
有一次，我最终与一些经过一年半的培训后仍无法编写循环代码的人一起工作。我对他们进行培训，直到他们能够使用功能齐全的Web框架，而只花了一个月的时间。
也许您应该接受培训。
也许您应该阅读一份关于您的报告。
我这么说并不是为了攻击你。一点也不。我很理解这个问题，因为我过去也管理不了团队。
但不要躲避球，无论你一生中读过多少优秀的实践文献，你对球队中发生的事情负有主要责任。
在这种情况下，停止抱怨并开始工作。不是作为编码员，而是作为经理。
最后，我可能是错的。也许你已经做对了一切。在这种情况下，你可以而且可能应该辞职。无论你的力量有多大，试图通过移动你的双手来阻止飞机坠毁是没有用的。有很多休闲团队会利用你的技能创造奇迹，以充分发挥他们的优势。
Funny nobody told you that maybe you lack of management skills.
Once, I ended up working with people not being able to code a loop after a year and a half of training. I trained them, until they were able to use a full feature web framework, and it took only one month.
Maybe you should get a training.
Maybe you should read a report about you.
I am not saying that to attack you. Not at all. I understand the problem very well, as I failed to manage teams as well in the past.
But don't dodge the ball, you are mainly responsible for what's happening in your team, no matter how much good practice literature you have read in your life.
In that case, stop complaining and get to work. Not as a coder, but as a manager.
Finally, I can be wrong. Maybe you've done everything right. In that case, you can, and probably should, resign. Trying to prevent an airplane from crashing with moving your hands is useless, no matter how strong you are. There are plenty of casual teams that will do miracles with your skills to make the best of their's.
问题是否源于程序员缺乏技能或能力、态度问题，或者源于不提倡良好职业道德的企业文化？
如果是技能，你已经知道有些东西是你无法教授的。如果公司愿意（看起来确实如此），并且你可以表现出改进，我会加大培训力度，看看哪些开发人员能够胜任。那些不喜欢你的人就必须放手。在你知道你将放弃一些现有的开发人员之前，我不会雇用更多的开发人员。
如果是程序员的懒惰或其他态度问题，您将必须说服您的管理层支持您采取纪律处分。记录所有问题，如 Scott Vercuski 描述道。逐步淘汰那些不能胜任的程序员。让剩下的程序员知道他们应该学习良好的编程技术和最佳实践，并使用它们。
如果您还没有这样做，请进行代码审查。有大量资源可以解释如何正确执行此操作。他们不应该是喊叫比赛，而应该被视为产生预期结果的战略会议。讨论代码。如何改进？如有必要，请在评审中编写一些新代码。
如果管理是问题所在，请告诉他们问题是他们造成的，并向他们展示如何解决问题。但你必须口才好、有说服力。您必须是他们的拥护者。写一篇关于这个问题的论文。做一个演示并展示它。诉诸利润动机。
最后，尽你所能，成为你的员工最好的领导者。帮助他们。让他们畅通无阻，以便他们能够完成自己的工作。您工作的一部分是保护您的员工免受高层管理人员的政治影响，并维持体面的工作环境，以便他们能够专注于尽其所能。换句话说，确保您的员工可以信任您。
Does the problem stem from lack of skills or ability, attitude problems on the part of the programmers, or from a corporate culture that doesn't promote a good work ethic?
If it's skills, you already know that there are some things you can't teach. If the company is willing (and it seems that it is), and you can show improvement, I would ramp up the training, and see which developers rise to the occasion. Those who don't you will have to let go. I wouldn't hire additional developers until you know that you will be letting go some of your existing ones.
If it's laziness or other attitude problems on the part of the programmers, you will have to convince your management to back you up on disciplinary actions. Document all problems, as Scott Vercuski describes. Gradually cull away those programmers that cannot rise to the occasion. Let the remaining programmers know that they are expected to learn good programming techniques and best practices, and use them.
Have code reviews, if you are not doing that already. There are plenty of resources that explain how to do this properly. They should not be shouting matches, but rather looked upon as strategy sessions to produce desired outcomes. Discuss the code. How can it be improved? Write some new code in the review, if necessary.
If management is the problem, tell them they are the problem, and show them how they can fix it. But you must be eloquent and persuasive. You must be their advocate. Write a paper about the problem. Make a presentation and show it. Appeal to profit motives.
Finally, be the best leader for your people that you can be. Help them. Keep them unblocked so they can do their job. Part of your job is shielding your people from the politics of upper management and maintaining a decent work environment, so that they can focus on doing the best job they can. In other words, make sure that your people can trust you.
文档是你最大的资源......我的一位老经理告诉我“如果你不把它写下来，它就不会发生。”。如果您的开发人员向您提供完成任务所需时间的书面估计，并且经常（且严重）错过这些截止日期，则应将其记录下来。
你们有某种计时系统吗？还是开发人员记录他们的时间？如果他们说某个问题需要 X 天的时间，而 X 天后还没有完成，你可以质疑为什么没有完成。
重申一下......文件是关键，如果你突然解雇某人，并且你没有足够的文件来说明你可以进入诉讼领域的原因。拥有的文档越多，管理层就应该很容易看出初级开发人员没有尽职尽责，应该被替换。
祝你好运，但恐怕你正走在一条非常崎岖的道路上……我曾经经历过，这是一个漫长的过程。
Documentation is your biggest resource ... an old manager of mine told me "If you don't write it down, it didn't happen.". If your developers give you a written estimate of the time needed to complete a task and constantly (and severely) miss those deadlines it should be documented.
Do you have some sort of timekeeping system? or do the developers log their time? If they state that a problem will take them X number of days and after X days it isn't done you can question why it wasn't done.
To reiterate ... documentation is the key, if you all of a sudden terminate someone and you don't have adequate documentation as to a reason you can get into lawsuit territory. The more documentation you have, it should be readily apparent to management that the junior developers aren't pulling their weight and should be replaced.
Best of luck to you, I'm afraid you're on a very rough road though ... I've been there and it is a long drawn out process.
我以前经历过这种情况，当然可以理解。我所做的是削减一个小的、独立的任务，该任务应该花费我或其他高级开发人员不超过 2 天左右的时间。对于此任务，我将创建大量文档，确定如何实施解决方案、任何数据库更改等。然后我会与开发人员坐下来，向他们提供任务的高级演练并将其分配给他们截止日期为 1 周。到了周末，你就会得到一些有形的东西，可以将他们的工作与他们的工作进行比较：他们符合规范吗？他们做得怎么样？ QA 发现了多少 bug？他们是否以任何方式破坏了构建或破坏过程？
一旦完成，假设他们失败了，你将与他们进行直接而尖锐的会议，解释他们如何没有履行职责。同样的事情再做一两次，只要你在链条上进行记录和沟通，你应该能够将它们推出。这可能很严厉，但听起来你需要有人挺身而出，但你只是没有合适的人来做这件事。
另外，请确保您能够参加新候选人的面试。
I've been in this situation before and can certainly empathize. What I did was to pare off a small, self-contained task that should take me or another senior dev no more than 2 days or so. For this task, I would create scads of documentation identifying how the solution should be implemented, any database changes, etc.. I'd then sit down with the developer, give them a high-level walkthrough of the task and assign it to them with a deadline of 1 week. At the end of the week, you have something tangible that you can compare their work to: Did they meet spec? How done are they? How many bugs did QA find? Did they break the build or break process in any way?
Once that is done, assuming they've failed, you have a direct and pointed meeting with them explaining how they're not fulfilling their duties. Do the same things one or two more times and, as long as your documenting and communicating up the chain, you should be able to push them out. It may be harsh, but it sounds like you need people to step up and you just don't have the right people to do it.
Also, make sure you get to participate in the interviewing of new candidates.
我的建议是：
如果您是经理，那么您必须拥有与责任相匹配的权利。这些权利包括对您手下的纪律处分。如果上层管理人员拒绝授予您这些权利，请拒绝承担该责任。
你不一定要对你的主管那么严厉，但这就是必须发生的事情的本质。
My advice is this:
If you are a manager, then you must have the rights that go with your responsibility. These rights include discipline of those under you. If upper management refuses to grant you those rights, refuse to assume that responsibility.
You don't have to be that stark to your supervisors, necessarily, but that is the essense of what must happen.
我的建议是实施错误跟踪器并分配任务。这将显示团队中任何人的生产力。第一次使用它时，我们可以组织团队并衡量我们在任务上花费的时间。我喜欢的一件事是，当有人分配任务时，它会向工作人员发送一封电子邮件，并向其他人发送一份副本以检查该任务。
顺便说一下，我们使用了 BugTracker.Net。
My advice would be implementing a bug tracker and assign tasks. This will show the productivity of anyone of the team. The first time we used it, we achieve to organize the team and measure the time we spend working on tasks. One of the things I liked was the fact that when someone assigned a task it sent an email to the worker and a copy to someone else to check the task.
By the way we used BugTracker.Net.
我想知道这些人最初是如何进入公司的：
毫无疑问，您的公司需要投入更多的时间和精力来招聘员工，俗话说：欲速则不达。
现在，一旦您遇到您所描述的情况，请完成您的报告，（正如其他人所暗示的那样）使其简洁并强调这使公司花费了多少钱，提交并等待最好的结果（正如您所说，您“没有实际惩戒个人的追索权。”）。
I wonder how did these people get into the company in the first place:
You company needs, no doubt, invest more time and effort into the recruitment of workforce, as the the old saying has it: haste makes waste.
Now, once you're in that situation as you describe, finish your report, (as others have hinted) make it concise and underline how much money this costs the company, submit and wait for the best (as you said you "have no recourse in actually disciplining an individual.").
我不久前读过这篇文章，内容是关于鼓励程序员成为最好的。
书呆子羊群
I read this a while ago about encouraging programmers to want to be the best.
Nerd Herding