前言
众所周知，互联网行业的产品经理每天需要与形形色色、不同岗位的人沟通，上至老板，下至测试、客服等。产品经理的日常事务性工作有一大半都花在了与不同岗位的沟通协调上，自然在工作中也会和各岗位产生诸多交集。都说产品经理是CEO的学前班，所以就该你这么忙。那么在团队协作中，产品经理与各岗位之间的工作界限是如何划分的？对于很多“佛系”的产品经理可就是个难题。下面我们就来聊一聊“佛系”产品经理在日常工作中是怎样处理的。
与运营的爱恨交织
行业中，很多人都会认为运营与产品是不分家的，他们需要共同为产品的绩效考核指标负责，为用户体验负责，所以这两个岗位的工作界限真的是说不清，理还乱。
记得某一年的4月份，运营总监找到我，说老板需要一份关于产品的年度规划方案，对于这份方案，老板只有一个要求，希望今年的新增用户达到1000万，要求在一周内完成方案。听完后，我的直觉是这应该是一份关于运营的年度规划，哪里是产品设计、产品研发的规划方案。听完后，我试图向他解释说明，这是一个运营工作中关于拉新的方案，不是产品的规划方案，也不应该由产品经理来编写这份方案。唠叨了半天，我的解释说明是无效的，最终还是被运营总监怼回去了，他认为这个目标的完成，和产品设计、研发关系紧密，需要我们产品研发部先给出一份年度规划方案。然后还和我说了一堆，产品经理也需要对考核指标负责，接着还向我说明了他的思考方向与思路。
就这样，一脸无奈的接了这么个重要任务。方案中，将1000万的目标拆解到每个月，从运营的手段，产品的改版、优化，营销策略等几个维度来规划具体工作。后来这位总监还找到我，帮忙完成了多个营销活动方案的策划，甚至活动效果的总结。说实在的，也感谢他给我安排的这些任务，提升了自己的全局性思维，提升了自己看问题的高度与深度。
与设计师的千丝万缕
日常工作中，产品经理与UI设计师、视觉设计师之间的沟通合作也很频繁，大家都同属设计这一宽泛领域，只不过产品经理强调的是逻辑设计、结构设计，而他们更多关注的是视觉效果层面。
视觉设计师通常是在收到产品经理的原型设计后，才开始处理视觉显示的问题。很多视觉设计师都是直接按照原型的布局、结构、甚至颜色来设计界面，在他们看来只需要做好给页面配色，仅仅处理好这个层面的视觉显示问题就算完成了工作。如果做完后，发现还需要调整按钮或文字的位置，修改字体的大小或字体，他们会认为这是产品经理的原型设计有误，没有明确表达出这一效果。在与这类设计师工作配合中，我们只能尽量严格要求自己，提高原型的保真度，按钮的位置、颜色、字体的选择、字体的大小，还有一些阴影、透明度效果尽量表现出来。
有一次在做高保时，需要从网上抠取一张图片，当时想找一位设计师帮忙，那位设计师貌似有些不耐烦的说道，抠图这么简单的事情都不会啊，哪个产品经理不会使用PS。所以，只能自己琢磨如何抠图，当即从百度搜索了一些抠图的技巧，业余时间还将框选、套索、魔镜、钢笔等所有的抠图方法系统性的学习了一遍，从此抠图不求人。
与程序员的不打不相识
产品经理与程序员打交道的机会就更多了，他们之间的故事不胜枚举，在很多公司这两个岗位似乎总是对立的，产品经理与程序员的撕逼大战每天都有人在上演着。不是程序员在抱怨产品经理不懂技术、更改需求，就是产品经理在抱怨程序员的研发能力不足、拖延需求等。
对于很多没有技术背景的产品经理来说，在与程序员沟通的时候，会显得格外困难，当你在和他们描述业务需求的时，他们的评估反馈通常是这样的：这里需要一个什么样的接口来实现，这些内容存储在客户端本地会比接口调用效率更高；数据库应该怎么样设计，包含哪些表，表里包含哪些字段。他们不停的向你反馈这些内容，以表示他们对业务需求的理解，希望得到你的确认。相信很多产品经理，在听到程序员的这些话，是处于一脸茫然的状态。如果你不能明白他们这些话，随意进行确认，而事后等到测试阶段又发现了问题，这个时候在去找程序员去提BUG的时候，程序员通常会觉得这个产品经理不靠谱，又是在随意更改需求，同时也会引发很多争吵的声音。
既然程序员不能在沟通中转变他们的思维，如何理解专业的开发术语，了解一些基础的技术原理？那么身为产品经理怎么办，我们只能自己去学习了解接口能够实现的功能、了解接口规范，了解数据库设计的一些基础理论。懂得去分析哪些功能或者内容，需要依赖于接口的开发传递，哪些功能或者数据更适合客户端的本地开发，了解在前后端接口联调过程中有哪些注意事项。
记得曾经有一位技术总监要求我监控程序员的开发进度，他让我建立了这样一个表格，罗列出项目中包含的页面，每个页面包含的接口，接口的名称、接口的说明、接口的完成情况、接口开发的实际工作量。在技术评审会上，他们要求我一起参与确定关于接口的名称、定义、说明，确认数据库结构、数据表的字段设计。起初，在制定、维护这样的项目进度监控表时，遇到了很多困难，心里也有过很多抱怨。因为按照这样的要求来监控项目进度，必然需要产品经理对开发常用的技术原理非常熟悉，这样的进度表似乎有点超出了产品经理的监控范畴。虽然对于这样的项目进度监控，还是头一次，完全从技术开发的角度来监控项目进度，但确实也让我学到了很多，对技术原理的认识更加深刻了。
与测试工程师的唇亡齿寒
大家都说产品经理需要对产品的结果负责，所以上线前的需求确认自然成为了产品经理的份内工作。在上线前，有些产品经理都会仔细确认产品的文案，确认产品的核心功能是否完善，操作流程是否顺畅，业务流程是否正确。很多时候，其实是产品经理和测试工程师一同对产品质量负责，甚至在上线后出现重大问题，产品经理可能是第一责任人。
我们团队的测试工程师都没有编写测试用例的习惯，他们总是说很忙，认为有了详细的需求用例，没有必要在编写测试用例文档。所以在阅读需求文档时，常常会要求我们将需求用例写的足够详细，包含哪些操作步骤，期望输出结果，限制条件等。为了满足开发、测试他们的要求，希望从他们的思维角度能够准确理解业务需求，编写PRD时，再一次妥协了。在需求文档中，当你将需求用例描述的尽可能详细时，意味着你对用户操作流程的理解也会更加深刻，对很多细节的把控也会更加到位。
我们的测试工程师还有一个习惯，在测试过程中，如果遇到不清楚的需求或者不能推动开发解决BUG时，通常会在禅道系统中将问题提交给产品经理。每次产品进行大版本的改动时，都能收到来自测试提交的几十个BUG。他们不愿意做推动问题解决的第一人，这个重担还是落在了我的身上。有时候一个BUG问题可能会牵涉到好几个开发之间的配合，所以我想这也是测试工程师将一些BUG指派给我的原因，麻烦事都落在我的身上。但从另一个角度来说，我也感谢他们，正是因为这样的一些经历，使得我在开发项目中遇到问题时，能够较快的定位问题出在哪里，并给出一些建设性的解决方案，开发同学们也更愿意与我合作了，对我也多了一份信任。面对项目实施中遇到的问题，也能更从容应对。
最后的总结与期望
”佛系”产品经理的工作似乎没有边界，在沟通过程中不够强势，工作也比较辛苦，劳心劳力。身为一个产品新人，自己还不够强大时，很多“佛系"产品经理的一些习惯能够促使自己变得更加强大，能够获得快速提升自己综合能力的机会。平时工作当中谦虚点、低调点、温柔点，从某种角度上来说，吃亏也是一种福分。”佛系”产品经理能够锻炼自己的意志，不断提升自己的综合实力，使得自己成为团队当中不可替代的一类人。
佛系产品经理是团队当中的多面手，哪里需要就去哪里，遇到问题不闪躲，快速解决问题，是团队当中的救火队长。“佛系”的做法，只是我们在职场当中打怪升级的一些方法，但并不等同于工作中没有立场，没有原则。希望各位产品人，能够利用自己“佛性”的一面，提升自己的综合能力，在工作中，绽放你的光芒。
