WdBly Blog

懂事、有趣、保持理智

周维的个人Blog

懂事、有趣、保持理智

站点概览

周维 | Jim

603927378@qq.com

推荐阅读

读人人都是产品经理

读人人都是产品经理

关键信息记录

  • 产品是什么?什么产品?

    • 产品承载了需求,是需求的载体。
    • 产品可以是有形的实物,也可以是无形的服务。
  • 产品经理的价值

    • 将用户需求转换为产品需求
    • 好的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给出更好的解决方案,或者说是用户真正需要的东西。
    • 需求存在来源于理想与现实的差距,而产品经理需要设法减小这个差距
  • 产品经理的宝典

    • 少做就是多做,要有意识的“尽可能多地放弃”
    • 听用户的但不要照着做
    • 做产品经理最大的快乐来源于实现自己的想法,而不是执行别人给的任务
    • 如何发现一个问题,并设法将其转化为一个任务对产品经理很重要
    • 用户的行为比语言更能反映出他的真实需求
    • 我们永远无法猜到用户会怎么使用我们的产品
    • 产品设计的最高境界 —— 创造需求
    • 为了产品,有些需求死得其所
    • 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子
  • 管理的能力: 在资源有限的条件下,完成事情的能力(如同创业,创业就是资源不足)。可以表现为几个方面

    • 信息不足以决策。
    • 时间不足以周全。
    • 人员不足以难度。
    • 资金不足以调配。
  • 需求采集过程

    • 明确目标、选择采集方法、制定采集计划、执行采集、资料整理、分析需求。
  • 需求采集的一般方式 - 用户访谈

    • 用户会骗人:用户可能不是故意骗我们,他们被问了自己也没仔细想过的问题,又不想回答不知道,就在现场编造了一个看似有理有据的理由,或者他们有讨好访谈者的心理,会回答他们觉得你希望听到的答案,而不是自己真正的想法。
    • 样板少时注意不要以偏概全,样本尽量随机,多组样本最好。
  • 需求采集的一般方式 - 可用性测试

    • 可用性测试方式为:通过指定几个测试任务,让用户实际操作完成任务,在这个过程中记录到发现的问题,最好询问用户的感受后思考过程。
    • 明确是测试产品,而不是测试用户:可以告诉用户来体验我们的新产品并提出一些意见,而不是使用”测试“这个字眼。
  • 需求采集的一般方式 - 数据分析

    • 数据的来源渠道和类型比较多,客户端的操作日志(点击、移动,浏览等),页面的PV、UV等,原始数据最重要的是要准确。
    • 防止对数据沉迷于“科学研究”:科研的结果不是为了马上应用,而是为了证明实力,而实际上我们更加追求性价比。
    • 不要无意误读数据:不同类型数据的分布模式不尽相同,如人均收入不能使用平均值衡量(不满足正态分布),一个超级富豪和 1000个零收入的人一平均,很可能得出人均收入 100 万的荒谬结论。
    • 不要有意误读数据:所谓有意误读数据是指你抱有一定目的去寻找或验证数据,抱着这种思想,你总能找到相关数据。在分析数据前应该尽量减少利益牵扯,如为了证明老板的判断,或者为了保持自身英明形象。
    • 在产品设计初,就应该考虑到数据分析需求,如为按钮添加事件等等。
  • 需求采集的一般方式 - 二手需求

    • 二是需求通常是从老板、销售等人员中获取的一些过滤后的需求。
    • 产品开始阶段,更多的是从各个渠道获取需求,而在产品发展阶段,会有很多需要被”推“过来。
  • 用户是为想要的东西买单,而不是需要的

    • 用户是为自己提出的解决方案买单,而不是我们的解决方案
    • 其实这是短期利益和长期利益的权衡,如果是一锤子买卖,卖出以后又不用售后,那么采用实用主义,不妨用户要什么就给他什么,这样他掏钱最爽快,但是,我们的产品通常都是希望用户长期使用的,并且后续的服务也是我们来做,所以为了长期利益,我们就有必要找到用户的真实需求,然后给他真正合适的产品了,哪怕这个过程不那么讨好。
  • 降低用户需求和现实的差距

    • 改变现状:直接开发新产品。
    • 降低理想:打预防针、丑话说到前面、对比其它等。
    • 转移需求:通过寻找更加强烈的需求获引导用户关注其它需求。
  • 将用户需求转换为产品需求

    • 用户需求与产品需求是多对多的关系
    • 确定需求的基本属性: 如新增功能、功能改进、体验提升、Bug 修复、内部需求等。
  • 分析需求的商业价值

    • 重要性:很重要
    • 紧急度:紧急的需求重要性不一定高,如果熬过去没做,对长期影响不大
    • 持续时间: 如节假日的活动需求
  • 初评需求的实现难度

    • 实际中通常使用工作量来对难度进行量化,通常是以团队里的瓶颈资源的工作量为基准进行评估(如主要工作是开发,则以开发的工作量为评估)
    • 而开发量的评估需要工程师来评估,然后这会面临一个问题,需求不明确的条件下工程师无法给出准确的工作量,而产品经理又需要一个工作量来确定具体需求,这是个死循环。
    • 初评时需要经验较为丰富的工程师评估一个大概开发量(人/天),项目启动后,在确定具体工期。
  • 如何判断先做哪个需求

    • 绝对不能因为某个需求的实现难度很小就马上去做,也不能因为另一个需求的实现难度大就不做
    • “不要试图满足所有用户”,一切皆看性价比,性价比 = 商业价值÷实现难度(简化为开发量)
    • 但是工作中对“性价比”的判断还是会经常有偏差,很实际的一个原因,是自己经常和哪类人接触
  • 需求 PK

    • 需求 PK争夺的是后续的人力资源,即总是不够用的开发工程师、测试工程师等。
    • 有这样情况的原因在于公司的产品和研发部门分离,按职能线划分,初创产品多是按照产品线划分,产品的开发、测试等部门为一个整体。
    • 当公司里有多个产品慢慢成熟之后,就多用职能线来更充分地利用资源。
  • BRD 商业需求文档

    • BRD通常会跟老板、市场、销售等业务部门对接,主要应该包含几点内容。
    • 1、项目背景:我们在哪里?为什么要做这个项目,解决什么问题,可以列出一些数据说明项目的必要性。
    • 2、商业价值:我们去哪里?最关键的重点!大老板们最感兴趣的,做了这个项目以后有什么价值,一定要说在点子上。一般我们还会预测一下相关数字的变化,提出这个项目的商业目标。
    • 3、功能需求描述: 我们如何实现需求,当然我们也经常会
      搞点技巧性的东西,比如故意加入一些让老板砍的需求,希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西
    • 4、资源评估。
    • 5、风险和对策: 有的项目会有一些潜在风险,这个时候不妨抛给老板们看一下,并且给出自己的对策,说不定你觉得是很大的麻烦,在老板那里一句话就可以搞定。而且由于信息的不对称,我们无法了解某些功能是否会与公司将来的战略冲突,这时候提出来也是让老板们把一下关。
  • 尽可能多地放弃

    • 要想知道放弃哪些,我们需要收更多的需求,以看清事物的全貌。
    • 看到事物的全貌,有了大局观,在放弃的时候才知道孰重孰轻,也更下得了手。

