邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
33999 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
邱岳的产品手记
15
15
1.0x
00:00/00:00
登录|注册

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

团队士气的回升
产品经理和工程师的沟通
限制需求变更的流程
抗拒需求变更
运营手段稳定线上
变更的慎重性
变更时机的判断
变更可能带来的成本
需求文档结束前
需求分析过程中
使用工具如 Axure、墨刀、PowerPoint、Keynote
提前暴露可能的问题
在资源允许的情况下做具体的 Demo
方案不够具体
互联网公司中的解决方案
团队对需求变更的态度
变更的积极意义
项目基本完成开发
工程师接手后
最佳时机
解决方案
需求评审会问题
未来改进需求评审
原因
重要性
化变更于无形
拥抱变化
让团队能消化需求变更
变更时机的选择
具体的力量
总结
有效减少需求变更的伤害值
有效减少需求变更的伤害值
文章主题

该思维导图由 AI 生成,仅供参考

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

“具体”的力量

大部分的需求评审会都是过场,大家下面玩玩手机,产品经理在上面对着需求文档读一遍,再开开心心散会,除了浪费了时间,什么用都没有。
这里最大的问题不是参会的人员不负责任,而是需求评审时的方案不够“具体”。
我曾听说在微信团队里,不少产品在做出来之后,需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断,还听说有不少东西已经做出来了,但没有通过实际使用测试,所以一直压着没能发布。
我想,或许你也有同感,一个东西画在线框图上总是觉得很远,只有在指尖动一下才能有真切的体会和判断。
所以对一些关键性的特性,在资源配置合理的情况下,尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的,架构可以是假的,但看起来和用起来要尽量保真。
我记得以前有一次观摩一场游戏 Demo 制作比赛,团队在上面试玩展示,游戏角色在地图上能跑能跳,我特别不解地问旁边人:“这不都做好了吗,为啥还要参加比赛拿投资做开发?”他告诉我,虽然这看起来很完整了,其实后面都是空壳,大头还没开始呢。
在此之后,我经常提醒自己,对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的,让评审的人可以有真切的体验,把可能的问题都尽早暴露出来。有很多工具可以做到这一点,重一点的 Axure、轻一点的墨刀。如果实在不想学,用 PowerPoint 和 Keynote 也可以。
哪怕没有做成动态的,只是一张张截图,在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面,边引导大家边说:“现在我是一个从朋友圈打开 xx 的用户,我看到的页面是这个样子。”——这样代入具体场景,才能让大家产生真感觉。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

如何有效减少需求变更的伤害值?本文从需求评审的具体性、变更时机的选择以及团队对需求变更的消化三个方面进行了深入探讨。首先,强调了需求评审的具体性对于避免需求变更的重要性,提出了在资源允许的情况下尽可能做一个与实际情况没太大差异的 Demo 来做评审。其次,文章指出了变更时机的选择对于减少变更伤害的重要性,强调了变更最好发生在需求分析过程中或者在需求文档结束、工程师接手前。最后,文章强调了团队对需求变更的消化,指出抗拒需求变更会导致团队士气下降,而在互联网行业中,变化是永恒的,团队需要随时准备好用最快的速度追击或躲闪。文章以实际案例和经验分享的形式,为读者提供了一些实用的建议和思路,帮助他们更好地应对需求变更的挑战。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品手记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(40)

  • 最新
  • 精选
  • 听天由己
    置顶
    最近就遇上了需求变更,是在项目开发过程中发生的,早先的需求文档讨论都已确认,可在真正开发过程中却发现因为数据结构与真实性考虑,将原有流程重新拆分。此时面临着马上就要发布版本的情况下,好在开发还没做到这一步,临时变动还有挽回空间,只是项目上线压力更大了,最后那个例子看完了真的深有感触,我也希望遇见心态如此淡定的开发同事。 回顾工作,我的经验就是两点:一是需求评审一定要细致;二是产品迭代一定要迅速。 我们总说要设立项目里程碑与节点,可实践中却总是有各种问题,可能和公司整个管理方式有关吧。 继续修行。
    2017-12-07
    11
  • 野山门
    写的很具体,很有参考价值。很喜欢和这样的产品经理一起工作,可以有很多机会蹭烧烤吃哈哈。

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

    2017-12-07
    13
  • Bonnie Mei
    把需求文档凉了半天再去看,发现调整的地方还是有的,以前是不想看自己已经做完的东西,现在要勇敢面对。

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

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

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

    2017-12-07
    10
  • 张楚琪
    看过一个段子: 「产品经理经常变更需求怎么办?」 「打一顿就好了……」 有时候需求变更是没考虑周全,这时如果有比较充裕的需求发酵时间,可能可以减少被打的次数,因为没准自己就把自己给打了,自己打自己下手可以轻点。 有时候是不得不变更,比如有更好的满足需求的方案了。感觉无论哪种情况,第一时间「自首」特别重要。跑过去,相视一笑,嘻……嘻嘻嘻,嘿……嘿嘿嘿,「兄弟喝什么奶茶?我请」,等愉快的喝完奶茶后,「这个功能如果我们这么做,你觉得怎么样?」,在奶茶带给人的愉悦感还没消失的时候,一般就不太会被打了,即使被打,也会轻一些。

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

    2017-12-07
    6
  • vincent
    这不光是硬汉,更是大牛

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

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

    作者回复: 情绪也要稳定

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

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

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

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

    2018-01-02
    2
  • 时间之树
    对于投入产出比的权衡,是一个产品经理很重要的能力,同时也是不断学习的目标。对于二爷提出的通过流程来对抗变更,深有同感啊,看似降低了成本,实则严重降低了效率。

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

    2017-12-25
    2
收起评论
显示
设置
留言
40
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部