我们会在哪些地方耗费大量的时间
压缩需求确认时间的矛与盾
做项目的时候，一方面我们希望能够快速明确需求，开始投入开发，使产品能够尽快上线；另一方面，我们又深知需求会随着时间的推移越来越明确，就下意识的拖长这个流程。
需求细节的确认
需求应该确认到多细才合适？如何把握这个粒度？
方案优与劣的选择
这是最难的一个环节。目前仅靠个人经验和记忆力来做出判断，其实是很不保险的。因为有时候自己会不了解自己的局限性，给出的选择在另一方面就会出现问题。
外部接口的测试和沟通
需要注意两个地方：
第一是和其他部门沟通的方式：批量沟通+邮件交流+文明礼貌+严格自检
第二是自己这边，需要做好详尽的单元测试
程序框架、技术的选择
这个相对来说比较容易，只需要开发人员对于框架技术足够了解，知道其优劣，就能快速的做出选择。
搭建新项目的程序框架
直接拷贝已准备好的程序框架
新技术的学习
新项目，千万千万不要轻易尝试新技术。务必要在熟悉掌握之后，才将新技术加入正式项目中。
一些可以帮助明确需求和方案的方法
写分解文档
这个经过自己实践，是非常非常好的一个方法，在写分解文档的时候，你能拾遗补缺，发现细节上的问题，还能整理产品的流程，让自己思路更清晰。
如果是多人开发，那么建议每个人都写一个分解文档，然后汇总核对下，这样能发现很多被遗漏的东西。
讲出来
试想你是产品经理，将自己的理解，讲给产品经理听，或者讲给你的合作开发者听。讲述的过程，涉及语言文字的整理，同样会加深你对需求的理解。
设计数据库
这有助于理清楚数据结构和对象模型
名词定义
先定义好名词，能在交流的时候节省不少时间，这就像设计模式，一个词语就能包含很多信息。
一些常见问题
新事物
总之一句话：凡是涉及新事物，就必须谨慎考虑(新项目、新接口、新同事、新部门)
以新项目为例：
新项目的时间估算不能只看工作量，因为新项目还有很多其他的隐藏工作
比如方案设计、程序结构的设计、数据库的设计、和其他部门打交道等等
无中生有比优化改进要费事得多
