project-management - 软件需求实际上是政治性的好指针？

Question

可能是一个简单的：

是否有任何经验法则或提示可以帮助识别政治要求？

假设一个利益相关者（您的老板、另一个部门的负责人或实际用户）要求您或您的团队正在开发的软件的功能或特定特征。是否有确定要求是否具有政治性的试金石？

这个问题真的很简单，不是关于如何处理政治要求或者它们对软件是好是坏。你怎么知道无论你被要求做什么都是为了追求某人的默许或实际上公开声明的政治议程？

Answer 1

它真的会帮助你知道吗？我的意思是——如果你已经卷入了政治游戏，无论如何你都会知道的。如果你不是，它不是你可以使用的东西。

如果您无论如何都必须实现该功能，我会说继续使用它。发现它是一些管理游戏的一部分只会让你失去动力。

也就是说 - 如果您正在开发的应用程序是如此的软件以至于您无法判断它是真正的用户功能还是某种政治杠杆，那么它可能是一个安全的假设，一切都是政治的。

Answer 2

最好的办法是找出所有特征的用途，即不仅要找出一个特征是如何实现的，还要了解为什么要这样做。了解所需解决方案的背景确实很有帮助。它甚至可以让您建议更适合您的客户的替代功能集（甚至可以玩您自己的政治游戏）。

只要有什么你不明白的，就不要做这个项目。它只会在某些时候引起问题。

Answer 3

我想说你应该假设所有要求都是政治性的。

如果您处于一个多人负责确定您实现的功能集的情况，那么每个功能实际上都是这些人之间的协商。那次谈判使这些特征具有政治性。

然而，即使只有一个人来决定发布哪些功能，这些决定仍然很有可能是政治性的。在任何规模合理的组织中（比如十个人以上），你都会有政治。这种情况下的政治将不同于“委员会设计的情况”。他们将专注于讨好决定发布哪些功能的人，而不是委员会场景中存在的“如果你支持我的功能，我会支持你的”。然而，这一过程仍然是政治性的。

我并不是说不可能有一个没有政治的发展环境。这是。但是，我会说要实现它，您需要：

1. 一个小而紧密的团队
2. 一个专注于创造一个培养创造力的环境的老板，并委派创意所有权，而不是专注于控制创意过程。
3. 聪明、才华横溢、富有创造力的人，具有强烈的使命感和审美价值观。

缺少其中任何一项，你就注定会陷入重复的办公室政治泛滥。

Answer 4

显然这是一个棘手的问题，很大程度上取决于你对“政治”的定义。我将从一个简单的问题开始： * 需求的作者/发起者是否真的在使用相关软件？

需求可能来自你的老板，但它可能是真实用户的翻译有效需求

Answer 5

以下是我见过的一些：

• 它直接与其他要求相矛盾
• 技术上显然不可行
• 它是“在左边的领域”......它不适合定义的问题空间
• 违背常识

当心...有时这是由于您的用例错误或不完整造成的。我还特意允许其中一些进行开发（例如，销售产品但无用或至少通常不被运营商使用的 Eye-candy）。

Answer 6

使用 SCRUM 方法。不要将功能描述为

“它应该以下列方式做这个和那个”

虽然上面的句子描述了实现该功能所需的所有知识，但它并不能证明该功能的合理性。我的 SCRUM 书说功能应该写成故事。一个故事是这样的：

“作为 <user-role>
我需要一个 <functionality>
以便获得 <business value>”

使用这样的故事无法证明的功能是不合理的功能，因此实际实现它是没有用的。

例如

“作为门户网站的访问者，我需要一种身份验证方法，以便我可以访问我的客户数据，但其他人无法访问”

现在您不仅知道您需要对您的门户网站进行身份验证，您还知道谁需要它（访问者，基本上每个人都计划更深入地使用它）并且您还知道为什么需要它，因为它为用户提供了一些价值。

其他示例：

“作为一名乘客，我需要一份我所有预订旅程的清单，以便我知道我什么时候要去哪里旅行，并且不会丢失概览”

“作为一名簿记员，我希望根据客户数据将销售税自动打印到每张账单上，这样我就不必每次打印账单时都手动输入”

如果每个功能都需要这样编写，您将自动查看某个功能是否适合客户，因为它确实是必要的，或者只是您的老板/公司想要拥有的东西以及他们想要拥有它的原因（什么是背后的大局？他们为什么要这样做？）。

Answer 7

使用模棱两可的词或短语通常是政治性的。

然而，

永远不要把可以用愚蠢充分解释的事情归咎于恶意。