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