一些系统分析的经验

现已离职，也无所顾忌，特谈一谈对系统分析的看法，总结一下之前的工作的经验，有不当之处请指正。

  做需求分析，我觉得最重要的任务是简化业务流程、规则、逻辑；丰富用户体验；

    0. 尽量将复杂的用户需求抽像成最简单的业务规则、数据库结构来实现 。因为需求是不可能一下子就确定的 ，假设我们刚开始对核心需求的实现方式增加了一点点的复 杂性，比如说多加了一个表，一个藕合字段，那么对于以后的扩展我们就有可能要去制定更加复杂的规则去适应，从而“被逼”消耗更多的工作，使用更加复杂的结 构和业务规则。尤其当需求发生不断变化时，改变这种体系所要花费的代价也会随之几何级上升（因为一般是不可逆的），用户的可操作性也会随之越低，并增加了 其使用上的难度，从而不得不对其进行培训。

    1. 对于一个面向公共（大用户群、非公司内部系统）的系统，要充分进行“二八“划分；一个系统不可能满足所有人的需求；要关注最广大的80%的用户，因为另外 20%的需求很可能会使另外的80%的人产生困扰 ；一般人最容易记得7个字以内的句子，同样大部分软件只有20%的功能是经常使用到的，对于互联网公众平 台来讲对另外不常用的80%需求的“重视”，只会分散开发人员的注意力，使用户体验、易用性、可操作性下降，并增加系统复杂性、维护和运营成本；因此要将 主要精力放到那20%功能的开发上。

    2. 对于核心产品，业务规则和逻辑的设计万不可草率，并且不要集中由“一类”人去做；要从全局的角度制定业务流程，最好一开始就将最终使用和开发者纳入业务流 程、规则、逻辑设计队伍。 并充分讨论精简后完成产品的整体构架设计，然后进入编码阶段。综合考量成本/效果的比例，舍弃对系统可能产生混乱的设计，并想办 法最寻找简单的替代方案。而且尽可能一开始就确定数据库的主体框架，而非去制定每一步的细节。

    3. 对于功能宠大、业务复杂的系统，我认为用户需求接受比在 5:3:2 左右是正常的 , 相当于10条需求中有5条可以完全接受的，有3条需要将实现方式略加改变而达目的，但一般有1~2条无法实现是正常的，因为可能会对系统造成较大的复杂性 或不利于扩展，而且很有可能跟现有系统的功能产生冲突。不利于系统结构最简化，增加系统运营成本的不可控风险。

    4. 当公司的主打产品经历过数次功能扩展、升级后，而造成的构架复杂性、数据库负载、稳定性、可操作性和用户友好度下降达到一定程度时，就应该考虑将关联性不 大的功能分离成相对独立的几个系统，只进行核心数据表进行共享，以此增强各个分系统的可重用和可靠性。从而避免只向一个大型系统输出复杂性，造成可靠性下 降，以及维护、运营成本的上升。

 

需求变化是非常常见的问题，如果出现问题只能说是架构师有问题或者软件生命周期模型选择有问题。正常的设计是欢迎需求变化的。

项目经理或项目主管是项目成功最重要因素 业务+管理缺一不可,如果还是技术出身,那项目失败就没天理了 ! 目前在读微软的秘密,虽然是老书,但软件开发场景的论述很是不错

 

有的时候，市场专员为了完成自己的业绩。往往会满足客户的所有需求，客户以为买了系统就应该帮着他去完成一切可以完成的工作。这只是一个美好的愿望。现在 绝大多数的系统都不能100%的完成客户的需求。

不太同意需求接收比，这个是一个很虚的数字 接受情况还是要分析客户需求，能抽象出通用性功能肯定要做，是否要立即开发，还是要看重要性，根据产品具体情况可以给客户一个时间表，让客户心里也有着 落。具有行业特点的可以考虑做行业插件或放入产品中，完全个性化需求肯定是用客开方式解决。

通常这种情况，我都是直接给客户或者老板说，你说的功能很好，我们会在sp2中实现，但目前这个版本不能改动， 一改动会拖项目进度，并且很容易捡了玉米丢 了西瓜。如果是老板，可能更加客气点，说服他，如果是客户，就左耳进，右耳出，中间全是好好好，下个版本吧。。。呵呵

应该站在用户的角度看问题，只要是合理的都应该满足，由于技术的限制，实现上可以打折扣，用户一般都能理解。 我不敢苟同，2/8的方式，那20%才是成熟的体现，才是优势，少了这20%，到了特殊的情况系统就运行不下去.

与同类产品相比，那20％的功能往往出附加值和竞争优势的地方。

没有哪个系统从开始就能设计好，这是肯定的，后续的多追加修改，也是肯定的。不知到你们的产品啥意思，现在在设计时基本的原则尽量是装配件的形式，后续的需求都是plugin。 何况设计自己的产品何其艰难。如果面向的是行业软件，还是需要有一些顾问来做分析的，不是所谓市场部和总监一类人就能搞定的 ，再说 人人水平不一样，提的要求自然也就不一样，你遇到这样的情况也正常，上市公司也是刚上市，看看用友和金蝶，需要的是一条持续发展的路。国内多少公司都想做 自己的产品，结果呢，成功的少数还是。遇到具体问题，仍然需要修改，其实软件就是客户化开发， 除非你弄个中小企业来用，如果你的公司没分量，中小企业也会 要求你客户化开发。做产品，不是有个项目经理就行的。打个比方吧，金蝶的bos那是多少个系统架构师和顾问以及多年的实践经验才得出的成果，而且每次开发 也是需要客户化开发的，你碰到这些问题，实在是不算什么问题。主要的一点是，每个公司都有每个公司的文化，你改变不了什%E