分类目录归档:产品

关于运营,我在腾讯学到的最有价值的三件事

2019 年从上一家公司离职后,我在休息了一个月后,以开发者运营的身份加入腾讯,后多方原因,我在 2020年,入职一年之际,离开了腾讯。

虽然离开了腾讯,我依然很感激腾讯的小伙伴,以及我的 Leader —— 小昱。大家的宽容,让我可以在这一年里,磕磕绊绊的,学到了一些东西,掌握了过去自己所不能掌握的知识。

也正是如此,我希望延续我作为工程师的习惯,将我自己所学的知识分享给各位,希望这些信息可以帮助到大家。这些知识对于已经从事运营多年的同学来说可能没有价值,但对于当时刚刚开始做运营的我来说,确实帮了大忙。

以下三条,是我在腾讯做运营,学到的最有价值的东西。

1. 运营就是对于资源的调度和利用 —— 小昱

这句话源自我问小昱:「运营的核心到底是什么?」。彼时的我,还陷在运营就是打杂的境地之下,每天总是在怀疑自己所做的事情到底有什么意义?我所做的事情,到底有什么价值。于是我找到了小昱,问出了上面的问题。

她给出了上面的答案。

对于我而言,这句话让我豁然开朗。运营需要将自己所做的事情当成资源看,不仅如此,你所做的任何的事情和所接触到的人,你所拥有的物料、人脉,都会成为你的资源,当你从这个视角来看待你所做的事情的时候,就会跳出细节,进入到一个更加宏观的层面来看待这个问题。你会被这句话强行拉到一个更高层次来看待运营和你所做的事情。从而也会更加理解你自己在整个团队中的价值,和你能够提供的价值。

2. 运营的价值,是拉近产品和用户之间的距离 —— 读书

这句话同样出现在我迷茫的时候,当我迷茫的时候,我开始疯狂的去读各种各样和运营相关的书籍,希望从中找到我想要的答案,而这句话,便是我找到的答案。

我们提起产品,往往会想到「产品经理」、「产品研发」,运营的身影仿佛很少出现,那运营的价值是什么?

运营的价值便是用各种各样的运营手段,去拉近产品和用户/客户之间的距离,你所做的一切,只要可以帮助拉近用户和产品之间的距离,那便是有价值的,反之亦然。

因此,你在做事情的时候,可以思考一下 —— 我做的这件事,能否拉近产品和用户之间的距离,如何可以,背后的逻辑是什么?

3. 漏斗模型 —— 小昱

漏斗模型是我在看小昱的述职报告时学到的。

漏斗模型的形态很简单,便是一个分层的漏斗,根据每一层的名字不同,会区分 AARRR 漏斗模型、AISAS 漏斗模型、AIDMA 漏斗模型等等。但核心还是这个漏斗模型。

对于漏斗模型而言,你需要关注到漏斗是分层的,因此,每一层的流量都会依次减少。而能够影响流入到下一层的流量的因素有两个:流量总量 和 转换率。

流入下一层的流量 = 这一层的流量总量 x 这一层的转换率

当你在做任何工作的时候,都可以去思考,我做什么样的事情,才可以提升我这一层的流量总量,以及提升这一层的转换率。

而这个简单的逻辑,无论是你做拉新、留存、促活还是营收,都有意义。

总结

我的上面三点认知,对于一个多年的运营可能是没有价值和意义的,但我希望上面的这段话,可以帮助到那些刚刚开始从事运营工作的人。当然,这篇文章,也会放在我正在准备的电子书《GrowthForDev》当中,希望这段话,可以帮助到那些有心给自己项目做运营的开发者们。

black and red click pen on white printer paper

为什么工程师希望需求明确?

我作为一个工程师,引以为傲的,便是不要求需求一定是完全详尽的,我会根据自己的个人经验,来帮助产品经理补全这些内容。

但另外一个层面,我也确实在思考,为什么我们会希望需求尽可能明确?

需求明确,意味着工程师在拿到需求之后,就可以开始工作了,而无需思考这个需求中的不合理的部分。

但当你和一个不靠谱的产品经理去合作的时候,就会发现,几乎约等于没有的需求,意味着在产品的研发过程中,存在大量的重写和改写的部分。因为产品经理前期思考的不充分,和后续的架构调整的计划较多,就会导致项目在后续研发的过程中,会出现不断的架构调整,推翻之前的工作,对局部进行重写,最终导致工程的不断 Delay。

