今年有幸作为公司大型系统开发项目的产品经理，主导整个项目的需求。
一年以来，经历了不断的流程优化、架构设计、需求设计、功能优化等，有一些遗憾、也有一些收获，记录下来，给自己一个反思的机会。
总览
一个系统的开发是一个由简到繁，再由繁化简的过程。
项目中的部分模块需要由简到繁，强化功能，实现对差异场景的兼容性。
而有些已开发的模块，则需要由繁化简，优化实现的逻辑，剪除和调整不产生价值的和重复的功能和需求组件。系统的设计过程是一个从战略层面，以开发的思维考虑整个系统的构架体系；而在战术层面，以业务的思维考虑如何紧密贴合业务的需求场景。
而无论哪个层面，都需要对业务需求核心思想的理解和运用，而这是一个不断摸索和学习的过程。业务需求核心思想，我认为最重要的，是这项业务得以生存的和创造核心价值的内容，而通常这2者是一致的。
而项目需求的本质就在于，找到这个核心价值，围绕这个价值进行强化升级，配合和辅助这些价值进行延伸。
项目：
架构
- 考虑整个架构，重点在于底层表之间的关联关系，和每张关键表的作用范围。
- 架构中，要注意操作表和属性表的切分，如当前系统中异动表一般就指的是操作，而合同信息指的是属性，合同签订又指的是操作。
- 一个系统要有一个中心，尤其在关系型数据库结构下，所有其他表都会围绕整个中心发挥作用。
业务
- 要争取业务方的配合，要让业务方代表深度参与到整个项目中。
- 告诉业务方，需求本质不是为了减少人力，而是降低风险，提高作业附加值等。
需求
- 需求要标准化，要尽早的建议每个类型模块的需求标准，指引IT统一的，范式的开发，规范代码。
- 需求不要真正被业务方主导，业务方对需求的理解是片面的、有倾向性的、甚至是内在矛盾的。
- 系统的好用性：一个好の系统，需要即使没有系统说明书，用户也可以通过简单的摸索上手使用。而不需要大量的培训；在设计系统需求时，需要时刻牢记，这个功能对用户来说，是否合乎常理。尤其是一些系统自动功能，对用户来说要有就应该会这样的感觉，而不是怎么会这样的感觉。
- 开发一个新系统，必然会遇到有一些特殊场景。这时候，很重要的一点就是怎么把特殊和常规相隔离。这个隔离的逻辑和定位什么是特殊相关联的；所谓特殊，就是不可理解的、反逻辑的、可变的、不稳定的、小概率。如果不隔离，会导致系统整体不可理解、不易维护、变动大、不稳定，并伤害效率。
总的来说，就是需要兼顾灵活性和稳定性.
超越需求
- 鲁棒性：有些系统对于稳定性的要求非常高，对于这种高标准的系统。在实现需求的前提下，要做好风险防范。既对可能产生的系统bug，开发bug处理功能和问题件处理模块。这样，可以避免局部的系统异常，影响大范围的数据异常，导致大范围的报错信息。
- 安全性：对数据信息类系统，要优先考虑数据的安全性管理，尽早建立有效的权限管理和安全防火墙。
数据库
- 注意主键和外键等约束的设计
- 注意事务的创建，将一系列操作作为一个整体执行，避免只执行一半（回滚特性）
- 为常用的特定任务建立存储过程
- 触发器：对变动的数据进行检测，发现错误则回滚；数据变动后被触发并取代变动操作。