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 偏离真实现状的错误一：把现状误解为“纯手工”