当然,我也并不是说,我们应该在事事上都去追求完美的产品设计,这显然不现实,时间成本也比较高。但确实,作为一个 Trade Off,这是一个存在的现象。

换句话说,如今的行业的不断细分,是有其存在道理的。流水线化让每一个人的产出可以被量化、我们接受标准的 Input 和给出标准的 Output,让每一个人的工作都可以更加轻松。

sticky notes on corkboard

看板(KANBAN)是否能够满足你的项目管理需求?

从腾讯出来以后,我一直还在用的,和腾讯内部一样的工具,便是 —— TAPD。

说句实话,TAPD 的编辑器是真的很难用,但我很难找到类似的产品,只能继续使用 TAPD。

Trello 我一直还在使用,但我只会在一些个人的项目上使用,更多的时候,我是用 Trello 替代 ToDo 类应用。但涉及到更加复杂的需求/Bug管理,我会选择使用 TAPD 这样的应用来完成。

相比于 Trello,TAPD 提供了看板和看板以外的功能,比如文档、Wiki、需求管理、迭代管理、Bug 管理等功能,对于一个软件开发项目来说,所需要的几乎都提供了。

看板的功能只是TAPD中的一小部分,更重要的是 TAPD 提供了需求管理和标准的富文本编辑器,这使得一个需求可以更加详细的被描述,在开发过程中,开发者可以更好的和产品经理去对齐需求。

类似的,还有迭代和Bug管理,这些并非不能通过 Trello 实现,但Trello 的核心还是一个 KANBAN,对于更加重量级的内容管理,是力不从心的。

出于上述考虑,我最终选择了 TAPD,而不是 Trello。

国内类似于 TAPD 的产品还包括,腾讯旗下的 Coding,Coding 除了提供了基础的代码托管功能以外,还提供了项目管理工具,可以让开发者更好的管理自己的软件项目。

工具创造者的自我修养

独立开发者中有一大批人是通过做工具来获取收入的。做工具也算是独立开发者圈子中经久不衰的话题了。

但到了具体的工具开发之时,其中又有不少可以拿来讨论的内容。

而这里,我最想讨论的是工具的理念。

对于工具类的软件开发而言,最容易出现的就是「别人做了一个什么东西,我觉得不够新/便宜/不爽,我自己也要开发一个」。对于开发者来说,遇见问题, 并自己解决问题是非常常见的。 但是,工程师常常的问题也在于此,因为复制一个产品的成本越来越低,所以最先选择的是复制,而不是思考这个产品的长期发展道路。这会让产品陷入简单的 Copy and Paste 的模式下,长期来看,并不利于产品发展。

在我看来,如果工程师想要做好一款工具,那么一定要为自己的工具准备一个最基本的方法论。这个方法论一定是基于你自己对于问题的看法做出的拆解,而不能是依赖于其他第三方软件的。

这个方法论将指导你的产品朝着最终的目标,要解决的问题,奋力前行。你后续所遇见的问题,都会成为你前行的助力,为拓宽前进的道路。

而一个没有方法论的产品,则会被途中遇见的各种问题引导偏离最初的目的地。我们目前的市场中有太多的工具了,每一款工具都有其优秀之处,倘若没有自己核心的理念,那只会被众多的 Feature 搞得「乱花渐欲迷人眼」,最终失去了自己对于工具的定位,抄成了一个四不像。

总结

如果你想要以一个小团队打造一款好用、生命力持久的工具,那么先想清楚你的目标和理念,再动手开发,是一个好的路子。需求有很多,但并不是每一个都适合你。工具有很多,也不是每一个都适合你,预期去抄别人的理念,做别人要做的工具,不如发现自己的需求,做自己的工具。

white iPad on white surface

什么样的人适合做独立开发者?

我这几天在 Twitter 上发了一条推,引起了一些热烈反响。不少推油也从不同的角度给出了看法。

https://twitter.com/xiqingongzi/status/1336353507167780864

后续我也补充了一些信息

https://twitter.com/xiqingongzi/status/1336850171255091202

不过,我觉得我可能需要完整的描述一下我对于独立开发者的定义,以确定大家的讨论会在同一个维度上。

技术人的常见道路

技术人的常见路线其实很明确,总体可以分两个大类:技术专家和产品研发。

