团队中的产品经理最近提了几个问题，趁此机会做一下分享。
这是产品问答的第四篇，也是《百尺竿头更进一步》的下篇，主题是提升自身业务能力。
问：
我觉得我最大的问题是，脱离了基础工作，我有点不知所措，我还可以在哪方面去做更多~
答：
作为产品团队管理，提升业务能力也非常重要。
什么是产品业务能力呢？
产品业务能力有，业务理解、业务建模、业务抽象及业务解耦等。
业务理解
一个合格的产品，不能停留在被动接收信息、接收需求的层面。要主动走出需求范围，往前探究产品需求产生的源头，即产品所要满足的业务情况。
产品相当于海面上的冰山一角，真正埋藏在海面下，支持产品的是实际业务。只有深入理解了业务，站在更宏观的角度，才能更清晰更全面的看到产品本质。
冰山.png
前几年做的互医平台，是针对乳腺癌单病种单科的辅助诊疗业务平台。当时接手后发现系统很多功能混乱、重复，而且能没人说的清楚为何要开发成这样。于是决定从已成型的系统泥潭中脱身，重新开始理解乳腺癌的实际业务。
首先，我花一个月时间阅读乳腺癌诊疗最专业的两份指南：欧美的《NCCN指南》和国内的《中国抗癌协会乳腺癌诊治指南与规范》，建立对乳腺癌发病、诊断、诊疗等方面的基本认识，同时也梳理出一个问题集。
屏幕快照 2019-03-12 上午10.42.42.png
u=1074354051,1799881711&fm=26&gp=0.jpg
然后，我找几位合作比较深入的科室医生，提出我的问题集和一些个人看法。通过他们的热心解答，我基本建立对乳腺癌诊疗更完整的理解。
回头看，原来的系统和真实的业务隔了一层纱，很多功能建立在模糊不清的信息上。
上面说的业务是2B的，其实2C业务也有自身业务源头：产品背后的商业逻辑、用户的实际场景等，需要你自己去搜集、分析和理解。
业务建模
建立业务理解后，如何让业务转变为可实现的产品方案呢？
从业务理解转化到产品方案，要通过两层检验：业务建模和产品战略。
对业务建立了基础认识，就算入了一半行了。不会再出现听不懂业务人员的问题或描述的情况，也可以更深一步和他们进行沟通交流。
这时就需要搜集更加全面的业务信息，通过和业务环节的各类代表沟通，逐渐建立对实际业务的全面了解。这里说的不是他们想要系统实现什么功能，而是他们现有业务场景下的行为逻辑。
我建立了对乳腺癌诊疗的基本业务理解后，开始对多个科室的业务人员（主治医生、助理医生、护理人员等）进行访谈调研，这里用到我上篇文章所讲的“全程录音”。全面了解不同科室的业务路径，如何筛选患者、患者如何挂号、如何看病、如何确诊、如何安排手术、如何进行术后治疗、如何随访等等。然后先把不同科室的业务路径分别绘制流程图并确认，最后再把多个流程图整合为一个更完整的业务流程图。
最后总结一下，业务建模就是，基于基本业务理解，通过深入访谈调研搜集并完成业务流程图。
成型业务流程图，还需要产品战略的指导和检验，在之前的文章中有详细说过，这里不再赘述。
业务抽象与解耦
业务抽象是指对要实现的业务中的重复性进行归纳，业务解耦是指对要实现的业务中的逻辑环节进行拆分。
首先说要实现的业务。建立完整的业务建模之后，需要进行实现范围的确定。不是所有的业务环节我们都要通过信息化产品来满足，寻找合适边界是实现业务的第一步。这个部分未来会找机会详细解说。
前面对业务抽象和业务解耦的解释，听起来都比较难理解，我用例子来分别说明。
在乳腺癌诊疗平台上，患者在复诊时要进行挂号预约；在化疗阶段，每个疗程患者都需要确定化疗日期；在内分泌阶段患者需要确定配药日期。
原有系统对于上述几个业务，都分别作为一个单独的功能实现的。
深入分析后可以发现，不论是挂号看医生、预约治疗还是预约配药，其实都是对医院服务资源的预约、分配和使用。根本逻辑都是，供给方安排资源和资源限制条件，需求方对资源进行预约和使用。
基于上述分析，我们把所有类似的业务都通过：资源安排-资源产生-资源预定-资源消耗的业务流来实现，就是对上述业务的抽象。
同时我们发现，上述业务流，每个节点都有不同的业务规则。
比如，
资源安排，有些资源需要配置医生、配置地点，有些资源需要配置限制条件（自费患者才可以使用）。
资源产生，有些资源即时生效，有些资源要在固定时间才触发，有些资源预产量为一个月，有些则为一周。
类似的情况很多。我们就要考虑把各自需要管控的因素拆分管理。
把资源安排及限定拆分为排班模块，用来管理各种可被预约的资源及资源使用的限制条件；
把资源限制的部分信息放在患者信息管理中去实现；
把资源调整拆分为假期设置模块，用来灵活的根据假期来调整资源（包含已被预约的资源）；
把资源预定拆分为预约模块，用来比对资源的存量、资源的限制和使用者的信息，并最终决定预约结果。
这就是业务的解耦。
到这里，关于提升产品管理岗的三个建议就讲完了，希望你能有所收获。
网友评论