做任何事情都应该有个标准，不符合标准就不应该做。

比如现在我们的需求已经有一个标准了，这个标准就是黎叔，具体来说可以细化成：

1. 黎叔看不懂的不能做
2. 黎叔想不清楚的不能做
3. 黎叔觉得太复杂的不能做

总体来说，有这个标准比没有这个标准要好很多，BA们为了达到这个标准，会花更多的时间、精力和讨论来思考自己的解决方案和书面表达，比如支持一个TS多个Job这个需求，黎叔就让总是让我再想想再想想，我现在觉得这是对的，对于复杂的需求，BA要花足时间自己想并且花足时间和其他BA讨论，否则给出的解决方案肯定不是最好最简单的。

这个需求标准的实践是否可以应用到design review和code review上，需要有一个或多个人看所有的设计是否满足标准，需要有一个或多个人看所有的代码是否满足标准，不满足标准是不能继续往下做的。

除了工作中要有标准，生活里也要有标准，比如你给你的小孩报了一个学习班，你如何检验你的小孩是否达到了标准，你如何帮助你的小孩达到标准？

知易行难，最难的地方在于我们缺少一个像黎叔这样的人来愿意付出额外的时间和精力去维护这个标准。我决定从下周开始看回顾日志，不符合标准的要打回去重新回顾。