〖全域运营实战白宝书 - 运营角色认知篇④〗- 与运营打交道的小伙伴

---

大家好，我是 哈士奇 ，一位工作了十年的"技术混子"， 致力于为开发者赋能的UP主, 目前正在运营着 TFS_CLUB社区。

---

💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬 📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀 🔥 如果感觉博主的文章还不错的话，还请 👍 关注、点赞、收藏三连支持 👍 一下博主哦 🏆 CSDN博客专家认证、新星计划第三季全栈赛道MVP 、华为云享专家、阿里云专家博主 🏆

---

专栏系列（点击解锁）	学习路线（点击解锁）	知识定位
🔥Python全栈白皮书🔥	零基础入门篇	以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。
	语法进阶篇	主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。
	自动化办公篇	实现日常办公软件的自动化操作，节省时间、提高办公效率。
	自动化测试实战篇	从实战的角度出发，先人一步，快速转型测试开发工程师。
	数据库开发实战篇	掌握关系型与非关系数据库知识，提升数据库实战开发能力。
	爬虫入门与实战	更新中
	数据分析篇	更新中
	前端入门+flask 全栈篇	更新中
	django+vue全栈篇	更新中
	拓展-人工智能入门	更新中
🔥全域运营实战白宝书🔥	运营角色认知篇	初识运营，明晰运营的学习路径
	高转化文案速成篇	三种文案形式，抓住特点才能下笔如有神。
	策划活动与执行篇	更新中
	新媒体运营篇	更新中
	社区运营篇	更新中
	私域社群运营篇	更新中
	运营数据分析篇	更新中
	低成本渠道推广篇	更新中
网络安全之路	踩坑篇	记录学习及演练过程中遇到的坑，便于后来居上者
	网安知识扫盲篇	三天打鱼，不深入了解原理，只会让你成为脚本小子。
	vulhub靶场漏洞复现	让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。
	shell编程篇	不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结]
	WEB漏洞攻防篇	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
	渗透工具使用集锦	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
点点点工程师	测试神器 - Charles	软件测试数据包抓包分析神器
	测试神器 - Fiddler	一文学会 fiddle ，学不会倒立吃翔，稀得！
	测试神器 - Jmeter	不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。
	RobotFrameWork	Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。
	Java实现UI自动化	文档写于2016年，Java实现的UI自动化，仍有借鉴意义。
	MonkeyRunner	该工具目前的应用场景已不多，文档已删，为了排版好看才留着。

---

---

在上一章节我们了解到了 “运营” 的一个核心逻辑，大概得知道了用户与产品之间的关系。以及在这个关系中，我们需要做的一些非常重要的事情。在这一章节，我们重点了解一下在从事 “运营” 的过程中，会与哪些小伙伴们一起合作，一起打交道。

❤️‍🔥 一个产品诞生的过程

在大部分公司里面，有的时候需求来自于老板，有的时候则是我们自己有一个想法。但不管是老板有一个很好的想法，或者团队内有一个很好的 ideal ，都会有一个验证的过程，可能是反推、也可能是一个正向的推演。

这样的一个过程被称之为 需求调研 ，或者通过竞品调研达成一个需求的辨别的目的。

当我们确定了这个需求的真实存在，这个时候就会 立项 去做这一款产品。

立项 通过之后，就会进入 产品策划 的一个阶段，策划的一个方案会通过整个项目组的一个评审，就会进入到 产品设计 与 产品研发 的一个环节。

开发完成之后，不能够立刻的推广出去，因为再缜密的产品都有可能会存在一定的疏漏。

这个时候就会涉及到产品的测试，会有专门的测试工程师测试我们的产品，也会有产品经理专门的 体验产品 ，最后没有太大的问题才会正式的 发布产品 。

正式上线之后，我们的 "运营" 就会正式的介入到 “产品云运营” 的这一环节里来。与 "运营" 比较相邻的两个小伙伴，也就是 "商务合作" 与 "市场推广" (也就是 "市场运营")，去共同的运营我们的产品。

---

---

通过 产品从0到1 的这个过程，就可以基本上确定一些与我们打交道的小伙伴。

第一个就是产品经理；第二个就是产品设计师，在设计师领域又会分为 “交互设计” 与 “视觉设计”，此时可以通过一些简单的框架图、交互图来呈现出产品运营的一些需求。确认之后，才会正式的进入书面的UI方面的设计；

