连载:关于产品运营,关于需求,关于产品测试

发布时间 :2022-07-26 17:31

导言 首先跟大家做一个简单的自我介绍,我是卿宗伟,笔名十三

年毕业,法学本科,毕业即转行

目前就职于深圳一家非著名公司,公司产品偏运营,因此我在公司主要负责产品和运营(用户运营和活动运营为主),工作还是很杂的

网站产品运营

虽然我是产品非经理,但我从入职第一天起,就把自己定位成一个产品经理,在日常工作中并没有受限于自己只是一个产品助理的身份

网站运营

虽然我是新人,很多都不懂,但不懂并不可怕,可怕的是不懂还要装懂,不懂还不努力学

 本文不是教你怎么样从到打造一款牛逼的产品,也不是教你如何将产品运营到千万量级的用户

当然,我暂时也没这个能力

我所说的,都是我所经历的最真实的产品日常故事

若你有不赞同之处,那很有可能我说的是错的

好了,废话不多说,马上进入正文

 本文共分为五个部分: 第一部分:关于产品运营第二部分:产品需求与产品测试第三部分:用户反馈与用户行为路径分析第四部分:跨部门沟通协作第五部分:团队责任心与凝聚力 温馨提示:以上五个部分采用「卡片式设计」,每个部分都是独立存在,各部分之间并没有紧密,也不是成体系的方法论

 今天给大家带来的是前两个部分

 关于产品运营 产品运营,包括三个部分:即内容运营、用户运营与活动运营,这三者统称为产品运营

当然市面上还有更多分类方法,比如渠道运营、品牌运营、数据运营&#;等等,但我认为没必要分那么细,本来运营就是一箩筐,什么都可以往里装——亮哥语录

  附:关于运营的分类,可以参考作者提供的思维导图 点小图看大图 作者所就职公司产品部门有两位负责产品和运营,一位同事负责内容这一块,另一位就是在下

对于内容,坦白讲,除了运营我自己的公众号,平时写点东西,外加每月几条博文外,我没有正儿八经做过,所以可能没什么发言权

我就几句槽,先吐为快

 我们平时都说啊,做内容,首先你要找准你的目标用户群体,他们在哪里,分析他们的特征,由此探究他们的真实需求与阅读喜好,然后将内容精准地呈现在你的目标用户面前

你还可以借助热点事件,制造热门话题,进行病毒式话题营销,即时引爆……等 恩,都说得挺对的,但是,都是正确的废话

 谁不知道做内容要找准目标用户群体,要分析用户阅读习惯和喜好,将他们喜欢的内容触达给他们

 但是,怎么做

不知道

 关于内容,我还有一点真的无法理解,为什么现在市面上各种关于内容的培训讲座如此吃香

他们的标题大都是这样的: 小时教你如何打造一篇阅读量万+的文章

  或者是这样的: 分钟教你如何写好一个标题

 通常都是以感叹号结尾,生怕别人不知道你能达到这样的效果

 听讲座的时候觉得头头是道道感觉找到武功秘诀了,完了还是啥也不会

为什么呢,因为他们都是坑爹的

大道理谁都会讲,而且很多东西不是听一堂讲座就能做到的

就像爱因斯坦来给你开堂讲座,教你怎样成为第二个爱因斯坦,你能做到吗

是一样的道理

 说到这,不禁为部门负责内容的同事感到心疼

因为她做了那么多内容,数据就是上不去

个人认为主要有几个问题: 第一个问题:虽然说内容为王,但用户是基础,活跃用户是关键,如果活跃用户太少,内容没人看,数据怎么会好看;第二个问题:虽然做内容有一部分也是为了提升留存,但是内容若空洞乏味无价值,用户怎会喜欢;第三个问题:内容都是搬来的,几乎无原创

这个不怪她,因为一直以来都是做内容的搬运工,自己也没有这么强的原创能力,而且一天要发条啊

第四个问题:之前每天发布~条资讯,早上推送条,现在每天发条,早晚各推条

其实对于这种改变,我是拒绝的

并不会因为资讯发的多,用户就会看,数据照样不会好看,因为内容本质没变

然而拒绝无效

第五个问题:内容没有分享机制

因为页面不是H写的,分享出去的页面是的下载页面而不是关于内容的页面,即使用户想分享扩散,你都不给人机会

 当然,说了这么多,让我做内容,我可能还比不上我的小伙伴

至少对于我司目前的内容来说

 第二点想说的是用户运营

看过亮哥《从零开始做运营》或者对运营稍微有点了解的盆友都知道,用户运营主要就是四大块工作: 开源;节流;促活跃;转付费

 恩,概念我就不列出来了,重复发明轮子也没意义,直接引用亮哥的原话那你还不如看亮哥的书

不知道的赶紧下单去

 恩,拉回来

 首先一款产品要存活要成功,用户是基础,也是最重要的,没有用户,你做个产品出来自娱自乐吗

当然不是咯

那么我们面临的第一个大问题就是,如何拉新

