取款系统维护不给出款怎么办 写给业务型产品经理的第一堂课（上）
APP宣发
在我还上学的时候，有一本很流行的经管类（成功学）书籍 –《把信送给加西亚》，原书至今我都没有读过，但是背封上的介绍依然印象深刻。
当美西战争爆发后，美国必须立即跟西班牙的反抗军首领加西亚取得联系。加西亚在古巴丛林的山里，没有人知道确切的地点，无法带信给他。美国总统必须尽快地获得他的合作。这时有人对总统说“有一个名叫罗文的人，有办法找到加西亚，也只有他才能找得到。”
他们把罗文找来，交给他一封写给加西亚的信。关于那个“名叫罗文的人”，如何拿了信，把它装进一个油布制的袋里，封好，吊在胸口，划着一艘小船，四天之后的一个夜里在古巴上岸，消逝于丛林中，接着在三个星期后，从古巴岛的那一边出来，已徒步走过一个危机四伏的国家，把那封信交给了加西亚——这些细节都不是重点，重点是：麦金利总统把一封写给加西亚的信交给了罗文，而罗文接过信之后，并没有问“他在什么地方？”。
工作之后我才发现，类似“把信送给加西亚”的事情时有发生。
比如老板有一天会看着你的眼睛说“我们要做暗盘交易了，你去做一下暗盘的风控吧！”，或者是“这个季度打算把期权交易做了，你来搞一搞？”，好一点的情况是，老板在把信交给你的同时，会告诉你第一站该去哪里、如何走完第二站，做一盏明灯照亮远方的路，你要做的是不管用小跑着、徒步着还是摸爬滚打着，从此岸到达彼岸。但是随着一家公司的业务纵深发展，可预见越来越多的情形是没有人知道终点在哪里，作为一线的产品经理，你将不得不孤独一人的在未知的道路上探索，没有退路没有后援。
本文主要讲的事情，意图在于说明白一个业务型产品经理如何能独立搞定一块业务，成为送信的罗文。愿你在远方的路上自在独行，Enjoy 🙂
当企业发展到一定的程度，往往一些基础或横向的业务已经具备，如果企业希望能够继续往前走，自然会触及到能力圈的边沿，逐渐踏入深水区。此时作为业务产品经理的你，经常会临危受命，指派给你一块看起来不怎么难的活儿，说“给你3周时间，怎么样？”，但是这种一句话可以描述清楚的事情（比如“把信送给加西亚”）对你来说太大了，大到不知道该怎么下手，好比一口锅盔饼，硬到不知道如何吃下第一嘴。当然，你的任务是最终把事情搞定，至于如何把事情搞定，这个问题对别人来说不重要。
事情还是要做的。梁宁大师曾经在公众号“闲花照水录”中写过一篇文章，名为（我真的建议产品经理们认真读一读）。文章开篇所谈的是：不要谈产品和功能，多谈服务和特性。
为什么呢？举个例子：
比如说我们生产一个打孔机，用户要的是这个吗？
其实用户不需要一台打孔机，用户需要的是墙上有一个洞。
如果你定义自己在做的不是一个产品，而是一个服务的话，你的逻辑就会变成：我需要提供怎样一种服务让用户的墙上有一个洞？
那至少有几种方案：
第一个就是做一个打孔机，然后卖给用户；
第二个就是做一个打孔机借给用户，或者提供一个服务，用户需要的时候，我就上门去给他打孔。
以用户得到这个孔为目的去提供服务，而不是想着我要做一个打孔机，然后卖出去，这就是产品和服务的区别。
产品的对象是打孔机，服务的对象是用户。以产品为中心做思考的产品经理，产品谈得越多越容易陷入到对产品本身的自嗨之中，而忽视了真实的用户需求，这是非常要不得的。
有了“服务即产品”的意识，下一个问题是：实现需求的服务（业务）流程该如何制定呢？为了尝试说明，我们还是以打孔为例，拆解“给我一个孔”（也可以是“把信送给加西亚”）的服务设计流程。
假设我们提供的钻孔服务，是通过施工师傅完成的，那么服务流程中至少需要两个角色：用户、和钻孔师傅。完成服务流的过程是：用户提出钻孔需求，钻孔师傅开始钻孔，钻孔完成，明确这3个步骤后我们用泳道图（不明白泳道图是什么可自行知乎了解）表达一下这个过程：
（点击可查看大图）
貌似还少了些什么？比如在现实生活中，钻孔师傅总不是和用户黏在一起，随叫随用的吧？可能是用户一通电话，联系到钻孔师傅预约好时间，然后钻孔师傅上门服务。那钻孔作业完成后，孔的大小、口径、深度最终需要经过用户的验收，如果没有达到用户期望的标准，验收不合格该怎么办？是不是钻孔师傅就要做修补的工作，重新钻孔了。
于是可以得到一个更详尽的服务流程图：
（点击可查看大图）
修改点：
1 增加用户通知环节；
2 增加钻孔师傅上门服务环节；
2 补充用户验收环节，和合格/不合格情况下的流程。
这样，一个整体的服务流就完成了，看起来很简单。首先明确服务范畴，确认流程中的角色，制定流程结构框架，再以“问题发现/提出 — 问题解决”的方式逐步理清细节脉络，是一个产品业务流设计的通用拆解思路。如果能get到这一点，那么写到这里就可以全文终了，你已经具备一个业务型产品经理从0到1设计服务流程的方法了。
接下来尝试用该方法完成一道测试题：请设计一款“基于区块链技术的分布式基金代销系统”的产品服务。没有思路？那可以继续往下看。
接着上文讲，如果要设计一台ATM机该怎么做呢？假设我们把范畴限定在“取现金”服务上，那么服务的全流程又是什么？
沿着这个问题，我们做一下ATM机的服务流程设计。从一个用户取现钞的视角看，完成取现过程有这么几个步骤：插银行卡，输入密码，输入取现金额，ATM机吐钞，退卡。
整个服务过程中，有两个参与角色：用户和ATM机。我们将两个角色的交互流程用泳道图绘制出来，大致得到这么一张图：
（点击可查看大图）
仔细看又觉得好像有点不太对，比如说用户的银行卡是由招商银行粤海街道办分行发卡的，用户的钱也是在银行柜台存入的，那么此时一台位于宝安大道上的ATM机如何帮助用户实现读写银行卡，并且吐钞取现的呢？
再去多找一些ATM机和银行的资料，可以得出常识性的了解：ATM机是银行的终端机，内置有CPU和通信模块，也有负责存储现金、用于存放现钞的内置保险箱。
一台ATM机
因为有CPU和通信模块，所以当用户输入卡密码、填写取现金额时候，这段经过加密后的信息是经由ATM机传到银行后台，由银行后台做校验判断处理，再将“成功/失败”结果返回到ATM终端的。因为有这样的交互流程，所以除了用户和ATM机外，还需要引入一个新的角色：银行。
用户的钱是预先存在银行的，能够取出的现钞一定不能是无限的，也不能透支银行卡的吧？所以银行后台要去判断用户取现的额度不能超过卡余额。假如用户取现的额度是少于卡余额的，银行判定可以正常取款，但是存放在ATM机内的现钞也是有上限的吧，碰到的用户是思聪少爷，一次性要取10个亿怎么办？那么ATM机也要做判断，用户的取现额度不能超过ATM机存储的总现钞。
更新一下服务流程，会变成：
（点击可查看大图）
修改点：
1 密码校验：用户输入密码后，经ATM机通信传至银行后台，由银行后台校验密码是否正确；
2 检查银行卡余额：卡余额的数据是存储在银行后台的，用户输入提现的金额，由银行后台检查卡余额是否足够；
3 检查ATM现钞余额：ATM机检查现钞能否足够，能够给客户提取。
接下来继续按照“问题发现/提出 — 问题解决”的方式，补充更多服务细节。
比如将ATM机投入到测试使用中，发现有很多用户想要在出钞完后顺手打印取现凭条，那该如何满足用户的这个需求？为了完成这一附加子服务项，就要在ATM里再内置一个打印机了，打印机的正常运转还需要有油墨、有纸张等耗材。区别于主服务流程的“取现管理”，也要新增加一套“硬件管理”的子服务了：
（点击可查看大图）
修改点：
1 新增打印凭条流程，用户在取现结束后，可以选择打印凭条。由ATM机硬件管理完成凭条的打印。
在整理上面所有过程的时候，并没有考虑流程失败或者拒绝的情况，这样处理的好处是可以在完成主线流程前排除干扰。在主线流程丰富到一定程度后，就需要补充失败或者拒绝的流程了。
比如说，用户输入密码错误的情况，假如连续输错三次以上，机器就要吞卡了。吞卡之后，又需要联系用户到指定网点取卡；用户取现的额度超过卡余额的时候要给用户报错，让用户重新输入一个正确的金额；ATM机保险箱内现钞不足，无法完成用户的取现操作，更严重一点，如果ATM机现钞少于一定额度，就需要停机维护了。
补充完失败/拒绝的情况，流程图会变成：
（点击可查看大图）
修改点：
1 密码校验失败：如果密码错误，用户需重新输入；如果密码连续错误三次以上，机器吞卡并通知银行和用户；
2 卡余额不足：卡余额少于用户取现余额时，提示用户余额不足；
3 ATM机现钞不足：ATM机现钞不足时，取现服务暂停，通知银行维护。
看到这里，感觉一个完整的服务流程应该已经做完了吧？那我再来提几个拷问灵魂的问题：
1）用于打印凭条的纸张和油墨用尽了，打印机无法正常使用怎么办？
2）用户取现10000元，ATM机一股脑儿只吐钞100元，怎么办？
3）ATM机每次取现吐钞都多了，过了一个月还没有发现，怎么办？
4）ATM机吐出假钞被用户投诉了，怎么办？用户拿假钞找银行碰瓷，怎么办？怎么界定ATM机内有没有假钞？
5）用户的银行卡被人盗刷了，怎么办？
6）ATM机遭到暴力破坏，怎么办？
以上提及的都是需要解决的现实问题，是在主线服务流中可能遇到的异常流，异常流的处理的好坏决定着你能否保证服务品质稳定的输出。主线服务流的工作也许只用得到2成的脑力去思考，但是异常流的子服务设计需要用到8成的脑力。所以看起来一个“如呼吸一样简单流程”的ATM机，要保证服务运行的品质，背后有很多个岗位在做支撑。
总结一下，完成服务流程设计的过程是：
1）明确服务范畴；
2）确认流程中的角色和角色之间的关系；
3）拆分泳道图，拟定服务流程的初步主线框架；
4）以“问题发现/提出 — 问题解决”的方式，补充附加子服务的处理流程；
5）补充错误/失败/拒绝等服务流程；
6）发现异常流程，设计新的子服务流程处理异常。
流程设计过程和完成一张素描很像：1 先打好素描轮廓；2 再确立阴影关系；3 不断补充细节。
这个起形会比较累，是真的累，细节比较多，一点点画就好。首先先分析确定一些点，比如肩膀的点、头顶、左侧、右侧，然后画垂直中线，再画肩膀所在的横线，然后慢慢画出其他部位。
这张是开始铺色啦，可以看出我的铺色排线是顺着一定的方向排的，排线最好不要乱排
、
这张已经开始刻画啦，左右肩膀和头部已经刻画完成，开始画颈部了，刻画的过程就是要耐心，细细观察。
*图片来自于站酷，作者。
最终素描的完成度可能是在初期难以想象的（学过画素描的同学应该很好理解）。
2.5
因为ATM取现服务是串行的、单边的，所以在实际中新业务的起手复杂程度是超过做一台ATM机的。至少有下面3种情况会增加服务流程的复杂度：
1）并发
什么意思呢？比如在ATM机上，一个时间段内只允许有一个人使用，第二个用户先站后面排队，这样不可能两个人同时操作ATM机的，服务流程相对简单。
做电商业务则会不同，可能有1000个买家同时下单抢10双联名鞋的库存，买家太多鞋不够卖怎么办？如果发生了一双鞋同时卖给了10个人怎么办？
2）双边/多边
ATM/银行与用户的关系，是“服务提供方 — 服务消费方”的关系。类似于Uber这样的业务，是“服务提供方（车主）– 中介平台（Uber）– 服务消费方（乘客）”的关系，你需要在同一时间内，处理好车主、Uber和乘客的服务匹配，多个主体的服务流程拆解难度是要高于只有两个主体的。
3）两流（信息流和资金流）
这类情况多发生在电商/金融业务里，比如说你通过支付宝付款购买了一部 华为Mate 30Pro，账户里现金立马少掉¥6299，但这只是一个数字串的变化（信息流），真实的资金转移的动作（资金流）是发生在商户、银行、支付宝的清分和结算的时刻，因为有这样的业务逻辑，产生了信息流和资金流的分离。如果再算上 华为Mate 30Pro 的快递运输，还会产生物流。
为了说明如何做好并发、双边和两流的处理，以富途证券（欢迎下载注册开户，长期招人欢迎投递简历）的融券卖空业务为例，做最简单的说明。
首先确定服务范畴是：客户可以借到证券，再将证券卖出以实现卖空。
再整理一下整个服务流程中的角色：
融券人，是指融券后卖出股票的人，融券人可以从券商处借到证券卖空，或者买入证券归还券商。
出借人，是指持有证券的人，将证券借给券商从而获得证券的利息收入。
券商，扮演了中央对手方的角色，出借人首先将证券借给富途，然后富途再将证券借给融券人，而不是出借人直接把证券借给融券人的。
这个业务流程中并发的情况体现在，同一时间内可能有1000个客户去融少量的100张券。
双边体现在“融券人 — 中央对手方 — 出借人”的关系上。
因为证券业务是交易T+0，交收T+2，有天然信息流和资金流，因此也存在两流的情况。
对于并发的情况，思路是先完全不考虑如何做处理，主流程完成后再调整。也就是说，先假设只有一个融券人、一个出借人，最后再引入多个融券人、多个出借人的情况。
对于双边的情况，思路是先处理完成两个单边，然后再合并为一个双边。比如对于融券，可以先理清融券人和券商的关系，理清券商和出借人的关系，然后将两套服务合并为一套服务。
举例说明一下
1）一个融券人与券商，在融券过程中的关系是：
（点击可查看大图）
2）一个出借人与券商，在借券服务中的关系是：
（点击可查看大图）
融券人只有一个，券商只有一个，出借人也只有一个，不用考虑并发和双边的情况，看起来很简单嘛。
3）接下来将两个服务流程合并为一个。过程中会发现，因为出借人不断的“出借/回收”证券，导致券池在不停变化，如果因为券池的减少而产生可融券的额度不够用，就需要对融券人做强行要求还券的流程了：
（点击可查看大图）
修改点：
1 合并流程；
2 新增券池不足强制还券的流程
两流情况的处理也比较好理解，上面的示例是在交易盘中的信息流处理，资金和证券的交收则是在T+2收盘后进行的。对业务足够了解，按“问题发现/提出 — 问题解决”的方式是可以继续推导出“资金流”的处理流程的。最后再考虑并发情况下可能会发生什么问题，需要什么样的特性做支撑，那么整个服务流程就算整理完了。
读到这里，也许实现一个基于“区块链的基金代销系统”的服务你已经有思路了（了解区块链和基金代销原理会很好入手），至少对于一个普通基金代销的主流程，花点时间是可以搞定的，类似这样：
（这张没有大图）
通过业务服务范畴的定义、流程的定义，一个产品经理可以明白不同特性的全局和部分的关系，并且有能力hold住核心服务的品质输出。接下来，请拿你的服务主流程
1）多和自己的研发聊一聊，因为你的方案可能导致研发成本失控；
2）多和合规的同事聊一聊，因为你的方案可能在监管条例下压根不成立；
3）多和营运的同事聊一聊，他们会帮你提出你可能未曾想到的问题。
然后将自己的思路书面化下来，翻译成大家都能看懂的语言，俗称“需求文档”。此时要恭喜你，可以达到40分的水平了。
结尾
《写给业务型产品经理的第一堂课》是给在一线的产品经理们的，上半部分想要阐明的事情是“如何实现完整的服务流程，并且保证核心服务品质”的方法。下半部分会从产品的其他角度做一些设计的拆解。
曾经也自我过这么一个问题：对于人才的培养，希望能够达到怎样的能力是合适的呢？这个问题我给出答案是“期望能够达到取代自己的能力水平”，对我来说一直是这样。
感谢阅读，全文未完。
参考资料：
梁宁：在腾讯的第一堂产品课——菜鸟产品经理还是有专业度的产品经理
梁宁：产品思维30讲
