我父亲总是说"没有权力的责任是没有意义的"。

但是，我发现作为开发人员，我们始终会陷入困境：

• 负责确保软件"无错误"，但无权实施错误跟踪系统
• 负责按时完成项目，但不能影响需求，质量或者团队资源(项目管理的三个部分)
• 等等。

当然，我们可以说很多话可以解决这个问题，找到一份新工作，与老板打架，等等。

但是如何解决这个问题呢？也就是说，我们可以自己进行哪种编码工作而不必说服团队来纠正其中的某些问题，或者可以使用哪种工具来证明未跟踪的bug为何损害利益，因为质量问题，以及如何在不必成为老板的情况下使用这些工具获得更多的"权威"？

***老板举个例子，你说："为什么有那么多虫子！！！？"我们大多数人会说"我们没有一个很好的系统来跟踪它们！"，但这通常被视为我的经验的借口。那么，如果我们可以指向一些报告(经理们喜欢的报告)并说"看，这就是为什么"怎么办？

解决方案

很抱歉没有直接回答问题，但是...

我强烈认为，我们所指的失败是沟通中的一种，这是我们作为专业人员的责任，需要发展我们的沟通技巧，使我们受到足够的尊重和信任，以利用我们改善工作环境和流程所需的权威建议方式。

简而言之，我认为没有一种技术解决方案可以解决由于工作场所沟通不畅而造成的所有问题。

如果有的话，技术已经导致直接面对面交流的减少。

抱歉，我再次切线，可以随意下调。

我们不需要错误跟踪系统，而需要自动化测试：单元测试或者其他。我们可以使用Makefile设置自动测试。我们总是可以找到被管理人员阻止的路径，但这并不意味着我们无法在工作限制内做任何事情。当然，答案可能是"找到另一份工作"。如果我们现在找不到其他工作，请学习一些技能，以便我们可以。

只有进行编码，才可以使自己的源文件保持整洁，注释良好，并通过测试使错误计数保持较低水平。但是我们将需要用于跟踪进度和错误的外部工具(bugzilla，yoxel，trac，gantt图表工具，Mylyn for Eclipse，博客等)。在这些情况下，人员和纪律以及良好的习惯和领导才能是压倒一切的力量，没有软件工具和个人的奉献无法独自赢得。

至于显示未追踪错误正在损害团队生产高质量代码的能力的特定工具，这里有一个问题22，因为在显示错误效果之前，我们需要一些追踪错误的工具。我们无法衡量无法追踪的内容。那么该怎么办？

举个类似的例子，我们最近有一个人加入我们的团队，他觉得我们通过电子邮件进行代码审查的方式很荒谬。因此，他找到了一个开源工具，将其安装在自己的盒子上，让我们一些思想开放的团队成员试用了一段时间，然后将其演示给我们的团队负责人。在几周内，他有机会向我们所有团队进行了演示。这个新人正在影响整个公司。我听说过许多采用游击式工具的故事。

诀窍是确定谁有权做出决定，找出他们的价值，并收集足够的证据表明我们想要实施的东西将给他们他们所价值。

要更广泛地了解如何从组织的中部或者底部进行领导，请查看约翰·麦克斯韦(John Maxwell)的" 360度领导者"。

我们所能做的就是尽力而为，不要认为成功软件的关键只在我们自己，团队的一部分中，而不必对所有事情负责。

显然，我们所处的环境会对软件造成负面影响，但无法改变其所有行为，因此我建议我们从自己的行为入手，以一个拥有自己的错误，期限，要求，质量和资源的团队开始工作麻烦其余的事情，但要努力做到最好。

作为一个自我指导的团队，一个团队向老板展示计划，并报告进度，在我们需要时请求更多的资源，并向他展示计划对计划有何影响(无论是否给我们)。

我们可以在Wikipedia的PSP和TSP文章中找到有关此问题的更多建议。

向老板展示出色的工作并按时完成任务后，他肯定会更加信任我们，并将一些想法传播给整个团队。

简单的答案是-我们可以自己开始使用这些工具。

改善自己的工作。如果人们要我们修复代码，请告诉他们提交错误。向他们展示如何。确保他们无需安装任何组件即可完成此操作。他们想要状态更新吗？告诉他们检查错误。他们问abou我们所做的代码更改？向他们展示如何进行源代码管理历史记录查询。或者只是将它们显示在盒子上。开始向他们展示这些东西有效。

并且当我们需要他们提供相同的结果时，要求他们做些合理的事情。当我们在源代码管理中找不到更改时，请他们开始手动从备份磁带上进行修订。不要为他们做他们的工作，或者源代码控制和错误跟踪的工作。

最重要的是，在施加同伴压力时，要对此保持友善。苍蝇和蜂蜜等等。

如果他们不了解，我们可以继续成为公司或者团队中唯一的专业开发人员。或者至少它会填写简历："体验设置并指导CVS和FogBugs中的其他人提高产品质量"等。

如果我们想获得有关质量及其对生产率的影响的报告，那么最好的方法是：
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
雀跃琼斯(Caper Jones)有几本书要出版，现在仍在会议上露面。在良好的IDE之外，开发人员/ IT小组需要源代码控制(VSS，SubVersion等)并进行问题跟踪

如果要求会计师在不使用重复输入和不余额的情况下生成一组帐户，则没人会期望会计师这样做。

但是，大约从13世纪开始，会计人员就已经在标准用法中采用了重复输入法。

我们作为一个专业人士需要很长时间才能拥有根深蒂固的标准实践，以至于没有这些实践，一个人就能工作。

因此，对不起，我希望我们将在未来的很多年中面临此类问题。