系统设计方法论2-找出主干点明关键

系统设计方法论2-找出主干点明关键

通过使用上一篇文章介绍的方法，将需求分析完成之后，下一步去做什么？

直接进行详细设计，然后再去开发？

No！

中国有一句古话：谋事在人成事在天。

那么，在实际工作中，“天”指谁？

其实可以换一种表述方式，谁是对你的项目影响最大的人？

谁是你的直接负责人？

这个时候，应该出一版概要方案设计，汇报沟通。

寻求支持、确认。

很明显，给领导层汇报，不会有时间有精力看你的细节。

所以，此次汇报的内容，可以理解为更精简的概要设计。

领导只会关注定位、策略、思路，以及实施路径，还有风险考量。

关于项目的定位、实施路径、风险考量方面的事情，是项目经理的工作，系统设计师可以不用考虑。

具体的办法见另外一篇项目管理的文章。

1

主干视角

这一次的设计方案，首先要点明的是，就是系统设计的主逻辑线。

因为，任何一个产品，不管旁枝末节多么复杂，总归有一条主线把所有内容串联起来。

所以，系统设计上来就要找到主干。

汇报的时候，更是要开宗明义，点明主线。

否则你应用的技术再精巧、考虑的再细致，都只会让领导皱眉头。

除非是不懂行的领导。

一般情况下，所有领导都是过来人，从内心就知道一个系统设计，如果逻辑清晰，交互明确，基本上就成了大半。

因为通过汇报表述，也能体现设计人员的思维清晰程度。

反之，如果舍本逐末，上来就去考虑精巧的实现，反而会有很大的风险。

其实这也是一个汇报的技巧。

除非你准备忽悠人，否则一定要有逻辑条理，尽量的清晰简练。

不要将繁杂的细节展露出来。

或者说，不要炫技。

一个脱敏后的例子：

一个业务系统功能模块，需要填写完成了信息之后，自动生成4个待办任务，其中2个子任务完成之后，才能流转到下一岗位进行审批处理。

这个功能的汇报，重点展现什么？

难道上来就从技术上来讲，考虑到扩展性，待办任务设计成支持无数个？

或者，目前是以2个子任务完成为判断条件，我们进行了技术上的精巧处理，后续假设需要判断3个子任务完成后，直接通过参数化配置即可？

这些是亮点吗？是。

是主干吗？不是。

这些都是锦上添花的东西。

重要的是花吗？

不，是锦。

应该点明主干，就是以填写的**“主信息”**为主体，生成多个子任务，然后以“主信息”为主题进行流转下一岗。

如果画图的话，都要体现出来**“主信息”**的核心主题地位，以及整个处理设计逻辑流程，都是以主信息的视角来开展。

2

关键点

在找到主干以后，才是去点明关键点的好时机。

如果说主逻辑处理流程，给领导了信心，保证了系统不跑偏。

那么接下来，就是点明关键点的时候。

但是，现在仍然不是强调技术亮点的时候。

这个时候，应更体现出来的关键点，指的是几个功能之间的交互逻辑，总分关系，流转状态转换等方面内容。

“关键点”可以理解为是业务方面的处理关键里程碑。

具体可以从如下几个方面考虑：

总分逻辑

还是以主流程信息为主干，说明在此主干下有多少分支。

并且，每个分支的划分逻辑是什么，如此划分的必要性。

转态转换

尤其是主干，有哪些转态，分别对应哪些业务逻辑里程碑？

达到骂个转态的前置条件是什么，后续动作是什么？

交互逻辑

各个分支之间的关系是什么？

或者说，子任务之间的交互逻辑是什么？

这样，就能将粗粒度逻辑处理流程整体展示出来了。

3

补充点

可以看到，整个过程，实际上仍然是一个设计人员自我逻辑梳理的过程。

非常遗憾的是，除非你所在的公司业务部门，是一个技术驱动中心，否则的话，很多公司的领导根本不会过于重视技术。

嗯，这么说比较委婉了。

可以直接点：根本不重视技术。

我曾经不止一次的从某些技术负责人、高层领导口中听到过：技术不重要！

这就是他们的态度。

业务交付才是重中之重。

所以，在汇报的时候，要站在领导的角度，汇报他们关心的东西。

当然，在汇报结束后，如果看到领导比较满意，可以补充汇报体现你自己的技术思考、应用的NB技术。

作为锦上添花的亮点。

如果汇报时，已经被否定的较多了，就不要再说技术亮点了。

一般情况下，会让领导越来越烦躁。