这是一个创建于 1692 天前的主题，其中的信息可能已经有所发展或是发生改变。
这些年基本都是从第一次听到某个项目，不到一周就开始写代码，写到最后发现需求有异义的地方需要大改（以为是 A 理解，其实是 B 理解）。
不是责怪产品没把需求讲清，产品能不能把需求讲清，取决于有多少时间。
所以忽然想，一个完整的从 0 开始的完整项目，大家一般是有多少时间去了解需求。
 | 1 kop1989 2021-02-22 18:13:23 +08:00 所以你的概要设计和详细设计文档呢？ |
 | 2 IssacTomatoTan 2021-02-22 20:13:03 +08:00 via Android 基本都是仓库来了直接写代码。。 |
 | 3 awanganddong 2021-02-22 23:25:09 +08:00 via Android 原来公司大概给一周左右理解业务。 现在公司，大概两到三天吧。 |
 | 4 jones2000 2021-02-23 02:00:21 +08:00 先把你要做的项目对标的其他产品自己使用下， 大致了解清楚你要做的是什么。 然后结合需求文档开发。 |
 | 5 luckylo 2021-02-23 07:50:07 +08:00 via Android 边做边改需求边加需求。需求都是不定的 |
 | 6 xuanbg 2021-02-23 08:49:59 +08:00 至少 60%的时间。用来一边设计，一边挑需求的毛病。你这个时候不去挑需求的毛病，后面写代码的时候就写不下去。如果随便糊弄糊弄上了线，就该需求来挑你的毛病了。 |
 | 7 Rache1 2021-02-23 09:23:07 +08:00 @xuanbg 真实。以前在外包的时候，项目下来就有个全体会议，设计、产品、开发、测试，一起找设计和产品的毛病，逐一解决，一次会议几个小时的那种。正式实施起来的时候基本上都是小问题了。 后面遇到到公司，基本都省略了这个流程了，产品讨论都没有 |
 | 8 2379920898 2021-02-23 09:49:01 +08:00 一边下达需求，一边做功能。连理解需求的机会都没有 |
 | 9 fengpan567 2021-02-23 10:10:08 +08:00 大概开两次会就定了，当然坑肯定留了不少 |
 | 10 securityCoding 2021-02-23 11:01:42 +08:00 我个人需求梳理与代码时间一般是 7/3 开。7 包括需求沟通、细节敲定、详细方案、任务拆解。实际上前期做的好的话代码写起来会非常非常快，基本就是把前期做的工作转换成代码。 |
 | 11 zhangxiaohui 2021-02-23 12:01:11 +08:00 毕业后，一直呆在小公司。目前基本上新项目下来，需求很快敲定，之后先做出来个样本出来，后续根据样本在进行修改，完善。期待去大公司。 |
 | 12 cupssb 2021-02-23 12:51:40 +08:00 可以通过过程控制来避免，比如需求反讲，测试案例评审。两个环节和需求人员一起参与，可以再次确认细节和避免歧义。 |
 | 13 wangyzj 2021-02-23 13:15:29 +08:00 这个因为产品，需求，设计等等存在非常多变数 一个成熟产品可能根本不需要时间了解需求，就跟写 bug 一样 新产品，可能前俩迭代都是了解需求 |
 | 14 madpecker009 2021-02-23 14:02:01 +08:00 从改 bug 开始熟悉。。。至于接口文档啥的，肯定是没有的拉 |
 | 15 Leonard 2021-02-23 14:09:00 +08:00 一开始不用花太多时间，随做随问。感觉一开始也不太可能把每个细节的需求都弄清楚。 |
Select Language