技术专家

技术专家的特征是对于技术研究更深刻,会更加专注于某一项技术的研究,有通才型的技术专家,但较少。更多的是在某一个领域方面深入的技术专家。

技术专家的话,一般而言,最好的路线是进入企业,以技术专家的身份,被企业供养着。特别是进入大的企业,较大的企业拥有足够的技术场景可以供技术专家进行深度研究。同时,大型企业也拥有足够的预算来供养这些技术专家。

产品研发

产品研发类,不会太过于纠结于技术的本身。而是会将更多的精力投放在技术产品的价值。

这类人大多最终会走上独立开发者/创业者的道路,企业内部虽然也会有内部创新的道路,但可能很多时候会受限于企业的资源和布局,因此,在出现企业利益与产品利益冲突的时候,容易触发这类人离职。

产品研发类的人的特点是,技术也会研究,但不会像技术专家一样沉迷于某一个技术,更加关注是技术之间组合产生的价值,站立在产品、研发、和人文的交叉点,讨论组合产生的价值。

从他们的表现逆推,则可知,两种发展路线可能会需要的一些特性:

技术专家

  • 耐得住寂寞:技术的研究远不如产品的研发能够提供的正反馈和多巴胺,绝大多数的时候是鼓噪的过程。
  • 热爱:技术的研究是一个枯燥的过程,热爱能够让他从初期的没有成功,抗过最初的困难期,渐入佳境。

产品研发

  • 不抗拒与人打交道:产品研发类的人最终走上的无论是创业还是独立开发,都会涉及到需要和人沟通,如果抗拒和人打交道,最终这个过程可能会让你心情低落,甚至抑郁。
  • 耐得住寂寞:产品研发虽然和技术专家大体路线不同。不过,产品研发早期可能很难得到正反馈,因此,耐得住寂寞可以让开发者在产品的初期,坚持做下去。
  • 抗风险能力强:独立开发者的路线是坎坷曲折的。和创业类似,唯一不同的是,失败的时候可能只有你自己,相同的是极高的失败率,因此,抗风险能力一定要强,扛得住失败。有多个收入来源,确保生计是一个很重要的事情。最好不要 All in ,容易一不小心把自己玩死。
  • 技术基本成熟:不一定是使用最新的技术,但要具备独立借助技术解决问题的能力。如果完全从零开始的话,可能会在前期获得非常多的负反馈。所以,有一定技术基础的人是比较好的。一般而言,我建议从业在 3年以上的人,可以开始考虑做独立开发者。

总结

关于独立开发者而言,需要具备的特点有很多,这里仅能根据自己的经验总结一些,也欢迎各位在下方评论。共同讨论。

视频课程制作手册

导语

因为我有“好为人师”的坏毛病,所以我经常制作一些视频,去指导别人,要如何做一个东西,在这种场景下,我会考虑制作一些视频。

这篇文章是介绍我的视频制作的课程,介绍一下我是如何制作视频的,并将这个流程分享出来,让大家了解,并给出一些建议。

流程说明

  1. 确定题目:制作视频之前,需要有一个主题,我不会平白无故就要制作一个视频,必然会有一个主题。有些时候,这个主题会是别人给我的,也有的时候,是我自己想起来的。这个环节耗费的时间往往是最少的,灵感来了,就会加入到主题里,并开始进行下一个流程。
  2. 背景调研:为了做好一个视频,显然不能简单的基于我自己的认知来制作,我需要借助一些别人的经验,这个时候,我就会进行广泛的调研,获取不同渠道的信息,以补全我对这个问题的认识(虽然并不能确保我的认知就一定正确,但往往会有更多新的视角出来)。这个环节往往是比较耗时的,因为需要做好相应的数据调研,准备好课程所需的资料。
  3. 准备 PPT & 讲稿:在准备好了所有的内容基础以后,就开始制作视频课程所需的 PPT,这个往往是比较快就可以完成的(当数据都已经准备好了)
  4. 视频录制:视频录制是整个环境最为简单的环节。特别是当你熟悉以后,往往是一遍就可以过,所需要的只不过是一个还算不错的麦克风(我一般是头戴式的,目前用的是 Jabra Envolve 20),头戴式的麦克风可以确保你的嘴唇离屏幕的距离始终是一致的,声音的一致性会更好。在视频录制的环节,我使用的是 Screen Flow ,这个软件可以很方便的完成视频录制 & 剪辑。Windows 你可以选择 Camtasia Studio
  5. 视频剪辑:视频在录制完成后,需要进行一些简单的剪辑,删除整个录制过程中出现的一些小的错误。比如口误(如果口误,你可以直接说下去,这样后续可以剪辑掉口误的部分,用正确的部分替换,有效的提升你的剪辑效率)、噪音(尽可能选择底噪低的环境,比如小的房间、会议室等)。
  6. 视频渲染:视频的渲染需要花费很长的时间,所以我一般是选择将所有的视频剪辑完成后,放在一起渲染,然后选择晚上睡觉的时候渲染,这样早上起来就已经渲染好了。
  7. 视频发布:视频录制完成以后,就是发布的过程,这步很简单,对外发布就好。

