您当前的位置:
离职了，总结的一些系统分析的经验
刚在一家公司离职，这是一家刚在境外上市的公司。因为公司上市后规模迅速状大，急于开发几款战略产品支承，公司高层对我们之前进行的一个项目非常重视，投入巨大。系统开发之初需求原本很明确，但新的需求总是在开发的过程中不断地被提出，今天来了个推广部经理，明天来了个市场部总监，各有各的想法，并且各个部门、分公司经常找开发小组开会提出新的需求变更。由于项目经理的“软弱”，我们一般很难拘绝。因为老总总是要先看到做出的效果再提意见，所以项目做的很急，系统框架在刚开始设计时没有被充分讨论、简化，感觉在后续开发中遇到很多问题，
现已离职，也无所顾忌，特谈一谈对系统分析的看法，总结一下之前的工作的经验，有不当之处请指正。
做需求分析，我觉得最重要的任务是简化业务流程、规则、逻辑；丰富用户体验；
0. 尽量将复杂的用户需求抽像成最简单的业务规则、数据库结构来实现。因为需求是不可能一下子就确定的，假设我们刚开始对核心需求的实现方式增加了一点点的复杂性，比如说多加了一个表，一个藕合字段，那么对于以后的扩展我们就有可能要去制定更加复杂的规则去适应，从而“被逼”消耗更多的工作，使用更加复杂的结构和业务规则。尤其当需求发生不断变化时，改变这种体系所要花费的代价也会随之几何级上升（因为一般是不可逆的），用户的可操作性也会随之越低，并增加了其使用上的难度，从而不得不对其进行培训。
1. 对于一个面向公共（大用户群、非公司内部系统）的系统，要充分进行“二八“划分；一个系统不可能满足所有人的需求；要关注最广大的80%的用户，因为另外20%的需求很可能会使另外的80%的人产生困扰；一般人最容易记得7个字以内的句子，同样大部分软件只有20%的功能是经常使用到的，对于互联网公众平台来讲对另外不常用的80%需求的“重视”，只会分散开发人员的注意力，使用户体验、易用性、可操作性下降，并增加系统复杂性、维护和运营成本；因此要将主要精力放到那20%功能的开发上。
2. 对于核心产品，业务规则和逻辑的设计万不可草率，并且不要集中由“一类”人去做；要从全局的角度制定业务流程，最好一开始就将最终使用和开发者纳入业务流程、规则、逻辑设计队伍。并充分讨论精简后完成产品的整体构架设计，然后进入编码阶段。综合考量成本/效果的比例，舍弃对系统可能产生混乱的设计，并想办法最寻找简单的替代方案。而且尽可能一开始就确定数据库的主体框架，而非去制定每一步的细节。
3. 对于功能宠大、业务复杂的系统，我认为用户需求接受比在 5:3:2 左右是正常的, 相当于10条需求中有5条可以完全接受的，有3条需要将实现方式略加改变而达目的，但一般有1~2条无法实现是正常的，因为可能会对系统造成较大的复杂性或不利于扩展，而且很有可能跟现有系统的功能产生冲突。不利于系统结构最简化，增加系统运营成本的不可控风险。
4. 当公司的主打产品经历过数次功能扩展、升级后，而造成的构架复杂性、数据库负载、稳定定、可操作性和用户友好度下降达到一定程度时，就应该考虑将关联性不大的功能分离成相对独立的几个系统，只进行核心数据表进行共享，以此增强各个分系统的可重用和可靠性性。从而避免只向一个大型系统输出复杂性，造成可靠性下降，以及维护、运营成本的上升。
------解决方案--------------------
很有道理。
------解决方案--------------------
5:3:2跟我们的情况也差不多。问题是那2如何去说服客户。
------解决方案--------------------
各个公司都有各个公司的情况和不足，世上没有完美的公司，所以才需要改善。
可是，那儿有更好的公司能让我们做一辈子，难找呀。
------解决方案--------------------
------解决方案--------------------
项目管理中，人、事、资金、时间、质量诸多因素，都很重要。
其它：
排在第一位，整体管理、范围管理。
范围管理={项目章程、项目定义、项目目标、……}
范围管理做得不好，就会引发需求多变。
重视范围管理，再通过需求管理+配置管理，控制需求变更
------解决方案--------------------
现在比较流行敏捷。但是敏捷不是一种具体软件工程设计技术，而只是一种项目组织要求。于是就有人又回头来强调具体的设计技术，强调要预先设计好、预先谈好、事后要重构之类的书本上多的是的条条框框，就又走向僵化的极端。最后，只能又回到一种似是而非的玄学态度，来讲应该几分靠死抠技术，积分靠见风使舵。
唉，周而复始，表面文章。何时有一个创造性的做法出来？
------解决方案--------------------
风险控制，基于用户需求的灵活调整，一直以来都是难题
使用系统的具体人员也不是一成不变的，再加上用户方相关的政策或方法调整，设计足够灵活的适用性好的系统平台，需要在一开始分析用户需求时下足功夫
------解决方案--------------------
其实我们的项目也遇到LZ一样的问题，现在脑袋正大着呢。
------解决方案--------------------
总结得挺好，但是我现在不做软件需求开发了
------解决方案--------------------
有时候,客户的需求本身存在矛盾;
不同角色客户存在不同的需求意见;
而且他们的需求意见还经常固定;
导致客户需求的重新评估;增加成本;
------解决方案--------------------
我认为很好啊.
"任务是简化业务流程、规则、逻辑；丰富用户体验"
但如何去确定出简化业务流程、规则、逻辑.
是很难做到的.
若项目上头头是很"弱"的话,项目会被老总,各个部门牵着走,可怜程式员,接着就是不断修修改改.
累啊.