project-management - 在您的软件开发周期中是如何做出决策的？

Question

我相信只有在团队例外和同意的情况下才应该做出软件决策。但大多数情况会有所不同。

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

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

你怎么看？

Answer 1

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

Answer 2

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

我的上一个项目有大约 8 名团队成员同时处理代码，因此每项任务都非常细粒度，每个人只影响他们正在处理的少量代码，我们不断进行代码审查以确保我们的更改与项目的整体方案“契合”。

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

Answer 3

必须有人做出最终决定。有时（经常）团队中的每个人都不会就某事达成一致。一个好的团队将有一个“止步于此”的人来处理没有达成共识或犹豫不决的决定。很多时候，我被要求成为那个人。我将大部分决策委托给我信任的团队领导，但有时，码头无法就方向达成一致。我已经为公司制定了架构指南并执行了它。我利用每个团队成员的意见、指导和我的判断来打破僵局。我不会说它是专制的，但它也不是一个完全的民主。

Answer 4

最坏的情况是，这是一种无政府状态。

在大型项目的规划阶段，我们与业务分析师坐下来进行一些问答环节，撰写规范草案，并与主题专家讨论业务需求的细节。然后，我们的团队草拟设计文档和流程的草稿。

在此后的某个时候，所有的地狱都破裂了。企业看到初始版本并突然意识到要么它没有说明它要求什么，要么我们没有说明他们要求什么，或者他们一开始就不知道他们要求什么。测试人员应该花在测试上的时间反而花在了开发人员的重构上，马虎。

最初是一个粗略但可能相对优雅的解决方案变成了一堆注释掉的代码，其中包含奇怪和不稳定的变通办法和填充程序，这挑战了每个人的能力，以防止自己的堆栈溢出关于在什么情况下适用什么变通办法的心理笔记代码。

时间被浪费了，人们感到压力很大，而且不可避免地会在测试中发现更多必须解决的问题。最终它会变得像《乐一通》中的东西，厨房用具、船桨、人和远洋班轮的大杂烩都堆叠在一起，不稳定地相互平衡（有点像那个花时间平衡岩石的奇怪艺术家相互叠加）。

关于你朋友的评论，我认为这种领导风格很好，只要那个人愿意与团队讨论。经理之所以是经理，部分原因是他们管理得很好（希望如此），如果他们的代码也很好，那是一种奖励，但如果不是，他们需要接受团队中比他们更精明的人的建议。如果做不到这一点，总会有一个后备立场，可以引用为“无论我工作聪明还是愚蠢，我得到的报酬都是一样的”。

Answer 5

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

Answer 6

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

• 做出正确的决定——就潜在的错误、维护的困难、满足要求的能力、遵守任何其他流程的能力、质量、安全性等问题而言。
• 为了做出一致/沟通良好的决定- 几乎总是，在一个地方以一种方式做出决定，在不同的地方以另一种方式做出决定会引入一些非常痛苦的错误。这些可能是代价高昂的错误，尤其是在设计决策中。
• 做出及时的决定——很多时候，没有任何决定比错误的决定更糟糕。通常有两种不同的可行架构/设计。考虑到要求，一个可能明显更好，但两者都可能是可行的。在这些情况下，即使做出错误的决定也比完全不做决定要好。

决策过程必须反映团队和公司的需求。我在这里看到了相当多的变化，即使在同一家公司内也是如此。因素包括：

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

我个人认为，当人们觉得他们与决策有利害关系时，团队会更好地工作。当您坚信自己参与了现在陷入困境的重大决策时，投入 100% 的努力会容易得多。软件工程不是无人驾驶的工作，如果人们在不为决策负责的情况下步履维艰，他们只会做一半的工作，因为他们不会寻找决策中的缺陷或制定克服这些缺陷的计划。

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