![]() | 1 springz 2015-11-06 14:26:37 +08:00 口头,几乎每天都在变 |
![]() | 2 ChanneW 2015-11-06 14:27:23 +08:00 即使是口头交代的,也要写下来。 |
![]() | 3 yuatom 2015-11-06 14:27:28 +08:00 ![]() 代码一写完就变了。 |
4 chenyu0532 2015-11-06 14:28:56 +08:00 文档啊。。。这必须的。。万一出什么问题,口头说的谁承认。。 |
![]() | 5 LancerComet 2015-11-06 14:35:35 +08:00 文档,发到 Redmine 上 |
![]() | 6 phpcxy 2015-11-06 14:36:52 +08:00 经常发一个有两三页的 PPT 过来,问完成这个项目要多久、开发计划怎么安排 |
8 ca1123 OP |
![]() | 9 davidqw 2015-11-06 14:57:20 +08:00 难道不是附上各种标注的原型图? |
![]() | 12 LancerComet 2015-11-06 15:03:33 +08:00 @ca1123 带有文案、原型图还有设计稿 |
![]() | 13 LancerComet 2015-11-06 15:04:07 +08:00 @ca1123 但临时需求还是会突然来的,这时候会口头说 |
![]() | 14 alphadog619 2015-11-06 15:05:55 +08:00 1 、比较规范的公司都是调研需求,然后评审,形成文档,就算变更也有变更流程,保证所有相关人员都知道需求变了。 2 、大部分作坊式的公司,就是领导一拍脑袋,想个需求,口头告诉开发人员(测试根本就不知道,等到测试的时候才知道做的是什么),然后第二天,又一拍脑袋,一个想法又出来了,改……如此反复。到了测试这,测试基本上靠猜了。 |
![]() | 15 dododada 2015-11-06 15:09:06 +08:00 @alphadog619 类型 1 的公司工作流程分工相当明确,类型 2 的公司基本谈不上什么管理 |
![]() | 16 learnshare 2015-11-06 15:11:11 +08:00 一般都是口头,一般都是一拍脑袋,或者灵光一闪,或者听说过、见过 小公司就是不拘小节嘛 |
![]() | 17 ren2881971 2015-11-06 15:19:37 +08:00 ![]() 口口相传 |
![]() | 18 admol 2015-11-06 15:22:58 +08:00 原型页面 |
![]() | 19 springz 2015-11-06 15:27:21 +08:00 公司就几个人,基本就老板拍脑袋定了,几天变一次。 |
![]() | 20 mjoseph 2015-11-06 15:32:06 +08:00 。。。。。。。。 |
![]() | 21 harry890829 2015-11-06 15:33:54 +08:00 和业务那边稍微大一点的需求就直接邮件,那种随便点点就好的,随手就改了 |
22 ca1123 OP @harry890829 我觉得要能把需求管理好 能省不少事 |
![]() | 24 yellowV2ex 2015-11-06 15:46:15 +08:00 客户的需求就这样啊:“我要做个可以让员工学习的系统,每天学,学完了答题,能有积分,积分可以在那个商城里换东西就行了” “ 12w 吧” 三个月后, “恩,不错,来,钱给你” |
25 ca1123 OP @LancerComet 那你们还是正规的 |
26 ca1123 OP @yellowV2ex 赞商业模式 |
28 laoyur 2015-11-06 15:51:59 +08:00 策划隔三差五 qq 发个 doc 、 xls 过来,然后我的下载文件夹就充斥着一堆出入此类的文件: XX 游戏策划最终版( 01 ).doc XX 游戏策划最终版( 02 ).doc XX 游戏策划最终版( 03 ).doc |
![]() | 29 harry890829 2015-11-06 15:57:07 +08:00 @ca1123 要是提需求的人懂技术那是最好的 |
30 ca1123 OP @harry890829 至少也得脑子清楚。。。 |
![]() | 31 harry890829 2015-11-06 16:00:55 +08:00 @ca1123 现在谁跟我提需求,我都要考虑完技术难题之后再回复,好在我们公司需求是能够商量的 |
![]() | 32 yuatom 2015-11-06 16:22:14 +08:00 @alphadog619 完全就这样,每一个版本都是对上一版的推翻。然后再临时加需求,写得差不多了老板说这个不要了。 |
![]() | 33 nikubenki 2015-11-06 16:33:35 +08:00 via iPhone 我们需求文档倒是挺正规的,可是业务人员需求提的不清楚,很多东西需要边开发边讨论,甚至有的问他们居然还没考虑到。 |
![]() | 34 solaya 2015-11-06 16:40:15 +08:00 我就拿张图片在哪里看 -_# |
![]() | 35 shenqiu15 2015-11-06 16:43:53 +08:00 我们是直接看领导脸色开发,让领导免开尊口,等领导发话了小鞋就已经穿上了 |
![]() | 36 onlyxuyang 2015-11-06 16:43:55 +08:00 via Android 一般口头说完会要求发 request mail , cc 到双方主管留证 |
![]() | 37 wleexi 2015-11-06 16:53:53 +08:00 @onlyxuyang +1 |
![]() | 38 i36lib 2015-11-06 17:03:56 +08:00 拍脑袋的也行?如果有内部系统就走系统,没有就发邮件。 |
39 JulyXing 2015-11-06 17:06:31 +08:00 文档,如果有数据改动加邮件。 |
![]() | 40 shakoon 2015-11-06 17:07:45 +08:00 有口头的也有书面的。如果是口头的,多半是因为太复杂,业务人员水平不够些写不清楚,然后我们会文字化后让他们签字确认。当然无论怎么书面,实施时照样会走出一推变更出来的。 |
41 ibireme 2015-11-06 17:16:16 +08:00 要形成文档啊,测试也得跟着文档走啊~~ 不过。。文档也是天天变呐。。。 |
![]() | 42 lbj96347 2015-11-06 17:30:55 +08:00 当然文档啊。除了文档还有专门的技术稿,设计稿。架构,前端细节,核心技术处理细节,必不可少。 |
![]() | 43 hahajin 2015-11-06 17:34:54 +08:00 @alphadog619 讲得太对了 |
![]() | 44 loveuqian 2015-11-06 17:39:08 +08:00 好歹也要走流程啊。 木有用项目管理软件嘛? |
45 NickIwannaRock 2015-11-06 17:50:05 +08:00 1 ,没有需求文档,可以拒绝开发的。产品经理写需求前,也会征求意见。文档写好后,开发人员、项目经理、产品经理、测试人员 参与评审。评审不通过,则打回给产品经理 修改重做,之后第二轮评审,通过为止。 2 ,需求定稿后,开始 概要设计。大概一周。 3 ,概要设计评审通过后,开始详细设计。大概 1 周。 4 ,详细设计评审会议通过后,发布设计文档定稿版本,然后开发评估时间、测试评估时间 5 ,这一步才开始 功能模块的开发工作 6 ,开发期间,有需求变更,不接受产品经理的口头通知。需要他提交 需求变更申请,更新需求文档,然后 项目组评审需求,才会开发。 |
![]() | 46 Akagi201 2015-11-06 18:20:56 +08:00 文档, 但就一句话, 需要原型图啥的, 要自己找人要. |
![]() | 47 altair21 2015-11-06 19:43:57 +08:00 via iPhone pdf 大部分交互都描述的很清楚 |
![]() | 48 lyning 2015-11-06 21:50:40 +08:00 via Android 我们公司是必须需求和设计出来才能做,这样变化没有很大,口头表达变得很快,如果只是加个业务判断处理的还好,太大的还是先别做,等设计 |
![]() | 49 Hipponensis 2015-11-06 22:08:47 +08:00 文档啊 TDD |
![]() | 50 kaedea 2015-11-06 22:41:50 +08:00 产品的话就是需求 |
51 chenyu0532 2015-11-06 22:52:26 +08:00 @ca1123 需求文档啊,有哪些功能,需要做成什么样子,需要什么效果之类的,文字、表格、图片只要能表达清楚了都可以的 |
52 chenyu0532 2015-11-06 22:53:56 +08:00 @ca1123 当然小改动可以口头上,大改动最后出问题,谁 TM 愿意承认是自己的问题 |
![]() | 53 imdoge 2015-11-07 00:33:08 +08:00 via Android 我们就属于那种不(luan)拘(qi)小(ba)节(zao)的,不过只要大架构没变,改点小需求,样式什么的我无所谓,反正很快搞定,虽说流程不够严谨,不过觉得楼上那种讨论详细文档一周各种审批的也太繁琐了… |
![]() | 54 msg7086 2015-11-07 02:56:44 +08:00 口头开坑,开坑以后出文档,规定 UI/API 各种细节,然后实现验收。 |
![]() | 55 loading 2015-11-07 06:45:11 +08:00 via Android “再改改,改得更大气一些!” 是的,就这么多! |
![]() | 56 t2doo 2015-11-07 10:39:14 +08:00 看到这么多口头需求地,俺就放心了 T_T |
![]() | 57 2015813 2015-11-07 10:51:42 +08:00 需求永远在变化! |
![]() | 58 unique 2015-11-07 11:12:29 +08:00 via iPhone 口头纯属扯淡 |
![]() | 60 tanteng 2015-11-07 11:54:16 +08:00 一般要开需求评审会议,产品,技术各有关人员一起评审需求是否合理可行 |
![]() | 61 geew 2015-11-07 11:59:12 +08:00 老大给我的 一般是口头 详细信息也不说 非要我问才行....其他人给我的 我一般都会回答 请给我写到 tower 上 ![]() |
![]() | 62 pomoho 2015-11-07 21:15:20 +08:00 口头肯定不行,得弄成书面的。 wiki ,邮件,或者团队协作工具 |