产品经理已经成为现在十分热门，但是门槛极低的岗位。但是随着时间的推移，专业度不够的产品经理们越发越步履维艰。我是一个从小白选手做了6年到一家全球30强公司成为产品总监，我希望可以帮到更多的人，让志同道合的我们，共同贡献中国的互联网产品。
介绍了“找寻定位”中的“公司定位”的三步法则。本篇我将要重点就“找寻定位”中的“部门定位”来进行深度剖析。同样，我会先讲总结归纳性的道理，然后再给出我的亲身经历。毕竟是自传，亲身经历必不可少。
「方法论」
“部门定位”这个事情很多人不会去做，因为他们没有沉下心来去发现：当仔细分析了部门在公司的定位后，能够改变他们在公司的言行举止和处理事情的态度、方法，以及最重要的——资源。因此大多数人只是随着自然规律发展而去发展，要知道，人是群居动物，任何人都有着影响周围的能力，至于怎么发掘和运用这个能力，很多人却忽略了。
直奔主题。我在做“部门定位”时候关注三点：
业务方向
兄弟部门
内部定位
-业务方向
部门的业务方向分为To C方向、To B方向、To G方向 和内部方向。不同的方向有着不同特点。关注自己所在部门的业务方向是十分重要的：能够使自己清楚的识别部门的核心需求方是谁，核心的协作方是谁，核心的依赖方是谁；以及他们的办事特点、沟通特点等。
-兄弟部门
识别了自己部门的核心需求方是谁，核心的协作方是谁，核心的依赖方是谁；这就已经识别出了兄弟部门。那么同样，要去关注兄弟部门：他们的核心需求方是谁，核心的协作方是谁，核心的依赖方是谁。也就是“多想一步”的思想。这个思想，我会未来在我的人生自传中经常提起。希望我可爱的读者靓仔和小仙女们能吧这个概念尽早消化。
-内部定位
明确了前两个要点后，最后一个“内部定位”就变得顺理成章了。因为通过对部门的业务方向的了解，自己就可以知道所在部门的需求方。很大程度上需求方决定了部门在公司内部的地位，部门的公司内部地位直接决定了自己在公司的成长。
三者结合：
To C （面向消费者）：这类部门往往扛着较大的KPI压力。部门需要尽一切可能去满足市场和消费者的需求，甚至是竞争对手的压力。所以他们拥有着极大的调动公司内部人力、金钱资源的能力。比如运营部门：为了提升公司用户注册率、下载率、转化率等指标，必须经常做活动。此时一个活动，可能又会是：需要BD部门去线下扩展一些场地和合作，需要市场部门去投放大量投放广告（地铁站、火车站、别的APP上内嵌等）来支持活动的举行；产品部门需要针对运营部门活动作出活动页面的规划，产品部门需要按照规划开发出来相关的活动页面和落地页面，测试部门随后跟进测试，运维部门随即按时上线。之后大数据部门（就是我的挨千刀的部门啊）要配套的根据活动定义相关分析指标，并且和IOS、Android开发人员协作数据埋点等工作来进行相关活动数据采集，最后和和数据分析部门联合开发数据分析报表。一个流程下来，基本上全公司都在为一个部门服务。然后活动结束后，财务部门再做收入和成本核算。最后一看，效果不错，这运营部门算是KPI达成了。苦了我们这群后勤部队（咳咳，我没抱怨，我奉献，我开心🙃）。这类部门对大经济环境因素十分依赖：顺风是大爷，逆风是dog。
To B（面向企业型）这这类部门都是和别的公司层面进行合作的。这种部门往往比较重，他们更多的接到的是来自于客户定制化的需求。因为面对的企业，所以带来的收益也是比较大的，而且这类部门有一个很大的特点：就是往往企业级别的合作往往是长期的，而不是一两年就结束了。因此可以认为，只要不太差，进了坑，就算占住了，而且是躺着挣钱。这类部门有个优势：经济大环境不好，逆风时候往往是神。这就是为什么近些年互联网流量已经饱和，很多大厂开始纷纷涉足做B端生意，挣企业的钱，就是这个道理。这类部门往往有着相对独立的体系，有一个小型的团队围绕着他们，就是让他们去满足客户的需求。可以理解为VIP部门了。
To G（面向政府型）这类部门就更厉害了。一旦和政府部门对接上了合作，那么内部资源基本上都会给他们优先让道。在公司内部的可调动资源更是多，自然部门话语权也更重要。更有甚者，部门的领导可以很大程度上影响整个公司的决策。这类部门，基本上就是SVIP了。但是有一点对于部门内员工的弊端：就是往往政府单位的需求都是高度定制化和政策导向，因此产品经理和需求方分析师等人员的作用就不大了，弱化成“传话筒”。因此若是想在产品经理这条路上好好发展的选手，一定要慎重。
内部方向。典型的就是运维部门、开发部门以及我亲爱的大数据部门。这类部门都是做support的。用一句老话“我们是块砖，那有需要往哪搬”。我们有个可爱的昵称叫做“基础服务部门”。因此我们不会直面可盈利的用户。但是这类部门虽然为支持部门，但是做“老实人”还是“狠角色”就看部门自己的努力了，这一点我会稍后再我个人经历中讲到。
「我的经历」
入职后，我就在大数据部门。这个部门的职责主要是提供业务所需的BI报表系统和临时性数据采集。然后随着工作过程中，我发现，临时性数据采集的需求太多了，为什么呢？首先，运营部门的活动很频繁，每次又都是有着些许不同，导致我们无法做出来一个BI系统页面供他们查看业务分析数据。同理市场部门、BD部门也是这样的情况。那么我们面临的情况是：要从大海一般的需求中梳理出适合做成系统的需求和临时性数据采集的需求。每个需求再评估可行性和实现周期。特别是临时性需求：频繁、定制化严重、需求时间紧。导致大数据工程师变成了数采工程师（我们叫蔬菜）。但是这样下去不是个办法，怎么办呢，我们分了三步：
采用工单系统，任何需求提交数据需求工单，按照要求填写，不合适不做，有数据产品经理把关；
数据产品经理在接到需求的时候，需要和业务方明确数据需求的真实意图，因为很多时候他们也不知道应该分析什么，只是胡乱一把抓，先看看再说（关键还说XXX总要今天下班前看数据）。引导需求方，提出最有价值的数据采集需求。
数据产品经理给出人员工作量计划和工单排期，能做成系统就不让蔬菜们搞，这样一来，苦了数据产品经理们，但是部门解脱了，可以更加专注于有价值的产出。
这里我分享一个我当年梳理的数据产品经理的工作流程图，就是如何来规范化部门内部工作流转的。（我们始终要记住，产品经理是部门的大脑，要能指挥该干什么，不该干什么。至于能不能指挥动，这个在以后我会讲“软实力-提升话语权”）。
现在回想一下，若是当初干运营，现在估计早就不至于脱发这么严重了吧。开玩笑一下，运营也很累，毕竟每天绞尽脑汁算计你们这些消费者，你说是不？
作者：白羊武士弗拉明戈 就职于世界30强合资企业。 现任产品总监，数据产品经理出身。喜欢讲课，喜欢分享，只讲亲身经验，不照本宣科。我有故事和酒，只要你愿意听我讲。
如果想要学习资料，请发送邮件：742305837 @qq.com
请注明目的。或者留下你的邮箱，注明想要什么。只要我有，就给你。
当然，也欢迎交流。
