今天讨论的一个话题挺有趣的，产品设计之初，应该造火箭还是螺丝钉？
言论类似于，“做态势感知，别想啥APT啥啥啥的，没用，先做能检测出来的，比如从流量里面检测SQL注入、XSS检测，这样就好了，之后想到的再加”。
个人认为，产品设计之初，应该知道这个东西是火箭，有一个完整的想法，关于这个产品到后期到成熟期应该是什么样子的想法。你觉得你设计的这个产品是优秀的吗？什么是你认为的优秀？能够跟得上业内的知名产品甚至超越么？
还是本来要造火箭的、只想造一个磕磕巴巴的推进舱再带上两个降落伞也能勉勉强强完成功能，用于充业绩呢？
理想的做法是，在产品的设计预想之初，就把产品的全态想清楚，怎么是一个能够兜得住后期需求的产品。这个全貌设计，应该忽略掉人力、现有场景的局限。
固然，现在只想检测SQL注入、XSS，那么，如果上头给补充了人数，给多了10个20个开发，甚至要什么有什么，要RD有RD，FE、QA都拉出一个团队来，来造这个小小的流量检测注入和XSS的产品么？
你能不能把他们的事儿给填满？如果不能填满，那么意味着，产品开发完一个阶段以后，不断的继续调研，继续思考要做什么，这是一个走一步看一步的产品。
在有了全貌的设计后，根据现在遇到的问题，从中挑选优先级最高的场景来实现。
数据源最终需要挺多，现在不做，但得知道有这么个东西，条件满足了就能做。
引擎有很多类，满足现在需求的就这几个分析引擎就好了，但得知道，以后添加其他场景，得添加别的引擎，否则走一步看一步的添加引擎，会导致在框架固定的情况下不停重构。
抽象出的规则和特征，如果在设计之初只想到规则，在某个迭代版本上想加特征，意味着大规模的推倒重建。
设计了几类告警，只想到了用于查询，之后的告警阻断、高危且确定被利用的告警发工单、低危告警不展示仅查询这些功能，再相加就得看看当初有没有预留的口子了。没有预留的口子，要不就是强行加上去，代码流程有点畸形；要不就是为了代码可读性可扩展性解耦性，继续推倒部分代码重建。再厉害的RD，也没法说在需求简简陋陋模棱两可的情况下，考虑到各方面的可扩展性吧。
所以产品设计之初，想完善；开始开发设计阶段，根据优先级抽取需求交给开发流程。
可能有的需求设计了，实在是优先级太低、成本太高，就无限期的放下。