程序员从知道新项目起，大概花多少时间了解需求是比较合适的呢？

[lagoon]

这些年基本都是从第一次听到某个项目，不到一周就开始写代码，写到最后发现需求有异义的地方需要大改（以为是 A 理解，其实是 B 理解）。
不是责怪产品没把需求讲清，产品能不能把需求讲清，取决于有多少时间。

所以忽然想，一个完整的从 0 开始的完整项目，大家一般是有多少时间去了解需求。

[kop1989]

所以你的概要设计和详细设计文档呢？

[IssacTomatoTan]

基本都是仓库来了直接写代码。。

[awanganddong]

原来公司大概给一周左右理解业务。
现在公司，大概两到三天吧。

[jones2000]

先把你要做的项目对标的其他产品自己使用下， 大致了解清楚你要做的是什么。 然后结合需求文档开发。

[luckylo]

边做边改需求边加需求。需求都是不定的

[xuanbg]

至少 60%的时间。用来一边设计，一边挑需求的毛病。你这个时候不去挑需求的毛病，后面写代码的时候就写不下去。如果随便糊弄糊弄上了线，就该需求来挑你的毛病了。

[Rache1]

@xuanbg 真实。以前在外包的时候，项目下来就有个全体会议，设计、产品、开发、测试，一起找设计和产品的毛病，逐一解决，一次会议几个小时的那种。正式实施起来的时候基本上都是小问题了。

后面遇到到公司，基本都省略了这个流程了，产品讨论都没有 😂

[2379920898]

一边下达需求，一边做功能。连理解需求的机会都没有

[fengpan567]

大概开两次会就定了，当然坑肯定留了不少

[securityCoding]

我个人需求梳理与代码时间一般是 7/3 开。7 包括需求沟通、细节敲定、详细方案、任务拆解。实际上前期做的好的话代码写起来会非常非常快，基本就是把前期做的工作转换成代码。

[zhangxiaohui]

毕业后，一直呆在小公司。目前基本上新项目下来，需求很快敲定，之后先做出来个样本出来，后续根据样本在进行修改，完善。期待去大公司。

[cupssb]

可以通过过程控制来避免，比如需求反讲，测试案例评审。两个环节和需求人员一起参与，可以再次确认细节和避免歧义。

[wangyzj]

这个因为产品，需求，设计等等存在非常多变数
一个成熟产品可能根本不需要时间了解需求，就跟写 bug 一样
新产品，可能前俩迭代都是了解需求

[madpecker009]

从改 bug 开始熟悉。。。至于接口文档啥的，肯定是没有的拉

[Leonard]

一开始不用花太多时间，随做随问。感觉一开始也不太可能把每个细节的需求都弄清楚。