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