需求分析应该非常重要吧？！在做一个需求分析都没搞清楚的项目

[SunshineLian]

在做一个网站，发现需求分析非常不明确。开始做整体和各个模块的时候，就是看着差不多是那么回事的样子先做做，然后，再不断的修改之前已经做过的。经常是前段时间做好的功能和模块，过了几天，说需求变了，把之前做好的东西再修改的面目全非。不光是功能部分如此，页面也是如此，能把以前做好的页面该成另一副样子。效率之低，大家可以想象。因为需求变了，有的时候，数据库的字段和结构也要跟着变。我真的很无语……O__O"…管事儿的人，好像也没有专门和客户谈过需求，似乎一直都是客户提出新的想法了，我们就跟着变……哎！
我不知道这种情况多不多，大家有没有遇到过呢?反正我很不喜欢这样，刚开始的时候也一度被折腾的抓狂，这都是在干什么啊……~~~~(>_<)~~~~ 这段时间我就在想，需求分析看似没有开发容易，但它是多么的重要啊，是一个好开发的根基啊\(^o^)/~。就像程序中的注释是多么的重要啊( ⊙ o ⊙ )，不经历体会不到啊……
大家都来说说……

[lichao]

按理说是要有个需求说明书的，但是很多国内客户连让他拿出一张纸来简单写写需求他都觉得麻烦，提需求变更需求之前也没有经过怎样的思考。
也是因为东西做出来之前，他们自己也不清楚自己要的是什么，只有做出来给他看了，他才会觉得合适或者不合适。

[lichao]

如果能按照工时向客户收费，那结果一定大不一样

[flied]

没有需求文档不干活。

[kingwkb]

国内都这样，国外不清楚

这样的活不干，估计就没什么活能干了

[juicy]

这估计是国内程序猿苦逼的一个很根本性的原因～～

[SunshineLian]

@lichao 是啊，客户对这个也不懂，但是，你说的“东西做出来之前，他们自己也不清楚自己要的是什么，只有做出来给他看了，他才会觉得合适或者不合适”，我觉得正是因为这样，所以，项目经理什么的才要专门的去谈需求，公司提出解决方案，可以画出网站页面的图纸、网页跳转的流程等，和客户充分沟通，不断磨合协调，把需求的大部分都定下来，然后才是开发，我是这么想的，需求分析不就是做这个的么??

[SunshineLian]

@flied 有时候文档只有一个大致的框架，细节还是一片模糊

[SunshineLian]

@kingwkb 谈需求分析的时候，尽量的谈的细致、周全，充分沟通，这样不是就好了吗？

[SunshineLian]

@juicy 的确苦逼，抓狂，崩溃中……

[SunshineLian]

我们这里是基本上没谈需求分析，不知道谈了的，会不会不是这样？

[jamiesun]

需要改变方式，去引导客户。这本身就是软件项目的一个环节，这不是客户的问题，而是开发商的问题，

[SunshineLian]

@jamiesun 嗯，引导客户，同意

[ytzong]

换不同的身份来考虑，有时候是不需要需求分析的，在不停试错中前进

[min]

不重要
开发的手快就行了
一遍一遍改，客户会很快找到满意的方案的

[davepkxxx]

这不会是你最后一次遇到这种事情

[janxin]

这个是面对单一客户时常出现的问题，只有内部项目或者不面对单一客户时，才不会出现

[yangqi]

@SunshineLian 这种客户啥也不知道的，应该先做个prototype出来给他们看吧，就是一个大概的框架和布局，不需要细节

[jamiesun]

客户是不会给你清楚明了的需求文档的，大部分客户对自己想要的软件产品初期都处在一个比较模糊认知的阶段，所以需要和客户去交流需求，这是通常由项目经理，业务人员去做，他们必须去和客户做深入沟通，去引导发现客户真正的需求。

很多客户往往简单的说“我想要个像某某产品一样的东西”，而不能说出更多具体的细节，因为客户受限于一些专业领域的知识。而这时需求人员应该主动去了解客户所说的那个产品，分析这个产品的功能特性，在足够了解的情况下，继续去和客户进行确认，和客户的沟通用语要能让客户尽量明白，最终可以形成一个比较靠谱的需求文档，对于后面的开发工作指导才有意义。

更严格的说，需求说明书需要客户签字的，客户会更小心谨慎。

