TengFan 2019-2-15 11:10:
老師，您在書上說開發團隊不是涉衆，但我發現像我們做的系統，如果需求考慮不周，在規則上有漏洞，被玩家鑽了空子，我們公司可能會有大損失。這種情況下，可不可以認為開發團隊也是涉衆呢？
UMLChina潘加宇：
業務模組化和需求工作流之前，可以認為"開發團隊"不存在，更不用說是涉衆了。
針對剛才的叙述:
首先不能糊塗地說"我們"、"我們公司"。
"甲方"、"乙方"、"客戶"這些不嚴謹的詞彙，《軟體方法》都不推薦在模組化中使用，用的是"目标組織"。當然，不妨礙在其他行政用途的媒體中使用。
可以用"團滅法"思考一下：這個系統不用開發了，三體人免費提供一模一樣的系統。然後，在不影響系統所參與的流程的情況下，三體人通過智子和水滴配合精确定位，把"系統不用開發了"帶來的備援人員全部殺光，哪些人還能活下來？那些活下來的人是涉衆，被殺掉的不是。
舉例，某電商公司，三體人義務提供"這個系統"。營運部的人不能殺，因為流程需要他們，而研發部的人可以殺。不過也有可能在研發部裡面，有人不能殺。可能目前系統有這樣一種用法，當營運部需要做某種複雜報表的時候，需要研發部的某個崗位幫忙做（系統不夠聰明，那也沒辦法，三體人隻提供一樣的系統），那麼這個崗位的人不能殺，不過可以把他大腦裡面的其他不相關知識（例如編碼知識）洗掉。
《軟體方法》下（第8章）也說了：
随着資訊化的深入，組織内部封裝在軟體（即業務實體）中的領域邏輯比例越來越大，深度越來越深，組織之間的競争越來越依賴于軟體的競争。市場的激烈競争，又使得組織越來越聚焦于一個領域，為組織提供軟體的軟體組織也越來越專注于一個領域，甚至逐漸成為組織裡的一個部門。将來，獨立的軟體組織也許将不複存在，或者說，所有組織都是軟體組織。從目前的趨勢看，軟體的運作形态越來越"網際網路化"，說"所有組織都是網際網路組織"也可以。
在名字不帶"軟體"的組織裡工作的軟體開發人員比例會越來越大，也就是說，上圖右側的情況會越來越多。這時，更要理清楚各自扮演的角色，不能以"我們公司"籠統稱呼之。
這個問題可以推到極緻，我給我自己做一個系統，怎麼做業務模組化和需求？