这些年基本都是从第一次听到某个项目,不到一周就开始写代码,写到最后发现需求有异义的地方需要大改(以为是 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
一开始不用花太多时间,随做随问。感觉一开始也不太可能把每个细节的需求都弄清楚。
|