TengFan 2019-2-15 11:10:

老师，您在书上说开发团队不是涉众，但我发现像我们做的系统，如果需求考虑不周，在规则上有漏洞，被玩家钻了空子，我们公司可能会有大损失。这种情况下，可不可以认为开发团队也是涉众呢？

UMLChina潘加宇：

业务建模和需求工作流之前，可以认为"开发团队"不存在，更不用说涉众了。

针对刚才的叙述:

首先不能糊涂地说"我们"、"我们公司"。

"甲方"、"乙方"、"客户"这些不严谨的词汇，《软件方法》都不推荐在建模中使用，用的是"目标组织"。当然，不妨碍在其他行政用途的介质中使用。

可以用"团灭法"思考一下：这个系统不用开发了，三体人免费提供一模一样的系统。然后，在不影响系统所参与的流程的情况下，三体人通过智子和水滴配合精确定位，把"系统不用开发了"带来的冗余人员全部杀光，哪些人还能活下来？那些活下来的人是涉众，被杀掉的不是。

举例，某电商公司，三体人义务提供"这个系统"。运营部的人不能杀，因为流程需要他们，而研发部的人可以杀。不过也有可能在研发部里面，有人不能杀。可能目前系统有这样一种用法，当运营部需要做某种复杂报表的时候，需要研发部的某个岗位帮忙做（系统不够聪明，那也没办法，三体人只提供一样的系统），那么这个岗位的人不能杀，不过可以把他大脑里面的其他不相关知识（例如编码知识）洗掉。

《软件方法》下（第8章）也说了：

随着信息化的深入，组织内部封装在软件（即业务实体）中的领域逻辑比例越来越大，深度越来越深，组织之间的竞争越来越依赖于软件的竞争。市场的激烈竞争，又使得组织越来越聚焦于一个领域，为组织提供软件的软件组织也越来越专注于一个领域，甚至逐渐成为组织里的一个部门。将来，独立的软件组织也许将不复存在，或者说，所有组织都是软件组织。从当前的趋势看，软件的运行形态越来越"互联网化"，说"所有组织都是互联网组织"也可以。

在名字不带"软件"的组织里工作的软件开发人员比例会越来越大，也就是说，上图右侧的情况会越来越多。这时，更要理清楚各自扮演的角色，不能以"我们公司"笼统称呼之。

这个问题可以推到极致，我给我自己做一个系统，怎么做业务建模和需求？

这个和医生给自己看病一样，要把"医生"和"病人"的角色分清楚。把"医生"那个我杀掉，变成三体人给我做一个系统。我代表的什么人群？白领？丈夫？父亲？最想解决什么麻烦……如果受过训练，后面的做法大家应该都知道了。