很好地指出软件需求实际上是政治性的?[关闭]

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

如果您所处的环境中有不止一个人负责确定您实现的功能集,那么每个功能实际上都是这些人之间的协商。那次谈判使这些特征具有政治性。

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

我不是想说没有政治的发展环境是不可能的。它是。不过,我想说的是,要想实现这一目标,你需要:

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

如果你错过了这些事情中的任何一件,你就注定要经历一场办公室政治的反复洪流。

这真的有助于你了解吗?我的意思是-如果你已经卷入政治游戏,你无论如何都会知道的。如果你没有,那不是你能用的东西。

如果你无论如何都要实现这个特性的话,我会说,继续做吧。发现这是管理游戏的一部分只会让你失去动力。

也就是说,如果你正在开发应用程序,那么 中间件 你不知道这是一个真正的用户特性还是某种政治杠杆,那么这可能是一个安全的假设,即一切都是政治性的。

最好的办法是找出所有特性的用途,也就是说,不仅要找出一个特性是如何实现的,还要了解为什么要实现它。了解所需解决方案的背景非常有帮助。它甚至可以让你推荐一个更适合你的客户的替代功能集(甚至可以玩你自己的政治游戏)。

只要有什么你不懂的,就不要做这个项目。它只会在某一点上引起问题。

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

需求可能来自您的老板,但它可能是实际用户的有效需求。

以下是我看到的:

• 与其他要求直接矛盾
• 这在技术上显然不可行
• 它是“左外场”…它不适合定义的问题空间
• 它与常识相矛盾

当心…有时这是由于您的用例错误或不完整造成的。我还特意让其中一些产品进入开发阶段(例如,销售产品但无用的眼糖果,或者至少通常不被运营商使用)。

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

“应该用以下方式来做这个和那个”

虽然上面的句子描述了实现该特性所需的所有知识,但它并不能证明该特性是正确的。我的Scrum手册说,特性应该作为一个故事写下来。一个故事是这样的:

“作为<用户角色>”
我需要一个<功能>
以便我获得<业务价值>。

使用这样一个故事是不合理的,因此没有必要实际实现它。

例如。

“作为一个 门户网站访问者 我需要一条路 认证 所以我可以 访问我的客户数据,但没有其他人可以 “

现在,您不仅知道需要对您的Web门户进行身份验证,还知道谁需要它(访问者,基本上每个计划更密集地使用它的人),而且您还知道 为什么? 它是必需的,因为它给用户一些价值。

其他例子:

“作为一个 乘客 我需要 我所有预定行程的清单 ,这样 我知道我什么时候要去哪里旅行,而且不会丢失概述 “

“作为一个 记帐员 ,我想要 根据客户数据自动打印到每个账单上的增值税 ,这样 我不必每次打印账单时都手工输入 “

如果每个特性都需要这样写,您将自动看到某个特性是否适合客户,因为它确实是必要的,或者只是您的老板/公司想要的,以及为什么他们想要它(它背后的大局是什么?他们为什么要这么做?).

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

然而,

Never attribute to malice that which is adequately explained by stupidity.