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的层次树形编辑工具
经常听到：语言不重要，业务逻辑才是最重要
但是语言决定了：你能不能把主要的精力花在实现业务逻辑上
（差的语言让你不得不把小半甚至多半的精力花在基本的字符串操作、对象操作、界面控制上了）
且慢！不是需求分析吗？怎么又说到编码实现了？！
对，用户要看到东西才能确定你想的做法对不对，你不能给他看，他自然就无法判断
当然，绝大多数开发平台、语言、工具是无法做到：
在需求分析时就让用户有“系统”可以“运行”起来“使用”的
那就没办法，老老实实在文档里写吧，再图文并茂也不如用户能直接交互的
有工具可以做能交互的原型，但是，最好是能当着用户的面，针对用户的意见直接修改
因为用户此时的意见仍然不一定对，只有（低成本、快速地）真的把他的意见实现了
这样用户看了结果才能知道哪个选择才是自己想要
无论是给客户开发，还是给自己开发
所以别的啥也没有，有的只是第一线的认识和感受
软件开发，尤其是信息管理类软件的开发，失败率非常高【第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
经常听到：语言不重要，业务逻辑才是最重要
但是语言决定了：你能不能把主要的精力花在实现业务逻辑上
（差的语言让你不得不把小半甚至多半的精力花在基本的字符串操作、对象操作、界面控制上了）
且慢！不是需求分析吗？怎么又说到编码实现了？！
对，用户要看到东西才能确定你想的做法对不对，你不能给他看，他自然就无法判断
当然，绝大多数开发平台、语言、工具是无法做到：
在需求分析时就让用户有“系统”可以“运行”起来“使用”的
那就没办法，老老实实在文档里写吧，再图文并茂也不如用户能直接交互的
有工具可以做能交互的原型，但是，最好是能当着用户的面，针对用户的意见直接修改
因为用户此时的意见仍然不一定对，只有（低成本、快速地）真的把他的意见实现了
他看到了不合理的地方，才会发现自己真的错了（当然，前提也是他不是死要面子的人）
delphi就是最高效的win32桌面应用快速开发工具，没有之一，不但开发快速，运行也快速（意外）
只是已经多年不再流行了
实在没有快速开发能力，就需要【典型示例】了，
之所以一直强调典型，就是要求这个示例能明确区分自己和其他选择的不同后果这样用户看了结果才能知道哪个选择才是自己想要
注意，这种示例不是UML里的用例图（User Case），除非你的用户是同行，能接受用例图
有了这些，管理软件的开发应该不再是噩梦，MIS的成功率应该也会大幅攀升
同行们也可以有真正的舒心日子了
作者：sz_haitao 发表于2013-1-27 22:44:28 原文链接
阅读：45 评论：0 查看评论