如何在软件开发周期中做出决策？

Question

我认为只有在团队例外和同意的情况下才能达成软件决策。 但大多数情况会有所不同。

您如何描述贵公司在软件开发周期中做出决策的方式？ 这是民主吗？ /这是听写吗？ /这是无政府状态吗？

以下是我从朋友那里听到的消息： “这不是民主，我是经理，我决定做什么”。

您怎么看？

Answer 1

团队决策很少及时提供最佳结果。通常有很多方法可以解决问题 - 性能，质量，可维护性等，以减少潜在的解决方案，在最佳环境中，具有最多经验和知识的领导者做出最终决策（希望在收集来自团队）。因此，我同意应该有一个人做出决定并对结果负责 - 希望你处在一个决策者被追究责任的环境中，并且根据技能和能力选择领导 - 否则，未来将是凄凉和痛苦......充其量

Answer 2

这将取决于软件团队的规模，团队成员的敏感度以及代码库的成熟度。

我的上一个项目一次有大约8名团队成员在代码中工作，因此每项任务都非常精细，每个人只影响他们正在处理的少量代码，并且我们不断进行代码审查确保我们的变化“符合”项目的整体方案。

我目前的项目（在一家新公司）是我从头开始编写的应用程序，但还没有人使用它，所以我成为独裁者并确切地决定事情的样子。我可以对代码进行广泛的更改，随意更改设计模式，重命名和重构广告。并且在其他人必须进入代码之前，需要进行大量的自我控制以确保代码对于局外人有意义。但我的希望是，当我完成后，其他任何人都可以直接进入并接管。 （否则我将永远维护这段代码。）

Answer 3

有人必须做出最终决定。有时（通常）团队中的每个人都不会就某事达成一致。一个优秀的团队将有一个“巴克停在这里”的人做出没有共识或仍在挥之不去的决定。很多时候我被要求成为那个人。我将大部分决策委托给我信任的团队领导，但不时，码头无法就方向达成一致。我为公司设定了架构指导并加以执行。我使用每个团队成员的意见，指导和我的判断来打破僵局。我不会说它是专制的，但它也不是一个完整的民主国家。

Answer 4

最糟糕的情况是，它有点无政府状态。

在大型项目的规划阶段，我们与业务分析师坐下来进行一些Q＆amp; A会议，编写规范草案，并与主题专家讨论业务需求的具体细节。然后我们的团队起草设计文档和流程草稿。

此后的某个时刻，所有地狱都破裂了。该公司看到了最初的发布，并突然意识到它没有澄清它的要求，或者我们没有澄清他们的要求，或者他们一开始并不知道他们要求的是什么。测试人员测试应该花费的时间是开发人员重构所花费的时间。

最初的粗略但也许相对优雅的解决方案变成了一堆注释掉的代码，其中应用了奇怪且不稳定的变通方法和填充程序，这些都挑战了每个人的能力，使他们不必拥有自己的堆栈溢出的心理笔记，关于什么工作方式适用于什么代码的情况。

时间浪费，人们感到压力，并且不可避免地会在测试中发现更多问题，这些问题必须得到解决。最终它可能变成Looney Tunes中的东西，厨房用具，船桨，人和海洋衬里的大杂烩都堆叠在一起，并且彼此之间不稳定地平衡（有点像那个花费时间平衡岩石的怪异艺术家的家伙在彼此之上）。

关于你朋友的评论，只要那个人愿意与团队讨论，那种领导风格就好了。经理是一名经理，部分原因是他们管理得很好（希望如果），如果他们也能很好地编写奖金，但如果不是，他们需要接受团队中比他们更精明的人的建议。如果做不到这一点，总会出现一个可以引用的后备立场，“无论我是聪明还是愚蠢，我得到同样的报酬”。

Answer 5

我们的团队非常小：一个办公室有3名开发人员，隔壁办公室有业主。但即使如此，我还是说大多数决定都是在整个团队中讨论的，最终大的决定由业主决定。它效果很好。但我认为根据团队规模以及决策对业务的重要程度来调整决策过程是有意义的。在大多数情况下，小团队的决策更容易。

Answer 6

总结到目前为止的答案 - 对于任何团队而言，决策过程必须在时效性和准确性之间取得平衡。任何团队需要：

• 做出正确的决定 - 就潜在的错误，维护难度，满足要求的能力，关注任何其他流程的能力，质量，安全等问题而言。
• 为了做出一致/沟通良好的决定 - 几乎总是如此，在一个地方做出单向决策而在另一个地方做出另一种决定会带来一些非常痛苦的错误。这些可能是昂贵的错误，特别是在设计决策中。
• 做出及时的决定 - 经常，没有任何决定比错误的决定更糟糕。通常有两种不同的可行架构/设计。根据要求，可能会明显更好，但两者都可能是可行的。在这些情况下，即使做出错误的决定也比完全没有做出决定更好。

决策过程必须反映团队和公司的需求。我在这里见过很多种，甚至在同一家公司里面。因素包括：

• 团队规模 - 在团队成员超过3-5人后，您无法再作为一个群体做出决策。这是一个基于人的小群体限制。与5岁以上的人数进行有效会谈非常困难。如果你不能有效地谈话，你就无法做出共同的决定。在这里，有必要指定一些线索，让他们做出决定并对子团队做出贡献，除非可以在一个团队中做出决定。
• 团队经验 - 在只有极少数开发人员具有相关技术经验的团队中，将重大决策与技术专家隔离开来是有道理的开发人员有问题领域知识。这符合建筑师的想法。据推测，建筑师对技术和技术风险的理解要好于平均水平，并且他处于做出重大决策的最佳位置。如果每个开发人员都对该技术有一定程度的经验，那么这可能不是那么必要。
• 产品性质 - 例如，如果安全性是一个大问题，则可能需要一个单独的组，其唯一的角色是确定安全体系结构。这个区域可以是一大块工作，单个人脑无法满足安全要求和常规功能要求。
• 正式流程的程度 - 支持关键应用程序或大型应用程序的公司在审核过程中可能会有一定程度的严谨性。就个人而言，我更喜欢“同行评审”，因为每个人都会审视一个人做出的决定。如果这些决定存在争议，最好在审核之前考虑其他一些沟通方式。
• 团队个性 - 不同的团队在不同的管理方式下工作得更好。我见过团队成员即使经过数月的合作也无法找到妥协的情况。在特定的时间范围内，“风暴，规范，整合，执行”的快乐团队理念并不总是可以实现的。在这些情况下，它将落在具有官方权力（如建筑师或经理）的高级人员身上做出决策，因为团队根本无法以任何其他方式做出决定。

我个人认为，当人们认为自己与决策有利害关系时，团队会更好地工作。当你坚信你已经掌握了你现在所处的重大决策时，更容易投入100％的努力。软件工程不是无人机工作，如果人们在没有承担决策责任的情况下继续工作，他们只做了一半的工作，因为他们不会在决策中寻找缺陷或制定计划来克服这些缺陷。

我还认为，如果你不能说服你（可能是理性的和聪明的）同事你的想法是好的，那么你可能错了。即使你是一切的经理/建筑师/神。如果你不能承认你可能是错的，你就没有掌权。如果你不相信你的同伴是理性和聪明的，那么是时候找一份新工作了。