这是一个创建于 1404 天前的主题，其中的信息可能已经有所发展或是发生改变。
这些年基本都是从第一次听到某个项目，不到一周就开始写代码，写到最后发现需求有异义的地方需要大改（以为是 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