没有权威的责任是没有意义的——基于技术的解决方案？答案

【问题标题】：Responsibility without Authority is Meaningless - a technical-based solution?没有权威的责任是没有意义的——基于技术的解决方案？
【发布时间】：2010-09-13 03:03:48
【问题描述】：

我爸爸总是说“没有权威的责任是没有意义的”。

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

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

当然，你可以说很多事情来解决这个问题——找一份新工作，和老板打架，等等......

但是这个问题的技术解决方案呢？也就是说，您可以自己进行哪些编码工作，而无需说服团队纠正其中一些问题 - 或者您可以使用哪些工具来证明为什么未跟踪的错误会伤害您，由于质量问题而错过了最后期限，您如何使用这些工具来获得更多“权威”而不必成为老板？

***举个例子 - 老板来找你说“为什么有这么多错误！！？！？” - 我们大多数人会说“我们没有一个好的系统来跟踪他们！”，但根据我的经验，这通常被视为一个借口。那么，如果您可以指向某个报告（经理喜欢报告）并说“看，这就是为什么”呢？

【问题讨论】：

我不明白为什么有人修改了这个。
几乎我们所有人的责任远大于权威。世界就是这样运作的。

标签： coding-style development-process

【解决方案1】：

如果会计师被要求在不使用复式记账的情况下生成一组账户并且不平衡，那么没有人会期望会计师这样做。

然而，从大约 13 世纪开始，会计师就开始采用复式记账法。

作为一个行业，我们需要很长时间才能拥有如此根深蒂固的标准实践，以至于没有他们就可以工作。

所以，很抱歉，我预计我们将不得不在未来很多年里面临此类问题。

【讨论】：

【解决方案2】：

如果您想要一份关于质量及其对生产力的影响的报告 - 这里是最好的： http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html Caper Jones 已经出版了几本书，并且仍然出现在会议上。在良好的 IDE 之外，开发人员/IT 团队需要源代码控制（VSS、SubVersion 等）和问题跟踪

【讨论】：

【解决方案3】：

你所能做的就是尽力而为，不要觉得成功软件的关键就在你手中，你是团队的一员，不必对所有事情负责。

显然，您所处的环境会对您的软件产生负面影响，但无法改变他的所有行为，因此我建议您从您的开始，开始作为一个团队工作，拥有自己的错误、截止日期、要求、质量和资源不要为其他的混乱而烦恼，但要努力在工作中做到最好。

作为一个自我指导的团队，向您的老板展示您的计划和进度报告，在您需要时要求更多资源，并向他展示您的计划是否会受到影响。

您可以在维基百科的PSP 和TSP 文章中找到更多建议

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

【讨论】：

我要补充一点，可能需要相当多的努力和耐心才能看到环境中的变化，这将使创建高质量作品变得更加容易。尽你最大的努力，但如果你觉得你已经做了所有你能做的并且你的情况对你不起作用，不要害怕寻找更好的情况。

【解决方案4】：

简单的答案是——您可以自己开始使用这些工具。

改进你的自己的工作。如果人们希望您修复代码，请告诉他们提交错误。向他们展示如何。确保他们可以在不安装任何东西的情况下做到这一点。他们想要状态更新？告诉他们检查错误。他们询问您所做的代码更改？向他们展示如何进行源代码控制历史查询。或者只是在你的盒子上展示它们。开始向他们展示这些东西有效。

当您需要从他们那里得到相同的结果时，要求他们做一些跑腿的工作。当您在源代码管理中找不到更改时，请他们开始从备份磁带中手动区分他们的修订。不要为他们做他们的工作，或者源代码控制和错误跟踪的工作。

最重要的是，在施加这种同侪压力时，善待它。苍蝇和蜂蜜等等。

如果他们不明白，您可以继续成为您公司或团队中唯一的professional developer。或者至少它有助于充实你的简历：'在 CVS 和 FogBugs 中设置和指导他人以提高产品质量的经验' 等等。

【讨论】：

【解决方案5】：

至于用于显示未跟踪的错误正在损害团队生成高质量代码的能力的特定工具，这里有一个 catch-22，因为您需要一些东西来跟踪错误，然后才能显示它们的影响。你无法衡量你无法追踪的东西。那么该怎么办呢？

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

诀窍在于确定谁有权做出决定，找出他们看重的东西，并收集足够的证据证明你想要实施的东西会给他们带来他们看重的东西。

要更广泛地了解如何从组织的中层或底层领导，请查看 John Maxwell 的360 度领导者。

【讨论】：

【解决方案6】：

只有编码才能使您自己的源文件保持整洁、注释良好、通过测试保持低错误数。但是您将需要用于跟踪进度和错误的外部工具（bugzilla、yoxel、trac、甘特图工具、Mylyn for Eclipse、博客等等）。在这些情况下，人员、纪律、良好习惯和领导力是压倒性的力量，没有任何软件工具和个人的提议可以单独获胜。

【讨论】：

【解决方案7】：

您不需要错误跟踪系统，您需要自动化测试：单元测试或其他。您可以使用 Makefile 设置自动化测试。您总是可以找到被管理层阻止的路径，但这并不意味着您无法在工作的限制范围内做任何事情。当然，答案可能是“找另一份工作”。如果你现在找不到另一份工作，那就学习一些技能，这样你就可以了。

【讨论】：

当然，如果您说 - “看，一半的自动化测试失败了，我们的代码覆盖率表明我们只有 10% 的代码库正在测试！” - 这是朝着正确方向迈出的一步。
我不同意这种强烈的说法。尽管您可以使用为每个错误创建测试的方法（如果我明白您的意思的话），错误跟踪系统不仅提供问题列表，而且还促进有关问题的沟通（不仅限于开发人员之间)。

【解决方案8】：

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

我强烈认为您提到的失败是一种沟通失败，作为专业人士，我们有责任发展我们的沟通技巧，使我们得到足够的尊重和信任，以利用我们需要的权威来改进我们的工作按照您建议的方式进行环境和处理。

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

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

抱歉，我又跑题了 - 随意降级。

【讨论】：

不——你肯定有道理。我认为问题在于，如果没有冷酷的事实或权威，有时你交流的内容并不重要。尤其是如果您有其他与您有不同意见的同行开发人员，以及不知道“信任”哪个人的老板。