开发项目里面遇到的坑（持续更新）

根据学习的项目管理知识和目前经历过的项目，总结一下。同时后期转岗也可以拿来作为参考。

虽然是很基础的东西，但是没办法去判断你是不是能够避免这些坑。也就是起到一个，吾日三省吾身的作用。多一事不如少一事。用项目生命曲线来解释也是收尾阶段变更越大，风险越高。

一、项目类

1.如果项目中，甲方是子公司中的一个部门（例如：属于集团公司的一个部门），且对方用第三方的OA系统（比如：企业微信），那么需要明确对方是否在类似企业微信的oa系统中存在多个公司（即：多个appid、appsercet）。然后需要明确采用哪一个作为本次项目中使用的数据源。

2.项目中遇到多个部门合作的情况下，在另外部门的领导和下属员工都在的情况下去聊自己所需要的功能，并在聊完，艾特所需要配合的员工，防止另外部门的任务下发不及时。

二、数据类

1.在系统开发中，多部门存在的情况下。记得考虑是否需要做多租户模式或者部门权限层级。很多系统在开发阶段没有提出来，后期交付甲方要求有部门分级权限等等。那时候项目处理这种问题，采用临时方案的话，往往对系统维护增加难度。

2.在下拉选的时候设计<请选择>一类的字样,数据库给定默认值,方便数据的误操作回退

3.甲方对接人不专业的情况下，我们自身设计需要保证核心的功能点不出变化，后续甲方需求业务梳理清楚后（可能花费3-4个月的时间，人都是慢慢进步的），我们可能会需要重新对接、或采取新的数据结构。所以前期尽量保证核心点，扩展方面都做到可配置或者留待后面迭代。

三、需求类

1.在项目开发中，最开始需求往往很模糊，并且很多领导不在场，没有一个稳定有效的说话人，公司领导有要求先做好占坑。所以这时候把项目章程和初版需求设计等准备好。后期变更一次记录一次（毕竟咱不能委屈自己是不），形成有效证据，到时候要款都好要一些。并且前期要多想一想，同时拿同行业的系统去揣摩一下。

2.UI规范等等

3.做系统的时候,比如资产这一块,尽量用自己系统资产进行业务处理,外部资产宁愿写个绑定逻辑都不要直接使用人家的资产。那水务系统举例，自己系统资产和上位机系统对接，不要直接使用上位机资产，避免用户在业务层面上有资产细化或者额外资产信息需求。

四、自身提高

1.学会说话和表达。