第廿四节：如何对已有产品中找到问题本质点（1）

         我们通常会在产品工作接手一个一个中途插入的产品，或者是抛来的需求，这些内容错综复杂，久而久之被大家形容为接盘侠。其实做一个接盘侠也是不错，锻炼的就是大家的火眼晶晶。本节讲述的是如何对已有产品中找到的问题本质点，其目的是回应第廿三节讲述的：如何对已有产品找到切入点干起来。

         当时，接手“高血压及公共卫生慢病疾病管理”这个产品时，属于中途切入，在已有团队中有比我从事此产品开发的技术前辈。现实的问题是：（1）根据高血压的管理规范要求，对高血压分级管理中分层分级出现错误；（2）按一个街道一个村统计群体高血压分层分级的报表速度慢；（3）每次遇到研究需要，修改分层分级需求的规则时，始终出现数据报表出现错误，并且会将之前统计好的报表内容，再打开看时与当时数据已经对比不上了。

      我是刚加入团队，在团队中属于一个新手；在医疗行业已经做过3、4年，相对现有团队而言在医疗领域的行业经验多一点。如何开展呢？

一、了解产品概念、以及细节内容

具体大家可以在百度搜索“高血压分层分级管理规范”的知识。这里特别提到一点，高血压与高血压高危是一个让人会产生误解的概念。从字意上讲，高血压高危比高血压严重的多，但实际情况高血压高危是指快高血压了但还没有到高血压。了解血压的水平分级、危险因素、高危危险因素、靶器官损害、生活习惯等。通过这些产品概念的学习，对业务规则内容进行梳理，并整理成文档，作为产品知识库。

二、从细小点入手、追溯全过程

        还记得，当时是潮鸣社区，一次社区医生反馈某人的高血压随访的评估好像不对。接收到此问题后，与医生沟通，并从业务知识，逐条判断，手工测算几次，发现产品提供的评估数据有出入。由此，与开发人员沟通存在的问题，想复现存在的问题，发现并没有问题。更加奇怪的是客户后来打开界面修改保存后，结果奇迹般发现评估数据正常了。

        由此，花了2天时间查看开发人员写的代码，查到的原因是，新增条件下，某一个危险因素被排除在外了；在修改重新保存后，代码里执行的是另外一段的代码，将此危险因素纳入在内了。通过本次代码的查看至少存在以下问题：

（1）易变的业务算法与界面层、数据层耦合紧密。

（2）新增、修改所使用的分层分级业务算法各自一套，部分计算调用又相互穿插。

（3）随访业务使用的分层分级业务算法又各自一套。

三、从产品架构角度引入分层机制

以上问题被发现后，引入分层机制，数据层、中间层、界面层。因考虑到已有系统在运行，因此，在做产品设计时引入逐步替代的过程：

1、先做数据层分离，将数据库直接引用的地方直接封装未数据处理层，作为一个方法引入，而不是将所有的业务逻辑中穿插数据库每次的SQL语句书写，调用等。

2、将核心的高血压分层分级的业务算法，独立为中间业务层，并根据系统时间设置，业务规范调整时间与版本，设置不同的算法入口。所有使用到分层分级算法的界面调用，都调用公用算法。

3、将中间业务层单独编译为一个组件；有业务变化时只更新此业务组件即可；不用暂停整体网站或整体网站页面及组件全部更新，降低系统升级的风险。

四、引入社区试点，保障全面升级后的应用。

五、整体产品稳定运行，彻底解决了分层分级总是不对的问题。

待续。