http://blog.csdn.net/sz_haitao/article/details/8547210
20年没干别的，都是在软件开发第一线，尤其是总是最受轻视的MIS开发
无论是给客户开发，还是给自己开发
所以别的啥也没有，有的只是第一线的认识和感受
软件开发，尤其是信息管理类软件的开发，失败率非常高【第1个为什么】
中国尤其突出，因为中国的甲方、用户特别牛
自己则比较幸运，做过的这些项目和系统，基本都还是比较成功，失败的相当少
要知道这些系统的用户有些是机关单位，有些是银行等金融机构
都是最难伺候的甲方了，居然能让他们满意，除了幸运就多一点后怕了
所以，希望能对还在沼泽泥坑里奋战的同行有所帮助和引起共鸣、探讨
业界一般总结的经验是，要想成功开发管理信息系统，工作量（时间进度）的分布为：
需求分析、设计阶段占60%
编码实现、内部调试占30%
最后联调验收占10% 【第2个为什么】
需求分析、设计是动嘴动脑而已，编码实现才是动手落实
一般都说“领导动动嘴，干活跑断腿”，
为什么“动嘴皮子”的反而比“跑腿杆子”的要工作量大？【第3个为什么】
系统分析师、设计师为什么比程序员“贵”那么多？【第4个为什么】
除了前者资历往往要比较高，可是有必要吗？
不同程序员的工作效能，为什么往往能差几倍到几十倍？！【第5个为什么】
同样的项目，不同人、团队实现，所需的时间也往往能差几倍到几十倍？！【第6个为什么】
为什么软件的错误，发现越早，修改的代价就越低。
发现修改的早、晚导致的工作量不同，往往能差几倍到几十倍？！【第7个为什么】
这么多“为什么”！有些“为什么”其实是其它“为什么”的原因，而最终的根源只有2点：
1、软件系统的功能，往往是很多步骤、环节组合而成的
每个环节都有多种潜在的不同做法，不连贯起来、系统性地看，很难判断哪一种做法就是本环节最佳的做法
2、用户在看到、使用到具体的系统、每个环节前，无法提出完整准确的需求意见
哪怕这个系统将由他自己使用，他以前也按传统、手工模式从事着同样的业务
由根源1可以得知，假如一个系统有10个环节，每个环节有2种做法供选择（这已经是很理想的情况了）
那么这个系统就有2^10=1024种选择（每种选择都是长度为10的路径），
而用户真正想要的选择只是其中一种：10个环节都选对做法了的情况（路径）。
这就能解释【第1个为什么】了：一千条路径里面只对了一条！
当然，开发者根据粗略的需求，替用户做的判断，也不是每个环节都是正好选错了的，
所以成功率由理论上的1‰“猛升”到现实中的5%至40%
正是“领导动动嘴，干活跑断腿”，
所以，开发者希望能实际干活跑腿前，能把用户的需求确定下来，
免得用户嘴巴乱动，开发人员跑断腿也跟不上
所以，开发前做好需求分析和功能设计，不是闲得没事的结果
而是血的教训和现实的逼迫
但是，根源2决定了没法直接从用户嘴里得到正确的路径！
即使用户很想配合，也没有用——人之常情，
所以，不能希望用户正好是合格的需求分析师
怎么办，只有开发者把这10个环节一一分解，逐个环节地展开每个可能的选择
同时，为每种选择举一个【典型示例】，说明选择它会有什么样的特别效果、影响
与其他选择的区别在哪里——不够典型就无法区分，用户的判断也就随意了
用户面对具体环节里的所有选择了，才能发挥他作为业务专家的作用：
哦，这个环节我是希望第一个做法，而不是第二个做法！
当然，前提还得是：具体来帮开发者做选择的用户的确是个熟悉业务的人，
而且是个能明白是非逻辑的人，另外，最重要的是他愿意配合！
（最后这个“配合”前提看似废话，其实也是非常难达到的，因为系统做好了，
他作为业务专家、业务骨干的价值、在单位里的地位，往往也就降低了，
有些甚至是浑水摸鱼、损公肥私的机会大大减少了，即使领导要他配合，他也只是阳奉阴违
当然，这不是本话题希望展开的内容了）
需求分析者要做的工作就是把这1024种选择逐个环节地罗列出来
分别配以能说明特征的【典型示例】
并从用户那里得到确认——这种情况下，用户是可以确认了
所以，需求、设计的“动嘴皮子”其实是在“嘴”上跑1000条路径后，
才能从用户那里得到确定的1条正确路径，
“跑腿杆子”则只需要以代码跑出这1条正确的路径！
所以，【第3个为什么】“动嘴皮子”的反而比“跑腿杆子”的要工作量大，
因为两者有相差更大的倍数（1000:1）！
所以，【第2个为什么】需求设计占60%，编码实现占30%
（从此可以反推：如果路径数量相同，“动嘴皮子”和“跑腿杆子”的工作量之比其实是1:500
说明“领导动动嘴，干活跑断腿”这句老话也的确没错）
磨刀不误砍柴工，这句老话在这里也是很好的总结
如果没有先确定唯一的正确路径，可能需要程序员根据自己的理解做判断
这样的选择不是必然错误，也是近半环节会选错
假设7个环节都选对了，也还是在2^(10-7)=8条路径里误打误撞
相当于需要程序员跑腿8遍才能最终得到正确（用户想要）的系统！
同样的项目，有好的系统分析师，总共需要100%的工期
差的系统分析师，就是10%(需求分析、设计)+8x30%(编码)+10%(联调)=260%的工期了！
如果是40个环节，选择对了30个环节，则是：
10%(需求分析、设计)+(2^(40-30))x30%(编码)+10%(联调)=30740%的工期了！
也就是300倍的工期了！显然，这就是《人月神话》里说的沼泽泥坑了！！
（当然，真的返工几遍，有些模块其实可以重用，不一定都要再次实现
但是，设计不好，有些不同的路径，会导致很多模块要彻底推翻）
可见，不同水平的需求分析、设计人员，决定了工期差几倍到几十倍！【第6个为什么】
系统分析师能在事先一步步诱导用户，根据粗略、零碎的需求，总结汇总得到所有的可能路径
并附注以对应的【典型示例】，让用户看到不同选择的结果差别
再一步步让用户配合进行选择、排除、确认，得到正确的路径
往往在需求获取、确认的过程中，系统分析师就已经成为比用户还精通业务的行业专家了
在【典型示例】的寻找和验证过程中，已经完全了解了业务发展变化所有趋势和结果
因为他们逻辑性强、思维慎密，既善于沟通探讨、又善于整理归纳
这样的人，比只需根据正确路径写出实现代码的程序员“贵”很多，有什么奇怪的？【第4个为什么】
当然，在中国国情下，很多小的项目，或者大项目的很多环节也分析得没那么精确
很多时候，往往需要程序员发挥系统分析师的作用，由他们自行进行小的、局部的路径展开和确认
这种展开和确认，与正规的需求分析其实没什么本质差异，同样有覆盖面、正确率的问题
所以，即使编码水平相同，分析能力决定了不同程序员的工作效能差几倍到几十倍！【第5个为什么】
同样，发现修改的早，需要修改的只是“动嘴皮子”，发现修改的晚，需要修改的就是“跑腿杆子”了
根据上面的推论，“动嘴皮子”和“跑腿杆子”的工作量之比其实是1:500
所以，它们能差几倍到几十倍也不足为奇了！【第7个为什么】
（需求、设计）差之毫厘,（开发、实现）谬之千里
——中国古话用在现代的软件开发里，居然也这么恰如其分，真的是有点不可思议
可能很多事情，抽象到了终极的程度，其实就是一个哲学问题了
它就不分时代、不分国界、不分行业了
另外，不知道大家注意到没有，上面的工作量和工期，有点混用
这也是软件开发的另一个特点了：
人多不一定有用（减少工期），很可能反而增加工期【第8个为什么】
也许，严格一点应该说是中国大多数小型开发团队的特点了
这个特点，也是因为需求分析、设计的普遍低水平
如果分析、设计做好了，路径明确了，的确是可以多人并发编码，也就没这个特点（缺点）了
但是，理想是丰满的，现实是骨感的
分析、设计没做好，才导致编码工期远远超出30%，这时再来加人，新人需要设计者从头介绍项目情况
而且因为模块间耦合度高（分析没做好，设计也一般），还需要已有程序员停下工作介绍复杂的接口机制
甚至时不时共同修改接口。。。。
上面，都只是示例化地比较了各种悬殊的差异产生过程
证明了需求分析、设计工作的重要性，
我们如何具体地做到把需求设计做成功？
从上面的分析，也容易得到：
1、各个环节想清楚，不要遗漏
2、每个环节的每种可能的做法不要遗漏
3、通过构造【典型示例】，为可能的做法增加效果说明
4、设计好环节间的耦合、传递、协作关系
1、2、3要求分析师逻辑性强、思维慎密
这时如果遗漏了，到编码时或使用时才发现，很可能不仅仅是增加做法就行了
而是需要前后环节都跟着改，运气不好，甚至原来的模式都无法满足这个“新冒出”的需求，
需要重新设计部分甚至全部的模式！
对于如何加强这3项工作，基本有2个工具，后面具体介绍
4主要受1、2的限制，更多是设计了，基本靠设计师的基本功了
工具1：思维导图工具（如xmind、freemind、mindmanager）
多个环节-多种候选，就是很典型的多层次、多分支的“决策”树
没有专门的层次编辑、展示工具，很容易遗漏层次或分支
在罗列完成后，根据用户的判断，分析师能当场方便地做出调整（増、删、改、移分支及层次）
或者基于Treeview的层次树形编辑工具
我自己都做过一个： http://xq.com.nu/?app=mytree
工具2：快速开发工具
经常听到：语言不重要，业务逻辑才是最重要
但是语言决定了：你能不能把主要的精力花在实现业务逻辑上
（差的语言让你不得不把小半甚至多半的精力花在基本的字符串操作、对象操作、界面控制上了）
且慢！不是需求分析吗？怎么又说到编码实现了？！
对，用户要看到东西才能确定你想的做法对不对，你不能给他看，他自然就无法判断
当然，绝大多数开发平台、语言、工具是无法做到：
在需求分析时就让用户有“系统”可以“运行”起来“使用”的
那就没办法，老老实实在文档里写吧，再图文并茂也不如用户能直接交互的
有工具可以做能交互的原型，但是，最好是能当着用户的面，针对用户的意见直接修改
因为用户此时的意见仍然不一定对，只有（低成本、快速地）真的把他的意见实现了
他看到了不合理的地方，才会发现自己真的错了（当然，前提也是他不是死要面子的人）
delphi就是最高效的win32桌面应用快速开发工具，没有之一，不但开发快速，运行也快速（意外）
只是已经多年不再流行了
实在没有快速开发能力，就需要【典型示例】了，
之所以一直强调典型，就是要求这个示例能明确区分自己和其他选择的不同后果
这样用户看了结果才能知道哪个选择才是自己想要
注意，这种示例不是UML里的用例图（User Case），除非你的用户是同行，能接受用例图
有了这些，管理软件的开发应该不再是噩梦，MIS的成功率应该也会大幅攀升
同行们也可以有真正的舒心日子了
------------------------------------------------ 评论 -------------------------------------------------------------------------
架构师是负责系统运行的技术模式的选择、创建，行政、市场（项目经理、产品经理的事情）应该不用他分心了。
系统分析师更关键：承接用户，发掘需求，归纳总结，从千万条可能的功能路径里排除大部分，剩下的再征求用户的有效反馈，最后落实到一条功能路径，以便后续的编码实现。
项目经理、产品经理是负责整体项目，更多行政、市场等非技术因素、环节；
系统分析师、架构师则是侧重技术部分的总体把控，其中后者作用可能会少一点：类似的项目、系统，架构其实是可以复用、照搬的；而需求则是不同客户都不尽相同的，除非是SAP这样的软件商，可以店大欺客。
补充（下面就是利用层次工具编辑所得）
├1、需求不一定都是一条路径
│├的确，需求里的某个环节可能就是5种做法里同时支持3种
│├不同的前提下对应选择不同的做法
│├这些不妨碍分析师的工作，都是最基本的
│└单路径只是一种简化的形象说法
├2、需求，比复杂更可怕的是老变
│├简介
││├的确，用户越强势，需求越是容易变
││└所以，中国这种情况是很普遍的
│├原因之一
││├但是，很多“变”，其实是因为分析师预先没罗列到
││├以至于用户根据使用情况遇到了，不得不后期加进去
││└如果前期已经考虑到了，就不存在“变”了
│└原因之二
│ ├有些“变”的确是当时的需求之外的
│ ├但是，如果分析师真的全盘了解了用户的情况
│ ├自然应该比用户更深远地想到不久之后的发展情况
│ ├在系统里增加扩展余地或直接预留、实现
│ └这样，那些“变”也不算是变了
└3、需求，比老变更可怕的是矛盾
├这个的确也是最棘手的，也是很常见的
├因为用户其实是一个多层次的群体
├最简单就有领导和员工，他们的需求就是对立、矛盾的
│├领导希望的是管理、监控、统计越完善越好
│└员工是希望监控、约束、工作量越少越少
├这种情况，顾了领导就是“害”了员工，顾了员工就无法满足领导
├唯一的解法就是利用IT带来的替代机械、重复劳动，来缓解员工的工作量、出错率
└从而换取员工对系统带来的新要求的谅解