读文章小结，《离职了，总结的一些系统分析的经验》

因为这篇文章里提到的情况和自己公司很相似，所以拿来小议一下。

 

本公司虽没上市，但公项目合并、规模迅速状大，招了一批又一批，走一也是，人员流动性很大。

 

公司壮大，需要产品迅速完善，创新，打开新的销售渠道，来支撑整个公司的稳步前进。产品完善没有整体规化，想到哪改到哪，在哪发现问题随时更改，但新的需求总是在制作的过程中不断地被提出，今天这个有想法，明天那个部门有想法，各有各的想法，经常找开会提出新的需求变更。影响了一些日常正常的工作。因为老总是要先看到做出的效果再提意见，所以东西做的很急，刚开始讨论不到位，导致制作过程中又遇到很多问题。

 

公司高层对项目不是很重视，投入甚微。

 

很多想法决定的太突然，一拍脑门定了。

 

对于一个面向公共（大用户群、非公司内部系统）的产品，要充分进行“二八“划分；一个产品不可能满足所有人的需求；要关注最广大的80%的用户，因为另外20%的需求很可能会使另外的80%的人产生困扰；同样我们产品只有20%的功能是经常使用到的，对于互联网公众平台来讲对另外不常用的80%需求的“重视”，只会分散开发制作人员的注意力，使用户体验、易用性、可操作性下降，并增加系统复杂性、维护和运营成本；现在经常跳出来个客户说我们要打印系统，一篇必须多打点，不想打的的可以隐藏。明天又跳出来一个，我们不想显示产品类型，我们公司的不全，还得找。今天能不能多个这功能，明天能不能做这个东西。公司想有朝一日收几十万会员的会员费，照现在这种情况到时需要几百几千人来维护公司会员。

 

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

 

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