关于How,刷墙和亲戚

对于需求而言,最宏观的概念是六字诀:

Who->Where->Which->How->End->Effect;谁(Who)在什么地方(Where),对那个对象(Which)做了什么(How),做完了(End),影响是什么(Effect);

在How上面要做的文章是最多的,How其实本质就是场景,操作,数据(对象)。

刷墙

只要是被操作的数据就需要考虑是否需要添加状态,比如IMS审批从NPIOT系统中抽调的数据就需要考虑是否需要加状态,防止审批期间物料被移动;不加状态,就代表着,操作本身不具有数据"加锁"性或者"刷墙性"(狗撒尿性,数据刷一层油标记),比如简单的查询看结果;但是一旦被刷墙了,就要考虑是否需要再刷回去。

覆盖刷墙

需求的任何操作都要考虑一个"数据冲突问题"(是否破坏了人家安静的生活),现有的操作是否会导致信息冲突,比如数据导入,如果导入图纸,重复了怎么处理,怎么来判定处理;IMS审批的数据也是这个歌道理,你要考虑到如果别的数据动用了你操作的数据是否可以?两个方向考虑问题:你的动作是否导致了别的数据的冲突(导入);你的动作"维护的"数据是否导致了别的数据冲突(IMS审批);

冲突问题的本质就是刷墙,本来数据已经被人刷墙了,结果你又刷了一遍,如果你的优先级就是高或者就是要覆盖性的刷墙,没问题;但是如果没有权限去覆盖或者不确定,你就要考虑是否是要用户来判断,或者新添加一个字段(墙,用来刷)来标识;

亲戚关系

每创建一条数据的时候,都要捋清一个问题,他和"近亲"数据的关系(比如WAS单预留项和需求的关系,WAS单预留项和WAS单的关系); 八竿子打不到的亲戚就不要管了,我们只管"近亲"的。

外一篇 When:场景集市

When的概念有两个,一个是出发需求的时间点,另外一个就是场景(外景);考虑需求"支撑"一定要把支撑的场景想全了,比如发放控制,需要跟踪需求的预留量,支撑场景一是精确预留,每一个需求,会精确到一条UP记录;但是还有场景二,费精确预留,所以客户有一个需求,一定会有一个场景集市来做做支持,一定要把场景集市都考虑清楚了;比如Peter之前就有一种思想:把所有的物料类型都过一遍,以确定所有的场景,我们设计的需求流程图都走得通,很多时候可能就是某一类物料(关联的内容和约束不一样)就走不通了,这个时候需要考虑一下。

posted on 2015-02-11 18:25  下士闻道  阅读(176)  评论(0编辑  收藏  举报

导航