MS Project客户端选型带来的接口约束设计

PM Suite案例选择直接采用MS Project作为客户端，这个决策看似省去了”客户端本身不需要设计”的工作量，但实际上带来了另一类不可回避的设计任务——PM Suite后端必须支持MS Project客户端所需的、有标准约定的接口，也就是说PM Suite后端要”模仿”微软的Project Server，实现一套名为”Project Server Interface”的接口来支持客户端。具体而言，特定版本的MS Project Server通过Web Service支持320个函数，PM Suite系统当然不必实现所有320个函数，而应该根据PM Suite的实际功能要求，确定MS Project客户端和后端正常交互所必须的那些函数，并只实现这个子集。这个案例揭示了一条容易被忽视的设计原则：选择直接采用一个成熟的第三方客户端（而非自研）不等于”减少了设计工作”，而是把设计工作从”客户端本身怎么设计”转移到了”后端如何精确对齐第三方客户端的既有接口约定”——这种转移往往更难，因为接口约定是别人定的、不能修改，只能被动适配；而且必须先系统性地梳理出这320个函数里哪些是自己真正需要的功能子集，既不能遗漏（否则客户端某些操作会失败），也不必全部照单实现（否则会做大量无用功）。这正呼应了[[确定关键功能的四条启发规则]]中”识别真正需要的子集”这条判断原则——只不过这里判断的对象从”业务功能”变成了”第三方接口函数”，判断标准从”业务重要性”变成了”客户端-后端交互是否必需”。