系统分析师的经验的一些总结

刚离职一家公司，刚在海外上市。由于公司上市后规模迅速，急于发展几个战略产品支撑，公司高层对我们之前进行的一个项目非常重视，投入很大。系统开发之初，需求非常明确，但在开发过程中总会提出新的需求。今天来了一个推广部的经理，明天来了一个市场部的总监，各有各的想法，各部门、分公司经常和开发团队开会，提出新的需求变更。因为项目经理的“软弱”，我们一般很难被抓。因为老板总想看到结果再发表意见，所以项目做的很匆忙。设计之初没有对系统框架进行充分的讨论和简化，感觉后续的开发存在很多问题。
现在他已经离职，无所顾忌。我来说说我对系统分析的看法，总结一下我之前的工作经验，如有不规范之处请指正。
做需求分析，我认为最重要的任务是简化业务流程、规则和逻辑；丰富用户体验；
0。尝试将复杂的用户需求抽象成最简单的业务规则和数据库结构来实现它们。因为需求不能一下子确定，比方说我们刚刚给核心需求的实现增加了一点复杂性，比如增加了一个表和一个耦合字段，那么我们可能要制定更复杂的规则来适应未来的扩展，从而被“强迫”消耗更多的工作，使用更复杂的结构和业务规则。尤其是在需求不断变化的情况下，改变这个系统的成本也会呈几何级上升(因为一般是不可逆的)，用户的可操作性也会更低，增加了他们的使用难度，所以不得不进行培训。
1。对于面向公众的系统(大用户群，非公司内部系统)，“二八”要充分划分；一个系统不可能满足所有人的需求；关注绝大多数80%的用户，因为另外20%的需求很可能让另外80%的人吃亏；一般来说，人们最容易记住少于7个单词的句子。同样，大多数软件只有20%的功能是经常使用的。对于互联网公众平台来说，“关注”其他80%不常用的需求，只会分散开发者的注意力，降低用户体验、易用性和可操作性，增加系统复杂度、维护和运营成本；所以要重点开发那20%的功能。
2。对于核心产品，业务规则和逻辑的设计一定不能操之过急，不要集中在“一类”人身上；要从全局角度制定业务流程，从一开始就应该将最终用户和开发人员包括在业务流程、规则和逻辑设计的团队中。并充分讨论简化后的产品整体框架设计，然后进入编码阶段。综合考虑成本/效果比，摒弃可能对系统造成混乱的设计，尽量寻找最简单的替代方案。并且尽量一开始就确定数据库的主框架，而不是制定出每一步的细节。
3。对于功能庞大、业务复杂的系统，我认为用户需求接受比例在5:3:2左右是很正常的，相当于10个需求中有5个是可以完全接受的，3个是需要稍微改动才能达到目的的需求。但一般1~2个需求实现不了也是正常的，因为可能会给系统造成更大的复杂性或者不利于扩展，很可能会和现有系统一样。不利于系统结构的简化和增加系统运行成本的不可控风险。
4。当公司的旗舰产品经过多次功能扩展和升级，导致架构的复杂程度、数据库负载、稳定性、可操作性和用户友好性都有一定程度的下降时，应考虑将不相关的功能分离到几个相对独立的系统中，只共享核心数据表，以增强各子系统的可重用性和可靠性。从而避免了复杂只输出到大系统，导致可靠性降低，维护运营成本增加。