邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9952 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

08 | 关于需求变更(下) : 化变更于无形

邱岳 2017-12-07
“拥抱变化。”——阿里巴巴价值观之一
上一次的文章中,我聊到了需求变更的原因,以及通过引入需求评审来尽可能避免需求变更,并在文章的最后提到了一次并不成功的项目经历。
这次项目已经根据项目流程开过了需求评审会,却没有在这个环节暴露问题,直到临发布的最后一刻才引入了变更。那么,怎样改进需求评审才能避免未来可能的变更呢?

“具体”的力量

大部分的需求评审会都是过场,大家下面玩玩手机,产品经理在上面对着需求文档读一遍,再开开心心散会,除了浪费了时间,什么用都没有。
这里最大的问题不是参会的人员不负责任,而是需求评审时的方案不够“具体”。
我曾听说在微信团队里,不少产品在做出来之后,需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断,还听说有不少东西已经做出来了,但没有通过实际使用测试,所以一直压着没能发布。
我想,或许你也有同感,一个东西画在线框图上总是觉得很远,只有在指尖动一下才能有真切的体会和判断。
所以对一些关键性的特性,在资源配置合理的情况下,尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的,架构可以是假的,但看起来和用起来要尽量保真。
我记得以前有一次观摩一场游戏 Demo 制作比赛,团队在上面试玩展示,游戏角色在地图上能跑能跳,我特别不解地问旁边人:“这不都做好了吗,为啥还要参加比赛拿投资做开发?”他告诉我,虽然这看起来很完整了,其实后面都是空壳,大头还没开始呢。
在此之后,我经常提醒自己,对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的,让评审的人可以有真切的体验,把可能的问题都尽早暴露出来。有很多工具可以做到这一点,重一点的 Axure、轻一点的墨刀。如果实在不想学,用 PowerPoint 和 Keynote 也可以。
哪怕没有做成动态的,只是一张张截图,在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面,边引导大家边说:“现在我是一个从朋友圈打开 xx 的用户,我看到的页面是这个样子。”——这样代入具体场景,才能让大家产生真感觉。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(32)

  • 刘祯 置顶
    最近就遇上了需求变更,是在项目开发过程中发生的,早先的需求文档讨论都已确认,可在真正开发过程中却发现因为数据结构与真实性考虑,将原有流程重新拆分。此时面临着马上就要发布版本的情况下,好在开发还没做到这一步,临时变动还有挽回空间,只是项目上线压力更大了,最后那个例子看完了真的深有感触,我也希望遇见心态如此淡定的开发同事。

    回顾工作,我的经验就是两点:一是需求评审一定要细致;二是产品迭代一定要迅速。

    我们总说要设立项目里程碑与节点,可实践中却总是有各种问题,可能和公司整个管理方式有关吧。

    继续修行。
    2017-12-07
    8
  • 野山门
    写的很具体,很有参考价值。很喜欢和这样的产品经理一起工作,可以有很多机会蹭烧烤吃哈哈。

    作者回复: 哈哈哈哈哈哈好哇欢迎

    2017-12-07
    10
  • 剑走偏锋
    站在一个开发角度,结合敏捷实践,谈谈自己的想法:
    1. 团队的整体设置一定是快速响应变更的,需求的变更程度和sprint长度成反比,这个对于dev team的要求极高;
    2. 做技术的一定要积极投入需求评审会中,不断challenge产品经理,一方面帮助他们更多思考,另一方面探究自己的理解对不对,一定不能闷头执行;这就要求dev team一定是跨职能的,否则在开会时就他妈是走过场;
    3. 在技术层面,快速响应变更后面意味着有一套完整的TDD,CI/CD流程,否则无法形成可靠的workflow。

    依然在不断践行中........
    2017-12-21
    9
  • Atom
    哈哈哈哈哈哈我用PS+PPT,不仅做静态原型,偶尔还做小动效。PPT打到屏幕上还是比用网页好的,6的屏幕750*1334,两侧空出黑色留白,视觉效果很集中。

    作者回复: PPT 的交互效果好像可以做得更酷炫

    2017-12-07
    8
  • 桃园悠然在
    赞同“留给需求发酵的时间”,实际工作中要求是当前版本提测时下个版本就要需求评审,但由于白天时间被各种“会”占据,经常只有晚上才有时间发酵需求,很容易陷入疲惫的循环。二爷能简单讲讲日常产品工作流或精力分配么,谢谢
    2017-12-07
    7
  • Bonnie Mei
    把需求文档凉了半天再去看,发现调整的地方还是有的,以前是不想看自己已经做完的东西,现在要勇敢面对。

    作者回复: 看过去的东西觉得不完美,也说明自己进步了

    2017-12-21
    6
  • GeekAmI
    二爷这都是血的教训的总结啊。我们团队是技术、设计、老板一起讨论需求,让设计出设计稿,大家一起填坑和优化。没有产品经理这个职位。
    2017-12-07
    6
  • vincent
    这不光是硬汉,更是大牛

    作者回复: 嗯,硬汉一般都挺牛的

    2017-12-07
    4
  • Jason
    这上下两篇写的好。作为研发,我终于了解了需求变更的前世今生。同时觉得,产品经理真不容易,笑哭😂
    2018-06-07
    3
  • 张楚琪
    看过一个段子:
    「产品经理经常变更需求怎么办?」
    「打一顿就好了……」

    有时候需求变更是没考虑周全,这时如果有比较充裕的需求发酵时间,可能可以减少被打的次数,因为没准自己就把自己给打了,自己打自己下手可以轻点。

    有时候是不得不变更,比如有更好的满足需求的方案了。感觉无论哪种情况,第一时间「自首」特别重要。跑过去,相视一笑,嘻……嘻嘻嘻,嘿……嘿嘿嘿,「兄弟喝什么奶茶?我请」,等愉快的喝完奶茶后,「这个功能如果我们这么做,你觉得怎么样?」,在奶茶带给人的愉悦感还没消失的时候,一般就不太会被打了,即使被打,也会轻一些。

    作者回复: 哈哈哈哈哈哈哈哈哈哈哈哈哈

    2017-12-07
    3
  • 丸子
    最近接手了个半路撂挑子的项目,前任不明确的需求在我提给研发的时候收到了负面反馈。
    他的意思是我做好了你为什么要改?
    我的想法是你做的是错的我这不是新需求只是 提 bug。
    不欢而散。
    最近越来越觉得,有个认真负责的产品把需求都想清楚,可以避免很多无用功,接过别人几个烂摊子之后就很反感人人都是产品经理这个说法,其实产品的门槛不低,不是人人都能做的来的。

    作者回复: 产品经理进门的门槛不高,但做到合格挺难的

    2018-04-14
    2
  • Henglu
    虽然是产品实习,但是已开始看到二爷说的所有产品变更的场景。

    作者回复: 常态,习惯就好了

    2018-01-02
    2
  • 拾叔
    其实我就一直觉得需求评审很无聊,我们的需求评审叫KT~knowledge transfer ,含义就是将需求同步各方。所以其实需求评审,我理解,其实就是需求的最后一步,最关键的都在评审前。
    需求变更,我们的定义一般处于评审之后到kick off之前,如果已经开发了,再变更,基本要挨刀子,小的变更还好,出个邮件,更新下文档就可以,开发基本能忍,如果大的改动,基本都要重新需求评审重新走流程,不管开发是否要求,从需求准确性考虑都要这么走,否则,很有可能到时候需求没同步到位,导致坑一大片
    2017-12-26
    2
  • 时间之树
    对于投入产出比的权衡,是一个产品经理很重要的能力,同时也是不断学习的目标。对于二爷提出的通过流程来对抗变更,深有同感啊,看似降低了成本,实则严重降低了效率。

    作者回复: 嗯 有时候只想着用流程来限制问题发生,却忽视了流程可能带来的伤害

    2017-12-25
    2
  • grayson
    原则就是如果开发接手后有变更的想法,一定尽快跟工程师沟通,不要自己去猜测成本,而是让开发去做判断,然后再综合沉没成本和额外增加的成本去做评估。


    这里有个前提很重要, 找到对的人。 知道谁是对的人这个也是职场需要锻炼出来的。

    作者回复: 没错,在不知道怎么识别的时候,一般是直接找项目的技术负责人,如果他完蛋,基本项目也就完蛋了

    2017-12-18
    2
  • abillow
    拥抱变化,做到不易,即需要开放心态,又要能力过硬

    作者回复: 情绪也要稳定

    2017-12-07
    2
  • heha37
    硬汉
    2018-10-20
    1
  • 杜子
    我是技术,也是特别讨厌改需求,不过,也是可以理解的,一切都是为了做好产品
    2018-01-27
    1
  • Xg huang
    经历过二爷说的变更基准线的制度,确实会出现这样的问题,做法就是暂停现有的开发,需求方新提需求,再一起重新开发。这样开发流程很长,然而,没关系!领导认可

    作者回复: 传统软件公司可以理解,互联网企业这么做效率太低

    2017-12-15
    1
  • Lynn
    关于最后一点,让团队消化需求变更。其实也是产品的沟通能力之一,还有就是公司工作流程问题。需求变更出现在各个层级,领导要求变,ui设计又要变,开发过程中又会变又或许是需求方的业务需求变,那么对于这些场景来说,该用什么样的语言跟对方沟通?

    作者回复: 对方是什么世界的人,就用什么语言。比如跟开发尽量用技术语言,跟业务多说业务语言,争取打成谅解

    2017-12-12
    1
收起评论
32
返回
顶部