DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集4.2 建模步骤A-4 建模待改进流程现状4.2.1 建模步骤A-4-1 定位要建模的待改进组织流程4.2.1.1 思路目标组织有很多流程建模人员需要根据愿景定位当前最值得建模的流程。这个流程应该符合以下条件*该流程现状表现不佳是愿景所涉及组织指标差的罪魁祸首*目标系统有能力改进该流程。这个思考应该不是从零开始。在之前推导愿景时建模人员会思考因果关系“这个问题的原因有哪些”甚至会画因果图来帮助推敲。此时可以借鉴之前的成果。4.2.1.2 AI辅助和第2章类似AI不方便对某个真实存在的具体组织例如案例的目标组织“软件开发个人组织马宝中”的真实流程现状给出评价但可以提交目标组织规格例如案例的目标组织规格“有冠军的心、认同《软件方法》的软件开发个人”以及愿景让AI给出参考意见。★“马宝中”可以看作某个真实存在的个人在书中的化名因此说“马宝中”真实是没问题的。提示词如下# 任务名称定位组织规格待改进的业务流程# 任务说明根据所输入的组织规格和愿景思考该组织规格会因为有哪些流程表现不佳而导致愿景所要改进的指标受影响。# 数据结构定义struct 待改进业务流程 {理由: string,流程名称: string,愿景影响程度排名: int}# 形参说明[输入形参]- 目标组织规格名称:一类组织的描述可以是机构组织例如“机械零部件生产车间”也可以是个人组织例如“大学生”。- 目标组织规格说明:对目标组织规格的详细描述用于区分可能会产生混淆的名称。这个参数可以留空。- 愿景:对某个组织的某个度量指标的改进期望。例如针对机械零部件生产车间有一个愿景“缩短订单的交付时间”。[输出形参]- 返回一个包含至少 3 个 “待改进业务流程” 对象的 JSON 数组。请且仅请输出纯 JSON 数组格式不要包含 json 等 Markdown 标记也不要输出任何前置或后置的问候语及解释说明。如有可能把流程名称写成动宾结构例如写“编制计划”不写“计划编制”。已经形成行业用语或习惯用语的不必强行修改成动宾结构。流程名称后面不用再加“流程”二字例如写“编制计划”不写“编制计划流程”。结果按愿景影响程度排名的属性值从低到高排序。影响程度越大愿景影响程度排名的属性值越低排序越靠前。# 示例[输入实参]目标组织规格名称 机械零部件生产车间目标组织规格说明 留空愿景 缩短订单的交付时间[输出实参][{理由: 如果生产作业排程做得不好工单排序、设备分配或工序时间安排不合理会造成关键设备空闲与拥堵并存、工序衔接等待和在制品积压导致交付时间变长。,流程名称: 生产作业排程,愿景影响程度排名: 1},{理由: 如果物料齐套检查做得不好缺料信息发现过晚会造成生产任务因等待原材料和零部件而停滞导致交付时间变长。,流程名称: 物料齐套检查,愿景影响程度排名: 2},{理由: 如果生产检验与不合格品处置做得不好质量问题发现过晚、不合格品处置时间过长或返工流程效率低会造成重复加工和等待时间增加导致交付时间变长。,流程名称: 生产检验与不合格品处置,愿景影响程度排名: 3},]# 本次执行[输入实参]目标组织规格名称 ******目标组织规格说明 ******愿景 ******我们把前面“Fagao智能需求和设计建模工具”的建模结果填入[输入实参]目标组织规格名称有冠军的心、认同《软件方法》的软件开发个人目标组织规格说明冠军的心意思是软件开发个人有雄心壮志让自己所开发的软件聚焦于某个领域并成为该领域的冠军《软件方法》是潘加宇所写的一本关于软件需求和设计方法学的书。愿景减少在使用《软件方法》建模时花在工具操作上的时间。Gemini 3.1 Pro的反馈如图4-25图4-25 Gemini 3.1 Pro关于Fagao案例的反馈得到的待改进流程和我这个《软件方法》的作者所判断的差别较大。原因是AI没有掌握《软件方法》书中的内容最多是了解该书的一些介绍。它不知道熟悉《软件方法》的软件开发组织在工具上有哪些困扰只能按常见的软件开发组织来推测。★AI没有掌握《软件方法》书中的内容——得出这样的判断并非因为AI的反馈和预想差别较大而是我从其他多个对话中总结的而且我是《软件方法》的专家。在这里强调这一点意思是当出现AI的反馈和预想差别较大的情况时不能武断地认为AI错了。我们把[输入实参]换成一个AI可能比较熟悉的领域目标组织规格名称 城中村自建房房东愿景 减少花在收租上的时间Gemini 3.1 Pro的反馈如图4-26图4-26 Gemini 3.1 Pro关于城中村房东收租的反馈涉及熟悉的领域AI的回答看起来就靠谱很多。如果让AI先学习《软件方法》及相关资料再来做前面关于Fagao的提问相信AI的回答也会靠谱很多。AI只是在组织规格的层面给出一些参考意见针对具体的目标组织最佳答案可能会有不同。不过由于有愿景的约束在AI熟悉的领域回答还是很有参考价值的。医生面对一位60岁的男性患者马宝山要解决他“慢性持续性咳嗽”的问题于是问AI“60岁男性患者伴慢性持续性咳嗽请提供鉴别诊断思路及常见病因”由于有“慢性持续性咳嗽”的约束AI的回答还是很有参考价值的。如果只是问“60岁男性患者会有什么病回答的范围就大了去了。★为了帮助理解本章会在多个地方使用“医生为患者诊疗”的场景来类比。建模人员相当于医生被建模的组织相当于患者。4.2.2 建模步骤A-4-2 建模待改进流程现状4.2.2.1 现状的时间“现状”的意思就是当前的状况。假如现在暂且称为时间T1目标组织的业务流程发生建模人员亲临现场会观察到什么把观察所得如实绘制成业务序列图就得到了待改进流程现状的业务序列图。这时候得到的是T1的组织流程现状。接下来建模人员会在此基础上推导目标系统的需求并实现然后在时间T2将目标系统引入该流程。在T1到T2这段时间内受到其他因素影响待改进流程的现状可能有变化不一定是改进。这些变化是被排除在建模推导过程之外的。用“医生为患者诊疗”类比患者做完检查后病情不是就此乖乖地保持停滞静等医生来处置而是受很多其他因素影响。在医生开始治疗患者时患者的情况可能已经偏离之前的检查结果。即使让检查时间尽量靠近治疗时间也不能保证没有变化。组织流程的现状也是如此这是必须接受的事实。建模人员可以注意缩短A到B的时间间隔但也不用追求完全无变化。在上一步建模人员定位最值得先改进的业务流程先建模该流程的现状。这就已经缩短了T1到T2之间的时间间隔减少了可能的变化。如果因此出现问题可以在下一次迭代出现业务建模工作流时再解决。4.2.2.2 现状的真实在接受时间差带来的误差的前提下建模人员要尽力描绘出目标组织真实的现状接下来在此基础上改进才有可能得到【最】符合现状需要的、【最】有竞争力的改进方案。关于这一点很多建模人员认识不足。有的人觉得即使不是在目标组织的真实现状上改进得到的改进方案也会让目标组织受益。注意到【也】字了吗这个字一出第2章所做的工作就白费了——当初还费那劲干嘛还不如拍脑袋“敏捷试错”呢。用“医生为患者诊疗”类比医生用第2章的思考辛辛苦苦定位了一名“最佳患者”结果他的猪队友却拿了同一天来看诊的另一名患者的检查和检验报告给医生看。后续发现了问题猪队友还振振有词你看你开的处方里面某某药不【也】给该患者带来改善了吗问题是之前的期望是用这个“最佳患者”做出90分甚至100分的成绩——【最】现在只有60分了——【也】。★观察伪创新卖家和买家的言论类似这样不知道柴米油盐贵的内容比比皆是。需要稍为辛苦思考的内容伪创新圈子往往会避之不及或者想方设法用他们的“创新”来代替。为了在这一步不轻易滑坡建模人员甚至应当在心里暗暗发誓如果我不尽力去靠近真实现状天打雷劈4.2.2.3 偏离真实现状的错误一把现状误解为“纯手工”