产品研发中敏捷方法的用与不用
敏捷并非万能,其应用需要结合具体场景和时机。本文从产品经理的视角出发,探讨了敏捷方法在产品设计、用户研究、交互框架定义等阶段的适用性与局限性。
敏捷的思想虽然起源于软件开发领域,但是实际工作中被不断泛化到其他工作领域,比如:用户研究、产品设计、交互设计、视觉设计、业务协作等场景。
但切记一句:敏捷初心不假,切莫无节贪用!
敏捷被利益相关方中的商业利益相关者(你团队的vp)所钟情,无非是看中他的经济高效的预期。这里就是经典的不可能三角,速度、质量、成本,不能同时兼得。所以,敏捷受到不可能三角的约束,换句话说,敏捷是不可能三角里面的最优解。
特别在产研前期的用户模型构建阶段、需求(场景需求或者俞军老师口中的交易模型)定义阶段、交互框架定义阶段,即便我们的开发团队迫不及待的想进入敏捷的节奏里面,恨不得边设计边coding,但是这里还是不得不刹一脚,尽可能的给即便是我们口口声声所谓的“敏捷设计”方法预留时间。
敏捷就算应用到用户体验设计阶段,也意味着无法一蹴而就的达到最贴合用户目标的设计。但也正是敏捷方法具有自己独特的优势,支持设计者可以在过程中进行定义的修正和优先级的安排。
大设计->大开发,是不是严格的瀑布?
先设计、再研发,常规理解上很像是经典的瀑布式模式,尽管在大开发内部已经普遍流行敏捷方法。但不得不说由技术限制蕴藏的阻碍与机遇,对于支撑用户目标、市场目标、商业目标来说也同样重要,这就导致了技术对于设计的反向制约。
你会发现,大设计、大开发其实并不太适合直接放在瀑布流中的。实战的经验也发现了,如果你把它们当作瀑布,严格遵守设计之后再去做开发,它们就会给你猛泼一脸冷水!最后还不忘一口,呸!相反,有些市场机会就算商业和产品层面嗅探到了,但也可能由于需要技术发展的跟进才能进行场景的承接落地。比如移动支付、短视频、NFC、RFID相关的商业场景,哪个不是要依赖技术和硬件设施的成熟后才得以场景的落地。
一个产品经理把敏捷方法应用到工作中,特别是新产品、完全开发需要一定周期的,敏捷给你的最有价值好处就是用户对于体验的反馈。哪怕前期的用户研究如何细致,当用户真正面对和使用产品时,真实的体验反馈/态度、如何使用、哪里易错、哪里出奇不意,这些一定是更为宝贵的资源,切实的把你引领到藏宝阁。
敏捷,有所用,有所不用,最底层思想大致总结为三点:
1、别死磕计划,先干再说
需求会变、问题会冒出来,别等“完美计划”,先做最核心的功能,边做边调整,越快看到结果越好。
2、别自己憋大招,拉所有人一起搞
客户、老板、程序员天天碰头,有问题当场吵明白,别等到最后才发现做歪了。
3、做一点就立马给客户用,听骂声
早挨骂早改,别等做了一整年才发现全错。客户骂得越狠,你改得越快,最后东西才靠谱。
适合用敏捷的:需求不明确、老变卦的事(比如做个新App、搞市场活动)。
别硬用敏捷的:
- 需求100年不变的事(比如造桥,图纸定了就不能天天改);
- 领导非要按自己说的做,不听团队反馈的;
- 团队躺平不沟通的,敏捷能急死你。
敏捷就是对付“变化多、要快”的武器,但如果你非要拿它砍柴,倒不如用菜刀。
作者:Kris_3zzz, 公众号:iSpiik产品说
本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自 Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
- 目前还没评论,等你发挥!