没有权力的责任毫无意义——基于技术的解决方案吗？
我爸爸总是说“没有权威的责任是没有意义的”。
然而，我发现作为开发人员，我们总是陷入这样的情况：
- 负责确保软件“无错误”，但无权实施错误跟踪系统
- 负责按时完成项目，但不能影响需求、质量或团队资源（项目管理的三个部分）
- 等。
当然，你可以说很多话来解决这个问题 - 找一份新工作，与老板吵架等等......但是
这个问题有什么技术解决方案吗？ 也就是说，您可以自己进行哪些编码工作，而无需说服团队纠正其中一些问题 - 或者您可以使用哪种工具来演示为什么未跟踪的错误会伤害您，由于质量问题而错过最后期限，如何使用这些工具来获得更多“权威”而不必成为老板？
***举个例子——老板来找你说“为什么有这么多bug！！！？！？” - 我们大多数人会说“我们没有一个好的系统来跟踪它们！”，但根据我的经验，这通常被视为借口。 那么，如果您可以指着一些报告（经理喜欢报告）并说“看，这就是原因”怎么办？
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
- Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
- Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
- etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您所能做的就是尽力而为，不要觉得成功软件的关键只在您手中，您是团队的一部分，而不必对所有人负责。
显然，你所处的环境会对你的软件产生负面影响，但无法改变他的所有行为，所以我建议你从你自己的开始，开始作为一个团队工作，与你自己的错误、截止日期、要求、质量和资源无关。为剩下的混乱而烦恼，但努力在工作中做到最好。
作为一个自我指导的团队，向老板展示你的计划，报告你的进度，在需要时请求更多资源，并向他展示当他是否给你资源时，你的计划会受到怎样的影响。
您可以在 PSP 和 TSP 维基百科文章
在向你的老板展示了出色的工作并按时完成后，他肯定会更加信任你并让你的一些想法流向整个团队。
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
您不需要错误跟踪系统，您需要自动化测试：单元测试或其他测试。 您可以使用 Makefile 设置自动化测试。 你总能找到被管理层挡住的路，但这并不意味着你在工作的限制内无事可做。 当然，答案可能是“找另一份工作”。 如果你现在找不到另一份工作，那就学习一些技能，这样你就可以找到另一份工作。
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
简单的答案是——您可以自己开始使用这些工具。
改进您自己的工作。 如果人们希望您修复代码，请告诉他们提交错误。 向他们展示如何做。 确保他们无需安装任何东西就可以做到这一点。 他们想要状态更新吗？ 告诉他们检查错误。 他们询问您是否进行了代码更改？ 向他们展示如何进行源代码管理历史查询。 或者只是将它们展示在您的盒子上。 开始向他们展示这些东西有效。
当你需要他们得到相同的结果时，要求他们跑腿。 当您在源代码管理中找不到更改时，请要求他们开始手动将其修订版本与备份磁带进行比较。 不要为他们做他们的工作，或者源代码控制和错误跟踪的工作。
最重要的是，在施加这种同侪压力时，要友善对待。 苍蝇、蜂蜜等等。
如果他们不明白，您可以继续成为唯一的专业开发人员 在您的公司或团体中。 或者至少它将有助于丰富您的简历：“在 CVS 和 FogBugs 中设置和指导其他人提高产品质量的经验”等。
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
至于用于显示未跟踪的错误正在损害团队生成高质量代码的能力的特定工具，这里有一个第 22 条军规，因为您需要一些东西来跟踪错误，然后才能显示其影响。 你无法衡量你无法追踪的东西。 那么该怎么办？
作为一个类似的例子，最近有一个人加入我们的团队，他觉得我们通过电子邮件进行代码审查的方式是荒谬的。 因此，他找到了一个开源工具，将其安装在他的盒子上，让我们一些思想开放的团队成员尝试了一段时间，然后向我们的团队领导演示了它。 几周之内，他就有机会向我们所有的团队演示它。 新人正在影响整个公司。 我听过很多关于采用这种游击式工具的故事。
关键在于确定谁有权做出决策，找出他们看重什么，并收集足够的证据来证明您想要实施的内容将给他们带来他们看重的东西。
要从组织的中层或底层进行领导，请查看 John Maxwell 的360 度领导者。
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
如果您想要一份有关质量及其对生产力影响的报告 - 这是最好的：
http://itprojectguide.blogspot.com/2008/ 11/caper-jones-2008-software-quality.html
卡珀·琼斯出版了几本书，并且仍然出现在会议上。 除了良好的 IDE 之外，开发人员/IT 团队还需要源代码控制（VSS、SubVersion 等）和问题跟踪
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
如果要求会计师在不使用复式记账且不平衡的情况下生成一组帐户，则没有人会期望会计师这样做。
然而，自 13 世纪左右以来，复式记账法已成为会计师的标准使用方法。
作为一个职业，我们需要很长时间才能拥有根深蒂固的标准实践，以至于没有它们，on-one 也能工作。
因此，抱歉，我预计我们将在未来许多年内面临此类问题。
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
很抱歉没有直接回答您的问题，但是...
我强烈认为您提到的失败是沟通的失败之一，作为专业人士，我们有责任发展我们的沟通技巧，直到我们受到足够的尊重和足够的信任利用我们所需的权力来改善我们的工作环境并按照您建议的方式进行流程。
简而言之，我认为没有一种技术解决方案可以解决工作场所沟通不畅所产生的所有问题。
如果说有什么影响的话，那就是技术导致了直接面对面交流的减少。
抱歉，我又跑题了 - 请随意下载。
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
只有你编码只能保持你自己的源文件整洁，注释良好，通过测试保持错误数量低。 但是您将需要外部工具来跟踪进度和错误（bugzilla、yoxel、trac、甘特图工具、Mylyn for Eclipse、博客等）。 在这些情况下，人员、纪律、良好习惯和领导力是压倒性的力量，任何软件工具和个人的提议都无法单独获胜。
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.