DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
第五元素 2023-10-27 22:02
潘老师，请教一个实践中遇到的问题：
假设生产人员使用某个工具处理数据，需要10天时间；现在改进了这个工具，0.5天就完成了。那这个属于哪个类型的改进呢？改进了哪些内容呢？似乎改进前后业务流程并没有什么变化啊？
UMLChina潘加宇
如果某个东西是需求，那么它的推导来源应该是业务建模——改进某个人群或机构的问题。
这里面有一个很多开发人员经常有的思维幼稚，以为“改进了这个工具，0.5天就完成了”这个是从天上掉下来的。
事实上，“改进了这个工具，0.5天就完成了”可能只是拍脑袋想到的改进结果之一。它需要通过以下这些问题的考验才能证明是正确的。
（1）老大认为“需要10天时间”是当前最值得解决的问题吗？
——也许品牌主打的就是一个“慢工出细活”，那些急吼吼的客户不是目标客户？
——能不能用“敏捷迭代，小步前进，摸石头过河”给客户洗洗脑，干完0.5天，先给他们交付5%，干完0.5天，先给他们交付5%……
（2）如果（1）的回答为是，“0.5天就完成”合理吗？
—2天可以吗？1天可以吗？
（3）如果（2）的回答是“0.5天就完成”合理，一定要通过“改进这个工具”达到吗？
——也许“需要10天时间”的原因有下面这些（还可以往下画，但节约时间就不画了，大家自行脑补）：
如果造成“需要10天”的最大原因是①，那么可能要建模招聘或培训的流程，看这些不合格的人怎么到岗位上的。如果需要通过信息化解决，“新的系统”的功能可能和培训员工相关。
不通过信息化解决也行：可以挑几个人毙了；可以给做得好的发一百万奖金；可以买20套工具，20个生产人员一起干；可以24小时三班倒不停歇地干……；
如果造成“需要10天”的最大原因是②，那么可能要建模采集数据的流程。如果需要通过信息化解决，“新的系统”的功能可能和采集数据相关。
不通过信息化解决也行：仿照上面①。
如果造成“需要10天”的最大原因是③，那么可以观察一名善于利用现有简陋工具干出好成绩的的老司机生产人员，建模他大脑里的逻辑。如果需要通过信息化解决，“新的系统”的功能可能和处理数据相关——这个才比较接近一开始拍脑袋的想象，即把数据处理工具改进到新版本。
还有一个不得不回答的问题，这个想象中的新版本能做得出来吗？
伪创新警告！
有的伪创新会迎合某些不知道柴米油盐贵的开发人员，鼓动：干就是了，先做出来投入市场试错！
于是开发人员摩拳擦掌，跃跃欲试，迫不及待要进入自己的舒适区，而且一下子工作量就饱满了，感觉对得起自己的薪水。
jeri 2023-11-06 12:28
潘老师，这个是否从书上用例的定义也能解释，这个系统用例是原来存在了，当时用例的质量需求写的响应时间1小时，那为什么是一小时，不是1秒，需要付出的代价是不同的，用例是买卖的平衡点，如果在当前形势下，1秒才能胜出，客户才买单，那就要做成1秒。
UMLChina潘加宇
同上。
怎么知道“在当前形势下，1秒才能胜出，客户才买单”呢？
这可不能靠感觉或者哪个人说一声就行了，照样需要建模背后的组织流程来找到证据。
如果一说就行，“客户”多半是狮子大张口，越快越好，1毫秒更好！
但如果去观察具体业务流程，会发现各个场景下“客户”能接受而且系统也能满足的最佳时间，这个时间往往是经过权衡和对比得到的。