恩这确实是一个大问题

我没有经历过冷启动,不知道冷启动是如何操作的

我们公司产品虽有两岁多了,用户量级也还好,但拉新还是要做的

 我所做过的拉新工作主要就是做活动

那我是怎么操作的呢

首先我每月答帖到后面的一系列动作,都形成了一个完整的消费体验闭环

 注意上面提到的「消费体验」,也就是说所有的金币和积分都是可以消费的

如果你仅仅给用户一大堆积分和金币,但是不能消费,那有什么卵用

正如亮哥所言,「不能消费的无价值积分,连狗屎都不如」 产品需求与测试 产品同学都知道,提需求砍需求是产品经理的日常工作

那么需求哪里来

 第一是老板需求;第二是用户反馈与调查访谈;第三是用户行为路径分析;第四是产品经理与助理沟(意)通(淫),然后经理拍板

第五是……其他

 关于老板需求,我常常想,要是老板懂产品的就还好,要是不懂产品的,呵呵那就操蛋了

今天说这个功能好,给我上这个;明天说那个功能好,给我上那个

那你就等着被蹂躏吧躏吧吧&#; 至于产品经理自己在心里需求,其实这是很多产品经理在从事产品工作中会做的事情,而且常常是大多数产品经理的大多数需求的来源(我也会干这样的事儿啊,说出来不丢脸的)

对于这点,我想一句话就能表达我的想法,需求可以来源于产品经理,但并不是唯一来源,也不是主要来源,应当仅仅作为附属

 更多的需求应当来源于用户反馈、调查问卷、用户访谈、用户行为路径分析&#;等等(当然很多方法并不是每家公司都能做到,一个是资源问题,一个则是成本考量,你懂得(*≧▽≦*)) 需求当中我感触最深的就是,一定要有需求评审

作者所在公司是没有需求评审的,这是非常蛋疼的

那我们平时是怎么提需求推进产品迭代的呢

 做产品要多体验产品,所以我有时候会参考其他产品(包括竞品)的优点,提出一个需求,首先跟UI简单沟通探讨这个功能怎么样,探讨如何实现,效果会是怎样,双方觉得可行我就将这个需求提交给A,征求他的意见

 需求确认主要关注三点: 第一,这个功能还可以,可以参考一下,说明该功能对于产品用户的某一方面是有价值的,比如可以提高留存促进用户创造内容;第二,你看看要不要做,技术上能不能实现;第三,如果要做,难度大不大,开发周期预计多久

 这样心里有一个预期

 如果需求被掉了,那基本就了,不过可能过段时间我又会重新提起

那如果通过了,我就直接跟UI说,上

因为之前已经跟UI探讨过了,他基本知道我要什么样的效果,当然后面会持续跟进

 我觉得这种做法还是勉强可以接受的

可怕的是上面或A直接下发需求,说给我做这个

这是要求的

这他妈就蛋疼了

又会出现问题: 第一,这个功能是基于什么提出的,用户是否需要这个功能,是不是刚需,频度如何,做了对产品有什么价值吗对用户有价值吗;第二,你都不跟我们商量一下,直接就说上,怎么上,你想要的效果是什么我不知道,如何实现我也不知道,我连原型图都没法输出

UCANUUP啊

第三,这个功能放在哪里,总得有个入口吧,你不说我就按自己的想法执行咯,到时候不行又要返工,我返工也就算了,如果UI也要改改改那就真操蛋了

 我在团队内部提过多次,要改善工作流程,且不说像大厂那样制定规范有条理的流程,那最基本最重要的环节总不能省吧,敏捷开发也不是这么个敏捷法啊

可是没办法,我又不是经理,人微言轻,建议听不进去阿西吧~ 所以,人哪,有时候你还就得忍

毕竟你一个人改变不了什么,工作有时候也像强奸,既然无法反抗,那就只能享受了

没关系,卧薪尝胆,三千越甲还可吞吴呢

 下面我想简单聊聊产品测试

 首先作者所在公司是没有测试人员的,测试工作主要由我负责

不过这个测试没有涉及技术层面,只是简单的关于产品核心功能能不能用,比如能不能顺利登录,提问有没有问题,充值流程是否顺畅这些可见的非技术性问题

虽然不涉及技术问题,但是有一个东西也是必不可少的&#;测试用例

 一定要写测试用例

一定要写测试用例

 测试用例文档的基本元素大致包括但不限于以下几点:即测试时间,测试人,机型,测试环境,问题页面,问题详情,处理情况,复测时间,备注&#;等 测试用例文档用写就了,但是光写测试用例还是不够的

还要做好「回归测试」,跟踪后续问题处理进展,是否修复,修复人,修复时间,复测时间&#;等,方便追溯干系人

另外,如果产品分A和IOS版本,在制作UC时,建议分开记录,避免问题混在一起,不好处理

 下面提供一个简单的模板供大家参考,这是作者自己输出的简易测试用例(UC): 点小图看大图 作者:卿宗伟 来源:张记杂货铺



- END -