项目 VS 产品

  • 什么是项目

    • 通用定义: 一系列独特的、复杂的、相互关联的活动组成,活动有着明确的目标,并受预算、时间等资源限制。
    • 互联网中常见项目定义: 为了实现产品而发起的一个又一个工作。
  • 项目坎坷的一生

    • image.png
  • 产品和项目对比

    • 生命周期:产品生命周期较长,没有明确的结束时间,项目通常生命周期短,有明确的结项时间。
    • 做事过程:做产品的过程更多的是探索,随着内外信息的变化,需要调整策略和方向,注重创新;而项目一开始就有明确的目标,注重的是计划与控制。
    • 产出事物:产品更像是用有限的资源去完成一个批量的、通用的事物;而项目的产出更多的是定制化,为了满足特定需求。
  • 产品经理和项目经理对比

    • 产品经理: - 靠想,做正确的事情,多是一个信息汇聚、方向选择层面,主要是内部驱动。
    • 项目经理: - 靠做,正确的做事情,在有限资源下完成既定目标,主要是外部驱动
    • 两者对冲:两者在实际的职能和工作中,是对冲关系,产品经理往往关注的产品的商业价值,需要更多、更完备的功能来满足用户需求,而项目经理却想尽可能小的控制工作范围。需要在这之间寻找到一个平衡。
  • 项目团队结构
    image.png
    image.png

  • bug状态流转图
    image.png

  • 产品生命周期所经历的会议评审

    • 商业会议:分析产品的商业能力,会决定三个事情,项目继续、项目重定向、项目终止。
    • 产品会议:决定做不做、做多少
    • Kick off: 产品启动会议
    • 需求评审
    • 设计评审
    • 功能评审:完成测试后由项目相关人一起对功能进行评审
    • 发布评审: 由开发经理决定是否需要。
提交

全部评论0

暂时没有评论...