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

[SunshineLian]

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

[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 一种是，接下来继续做某个新功能，仍然很忙，仍然很让人崩溃
还有一种是，接下来，你们做的功能挂掉了，公司决定好好规划，要重新开发