最近看到简书上作者“绿小豆” 的《 复盘总结：和外包开发对接的那些事儿》。
作为一名乙方的产品经理，也近期感触颇深，想记录一下自己的工作感悟。
因为第一次尝试写文章，很多地方都是个小白，告诉自己不要怕，进步是点滴积累的。
最后感谢“绿小豆”的这篇文章，因为我是看了这篇文章，才开始自己的尝试，也套用了你整体的一个框架来补充自己的内容，如有不妥，请私信我。
在正式开始之前，先对我们公司的工作流程做一个简单介绍：
基于我是乙方，项目的选择不是我能决定的。通常都是公司分配给我的项目，我会先自己梳理出思路，然后和业务一起去甲方公司，根据他给我们事先提供的文档和我整理的疑问点，进行交流。
我们公司的流程是，业务先去谈合同，收集需求，然后整理出架构图（先不管是否准确....）然后带回来，我根据他梳理的很多点，先去问业务本人，最后再去和甲方沟通。
这就造成了，很多需求需要二次理解，很多需求要进行二次匹配。很多项目我都是中途参与进来，有时候不敢保证我是从收集需求就开始进入项目的，所以这也是我认为流程出现问题的环节。
当然这不是我应该纠结的问题，我要做的是从参与的那一刻，去根据所有给我的文档，梳理出关键点，好和甲方对接的时候，是有效沟通，能准确的理解到甲方的需求。
我和甲方对接的经历，会从以下进行说明：
1.乙方产品经理的定位
2.项目流程
3.对接中出现的问题
4.反思和总结
一.乙方产品经理的定位：
在乙方做产品经理不只是要做好需求收集，整理，把控项目节点等工作，更好的是协调部门内部资源，充分做好资源调动。
因为很多乙方外包公司，不会每个人手里只有一个项目，不论是产品，设计，研发等等，人手至少几个项目。
就拿设计举例，你的case已经设计完，交出去，当你第二天想要修改的时候，昨天参与的设计师已经安排了别的项目，所以这个时候，你就要说出你项目的紧急性，但是你不能和设计师去说，你要和设计总监去说，让TA来负责人员分配。（当然不同公司情况有所不同）
在保证项目节点的情况下，还要尽可能的把控产品质量，这个东西很多时候，不是我们一个人能控制的。（这时候就很考验一个产品经理的各方面能力）
二.项目流程：
我们公司做的项目大多数是企业官网，大多数的客户都有自己的网站，要么在此之上进行优化，要么放弃前有版本，重新开发一版。
我们前期需求收集都是由业务来进行的，业务收集到的需求，回来自己整理好框架，这时候我才介入。（当然不是说前期我不参与，只是大多数时候我都不知道他们手里签下了什么单，我还在忙自己手里现有的项目。都是等到公司进行分配的时候，我们才知晓，原来增加了新项目）
当我接手了项目后，就会进行：需求整理 —— 和甲方再次对接需求 —— 回来重新梳理，输出流程图，和甲方确认主要流程 —— 输出原型图 —— 和甲方确认 —— 输出标注文档，进行内部宣讲 ——交付到设计师手上 —— 设计后，甲方审稿，修改，定稿 —— 签署需求确认书 —— 进入研发 —— 提测 —— 交付。
这个过程中产品经理一定要知道每一个环节的进度，收集到各方位人员的一个项目节点，才能提前预估项目是否能如期交付，好及时进行反馈，沟通。
三.对接中出现的问题：
相信所有找外包的甲方公司都有一个最大的难点，就是乙方对自己公司的底层业务逻辑不熟悉。
做简单的企业网站还好，我曾接手一个项目，是做大型供应链平台，平台是电商属性，设计的功能点很多，涉及的业务点更多，这个时候就需要对整个供应链的模式有一个清楚的思路，从建立——销售——售后，都要很清楚。任何一个环节出现疏漏，都会让后期研发的时候出现很多问题。
往小了说做出来的东西很可能差强人意，往大了说，很有可能页面逻辑是不通的，造成项目相关页面都要重新来过，整个项目节点出现问题。
目前所碰到的问题，总结如下：
1.业务逻辑不清楚：涉及到一些自己曾没有接触过的项目，在平时使用中也很少接触的项目，这时候，对底层业务逻辑理解起来，经常需要去耗费很长时间，尤其在甲方自己都不清楚的情况下。（这时候，一定不要急着去做，不要懒，要多沟通，让甲方一起参与到业务逻辑确认这一步)
2.甲方对接人不明确：有时候甲方的对接不是一个人，很多时候，会告诉你这些都是我们的对接人，你有什么问题找他们就行。这个时候你就要明确，哪一模块的负责人是谁，是谁能说的算，而不是他说了之后，后期还要经常改动。大多数时候我们会建立一个项目群，有什么问题直接在群里说，可也要清楚的知道对方说的算的负责人是哪个，减少无必要沟通和修改。
3.需求把控 ：很多项目，业务签回来的时候，都有一个需求范围，这个时候我们要对合同内容有个大概了解，和甲方对接的时候才不会需求把控不住。
4.项目周期评估，及时反馈：大多数接过来的项目，都是很急的，交到你这里，不是一个月就要上线，就是让你几天内出设计稿。
不论怎么样，甲方给的时间节点，不是我们产品经理能改变的，但是从接手的那一刻，我们就要看需求，来预估这个项目周期，及时反馈给你的领导，这样你是需要人手配合，还是需要重新评估时间，都有一个提前知晓，而不是在后期做的时候，发现时间越来越少，交期日子越来越近，还有很多东西没有做。（这中间产品经理只需要评估自己的工作进度，然后进行反馈，根据原型设计出来，让设计师和研发那边来预估他们的时间周期，你做一个汇总，如果不能控制在时间节点内，及时反馈，让领导层知道，看是否需要和甲方重新评估时间）
四.反思和总结：
接手的项目中，有全部项目外包的公司；有甲方有自己的团队，外包一部分出去，双方对接；还有传统企业转型互联网行业，第一次建立自己的系统项目。
结合我和甲方沟通的经历，总结以下几点：
1.减少无效沟通：每次去之前都进行思路梳理，保证你每次去都是解决了问题的。
2.专业性：很多时候我们会让甲方的思路引导到一个有偏差的思维中，尤其新手产品经理。这个时候我们要拿出自己的专业思维，要去了解对方真实的需求，给对方提供解决方案。
3.学会拒绝，平等沟通：第一次来外包公司做产品经理，我开始以为甲方说的我们都要满足，不能拒绝。就算明知不能满足的，也不当面拒绝。
但这样毫无意义，合理的给出建议，采纳与否不重要，重要的是你要说出你的理解。
当然不能你说完了，就没有然后了，不能满足的原因是什么？如果这种方式不能满足，是否还有别的替代方案？
我碰到的甲方，很多时候，在我给出建议后，还是重新思考了，尽管可能没有按照我的建议走，但我们仍然共同思考了这个解决方案的最终实现过程，这是比较重要的，因为我们是平等的。
当我们在一起沟通的时候，我们是一个合作关系，不要觉得自己是乙方，自己不应该拒绝。（这里如若涉及到技术上实现的难点，这时候我们要和甲方说清楚，我们需要和技术来沟通，是否可以实现，实现的周期是多久）
4.合理调配资源：在各个环节的人员调动上，我们要有一个预估，在这样的周期里，我们需要怎样的配合，我们需要和各个部门的负责人进行内部会议沟通，保证有可调配的资源。
5.担起外部与内部的桥梁：作为乙方产品经理，对外部，公司内部的开发是我们的伙伴，我们应该尽量帮他们争取时间。对内部，我应该督促开发进度，保证项目节点在自己预估范围，产品经理担任着多重角色，要找准中间的平衡点。
6.时刻复盘：针对自己每天的进度和团队的进度，进行复盘。很多公司是没有项目经理的，像我们公司是有项目经理的，但是TA们都是在进入研发的时候才进入整个项目。所以，产品经理要时刻进行复盘，知晓自己是哪个环节出现了怎样的问题，进行及时调整。
7.情绪控制：不论在和甲方对接中，还是回来进行内部沟通的时候，产品经理都是一个重要的纽带，这个时候我们一定要对事不对人，有问题针对性的去解决。切记不抱怨，不去带给伙伴们负能量，永远记住，沟通是为了更好地解决问题。
作为乙方很不容易，很多乙方都喜欢开玩笑地说：“感谢甲方爸爸不杀之恩”。
但我认为，虽是乙方，我们也要明确自己的责任，不要因为我们自己是乙方，把自己区别对待了。
很多时候，我们碰到的甲方也许差强人意，也不会都很理解我们，但当我们能更多的去倾听对方的需求，彼此沟通，问题总会得到一个处理点。
作为乙方我们也多一些理解，多一些勤奋，多一些质量，多一些时间概念。
当然也希望甲方多一些耐心，多一些沟通。
这是合作的过程，但未来的甲乙双方，还未完待续....
网友评论