在设计稿出来之后，就会接触到技术人员。技术人员一般情况下分为两种，一种是负责前端页面研发的前端开发工程师，另一种则是负责后端功能业务实现的后端开发工程师。

在产品运营上线之后，还会通知到我们的客服小伙伴。因为在用户使用的过程中会出现用户不会使用的一个情况，甚至会出现一些使用过程中用户不满的地方会产生投诉，这个时候运营人员也需要把产品的使用说明文档对接至客服这边。运营的手段 与 运营的活动 也需要及时的告知到客服侧，以便于客服同学被咨询的时候能够马上清楚的知道如何去解决、如何去答复。

还有一个与 “运营” 息息相关的就是 市场 部分的小伙伴，市场可能会涉及到的角色就会包括 公关、媒介、策划、品牌 等。

除了上述业务方面的小伙伴，还有一些其他部门的小伙伴支撑。比如 运营活动 的时候会涉及到预算，甚至在运营活动的时候会涉及到一些用户产生纠纷的条款和规则等等。这个时候就会涉及到 "财务" 与 "法务" 。

更高级的一些运营经理还会涉及到整个团队的规划，这里就会涉及到 人力资源 的一些部门的介入与支撑。

由此，运营所涉及的一些小伙伴们即他们所在的一个具体部门，也就呈现在了我们的面前。

---

---

那么作为运营人、或者运营经理，我们要如何与这些小伙伴们打交道才能够更好的协同呢？我们继续往下看。

❤️‍🔥 与产品经理的协同

产品经理是做什么的？

产品经理更多的时候是负责一款产品。在洞察了用户的需求之后，把改需求落地成服务或者产品功能的一个角色。

他会涉及到整个产品的策略、设计以及其他业务的开拓与联动这样的一个关键的角色。 也会参与到产品研发的全流程里面来，去推动实现用户体验的五个层次。包括表现层、框架层、结构层、范围层以及战略层的产品目标。大家可以简单的理解为，这个产品长什么样子？服务于哪些人？最终是解决了用户的哪些需求和为我们的公司、企业去贡献了哪些核心的价值等等，类似这样的问题 。

那么 “运营” 要与 “产品经理” 打交道呢？

首先运营经理会是和产品经理一样的关注产品的数据，同时这些数据会有对应的指标。作为 “运营” ，我们需要通过 “运营的手段” 来帮助 “产品” 达成这些指标。

“运营” 其实会更靠近用户，更站在一线用户的前面，也会更多的保持与用户的沟通，去挖掘用户的需求可以反馈至我们的产品侧，进行优化迭代相关的服务。

---

---

❤️‍🔥 与设计师的协同

在设计角色经常打交道的有 “视觉设计师” 与 “交互设计师” 。

“交互设计师” 负责的更多的是设计界面的规范，在上线之后通过数据的分析，服务于迭代用户的体验。

“视觉设计师” 负责的是视觉定位，包括我们再做活动的时候也会涉及到 “视觉设计师” 帮助我们做一定的素材的绘图的设计稿件。

那么 “运营” 要与他们如何协同呢？

首先就是在提需求的时候，需求的目的要明确清楚，撰写 “需求文档” 时，要达成共识。要准确的传递出需要 怎样的一个设计稿件 。尤其是一些营销类的素材，一定要明确的定位到尺寸的大小、投放的位置等等的这些地方。在讲不清楚的需求的时候，可以给出一定的例子作参考。

在 “视觉执行” 的过程中，一定要去探讨视觉创意方面的东西。当我们没有数据支撑、反馈支撑，产生歧义的时候，也需要去尊重设计师的审美和创作。让设计师们也能够发挥自己的想法，当他们按照自己的想法做出内容的时候，也需要反馈数据给到实设计师，告诉他们来自用户的一个真实数据，与他们一起把视觉设计的工作能够做好。

---

---

❤️‍🔥 与技术的协同

我们的技术分为 “前端” 和 “后端” 。

前端负责的是一款产品的前端页面的构建，包括 “交互设计” 在页面上的具体的实现，比如说 H5 界面。

后端的开发其实更多的事负责后端逻辑的架构，包括数据库的一些操作和一些基本的管理，与 “前端” 之间是相互配合的，达成前端交互的一个过程。

