企业在做品牌营销的时候,想要做到品效合一是很难的。大多数广告的结果都是品牌热度在此期间达到了一个升值,或者说在此期间达成一定的产品交易效果。鱼和熊掌真的不能兼得吗?成年人不能两者都要吗?当然可以。 品效合一就是企业在做营销的时候,既要看到品牌的声量,又要看到效果的销量。产品要带动品牌声量的提升,同时品牌推广本身也要有销量的增长。因此,企业营销不仅要品牌,更需要效果,在移动互联网上做营销必须要追求品效合一。 换而言之,企业在做品牌营销的时候,品牌在整个营销活动中的热度与产品的销量是一个相辅相成的存在,品牌的热度可以效率提高更好的辅助,而好的销量可以为品牌达成更加广泛的传播。 随着互联网的进步发展,现在任何一个品牌只有有足够的“资源”都可以在央视投放广告,而在二十年前一个品牌在央视播放一个几秒钟的广告都是一件了不得的事情。人们的认知以及网络环境的变化造就了品牌营销的内卷,如何尽可能的做好品牌的“品效合一”可从以下几个方面思考 了解用户痛点:结合“品效合一”来看,一个广告营销的最终目的有两个。一是扩大品牌在用户中的知名度,让用户知道这个产品,从而影响用户后续所有的购买行为中增加成功购买率。二是让用户用最短时间完成产品购买,将产品转化为产品销量。但需要做成这两件事的前提就是营销广告在主题传达路径之时,就要针对用户的痛点进行系列的营销手段。 占领用户的心智的广告很多,譬如脑白金洗脑广告““今年过年不收礼,收礼只收脑白金”,王老吉广告;“怕上火,就喝王老吉”。在我看来,品牌广告想要占领用户心智,并在后续用户有所需求的时候想到依然是它。在广告语方面除了朗朗上口容易好记之外,必须是帮用户解决问题的。 加速用户购买 当用户看到你的广告并且在购买的时候优先选择你的产品时,你的广告已经帮助用户加速完成购买的过程了,简单举例下;你去一个便利店购买一个矿泉水,农夫山泉的广告语是“我们不生产水,我们只是大自然的搬运工。”加速用户购买其中最重要的用户所在的渠道,一个用户决定购买某个产品是从多方面考虑的。
玻璃 发布的帖子
-
整合营销如何兼得
-
运营人的难题
运营人的两大难:新用户拉新,老用户留存。而拉新的成本远高于留存的成本,且老用户的消费能力远高于新用户。那么,如何做好用户留存呢?
提供一如既往的高品质产品,无论你是写文章还是做服务,亦或是卖货,从用户的角度来说,这都是一个商品。 关注用户的售后服务体验,只管卖,不管售后,这是很多平台都容易犯的错,往往服务跟不上销售。一种是在业务高速发展中忽视这样的问题,一种是业务进入平稳期轻视了这样的问题。而对于用户来说,如果自己花钱得不到良好的售后保障,自然是会对平台失望的。 千万不要让用户找不到你,每次把货卖出去以后,商家都挺怕用户找来的,甚至主动拒绝与用户联系。大家有没有遇到过,打一些机构的电话,永远都是打不通的?但凡那写怕用户找的,或者用户找来服务不好的,都是对自己的产品、服务不自信,怕麻烦、怕吃亏,把用户假设成了坏人。 做一个有温度的人,平常这些app给我推送的大部分消息我都会忽略,但每年唯独这条我会打开看一眼,这是一种很微妙的关系。虽然我们和客户之前本质上就只有一种消费关系,但消费关系如何巩固,就和我们做了什么息息相关。 让用户对你充满期待,为什么苹果手机的发布会,每一年用户都会充满期待。因为大家认为它就是行业的方向标,从它的外观设计到产品功能再到周边产品,的确会有一些惊艳的地方。所以,创新是任何一个个人和品牌保持竞争力的核心。
-
通过改变思维方式替代同理心
产品经理要有同理心,站在用户的角度思考问题,和用户共情,这已经成为了很多产品经理的共识。 同理心(Empathy),亦译为“设身处地理解”、“感情移入”、“神入”、“共感”、“共情”。泛指心理换位、将心比心。亦即设身处地地对他人的情绪和情感的认知性的觉知、把握与理解。主要体现在情绪自控、换位思考、倾听能力以及表达尊重等与情商相关的方面。 同理心的核心作用在于理解,而产品经理与需要的是什么?是了解用户。一字之差,天差地别,“我理解你”和“我了解你”这俩句话的差异有多大?简单来说,产品经理需要了解用户情感的动机来源,而不需要理解用户有多痛苦,多快乐,多悲伤,多愤怒。 用户的情绪就是对于马匹速度的不满,产品经理需要做的不是理解用户有多不满,而是了解用户为什么不满,这需要的是透过现象看本质的能力,而不是同理心。想要了解用户为什么不满,可以通过直接询问,问卷调查或是数据分析,都可以达到了解用户需求的目的,而不是通过同理心去感受用户的情感,代入过多的情感只会增加判断出错的,而判断力就是产品经理的生产力! 在基本了解了同理心作用和基本概念后,接下来从“经历”对于同理心的影响来说明为什么“产品经理需要同理心”是个伪命题,或者说“产品经理会和用户产生共情是个伪命题”。 产品经理现在对于用户的判断并不是出于同理心,而是通过对规律的判断,再结合自己的感受,形成对用户的理解。说直白点,现有产品经理大部分都是通过用户信息判断用户类型,然后根据用户类型推测用户行为与思考方式,这个过程需要严谨的逻辑思考能力与丰富的知识,同理心能起作用只是推测时产生的幻觉。
-
一份漂亮的表单设计
表单在我们的日常工作中经常会用到,一个优质的表单可以提高我们的工作效率,完成一些更多的业务,提高产品体验。 产品角度 – 收集产品现存的问题:运用“交互行为五要素”将一整套业务拆分成一个个小的业务场景,通过产品体验剧本进行交付沙盘模拟分析各个核心业务场景下的产品现状。 客户角度 – 获取客户的诉求:一线交付人员对客户做了调研访谈,深入的挖掘他们对当前的产品使用问题;客户成功团队收集用户的心声,将不同岗位和职级对于租赁系统的问题真实反馈收集汇总。 将每个场景下的客户诉求,与产品现状进行对比,那么在产品现状中没能满足客户诉求的地方,便是产品需要改进提升的问题。由于得到的问题其实还是较为零散,最后我们利用“双钻模型”对待改进的问题进行聚焦,也就是对同类问题进行归类、发现零散问题背后的本质问题,得到目前新签合同的核心问题:缺乏业务场景化设计,签订效率低。 针对之前所提出的问题,本次新签合同流程的设计目标“有场景、更高效、更易懂”大致体现在如下几个方面:功能整合,架构升级。在旧版的框架体系中,所有任务信息直接平铺展示在页面中,导致功能信息杂乱分散,重点信息难以查找,信息关联性弱等问题,严重影响了客户的签订效率。 聚焦业务,重组结构;在页面结构上,通过捕捉用户习惯与认知,借鉴了用户最熟悉的线下纸质合同样式,消除机器语言的陌生感,强化业务感知,降低用户认知负担。 化繁为简,内容为王:在表单填写中,过多的信息透传会让用户在使用时产生“冗余感”,影响填写效率。而清晰明了的信息展示,则可以减少用户对选定内容的反复查对,降低焦虑感。 精益求精,更有温度;复杂业务表单由于充斥着各种条理和逻辑性,给表单本身带来了额外的使用负担。通过心理学的思考、UI 上的感情化设计、目标人群的特性、使用场景的氛围结合等手段进行等手段进行表单设计,能让用户在填写中更轻松、更顺畅。
-
iOS平台设计规范
iOS是运行于iPhone、iPad和iPod touch设备上、最常用的移动操作系统之一。作为互联网应用的开发者、产品经理、体验设计师,都应当理解并熟悉平台的设计规范。这有利于提高我们的工作效率,保证用户良好的体验。 三大界面要素Interface Essentials:大多数iOS应用都是由UI Kit中的组件构建的。UI Kit是一种定义通用界面元素的编程框架,这个框架不仅让APP在视觉外观上保持一致,同时也为个性化设计留有很大空间。UI Kit提供的界面组件有三类:栏(Bars),视图(Views),控件(Controls)。
栏(Bars):栏,可以告诉用户在APP中当前在所在的位置、能提供导航,还可能包含用于触发操作和传递信息的按钮或其他元素。包括6种:导航栏、搜索栏、侧边栏、状态栏、标签栏、工具栏。 视图(Views):包含用户在APP中看到的基本内容,例如:文本、图片、动画以及交互元素。视图可以具有滚动、插入、删除和排列等交互行为。
控件(Controls):控件,是用于触发操作并传达信息的。例如:按钮、开关、文本框和进度条,都属于典型的控件。! -
基于Paxos协议的分布式队列PhxQueue
PhxQueue 目前在微信内部广泛支持微信支付、公众平台等多个重要业务,日均入队达千亿,分钟入队峰值达一亿。其设计出发点是高数据可靠性,且不失高可用和高吞吐,同时支持多种常见队列特性。
PhxQueue支持的特性如下:同步刷盘,入队数据绝对不丢,自带内部实时对账出入队严格有序,多订阅,出队限速,出队重放,所有模块均可平行扩展;存储层批量刷盘、同步,保证高吞吐;存储层支持同城多中心部署;存储层自动容灾/接入均衡,消费者自动容灾/负载均衡。
Store 作为队列存储,引入了 PhxPaxos 库,以 Paxos 协议作副本同步。只要多数派节点正常工作及互联,即可提供线性一致性读写服务。为了提高数据可靠性,同步刷盘作为默认开启特性,且性能不亚于异步刷盘。在可用性方面,Store 内有多个独立的 paxos group,每个 paxos group 仅 master 提供读写服务,平时 master 动态均匀分布在 Store 内各节点,均衡接入压力,节点出灾时自动切换 master 到其它可用节点。
Producer 作为消息生产者,根据 key 决定消息存储路由。相同 key 的消息默认路由到同一个队列中,保证出队顺序与入队顺序一致。
Consumer 作为消费者,以批量拉取的方式从 Store 拉消息,支持多协程方式批量处理消息。Consumer 以服务框架的形式提供服务,使用者以实现回调的方式,根据不同主题(Topic),不同处理类型(Handler)定义具体的消息处理逻辑。
Scheduler - 消费者管理器(可选择部署):Scheduler 的作用是,收集 Consumer 全局负载信息, 对 Consumer 做容灾和负载均衡。当使用者没有这方面的需求时,可以省略部署 Scheduler,此时各 Consumer 根据配置权重决定与队列的处理关系。
部署 Scheduler 后,Scheduler leader 与所有 Conusmer 维持心跳,在收集 Consumer 的负载信息的同时,反向调整 Consumer 与队列的处理关系。当 Scheduler leader 宕机了后,Scheduler 依赖下述分布式锁服务选举出新 leader,不可用期间仅影响 Consumer 的容灾和负载均衡,不影响 Consumer 的正常消费。
Lock - 分布式锁(可选择部署):Lock 是一个分布式锁,其接口设计非常通用化,使用者可以选择将 Lock 独立部署,提供通用分布式锁服务。
项目地址: https://github.com/Tencent/phxqueue -
全局捕获Crash的库NeverCrash
NeverCrash for Android 一个全局捕获Crash的库。信NeverCrash,永不Crash。
全局捕获: 全局(包含浏览器外)出现一个鼠标事件,会被设置全局捕获的对象捕获,如果此对象正好有对应的事件函数,那么会被触发,而最初的发起事件的元素就不会执行它的事件函数了,通俗点说就是事件被掠走了。
全局捕获只能执行一次捕获的事件,如果持续捕获可能会出现问题,可以想象下:如果全局捕获点击事件,鼠标无论点击哪里都会执行那段代码,那么连最基本的关闭浏览器窗口都不行了。如果持续捕获,必须有取消全局捕获。
-
Arkcontrol数据库云管平台
Arkcontrol是极数云舟独立自研的一套全面解决MySQL日常运维和集群管理的自动化平台,平台提供MySQL的集群管理、实例管理、监控备份、日常巡检、参数建议等等多种功能,同时提供对公有云数据库API的调用管理,帮助使用MySQL的企业或者用户提升工作效率,降低故障时间,提升数据安全性。
多样化产品支持:Arkcontrol支持官方版MySQL以及MySQL的各种分支版本,也支持MySQL的常见架构,例如传统的Master-Slave、Galera Cluster、Group Replication等等。同时Arkcontrol也支持Redis的运维,并计划逐步支持Oracle、SQL Server、HBase、MongoDB等数据库。
系统化资源管理:Arkcontrol统一管理主机和数据库资源,通过资源录入功能,实现自动侦测发现已有数据库集群及其拓扑结构,并对数据库实例和数据库集群统一管理。
平台化安装部署:Arkcontrol实现多种数据库和集群架构的一键式自动化部署,避免重复性操作和人工误操作,提升工作效率,保证部署的规范化和正确性。
定制化监控告警:Arkcontrol内置数据库日常巡检、以及定制化监控告警功能,实现各种告警阈值和告警通道的动态设置及巡检报告的格式化输出。  自动化备份恢复:Arkcontrol可平台化定制数据库备份策略,自动化完成备份任务;同时根据实际恢复需求,实现自动化数据恢复,保证数据安全。智能化查询分析:Arkcontrol提供自动化慢查询采集、统计和图表展示,并对查询语句给出智能化优化建议。
-
TMS运输管理系统
TMS(运输管理系统)是一个物流运输平台,它是供应链管理系统(SCM)的一部分。广义的TMS平台涉及面较广,不同企业的业务模式不一样。 运营方按照一定的运输规则处理,做这个规则处理的过程,一般称之为计划,计划的形式有多种,主要有拼单、拆单、规划线路图、地图合单等,然后再将计划好的这个订单分派给合适的承运方。 最常见的手段是拼单,又称零担运输。将多个货主订单合并拼成一个派车订单,一般规则的处理条件有:订单量、装载能力、价格、路线、发货时间、收货时间等。 计划的手段除零担集货外,还有大单拆分、长单分段等,主要目的来达到成本分摊的作用。计划的手段有智能计算,和人工处理+半自动计算。 承运方接受订单,并将订单分配给司机,由司机执行完成运输任务,这个阶段又称之为调度。运营方将计划的订单分配给承运方,生成最终的运输订单,它是运营方同下游承运方的唯一标识,这个凭证会关联到订单的跟踪监控和应付结算等功能。 基础资料的建立,对TMS的需求任务单和调度非常重要,只有建立了合作关系,才能在客户需求订单上选择到正确(有合作关系)的客户,在计划调度的时候才能匹配到正确(有合作关系)的承运方。 录入货主、承运方的信息,以便于后期订单的生成, 这些信息的维护可以保证每个订单都有归属客户,方便订单的管理。
-
SaaS系统
SaaS是一种通过Internet提供软件的模式,软件的开发、管理、部署都交给第三方,不需要关心技术问题,可以拿来就用,如今很多企业也都在开发SaaS系统。 从全球范围看,软件业的SaaS化已是大势所趋。传统软件厂商大多在推进云化、平台化,典型如Adobe、WPS、万兴;新兴厂商如Figma、墨刀、石墨文档等,则从创业之初就坚定走在云端。 可有意思的是,大家在内部会上听的是连连点头,但私下交流时却很难对SaaS说出个所以然;有人认为它等于ToB,有人认为它就是公有云,也有人认为它是通过浏览器访问使用、无需下载的应用。 起初我以为这只是个别的理解偏差。后来看了市面上的相关资讯和资料,并且与部分业内人士交流后,我发现原来不少人,包括部分科普者,对于SaaS的理解也存在相当的局限性;于是决定写篇文章,整理下目前大家在SaaS理解上的几个争议,以及自己对SaaS的一些观察和思考。 SaaS平台供应商将应用软件统一部署在自己的服务器上,客户可以根据工作实际需求,通过互联网向厂商定购所需的应用软件服务,按定购的服务多少和时间长短向厂商支付费用,并通过互联网获得SaaS平台供应商提供的服务。 简单翻译过来就是,服务器在云端,按照客户定购需求,通过网络提供应用软件服务的,都算是SaaS;比如大家看视频常用的优爱腾,存资源用的百度网盘、阿里云盘,办公必备的Office 365、Adobe CC,等等。 与SaaS软件相对的,是需要下载到本地运行的传统软件,典型如未转型前的Office和Abode;后者需要按版本购买,获取license(软件序列号)激活。 软件license在市场上进行买卖,本质是一种单纯的售卖关系,用户通过一次买断的方式获得传统软件的永久使用权;它区别于SaaS模式(普遍采取订阅付费),后者售卖的内容从软件license转变为服务,软件成为服务的载体。软件提供商与用户的关系,从一锤子买卖转变为长期服务关系。![0a8d89f9-a878-4a40-9a27-9575c9a5aa2a-image.png](https://upyfuntask.suwis.com/xnit.funtask.club/f73cce0c-fb3a-4450-ae81-f3e523f5cc54.png)
-
短视频系统运营指南
短视频要养号的必要性:从平台的角度来看更希望把流量给那些正常的、能创作高质量、垂直内容的账号。正常的账号,在初期,抖音都会有流量扶持。通过对账号的前3-5个视频进行标签测试后,抖音会在后续推荐更多精准的用户,以便于这些账号产生的优质视频获得更多互动(转评赞)和推荐。前提是我们得让系统知道我们是真人用户,不是机器注册的黑产号。 什么情况需要养号?刚注册的新生号:这个比较好理解,新生号得靠养号的动作让系统知道你是个正常号,不是机器营销号,更好的让系统识别;废弃的老号:为什么废弃过的老号也要养?原因同上,证明下自己的正常用户;被拉过小黑屋或者警告过的号:毋庸置疑这种号能出来一定要展现给系统看你不会再疯狂的营销,或者发布其他违禁内容; 但我的观点是所谓“养号”,也就是发视频之前正常刷刷视频,让系统知道你不是恶意注册的机器号就行了,并不是刻意的去营造些所谓的“标签”之类的,这个官方已经辟谣了,没必要再浪费时间去花精力了。记住了:你看什么不重要,你能在短视频APP上为用户创造什么才是关键! 所谓养号,仅仅只是像系统表明你不是机器注册,是真人用户,以及向你推荐对应的标签视频,这里的标签是指你是用户。所以需要不需要像网上培训所说花一周时间来养号呢?答案很明显,不需要!完全没必要。科普一下,官方明确公示过,抖音的标签有两个:用户标签和创作者标签,你每天刷的视频类型构成了你的用户标签,你账号发的内容才决定你的创作者标签。这两个是不冲突,也没关联的。 善于运用热门的梗:抖音每隔一段时间就会出一个热门的梗,可以尝试做一下排名评分类视频,这样的话有不同的意见,评论区也会有人去讨论带动评论区讨论;
-
营销系统复盘
如今随着互联网的不断发展,更多企业会利用互联网做营销推广,互联网的各种渠道进行宣发触达,利用各种数据进行分析,是如今很适用的一种营销方式。 一场营销活动的全流程,涉及:活动物料制作:活动h5、小程序、海报等;渠道分发:线上渠道(微信群、公众号、APP等)、线下渠道(门店、网点、卖场等);运营策略:用户挽回、生日关怀、裂变拉新等;用户触达:通过短信、微信模板消息、app push等方式触达用户;用户数据沉淀:身份信息、行为信息;BI展示/数据分析:访问量、分享数、转化率等报表展示与分析。 针对以上营销活动的全流程所需的基础设施进行抽象,可以得到营销系统所需要的功能模块:活动编辑器:活动制作能力复用。(不建议划到营销系统的范畴);渠道管理:渠道新建、删除、修改以及以渠道为维度的数据统计查看等;营销自动化:根据既定营销策略,根据事件触发,自动化对客营销。比如生日前3天自动给客户推送生日券等;触达:短信推送、邮件推送、微信模板消息推送等; 客户档案:客户标签系统;大数据底层:数据采集与处理;BI:数据可视化展示。 以上可以归结到业务基础设施的范畴,解决的是营销活动发起的效率与成本问题;目前业内大部分的营销系统,基本都包含以上模块。 在具体项目中跑模型,跑出成功的模型后,扩大到同行业其他客户甚至跨行业客户,验证成功后对模型进行产品化;最后由这一个个经过成功验证的产品组成提供跨行业的一站式解决方案的营销平台。 系统的设计者需要积累成功实践才能做出有价值的系统,而系统的使用者又需要一定的经验积累才能让系统产生价值达到系统设计之初的目的。
-
产品经理面试技巧
产品经理在经理面试时,面试官经常会提出一些产品经理高频问题,这些问题都是在考验产品经理对岗位的理解或者潜力如何。 简单的自我介绍,良好的开端是成功的一半,向面试官展示自我亮点的重要机会,可让他对我们产生兴趣,介绍时长控制1-3min。 自我介绍要保持良好的心态,心理暗示这只是和朋友简单交流,自信且充满热情。表达口语化,不要过于官方和呆板,就像讲故事或人物采访一样就好,切忌简历内容背诵出来。清晰结构化,搭建一个清晰的框架,反复练习调整,自我介绍是概括性的,“点到为止”让面试官感兴趣主动来问你,即设置”埋点”,让场子“热起来”进行有效互动。 结构化思维是将事物结构化,从整体到局部、层级分明地引导思维和表达的一种思考模式,传达出一种有层次、有条理、脉络清晰的感觉。 最后再总结下整个项目因为自己的很多付出而获得收益,同时自己也获得了很大突破和成就。 你怎么看待加班这个问题,面试官是希望听到“认同加班”的回答,这个问题了解我们对加班的看法,是否一刀切地排斥加班;我们不必为了迎合公司而宣称自己“365天24小时做牛做马在所不惜”,更不要去问面试官是否有加班费,会让面试官认为我们眼界太小太在乎钱。 建议是表明自己觉得加班是可接受的,并且举例说在之前某个工作经历中,我们也因为产品赶进度或临时紧急处理任务会积极无条件加班完成,当然加班是因为工作效率低这种情况,那就会努力调整提升能力或做好时间管理规划。 如果问道:你为什么想要离职?切忌说前公司的坏话,相反我是会说前公司的好,因为有它给了我提供很好的成长机会和发展空间,也再次强调我因此具备的核心能力和优势,也突出我们有明确的规划目标,主要从行业、公司和个人发展来回答:行业:例如传统行业效率比较低下,节奏比较慢,成长也比较慢,而互联网相对来说节奏比较快,工作比较有挑战性,所以自己也可以比较快速的成长。 公司和个人发展:任何人都希望在一个有发展前景的公司发展,随着公司一起成长,希望有一个更加成熟和强大的产品团队,这样可以在工作上获得更多的思想碰撞和交流指导等。 回答这个问题的时候一定要注意,尽量不要说公司的坏话,从公司的角度说一些客观存在且自己无力改变的事实;比如:公司频繁的转型,一直没有找到合适的方向,自己职责也一直跟着变化,导致目前的工作内容与最开始的预期不符,或没有标准的工作流程以及培养体系,所以想找一个更大的平台发展。
-
交互设计师的必备技能—预判设计
预判设计(Anticipatory Design)是一种能够引导用户、缩短用户行为路径的有效设计手段。预判设计,可以根据用户的行为/用户所在的场景,让功能主动找到用户,并让用户与之产生自然的交互。 这种操作模式符合我们对于绝大多数产品使用的认知,交互设计师在设计用户行为路径时,往往是以功能为出发点,通过功能优先级,将功能分布排列,用户在界面中找到功能并进行操作。 这本质上还是依赖于用户的主动触发,一般来讲,如果用户不主动触发,就不会产生后续行为。 设计心理学中提到,当用户操作一个设备,他们会面对两个心理鸿沟:一个是执行的鸿沟,在这里,用户试图弄清楚如何操作;另一个是评估的鸿沟,在那里,他们试图弄清楚设备处于什么状态,他们采取的行动是否实现了目的。 预判设计侧重于解决第一个鸿沟:执行的鸿沟。在产品功能纷繁复杂的当下,界面中的功能元素、信息元素愈发复杂,有的时候,用户想要在一个界面中找到某个功能、操作某个功能并不轻松。预判设计,可以根据用户的行为/用户所在的场景,让功能主动找到用户,并让用户与之产生自然的交互。 预判设计首先是基于用户本身的,即系统预测用户即将做的事情,并且帮助用户缩短操作路径,整个过程虽然是系统主动发起,整体上却是符合用户整体预期的。而如果单纯只由系统主动触发,却与用户当前行为没有任何联系,就不算预判设计。 用户的交互行为是多样,常见的有复制/剪切、截图、手势(如摇一摇)等,从理论上讲,用户的各种行为都存在提供预判设计指引的可能性。 预判设计与用户行为、功能场景是紧密关联的,或者说,系统基于用户操作的行为或用户所处的场景才能形成合理的预判,否则很容易引起用户反感。 同一个行为,在不同场景,也会存在不同的预判设计方向。
-
产品经理做些什么来保障项目按时上线呢?
产品经理的任务就不仅仅在于完成产品策划,还需要承担项目管理工作,跟进项目进度,必要时还得出面协调和争取研发资源、解决冲突,以确保项目按时、按计划完成上线。但如果不是专业项目经理出身,应该怎么做来保障项目按时上线呢? 按照管理学对项目管理这一分支学科的定义,项目管理是指 “在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程”。 简言之,就是要懂得如何在复杂多变的环境中做好一件事,使这件事最终能达成目标。按照PMP(项目管理专业人士资格认证)的知识体系,项目管理的全过程分为5大过程组、10大知识领域、49个过程活动。 就国内的情况而言,大多数公司普遍更适合敏捷项目管理方法,一下内容分享的也正是本人基于敏捷思维下的项目管理实践经验:我们可以将一个项目从头到尾主要分为3个阶段:启动阶段、实施阶段、收尾阶段,每个阶段再梳理出关键事项,就形成了项目管理三阶段。 一份好的产品策划案需要具备以下几点要素:清晰的项目背景和价值阐述;明确的项目目标;不用过于追求原型的美观与酷炫的动效。产品经理应该注重需求的完整性以及清晰表达,但有时候简单的一个交互动效会比长篇累牍的文字描述要高效许多,恰到好处即可。 在项目启动阶段的重点是做计划,计划为纲,包括产品策划、提前识别风险、完成需求评审会,得出项目排期表。 在项目实施阶段的重点是监控进度,监控进度有几个工具:项目排期表、任务进度表、每日站会,而且项目计划需要在实施阶段根据实际情况动态调整(如需求变动、未知风险发生甚至目标变化等);完成项目上线不是项目的终点,在收尾阶段的重点应是复盘总结,沉淀项目经验教训,为后续项目沉淀经验资产。
-
如何提高产品留存
在这个流量为王的时代,流量的获取并不容易,而留存则更不简单。一味的强调获取流量并不是明智之举,如何抓住流量是应该考虑的重点问题。随着互联网人口红利的褪去,不少用户会同时使用几种同类型的产品,做不到留存就得不到忠实用户。产品留存,决定着一个产品的生死。 在以往流量时代,许多公司都在强调用户增长,想要用一切的力量去达到用户增长这个目的,不增长,不成功,彷佛产品一旦出现停滞的增长,就很难生存下去。 但是近年来,随着新用户转化成本的逐年上升,互联网人口红利减少,产品和用户越来越多出现同质化和用户同量化。一个用户,可能既是A产品的用户,又是竞品B产品的用户,交叉相互使用。 所以近年来,也越来越多的企业认识到存量时长的重要性,更加意识到产品留存的重要性。产品留存就像一个水池的出水管一样,这根管子的大小,流失的快慢决定着池子里能存多少水,在很大程度上也决定着产品是否达到MVP模型,决定着一个产品的生死。 提到产品留存,就一定会提高大家都非常熟悉的AARRR模型。在这个模型中,用户留存处于激活和变现的中间位置。 如何提高产品留存,达到用户增长的目的?但是,在我看来,产品留存不应该只是处于中间位置,链接激活和变现,它应该贯穿在整个用户的生命周期,最终实现商业变现和用户增长的目的。激活也是为了更好地提高留存,转化也是提高留存的一种手段和方式,比如各大平台推出的会员产品。 产品留存的本质是产品能够持续地满足用户的需求,并且随着使用时长的增加,产品的替换成本越来越高,用户也就更加倾向于在原来使用的产品中继续留存。替换成本越来越高,用户也就更加倾向于在原来使用的产品中继续留存。产品的长期价值成立和稳定,是产品留存能够产生意义的提前,也就是说产品本身能够解决用户的痛点,痒点,满足用户的爽点的。 但是不同的产品类型和变现模式,在确定留存指标的时候也存在明显的差异。广告模式变现的产品,更加主动使用的使用时长和单次广告的曝光价值,内容社区一方面注重内容的生产情况,另外一方面也注重消费用户的消费情况。 针对产品的核心价值和功能点,可以满足不同用户长期留存的需求。功能越完善,越可能满足众多用户的需求,但是也并不是越多越好,如果核心功能不能很好地做好用户留存,那么再多的功能都只能是拯救产品。
-
优秀的需求文档结构
说到产品经理的基本技能,很多人第一时间都会想到需求文档,需求文档是产品经理日常工作输出最重要的文档。对于许多初级产品经理来说,最迫切想要提升的,应该是写需求文档的能力。同时,写需求文档的过程,更是变相地锻炼产品经理的逻辑能力、全局能力、判定需求真伪能力、排需求优先级能力的良性过程。 产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。 PRD的主要使用对象有:开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前,必须要通过评审确定的最重要文档。 每个产品经理的需求文档,长得可能都不一样,每个人都有表达自己逻辑的方式和习惯。但是对于初级产品经理来说,还没有形成自己的风格之前,需要先了解需求文档的通用组成部分,以及尽可能多的参考和学习其他产品经理写的需求文档,以此来吸取精华,去其糟粕,后期再逐渐形成自己的风格。 这部分对于开发和测试没那么重要,但是对于产品经理本身却是最重要的部分。这部分的主要工作,就是梳理这个需求的来源、背景、方案、价值。任何一个需求的提出和落地,都离不开背景、方案、价值的思考,产品经理务必在认真思考清楚这3个方面之后,才着手整理更细的逻辑方案。 查阅需求文档的人,除了产品经理自身,还有开发、测试、UI、老板、其他产品经理,因此,这个需求值不值得做,做,这个方案是否是最优解?最好了,有什么用?这几个问题,产品经理需要先说服自己,才能说服其他人。
-
一个新手面试Linux运维工作至少需要知道哪些知识
首先明确一下,今天所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的;然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范、知名度、服务器 量级、pv量等考虑,其它因素不是重点;因此,我们先定义服务器规模大于1000台,pv每天至少上亿(至少国内排名前10),如sina、baidu、 QQ等等;其它小型网站可能没有真正意义上的运维工程师,这与网站规范不够和成本因素有关,更多的是集合网络、系统 、开发工作于一身的“复合性人才”,就如有些公司把一些合同采购都纳入了运维职责范围,还有如IDC网络规划也纳入运维职责。所以,非常重要一定需要明白:运维对其它关联工种必须非常了解熟悉:网络、系统、系统开发、存储,安全,DB等;我在这里所讲的运维工程师就是指专职运维工程师。 运维工程师的职责:”确保线上稳定“,看似简单,但实属不容易,运维工程师必须在诸多不利因素中进行权衡:新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素,都会是网站稳定的大敌,运维工程师必须把控好这最后一关,需具体高度的责任感、原则性及协调能力,如果能做到各因素的最佳平衡,那就是一名优秀的运维工程师了。 运维是一个集多IT工种技能与一身的岗位,对系统->网络 ->存储->协议->需求->开发->测试->安全等各环节都需要了解一些,但对于某些环节需熟悉甚至精通,如系统 (基本操作系统的熟悉使用,*nix,windows ..)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理)、通用应用(如lvs、ha、web server 、db、中间件、存储等)、网络,IDC拓朴架构。 开发能力,这点非常重要,因为运维工具都需要自已开发,开发语言:perl、python、php(其中之一)、shell(awk,sed,expect….等),需要有过实际项目开发经验,否则工作会非常痛苦。 通用应用方面需要了解:操作系统(目前国内主要是linux、bsd)、webserver相关 (nginx,apahe,php,lighttpd,java)、数据库(mysql,oralce)、其它杂七八拉的东东;系统优化,高可靠性;这些只是加分项,不需必备,可以边工作边慢慢学,这些东西都不难。当然在运维中,有些是有分工偏重点不一样。 系统、网络、安全,存储,CDN,DB等需要相当了解,知道其相关原理。 想要做一个合格的运维,要保证服务达到要求的线上标准,如99.9%;保证线上稳定,这是运维工程师的基本责职所在。还要不断的提升应用的可靠性与健壮性、性能优化、安全提升;这方面非常考验主动性和创新思维。 网站各层面监控、统计的覆盖度,软件、硬件、运行状态,能监控的都需要监控统计,避免监控死角、并能实时了解应用的运转情况。通过创新思维解决运维效率问题;目前各公司大部份运维主要工作还是依赖人工操作干预,需要尽可能的解放双手。 运维知识的积累与沉淀、文档的完备性,运维是一个经验性非常强的岗位,好的经验与陷阱都需积累下来,避免重复性范错。计划性和执行力;工作有计划,计划后想法设法达到目标,不找借口。 自动化运维;能对日常机械化工作进行提炼、设计并开发成工具、系统,能让系统自动完成的尽量依靠系统;让大家更多的时间用于思考、创新思维、做自已喜欢的事情。
-
腾讯云cloudbase云开发
云开发(Tencent CloudBase,TCB)是腾讯云提供的云原生一体化开发环境和工具平台,为开发者提供高可用、自动弹性扩缩的后端云服务,包含计算、存储、托管等 serverless 化能力,可用于云端一体化开发多种端应用(小程序、公众号、Web 应用、Flutter 客户端等),帮助开发者统一构建和管理后端服务和云资源,避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。 您可以使用云开发,轻松开发多种端应用,包括小程序、公众号、Web 应用、Flutter 客户端等:构建属于您的博客:将您的静态网站文件部署到云开发静态托管中,您的用户可以随时随地通过域名访问您的博客。 分析海量图片:将您的照片存储在云开发云存储中,使用图像标签扩展能力,轻松完成图片标签识别,帮您实现相册分类。 构建运营管理后台:使用 CMS 扩展功能,帮您完成文章编辑和发布、素材管理等数据和内容的管理,省去您手动线上修改数据库数据或者开发管理后台的麻烦。 最近折腾了一下腾讯云最近上线的静态网站托管产品,结合腾讯云提供的 CloudBase CLI 工具,可以实现的第三方的任意一个服务器快速持续部署自己的 Hexo、 VuePress、 Hugo。
-
DevOps部署和发布方法
在互联网和SaaS之前的时代,通常是,先有发布(Release),再有部署(Deployment)。研发团队发布一个版本,代表着开发完成并且测试完成是一个可以销售的软件,也代表着这个软件的上市。 将软件售卖之前,需要把版本复制到软盘、U盘或者刻录到光盘上,通常叫做发布到工厂(RTM,Release to manufacturing)。软件正式上市售卖代表着软件已经Gone Live,上线。 如果是面向个人的桌面系统软件,那么由个人担当部署的人员,将软件(来源于软盘、光盘、U盘)进行安装,安装后自行进行配置。如果是面向企业的软件,那么由甲方的IT工程师负责安装和配置,或者是由乙方的服务人员负责安装和配置。 还有另外一种情况,在甲方真正安装和配置软件之前,有一个用户验收测试(UAT,User Acceptance Test),在甲方的机房,先安装和配置一套,然后由甲方进行测试,如果测试通过,代表验收成功,就可以正式的去安装和配置。在互联网、移动互联网和SaaS时代,通常是,部署就代表着发布。敏捷DevOps时代,部署和发布解耦,变成了持续部署,按业务需要发布。 对于一些ToB的企业级软件,例如电信行业,通常是软件+硬件整体销售给运营商(例如中国移动),仍然会涉及到发送硬件(例如交换件、路由器)到运营商,然后设备商(例如华为)的服务人员在客户现场进行机房、硬件等的安装和配置,之后才会割接上线。 蓝绿部署是指有两个完全相同的、互相独立的生产环境,一个叫做“蓝环境”,一个叫做”绿环境“。绿环境是用户正在使用的生产环境。当要部署一个新版本的时候,先把这个新版本部署到蓝环境中,然后在蓝环境中运行冒烟测试,来检查是否正常工作,当一切准备就绪以后,向新版本迁移就非常简单了,只要修改一下路由配置,将用户流量从绿环境导向蓝环境就可以,这个时候蓝环境就变成了生产环境,这种切换通常在一秒钟之内就能搞定。如果出了问题,把路由器切回到绿环境上即可,然后在蓝环境中调试,找到问题的原因。所以蓝绿部署,是在部署之后,仅仅一次切换,立刻就向所有用户推出新版本,新功能对所有用户立刻生效可见。