[答疑]可不可以认为开发团队也是涉众呢
TengFan 2019-2-15 11:10:
老师,您在书上说开发团队不是涉众,但我发现像我们做的系统,如果需求考虑不周,在规则上有漏洞,被玩家钻了空子,我们公司可能会有大损失。这种情况下,可不可以认为开发团队也是涉众呢?
UMLChina潘加宇:
业务建模和需求工作流之前,可以认为"开发团队"不存在,更不用说是涉众了。
针对刚才的叙述:
首先不能糊涂地说"我们"、"我们公司"。
"甲方"、"乙方"、"客户"这些不严谨的词汇,《软件方法》都不推荐在建模中使用,用的是"目标组织"。当然,不妨碍在其他行政用途的介质中使用。
可以用"团灭法"思考一下:这个系统不用开发了,三体人免费提供一模一样的系统。然后,在不影响系统所参与的流程的情况下,三体人通过智子和水滴配合精确定位,把"系统不用开发了"带来的冗余人员全部杀光,哪些人还能活下来?那些活下来的人是涉众,被杀掉的不是。
举例,某电商公司,三体人义务提供"这个系统"。运营部的人不能杀,因为流程需要他们,而研发部的人可以杀。不过也有可能在研发部里面,有人不能杀。可能目前系统有这样一种用法,当运营部需要做某种复杂报表的时候,需要研发部的某个岗位帮忙做(系统不够聪明,那也没办法,三体人只提供一样的系统),那么这个岗位的人不能杀,不过可以把他大脑里面的其他不相关知识(例如编码知识)洗掉。
《软件方法》下(第8章)也说了:
随着信息化的深入,组织内部封装在软件(即业务实体)中的领域逻辑比例越来越大,深度越来越深,组织之间的竞争越来越依赖于软件的竞争。市场的激烈竞争,又使得组织越来越聚焦于一个领域,为组织提供软件的软件组织也越来越专注于一个领域,甚至逐渐成为组织里的一个部门。将来,独立的软件组织也许将不复存在,或者说,所有组织都是软件组织。从当前的趋势看,软件的运行形态越来越"互联网化",说"所有组织都是互联网组织"也可以。
在名字不带"软件"的组织里工作的软件开发人员比例会越来越大,也就是说,上图右侧的情况会越来越多。这时,更要理清楚各自扮演的角色,不能以"我们公司"笼统称呼之。
这个问题可以推到极致,我给我自己做一个系统,怎么做业务建模和需求?
这个和医生给自己看病一样,要把"医生"和"病人"的角色分清楚。把"医生"那个我杀掉,变成三体人给我做一个系统。我代表的什么人群?白领?丈夫?父亲?最想解决什么麻烦……如果受过训练,后面的做法大家应该都知道了。
===广告分隔线===
| ||||||||||||||||||||
[训练介绍] 软件开发中,需求是解决“产品怎样好卖”的问题,设计是解决“降低生产成本”的问题。二者相辅相成,缺一不可。而且,不能相互取代。要迈向“低成本制造好卖的产品”的境界,并非喊喊口号就能达到,需要静下心来,学习和实践各种技能。 在这个强调“做减法”的时代,建模是正确帮助您“做减法”的绝佳工具。 本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。 本训练对每个开发工作流,结合讲解、做练习巩固、应用到实际项目三种方式,展示使用UML2.5相关技能开发软件系统的全过程,解答实际应用中的疑难细节问题。 [学员要求] 有一年以上项目经验的需求或设计(编码)人员。不需要您有“UML基础”,只需要您有项目经验。欢迎学员携带自己的项目来听课,由专家在现场进行剖析。 [专家] UMLChina首席专家 潘加宇。在1999年还是一名程序员时,利用业余时间创建了UMLChina,潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务,到现在为止,已经上门为超过280家的软件组织提供服务,覆盖了国内各个领域的领袖企业,包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。 [课程大纲] 1. 概论 以上时间分配会根据项目特点和训练进程调整。 |