[benyur]

@yangqi 客户的需求会演进的，会随着学习和了解，不断进步的。

[eric94]

拥抱变化 快速迭代
需求变化很快是软件行业的本质，所以才会有那么多相关的流程提高生产效率。比如agile。
期待需求稳定 一点不变只不过是一种理想状态而已。
作为一个程序员，也应该了解自己所做的系统到底是做什么的，每次发生变更的原因是什么。

程序员应该在能力范围内从一开始就纠正一些不合符实际使用和习惯的feature。

这是一个长久的改进过程...

[sgissb1]

@lichao 需求说明书是不够的，要细致到业务说明。不过以前我们工作方式就是需求+业务分解+模块分解...然后一层一层迭代下去。

我现在遇到的一个神人，就是搞个所谓的需求说明书，然后里面就截几张图，配上少量文字。看着很有分量的样子，实际上空空如也，很多都要我们研发自己去考虑。

[Narcissu5]

@jamiesun 你确定客户签字有用？

@eric94 如果你必须写一个东西，并且写之前就知道这些东西根本就毫无意义，那是很挫伤积极性的，这跟敏捷不敏捷没有关系。

好多客户既不懂技术也不懂业务，却能依靠甲方的身份把码农牵着鼻子走。

哎，感慨太多了，谁让客户是政府呢。

[jamiesun]

@Narcissu5 对于某些客户，签字是很有用的，比如政府部门，事业单位，防止他们过于傲慢，乱提需求，需求和商务关联在一起的。怎么可能让客户来牵着码农的鼻子走，客户有要求决不允许直接找程序员做，必须走商务流程。

[avichen]

我只想问一句，上面有多少人真正和客户搞过需求的，并且执行过一个完整的项目过程的？

[SunshineLian]

@ytzong @min 但是客户的想法说不定什么时候就变了，效率不高啊，我没有相关经验，觉得不是很靠谱

[SunshineLian]

@davepkxxx 不明白公司为什么要这么来，对谁都没好处，不管是客户还是开发人员

[SunshineLian]

@janxin 为什么不专们派人去谈需求呢？对单一客户也可以啊

[SunshineLian]

@jamiesun 你说的跟我想的一样，我也是这么认为的，不过我没有经验，这是不是就是正规的需求分析？

[lichao]

@eric94 对啊，拥抱变化、快速迭代，既然不能反抗，那就好好享受。
客户的需求永远是多变的，也对方案通常两条
1. 尽量认真做需求分析，且敢于对客户说：No
2. 超前设计，甚至可能预知客户的后续修改要求

[SunshineLian]

@eric94 学习了，有道理，做需求分析无法保证以后都按这个来，但我觉得，正常情况下，大部分都应该按这个来，有少量变动也正常。当然，不排除有时候需求变化的很大，和之前的几乎“面目全非”

[davepkxxx]

很多项目都是需求不明确，尤其是政府项目，基本上都是领导拍脑袋，接到项目后再去各个科室调研需求，需求调研到哪里项目就作到哪里，最后还有不断的修改需求。

[tonyzzp]

常有的事。。
经常测了好几天了，开发、测试、产品经理还在群里为需求到底是什么样的争论。。

[SunshineLian]

@sgissb1 跟我这差不多，我们也有文档，但文档只有个大致框架，细节什么的都没定

[SunshineLian]

@avichen 你有过吗？说说

[SunshineLian]

@lichao 做好需求分析，看来难度很大啊

[SunshineLian]

@davepkxxx 去跟政府方面的人谈需求，项目组专门派人去谈，不行吗？

[66450146]

这种事太正常了，我就说一下我的经历吧。

我们是二月正式开始的项目，产品在美国，后台在俄罗斯，客户端在中国。是在原有的应用基础上改变界面增加功能。由于几乎没有招到有经验的 iOS 开发，就从几个团队抓了一些人，接过从 08 年开始就没清理过的代码开搞了。

到四月，客户端才刚刚有个框架。这时候服务器端还没开始改造。每天的工作就是问中国这边的产品，XX 地方要做成什么样的，然后对方回答一般是这个他不能决定，先按照自己的想法做吧，他会发邮件问的。同时几个传统主力功能的新界面交给实习生操刀，惨不忍睹。

