一般在讨论之前，有一个准备过程，每个人都会拿到自己对应的文档，分析自己这一块存在的问题。从编码人员开始，考虑的总是如何去实现，所有提的问题都应当为这个目的服务。那么要确保编码的时候没有问题，之前要怎样做呢？自然是在编码之前脑袋里已经编过一次了。这个时候写代码还早，程序的流程走通就需要其他工具来辅助了，Visio也好，Word也好，UML工具也好，只要顺手的兵器拿来用就行了。这也是我的一个深切体会，从一个新手到一个经验丰富的人，中间一定要有工具来辅助。人类现在的能力越来越强，从石器时代就明白一个道理，制造工具并利用工具，使能力无限延伸。
首先将流程图画好，Scope画清楚，这时候就开始尝试将内部逻辑走通了。先按照正常流程走一遍，所有的问题都记录下来，再考虑一些异常的情况，再记录碰到的问题。如果有些详细的东西不够清楚，尽早请教比你清楚的人，并征求他们的意见，很多情况下提不出问题是因为自己对这个不了解。内部逻辑走通后，再考虑外部和自己模块打交道的模块进出参数的问题，和他们讨论好方案，并有邮件记录最后的结果。当自己认为这里的问题都理清楚了，那将Scope再扩大一点，其实也是尝试把自己的能力扩大点，多有整体观会给工作上带来很大的好处。
这时候所有Scope的人一起讨论时，就会有一些重要的问题问了。但一个人的思维是有局限性的，也许你想都没想过的问题，在讨论时有人提出来，那就仔细听，仔细想对策了，如果想不到，问组织者怎么解决。经过几次这样的训练后，就会知道公司的产品关注些什么，哪些问题才需要仔细的解决。也要学会问一些经典的问题，比如产品的瓶颈在哪里，性能如何等等，如同面试的时候经典问题：你为什么离开上一家公司。
等到这一步熟练后，慢慢将自己的角色和Scope放大，从编码角度，从设计角度，从质量角度，从安全角度，从市场角度等等多考虑。如果哪一天从每一个角度都能提出很专业的问题，就说明在这个角度的积累深度。我们以前的读书环境并不提倡一天到晚问问题，但工作里不提问题就是和自己过不去，有些问题可能对专业人士来说是很浅显的，但不知道一定要问到知道为止。也许哪一天和最高级的老大开会的时候，你问问题的全面性以及逻辑的严密性引起了他的兴趣，那恭喜你，机会来了。