“运营” 要如何与 “技术” 打交道呢？

有一点是与上文的 “与设计师打协同” 是一样的，当 “需求” 给到 “开发” 的时候，要尽可能的没有歧义、准确的表达出我们的诉求，包括必要的时候找出一个可以提供参考价值的案例。能够帮助我们的技术没有歧义的理解清楚我们到底想要什么。

在产品使用的过程中与产品营销活动的上线之后，可能会发现一些 bug 、或者问题，我们需要及时的清楚的去描述出这个bug以及必现的场景与条件。然后分析触发了什么样的环节，导致出现了这样的一个问题，帮助 “技术” 能够及时、准确的判断出问题背后的原因。

同时，造成这样问题背后的用户规模，反馈的用户的数量，也需要及时的与开发沟通清楚，以方便 “技术” 在处理问题的时候，能够分得清楚优先级。

---

---

❤️‍🔥 与市场的协同

再有一个就是 “市场” 的相关角色，常见的岗位有公关、媒介、偏品牌的策划等一些人。

“公关” 所负责的更多的是借助 “媒体的活动”、“事件的营销”、"公关的稿件"等手段向外界去传递产品的品牌形象。

“媒介” 所负责的其实是 “公司的媒介” 以及 “渠道的管理” 的一些状态。

“策划” 也会做一些活动，但是与 “运营的活动” 还有一些不一样，“策划的活动” 会更偏市场、品牌端；而 “运营的活动” 则会更偏向于用户的活跃、增长和品牌端。这里会存在一定的交集，但是侧重点会有所不同。

那么 “运营” 要如何与 “市场” 产开合作呢？

首先我们需要了解 “市场部门” 的传播规划几重点，在当我们做 “运营侧” 的活动的时候，要尽可能的与 “市场侧” 的品牌、策划保持一致的声音。比如说我们的 “市场” 更多的是在做 “偏年轻化的品牌活动”，而 “运营团队” 还在重点做 “中年用户” 、甚至是 “老年用户” 的动作的时候，就会出现两个部门之间南辕北辙的一个情况，这样效果就会很低。

其次就是一定要这些部门保持沟通，在双方目标达成一致的情况下，在做运营的时候要顺势借助好市场部门去撬动更大的资源。所以在真实场景下，大家都会发现市场部比较有钱，而运营部门的预算则会少一些。所以我们也需要好好的抱市场部的大腿，能够更好的、一致的达成整个运营和企业产品对外传播的一个共同的目的。

---

---

❤️‍🔥 与客服的协同

客服这个角色更多的时候是在梳理客户的咨询与投诉，还有些客服的只能是收集用户的反馈，帮助提升产品的迭代。更多的时候是在处理用户的问题，帮助其解决问题的一个状态。

当 “运营” 在发布大大小小的活动的时候，一定要准备比较详尽的客服文档，在内部也会被经常的成为产品的、运营的 FAQ 文档 。这份文档是能够帮助客服及时的理解业务、产品的活动文档，也能够大大的提升用户在咨询过程中的问题解决效率。如此效率变快了，用户的满意度也就高了，这其实也是一个良性的过程。

---

---

❤️‍🔥 与其他支撑的协同

与 “其他支撑” 我们可以简单的了解一下，比如我们与 "财务"、"法务"、"人事" 的一些相关联动。

重点就是，我们要有法律的意识。在 “运营” 的时候，很多情况下都会涉及到版权的一些问题，在后续的章节会有详细的讲解，这里简单略过。这些版权的相关问题，很多时候也都是与法务相关的。

在 “活动” 的过程中，“运营” 的手段执行的过程中，也通常会与财务打交道，因为 “运营” 也需要一定的成本的意识。在 “财务” 的眼中，他们所关心的东西对应到 “运营” 的工作中，其实就是 "投入与产出" 、"预算"、"获客成本" 等等。

---

---

在这一章节，我们非常的了解到在互联网企业中，“运营” 或者 “运营经理” 并不是一个人在战斗。同时，我们也会发现，如果想要将 “运营” 的工作做好，聚焦在自己的一亩三分地上，仅仅是工作上的第一步骤；如果想要将工作做的顺畅，也就意味着我们日常也需要了解其他各个模块都在做些什么。

能够做到理解、听得懂，在提需求或者别人表达需求给我们的时候，也能更清楚和意识到对应需求。