六月的时候客户端的界面基本上改造完了，但是还有一个拳头功能的需求不确定，时不时有长长的邮件发来发去。我们这里有一个开发者专门给老毛子发邮件，调个 bug 也要等到老毛子上班。这时候我们 app 的 bug 数量在 100 左右徘徊（有很大一部分是需求没提过的）。这个 bug 数量前后持续了一两个月。

一直这样耗着到了十月，终于有人发话了：先把客户端的新功能关掉上线吧。。。补充一下，这个项目原计划六月就要做完的。。。于是我们就在新旧 API 混用的情况下，在客户端把新功能屏蔽掉之后草草上线了。。。听说反响还不错，这是后话。

整个项目最后完结的时候差不多是十二月底了，整个应用在我们无数的补丁之下，终于上线了。当然，一开始承诺过的项目奖金是绝逼没有的，我们团队的年终考核也是处在低位的。领导说，这段时间忙过了之后，接下来就会轻松一点了。你猜后来几个月发生了什么？

[sgissb1]

@SunshineLian 有些连框架都没有的，细节不做约束其实是推卸责任的一种做法。这样做的话，可以把工作量往研发的身上推。

而且越是这样，代码就越容易乱，因为产品需求表面上看很清楚，实际上很模糊。就和造车一样，给了个车的样子，没有对车的内部做详细的约束。

这种情况只能做做小项目而已。

[davepkxxx]

@SunshineLian 那么多科室一般不会集中调研，一般都是先调研好有哪些模块，预估一下大概的工作量，然后分一下任务，负责模块的人自己去跑需求。

[SunshineLian]

@66450146 一种是，接下来继续做某个新功能，仍然很忙，仍然很让人崩溃
还有一种是，接下来，你们做的功能挂掉了，公司决定好好规划，要重新开发

[SunshineLian]

@davepkxxx 这样的多吗？模块之间经常会有联系，分开做需求到最后还是要放到一块，这样容易整个项目协调统一吗?

[davepkxxx]

@SunshineLian 模块之间有联系就让那几个模块的负责人互相沟通，整理好接口以便调用，整个项目的协调统一由项目经理这一级别的人负责。

[favormm]

我们公司，做手机项目的。没有设计，没有UI,先叫我们程序写代码， 写出来后看了以后问你一句：“哇，杂这么丑啊”。 然后他们再写文档给客户，写文档过程当中：你把程序跑起来一下，然后截张图给我，我面要些素材。

听了这些话，顿时就有离职的冲动呢？

[SunshineLian]

@favormm 这就是瞎胡来，这样需求这么乱，项目整体也好不到哪儿去，估计也是一片混乱，我甚至怀疑这样做出来的项目能上线吗？上线之后会不会用不了多久就挂掉了？

[wity_lv]

@favormm 这个情况ok吧。 我上个应用就是这么干的。 客户就说我要个XXX软件， iPad 版，横屏，左侧 放A，中间放B, 头是标题栏，底栏是状态栏。附言：必须按这个页面布局实现。(用没有把 iPad 当windows程序的感觉？)

应对方法:
先实现，然后给客户看。
客户说，丑！！！
不理， 继续关注功能实现。

一段时间后再给客户看。
客户: 功能都ok, 就是页面丑。
不理，继续做周边工作。

临近交付期,再给客户看
客户：怎么还这么丑。
然后跟客户沟通，他们招设计公司，根据已经实现的软件出设计。 然后我们改资源引用。




@SunshineLian 这个客户典型的不知道自己要什么，我现在就在应对一个这种客户。
应对方法：
客户： 我要XXX功能?
我: 要这个功能想解决你们什么问题?
客户: ****讲一堆。
我: 换个思路如何, 然后讲一堆 **** (当然实现起来方便)
客户: no, 我们领导说了，就这样实现，不能改。
我: 我先实现。

下面是重点:
最快的方式做出来，主要能演示操作流程，能让用户点点用即可。
有bug? 不要管
页面丑？不要管
被客户B4? 不要管
之后各种改。


在之后各种改的时候，如何控制？
Git这类版本控制工具, 需要有。


branch对应客户需求点
tag对应发布点

记录用户提出需求的文档, 必须有。之前我一直用Evernote记录，现在发现一个更好的方式:
https://trello.com



碰见这种客户，要么搞定，要么跑路。

[panda]

双方都要有数学帝的逻辑思维才能更快解决，可8成最讨厌就是数学了吧。