Reference

项目中的视野

因为目前在做运营,所以经常要做一些活动。

在做活动的时候,会涉及到不同的角色,就工作人员而言,会分为 Owner 和 Staff 两种。

Owner 是活动的主要负责人,无论是最终的活动效果、活动转化率等等,都是由 Owner 背负。

而 Staff 则更多是项目中的合作者,他们可能是单项特别强,或者是掌握了相应的资源,或者是因为没有什么事情,被拉来帮忙的。

不过,无论 Staff 因为什么原因加入到 项目,可以肯定的是,Owner 相比于 Staff 能够了解更多的信息,在这种情况下,Owner 可以给 Staff 提出建议,当然,Owner 也可以不给 Staff 建议。

在之前的活动中,我曾经吃过亏,因为Owner 没有给 Staff 建议,结果 Staff 在对接资源时,对接了大量的非目标群体的渠道,致使钱花了,效果达不到。

此外,这里强调,是建议而不是要求。对于外包,可以给出要求,但对于项目的合作者,还是要给出建议,给 Staff 一些拓展的可能和空间,从而让活动有更多的可能。

SOP – 标准作业程序

标准作业程序(英语:Standard Operating Procedures,常缩写并简称为SOP)是指在有限时间与资源内,为了执行复杂的事务而设计的内部程序。从管理学的角度来看,标准作业程序能够缩短新进人员面对不熟练且复杂的学习时间,只要按照步骤指示就能避免失误与疏忽。

https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F

标准作业程序的成立理由,通常有下列几点:

标准作业程序可以节省时间,进而达到高效率。

标准作业程序可以节省资源的浪费,从而达到环保效应。

标准作业程序可以获致稳定性,稳定可以使组织继续存在,也是主要动力。

https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F

标准作业程序也可能产生若干问题,反而阻碍目标的实现:

标准作业程序常会抗拒变迁,无法因应特殊环境需要而适时调整。

标准作业程序的执行可能会延误时机,无法满足多数人的需求。

标准作业程序往往造成“新政策”与“旧实务”之间的矛盾,较难推动改革。

https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F

运营工作难做就难做在没有 SOP

为你的兔小巢加上实时消息推送

如果你也和我一样,使用[兔小巢][1]来作为你的产品用户社区,那么你一定会遇到一个问题:反馈不及时,由于兔小巢本身没有和用户的强关联,只有当用户主动填写了个人信息,或关注了兔小巢的服务通知,你才能对用户进行消息的触达。因此,你的回复的时效就十分重要了,快速的回复可以让你的用户在还没有失去和你的联系时获得反馈,完成一次有效的用户交流。因此,实时的信息反馈就十分重要了。

但是,兔小巢本身并不具备实时推送问答的能力,因此,我们需要借助一些第三方工具来完成自己的目的,在这篇文章中,我将向你介绍,如何使用腾讯云云函数将兔小巢的消息转发到企业微信当中。当然,如果你使用的聊天工具不是企业微信,而是诸如飞书、Slack、Bearychat,你也可以参考这里的说明,完成自己的相应的需求的实现。

需求

  1. 腾讯云账号
  2. 兔小巢

流程说明

这里使用兔小巢的提供的 WebHook ,来接管所有的用户请求,并辅以腾讯云的 API 网关和云函数的能力,将实时推送的消息转发至企业微信

这里我实现了企业微信,但对于你来说,还可以用来实现其他同类似渠道的能力。

