一些工作中遇到的坑，引以为戒，避免再次踩入系统问题：
1、报表查询缓慢，拖垮其他应用速度
解决方式：
首先，报表查询和界面表单查询，都可以走只读库。
且对于报表查询，虽然查询量最大，单只需要支持查询延时数据（每天同步一次）。
而对于界面表单查询，信息量比较小，但需要满足实时查询最新信息。且查询频率比较频繁，就需要做好缓存的设计。
在系统功能设计上，也要区分报表查询和界面表单查询。
2、因为涉及成本核算，每次组织更换负责人，就需要创建一个新的同名组织（orgid不一样），关闭原组织并更名。
解决方式：
建立“组织-核算组织”，1对N的结构，一个组织生命周期中包含多个核算组织，系统记录核算组织的各个周期和对应负责人。组织记录当前负责人。
3、一些与组织ID（orgid）关联写死的规则，导致每次涉及组织架构调整，都需要检视一遍关联的影响
解决方法：
首先通过2的方式保证组织架构调整，组织本身id不变。
其次，对于一些需要写死到ID的规则，建议在一个统一的配置界面上，凸显出来，可灵活修改。
另外，对于复杂的业务规则，还是建立单独的func进行处理，返回type值。系统基本逻辑仅需对不同type，应用不同处理方式。
4、系统逻辑上设计了一些else的默认规则，有些场景没考虑到，
解决方法：
慎用默认规则，尤其是对于一些关键数据，来源必须匹配到对应type。如超出预设场景，应提示报错，且不予以处理。否则，会因为意外的场景而导致系统结果错误。
5、财务计算的脚本需要在每月3日执行，按照截止上月月底的数据源信息进行处理，但数据源信息每天都会更新。
解决方法：
通过复制的方式，在月底的时候将当前时刻的信息备份，等到需要的时候，获取使用。
6、开发的招聘人才库，因为数据量比较大，界面查询的表单内容，开发不让加排序规则。
解决方法：
采用ES搜素引擎，提高查询性能。（用空间换时间）
对于时效性要求不高的数据，可以在晚上空闲时间跑完排序，参照推荐系统。
减少界面中涉及到全表查询的功能。（比如任务总数显示）
7、流程在系统中写死，一旦业务逻辑发生调整，需要开发花大力气修改系统底层配置。
解决方法：
对于人事异动等，尤其是发展中的企业，流程都是很难稳定的。采用可配置的流程管理系统和配置功能，是有价值的。
但对于一些稳定的流程，需要通过定制化，对使用界面和交互等进行完善，避免频繁调整导致异常。
所以，需要在系统设计时，兼顾定制和可配置双方。
对于一些简单的审批、文书类的流程，建议还是做一个通用灵活的审批链管理平台（类似签报/审批系统）。
8、开发需要经常做一些数据处理，会占用很多时间
解决方法：
每次数据处理的脚本放git上，分类记录备档。
开发轮流做数据处理，集中时间做。
业务问题：
1、权限管理混乱
解决方法：
严格按照组织、组织树和岗位配置对应权限，避免单独配到人的权限；同时，规范每个人的岗位名称，当某个人的权限有问题的时候，监视岗位名称是否合理。
（公司需要对岗位，和对应的职责范围有明确的定义）
2、有些功能上线后，对其他模块的功能产生了影响
解决方法：
在系统功能确认开发前，需要把要开发的需求告知给所有相关的部门。系统功能开发后，需要联系需求部门进行UAT测试，业务方需要测试更广泛的场景。并通知所有相关部门，新功能的上线时间。
产品必须参与提测，避免最终实现的结果和预想不一样，尤其是前端交互。
3、有些大需求，开发不了解，没办法评估时间和问题
解决方法：
大的需求和计划，需要提前告知开发，让开发有所准备。对一些老的和不常用的系统、功能的调整，也需要提前告知开发。便于开发预先了解起来。
4、部门文档缺失，对于一些老的和不常用的系统、功能，需要通过查代码去理解
解决方法：
产品需要保存和上传需求问题PRD，并且完善好产品原型（很重要）。开发自己也要留下相关系统的文档，尤其是各
工作调动，做好以上材料的交接。
5、关于开发产品测试的工作关键
开发工作的关键：就是细致、周到的思考技术实现。评估开发时间是否准确，就是开发是否够专业的结果指标。
产品工作的关键：对于需求的透彻分析，就是产品的关键工作之一，要达到的效果就是能够清楚明白的说给开发听，有理有据有说服力。
测试工作的关键：测试就怕欠考虑。对测试的要求不是事无巨细的测。一定区分关键流程和关键功能。做到在关键功能上不能欠考虑。
6、如何接需求
找更上面的层级的人沟通，有可能一个需求来源于某个领导的计划，但具体传达的人并没有传达到真正的需求。
多方位、多角度的了解需求，兼听则明。
如果事情本身对业务没有价值，就没有必要再去优化它。
7、如何阐述需求
对业务、产品，应按业务场景讲述需求（用例法）
对开发，应按照界面结构和功能讲述
产品需求分析和设计的一些看法
1、需求的设计需要区分：核心和辅助模块
2、核心的设计需要对业务充分的理解，对未来的发展有一定的预期。一旦定下，就基本不会改变。是作为开发业务功能实现中的最底层框架。一个好的思路是，把需求元素拆的越细越好，然后分析核心是什么，并考虑好属性表、操作表、过程记录表的区别和作用范畴。
3、辅助模块的设计相对灵活，可参照敏捷开发的思路，采用多迭代的模式，测试和开发循环进行。
4、产品的风险控制：系统性风险、安全性风险、操作性风险、流程性风险。
5、系统性风险：需要在开发中，对异常进行管理。
操作性风险：做大量的用户测试和试运营，并且在操作端做好提示，在应用逻辑层面限制用户执行“非法”操作。
流程性风险：设计监控环节、质检环节，采用专业工具进行流程监控，检查流程是否自洽。