一.目录
前言
内容
结语
二. 前言
失败的项目原因有很多，成功的项目原因不多，成功者不管说什么其他人基本上不会质疑。驾驶机动车要通过驾校培训，然后取得驾驶证，如果没有驾驶证都敢开车上路，那么发生事故的概率很大！社会套路年年深，什么是套路呢？套路是事物的规律。
根据我的了解现在软件行业有一大部分项目都缺少规范研发流程，原因无非是：小团队简单点、整个流程下来天都亮了；产品、测试、开发一人搞定，美名其曰：”减少成本“；没有这方面意识。做了与做好是两个不同的层次，事情本身没有对与错，如果你要建设类似”平安金融中心大楼“的建筑却使用了搭建毛草房的技术、方案、方法，项目最后基本以失败告终。不同的时期有不同的思维，凭经验但无科学依据，把问题归结为“玄学”，问题依然没有解决。
三.内容
设计好的接口要从以下几个方面入手：
行业通用知识
专业的人做专业的事，敬畏专业，不要拿自己的业务爱好和专业人士比较。现代社会是高度分工、互相协作的社会，不同专业的人掌握不同的技能与思维。老板与经理、主管与员工，企业根据不同的职位遴选相应的人才，做到事人匹配，发挥所长。
不管是做产品设计，还是技术研发都要拥有相关业务知识。比如：
E-governance（电子政务）
ERP（企业资源计划）
IOT（ The Internet of Things 物联网）
Cloud Computing（云计算）
Smart City（智慧城市）
还有大电商、保险、支付等业务这里就不一一列举了。
客户需求
产品团队负责把客户（客户可能是运营、甲方，产品团队自己）原始需求转化成产品需求，研发团队必须准确、全面、理解需求并且按时、按质完成。
- 需求评审。需求流转到研发团队之前已经评审过多次，研发至少要参与一次产品讲解需求
- 根据原型，渐进明细梳理需求。需求通常是复杂、依赖性和关联性强，先列出概况，然后由点到面、渐进明细进行设计。比如用户登录功能：
- 用户名，密码是否填写
- 忘记密码怎么处理
- 多次用户名，密码错误怎么处理，从安全角度讲有没有记录操作日志，频繁操作有没有锁定账户功能
- 用户是否注册
- 用户账号状态是否正常
- 用户登录成功后有没有活动需要弹出
有些逻辑是代码层面的，产品团队不一定要能想到。比如，发优惠券功能，产品同事说领取优惠券数量没有限制！但是，做为有经验、有职业素养的开发人员需要提出来这是不合理的，需要限定领取数量。
标准化文档
这里所指的是接口文档。
- 接口命名规范。简洁明了、通用、表达准确，风格统一
- 标准数据。入参、出参数据格式、字段命名、字段类型、编码、意义在各个接口中基本相同
参考历史接口
笔者在对接某第三方支付接口时，就发现其中一种业务的接口命名、字段命名与其它接口风格迥异，如果两个团队开发的也是可以理解的，但内部还是缺少沟通
- 设计新功能接口时，要熟悉之前接口、功能 ，可以通过查看历史接口文档、看代码、访谈之前的开发人员。这样可以有效避免设计新接口时有遗漏、兼容功能问题
- 参考历史接口还有一个重要原因就是要保持接口风格统一、减少服务端开发人员学习成本、减少与前端（外部）沟通成本，使接口文档易维护、看得懂。
公共接口
设计接口要特别留意公共接口，需要把它设计好、归类好，做好接口复用。
参考：
这里还要补充一下，接口文档要归类好，建议按业务归类，接口中文名、目录名要简洁明了、表达准确，方便阅读。
民主集中制
- 接口设计采取一人主笔、全员参与。一人主笔可以保证质量、风格统一，全员参与可以提高团队凝聚力、积极性。
- 某个版本指定一个人来梳理需求，其是主要的设计者；其他人配合他设计，保持业务连续性、准确性。
- 后期可以采用轮流主笔，全员参与，集体评审。为什么要后期？因为要先定规范、立标杆。
- “三个臭皮匠，顶个诸葛亮”，团队赢，个人赢。依靠团队、培养团队、让团队成长，进步，一个人成功取决于他身边的人，西游记里观音菩萨身边的花花草草听了经也成“精”，有点像数学上的平均数、中位数。
当然，团队要良好的沟通文化，不错的人员素质，否则容易产生不必要的矛盾。
四.结语
网上有的程序员经常吐槽领导没有套路出牌、同事瞎写代码，其实每个人都要去反思、复盘。改变可以改变的人和事！