优势

  • 轻量:如果你的需求仅仅是实时转发,那你不再需要重新启动一个项目,配置各种环境,通过云函数就可以完成这些工作。
  • 无需代码基础:如果你是一个运营,而不是一个开发,那么我这段代码你复制即可,简单修改其中的一些基本信息,就可以完成实时推送的功能,对于没有代码基础的同学来说,是十分方便的。

操作步骤

由于这篇文章是兔小巢的高级用法,因此,对于如何创建一个兔小巢产品,就不再赘述,此外,以下步骤均在电脑端操作,因此,请使用电脑来执行下述流程。

找到你的兔小巢产品 ID

首先,你需要打开兔小巢的管理后台,打开产品设置 ,在其中找到 产品 ID,复制这里的产品 ID,后续我们会用到。

产品 ID

创建一个企业微信机器人

由于我们本次要实现的是兔小巢消息推送到企业微信,因此,我们需要创建一个企业微信机器人。

在你需要推送消息的群上,右击,选择其中的添加群机器人

并在弹出的窗口中选择从新创建一个机器人

在新弹出的窗口中输入机器人的基本信息,并点击添加

添加完成后你会获得一个 WebHook 地址,复制这个地址,后续会用到

创建一个腾讯云云函数

访问腾讯云云函数控制台,点击界面中的新建,新建一个云函数。

这里函数的地域可以根据你的需要选择,几乎没有影响,我选择的是广州地域。

随后,在新建函数的时候,输入函数名称、运行环境(运行环境选择 Node.js 8.9),以及创建方式,选择空白函数。

填写完成后,点击下一步,在新的页面,设置函数的描述,这里需要注意,执行方法不要做任何修改,使用默认的,除非你知道你在干什么。

然后,复制这段代码,粘贴在下方的代码框中,操作步骤参考动图

'use strict';
const request = require("request")
const productId = ""
const botUrl = ""
function requestPromise(r,t){return new Promise(function(e,n){request({uri:r,method:"POST",body:JSON.stringify(t)},function(r,t,i){if(r)return n(r);try{e(i)}catch(r){n(r)}})})}
exports.main_handler = async (event, context, callback) => {
    const txcData = JSON.parse(event.body);
    if (txcData.type == "post.created") {
        await requestPromise(botUrl, {
            "msgtype": "markdown",
            "markdown": {
                "content": `**新增用户反馈**\n\n${txcData.payload.post.content}\n\n[点击查看详情](https://support.qq.com/products/${productId}/post/${txcData.payload.post.id})`
            }
        })
    }
    return "ok"
};

然后,将第三行的 productId 中加入你的兔小巢产品 ID,将第四行的 botUrl 中加入你的微信机器人地址。
比如,我的修改完是这样的

'use strict';
const request = require("request")
const productId = "149567"
const botUrl = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=d8c1e6b1-ccbf-467e-8dcc-31c1961baf41"

这里需要注意,不要删除放好的引号,把 ID 和 WebHook URL 放在引号内部就好,以免你的输入法输入了中文引号导致出错。

修改完成后,保存文件(按下 Ctrl + S 或 Command + S),点击下方的 完成,进入到函数的详情页。

配置函数请求地址

接下来,我们为函数生成一个请求地址,用作后续兔小巢的消息提醒。

在函数的详情页,点击左侧的触发管理,选择创建触发器,创建一个 API 网关触发器

触发器的具体配置可以参考下方的图片。

创建成功后,你会获得一个访问路径,这个路径就是你的函数请求地址了。复制这个地址,下一步我们就会用到。

兔小巢后台设置 Webhook

回到兔小巢的后台,找到左侧菜单栏中的 开发新反馈实时通知

将刚刚你生成的函数的访问地址,粘贴在这里,点击保存并发布

保存成功后,就可以去你的兔小巢中发反馈,测试一下效果啦

测试效果

当我在兔小巢社区发了一个新的反馈后,我的企业微信群内就出现了一个新的消息提醒,提醒我有了新的反馈,同时,还带上了一个链接。点击这个链接,就可以跳转到我的兔小巢对应的反馈页面,方便快速回复。

总结

通过简单的配置,我们就可以很轻松的实现兔小巢反馈的实时推送,十分的方便。对于广大使用兔小巢的运营同学来说,现在你可以不用每隔几分钟就去刷新一下社区了,耐心的等待机器人的推送就好了~工作效率大大的得到的了提升。