乙方产品经理：项目团队里的拆弹兵

　　一般来说，在合作关系中往往是甲方处于主导地位。但是作者却选择做一个乙方，究竟做乙方有哪些优势呢？
　　做产品经理，很多人都认为做甲方最好。为自己的公司做一款产品，看着它从无到有，逐渐迭代，就像对待自己的孩子，时时刻刻关注着它的成长，希望ta被人认可和喜欢。而随着产品的不断成长，产品经理也能安身立命，扬名于世。
　　但我并不这样想，我选择做乙方。
　　做乙方的好处在于，不确定性更高，挑战性更强，所以更有趣。就像开了一家侦探事务所，你会接触到各种各样奇葩的客户，无所不有的应用场景和光怪陆离的原始需求。拿上面的“养孩子论”来套，做乙方的产品经理，就像带着自己家孩子到处参加各种竞赛的父母，在竞赛的过程中，孩子的优缺点越发明显，ta未来的发展前途越发清晰，你也越来越明白，将来终有一天，ta将自己走上社会（开源和免费），创造出一个成熟产品应有的价值。
　　本文的题目是我早锻炼结束后忽然想到的。
　　在做乙方那些看似无穷无尽的赶任务赶时间点的日子里，我每天的工作无论是什么，其实目的都一样：为这个项目拆弹。
　　在互金这个领域里，甲方客户要么业务精专，要么技术力量强大，有的两者兼具。但即使两者兼具，也未必能很流畅的把一个互金项目做下来，其根本原因无非是：金融业务人员和系统研发人员无法沟通。如果这个项目无法流畅的做下来，那么最直接的解决方案就是找一个乙方来完成。
　　一个项目到了我手里，通常离甲方大领导要求上线的时间已经不长了。这也难怪，人家自己都能解决的问题，还找你专业的乙方团队做什么呢？所以，上线时间紧，外系统多，环境复杂，沟通困难，这是一个乙方产品经理必须要面对的问题。
　　拆弹组，go，go，go！
　　一直幻想着有一天，我可以拿着一份问卷，让客户填完之后，就能了解客户对项目目标的期望和真实需求，就像医生给病人看病之前，都是简单的问几句之后就上仪器各种测，拿到监测报告再继续问诊那样。
　　然而现实似乎并不太美好。
　　客户既不会乖乖的坐下来挨个回答你的问题，也不一定能准确的描述他们的需求。甚至他们连自己想要达成的项目目标也不清楚。这时候，我是应该发怒吗？Oh，no，参考上一节最后一段。
　　拆弹的要义在于在一堆电线回路中找到触发爆炸的主线。有些电线虽不是主线，但剪坏了并不会导致爆炸，而另一些电线，剪掉了不但不能阻止爆炸，还可能导致爆炸。对于这种任务，最好的方式，就是先观察客户每个部门、每个关键人物的关系，然后再开剪。
　　需求调研或讲标的会场上，于茫茫与会者中，忽然听到一个声音：你们产品支不支持我们这种先限制申购然后限制赎回，然后给50岁以上女性加息给60岁以上男性发体验券给投资总金额超过10万的投资者发红包的需求？在电光火石之间，那些只言片语就像电影慢速播放一样在大脑中拆解为无数个片段，找到最关键的点，1秒后，需要微笑的回答：“那你们需要怎样认定投资者的属性标签呢？”
　　庖丁解牛
　　寒冬的帝都常常是雾霾重重和天高云淡相交织的天气，这种干燥而凌冽的季节，也通常是各家互联网公司要冲年底业绩的时候。自家研发的金融平台历经一年还没有什么成果，必须要花点钱请苦逼的乙方出面消灾了。
　　这个时候的甲方颇具那种玩了整个小学初中高中，在高考前一个月忽然醒悟过来的高三生气质，常常抱着试试看的态度提出一大堆“不可能完成的任务”，然而当你推说不可能全都实现的时候他们又迫不及待的说就实现某某某也似乎大概可能应该可以。
　　互金的平台，需要完成的业务内容，与传统金融业其实并无二致，难点若说有，只存在于实现方式层面。想在交易场景中完成投资和融资，也许可称为余额理财或消费金融、供应链金融；在多市场交易的同一或类似品种套利，无非是要实现虚拟的跨市场交易；当下时髦的互联网理财品种，大多是大拆小，长拆短，期限错配：拉直资金流，无论多少次交易，只要遵循NPV0便无不能攻克之敌这时候，总想起“道法自然”这句话。互金业务并非镜花水月，它只是真实世界的另一种表现，不需要被创造，只需要仿生。
　　看到急上房的客户，不由得心生感激：江山父老能容我，不使人间造孽钱。于是操刀过来，把需求大卸八块，开始细细往前推。有些客户对这种大开大合的方式很喜欢，但另一些大概是安逸惯了，对于花钱雇了一个天天倒催他需求的”强势乙方“还很有怨言呢。对于他们我个人倒是觉得，就跟上健身房似的，你花钱给我做私教，那我得对你八块腹肌负责是不是？毕竟那几块肉没长在我身上不是？
　　慢慢来，比较快
　　客户对时间都有要求，而且通常很紧。如果跟着客户的节奏一通乱跑，那不但会拖垮自己的节奏，而且项目延期的可能性更大。于是，慢慢来，似乎是更好的解决方案。
　　慢慢来的前提是掌握项目的核心障碍在哪里。是项目需求本身实现起来困难，客户内部意见不一致，客户系统环境太复杂，抑或其他问题。也许需要花80的时间来找到这些关键点并且去解决它，其余20的时间在写代码做实现。关键点拆解的越细，解决方案越明确，代码实现就越快，而不是先驻扎一批开发进场，然后反复确认需求。
　　作为拆弹组成员，如果在你的心里真的在意那个炸弹上的倒计时，那只能说明，你对自己的拆弹技术本身就缺乏信心。