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

• 資深大佬 : kop1989

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

• 資深大佬 : IssacTomatoTan

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

• 資深大佬 : awanganddong

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

• 資深大佬 : jones2000

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

• 資深大佬 : luckylo

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

• 資深大佬 : xuanbg

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

• 資深大佬 : faqqcn

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

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

• 資深大佬 : 2379920898

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

• 資深大佬 : fengpan567

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

• 資深大佬 : securityCoding

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

• 資深大佬 : zhangxiaohui

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

• 資深大佬 : cupssb

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

• 資深大佬 : wangyzj

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

• 資深大佬 : madpecker009

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

• 資深大佬 : Leonard

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