您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
“极致”神话和产品观念
 
作者 曾成 来源:程序员杂志  火龙果软件  发布于 2015-1-7
   次浏览      
 

很多人、很多公司都在宣扬“极致”、追求极致,但在产品、在用户体验上追求“极致”真的一定就是对的吗?本文作者用他的切身经历谈了他对“极致”的理解,他认为不应该把“极致”作为开发路上的某种图腾或者指南针。

多年前,当我还是一个初出茅庐、颇为青涩的程序员时,曾经有这么一段经历:

当时我们所在的公司有一款已经可用的光通信局端产品,但是功能非常简陋,而且性能也谈不上出色。我入职没多久,这款产品的芯片生产商刚刚退出了光通信市场,也意味着不会再有后续固件发布,更不会有新型号的芯片出现。
当时一位做硬件的师兄挺身而出,肩负起了为公司的后续产品进行芯片选型的工作。没多久,新芯片选型方案定了下来。但是问题来了——新的芯片厂家也是一家规模还不算大的美国创业公司,所以在发布固件之余,实在是没有实力开发SDK为设备商使用。那位师兄的硬件出身使他在选型时更多的看重这款芯片的硬件性能出色和硬件周边设计方便,而在软件开发方面考虑得并不多。
正在这个档口,订单来了。无巧不成书,订单提出的要求正好要比我们的老产品提供的功能多出那么几项,而多出来的这几项又正好在新芯片的手册上声称可以支持。这里补充介绍一下,当时这家新芯片厂家真的是非常有美式创业企业的冲劲,正在以每两周或者一个月的周期,不断地发布着新芯片固件和芯片手册。
我还记得在一个大雪纷飞的傍晚,一帮身着各种颜色羽绒服的技术员,呼吸都伴着白色雾气,一边搓着冻得通红的手,一边轮流在白板前写写画画,点点刷刷,反复讨论。那场景,如同我曾讲过的其他故事,令我一直记忆犹新。
那场讨论中,年轻的软件开发者们达成了一个共识:不要在旧产品上耽误时间,而要和世界的脉搏同步,要和新的芯片龙头企业同步开发,我们要把自己品牌的新型号光纤到户局端产品做成精品,功能出众,性能超群,用全面的功能和出众的性能来赢得顾客的青睐,进而打开局面。产品经理虽然不懂软件,但也被我们的气氛所感染,眼里闪烁着发现金矿的灼灼光芒。
在讨论中,只有一个瘦小内向的测试负责人提出过一点不同看法,他问现在你们说的这些都是基于芯片手册,实际功能真的没问题吗?毕竟芯片刚刚下单,PCB制版、物料准备、芯片上板等工序完成之后,才能开始实际的验证。
然而这种忧虑很快被那个傍晚狂热的气氛所盖过,正如跳跃的火焰让人看不见周围的霜雪。
2个月后,芯片上板,软硬件联调时,发现终端会各种自动下线重启。
3个月后,新固件发布,终端下线重启问题解决,却发现端口限速无效。
4个月后,又有新的固件发布,端口限速问题解决,但是芯片内部桥不支持组播地址。这时,订单超期,我们始终无法交付重点关注组播订阅等功能的订单,公司因而错过了一次走上飞黄腾达道路的机会。在这4个月中,软件开发工作一直紧锣密鼓的有序进行,一点也没有耽误时间。软件架构的设计和实现都是非常迅速和高效的。但是为了组播功能在芯片固件上不能支持的条件下依然能够在产品上实现,只能改用主控程序来实现实时配置,打乱了原本合理的架构,产品的软件工作效率一下子陷入泥潭。
7个月后,解决了组播问题的新固件姗姗来迟,但是订单已经没有了,这时我们发现,虽然我们的确和华为和烽火等大厂在这一款主流芯片的使用上齐头并进,但是我们的公司已经没有资金继续当时的规模状态了。元气大伤的公司经历了很多人员变动,从此一蹶不振。

现在我还可以回想起那个寒冷傍晚的讨论,那时的气氛里其实并没有多少狂妄,有的只是一群年轻的开发者对于产品功能的完美追求;那时的气氛里其实也并没有多少偏执,有的只是一群开发者对于开发一个完善软件体系的执念。如果当时选择旧的芯片方案,其实最终功能的添加也绝不会花费4个月的精力,只不过看起来用的芯片还是旧的,只不过看起来没有“弄潮”的主观感觉罢了。

正因为我有过这段刻骨铭心的记忆,并且在日后总是反思当时究竟做错了什么,才导致一个好端端的项目就这样泡汤了,我有了很多和没有这样经历的人不一样的观点和思考结论。

今天的科技圈的朋友们,经常挂在嘴边的,就是“极致”。在论坛和新闻里,某某公司的成功源自他们对于“极致”的追求,某某公司产品的伟大,在于他们阐述了“极致”的用户体验等。一时间,似乎一个做技术的企业,如果不追求极致,如果不拿极致来标榜自己,就是不入流的表现,就是圈内朋友眼中的恐龙。

有一次,在一个技术论坛里,我将过去两年自己做可穿戴产品的经验和大家分享了一下,有一位做技术还比较资深的朋友留言说到:

“我觉得可穿戴设备受限于体积和续航能力,不能什么功能都要,一定要直奔主题,做到最简、最美、最实用。例如我老婆和她们的女性同事,一直抱怨手机太大,放在包里听不到。那么就只需做一个“信息提醒+时间显示功能”,对她们来说就足够了。其它的五花八门的功能,只能是负担。 我觉得,一个产品的极致,就是默默为用户服务,甚至不需要用户感知到它的存在。”

本文不讨论可穿戴设备究竟应该如何设计,也不讨论这位朋友印象中的极致具体内容是不是合理,只是单纯从他的逻辑来看,就会帮他得出一个逻辑结论:“xxx产品如果想要成功,就要做到极致”。

我把他的原话和我整理出来他的观点和很多身边的程序员朋友讨论。大部分朋友的第一反应是:“这对啊,没错啊!我也这么想!”

其实正是大家的反应才促使我有了写这篇文章的想法。从我的经历来看,大家的思路虽然看起来很合理,其实是经不住推敲,而且如果把这种思路当成产品开发甚至创业路上的指导思想,对不起,朋友,前面一定有大坑等着你哦!

为什么说“极致”这种东西是经不住推敲?

说白了,这个世界上,存在某种“极致”的产品吗?我认为不存在极致的产品,甚至不存在有着极致倾向的产品。

有人说你看乔布斯的苹果产品不就是“极致”的代表吗?持这种观点的人还真不少,原因可能是他们记忆力太差。2007年第一代苹果iPhone手机托乔布斯之手来到人间时,大家的确感慨于它的设计美学新颖独特,但是当时就有很多人吐槽iPhone手机的缺点。当时一副很有名的图片是将一部iPhone手机和一块石头放在一起,先列举它们的相同点:1.它们都不能播Flash;2.它们都不能进行视频录像;3.它们都不支持邮件附件。再列举它们的不同点,原来石头比iPhone手机结实。这样的嘲讽段子广为流传,在Nokia统治年代的人看来,刚刚诞生的iPhone手机和“极致”完全是八竿子打不着的关系。在当时的技术人员看起来,苹果手机不过是选用了一块支持多点触控的电容手机屏罢了,其他乏善可陈。也许现在大家因为苹果的成功而逐渐重新审视当年对iPhone的偏见,但这种偏见的存在恰恰说明苹果从来都不是追求所谓“极致”的。

再看谷歌、微软、亚马逊、IBM、Facebook、Twitter、阿里巴巴、腾讯、百度这些巨头们,也看不出它们的哪款具体的产品带有公认的“极致”烙印。

其实,“极致”从来都不是产品需要具备的品质,甚至从来都不是成为产品的开发倾向。产品的天性,只是迎合消费者的需要,体现技术的价值而已,无他。

但是这两年的确一股“极致”的语境席卷技术圈和创业圈。大家动辄就说雷军做小米手机追求极致,一会又说罗永浩真的是追求极致,还有不少人追捧黄章做产品追求极致,紧跟着的周鸿祎、傅盛、刘作虎等等,也都间或被圈里圈外的人奉作极致主义者,真不知道这是在吹捧,还是在用高级方式黑他们。黑吹风起云涌之后,后来的创业者们,往往赶紧给自己也打上这样的标签,以免看起来没有“成功相”。说穿了,“极致”在这里,已经成了一种宣传与推销手段,和“高尚”用于房地产销售, “领袖”用于汽车销售,是差不多回事。

思想淳朴而又善于虚心学习的程序员和技术开发人员在这样的语境下容易受到影响,开始产生词语崇拜,觉得“极致”这个表述可以用在工作中,并口口相传,形成某种一致的意见。我承认在工作中精益求精无可厚非,但是如果把极致用在产品开发和创业中,就有可能存在严重的后果,有两种情况:

  • 第一种,在产品开发中引入“极致”概念,必然带来一个逻辑谬误,那就是,我只管做好我自己的产品,做到极致,至于用户想要什么,我不用关心,也不应该关心,因为做到极致,用户自然就买账了。
  • 第二种,在创业中引入“极致”概念,小小的体量,却要大跃进式地完成跨越式的开发工作,制定一个又一个和自身实力不相称的项目计划。

这两种情况,明眼人一看就知道会出问题,但是它们的出发点都是一个看起来良好的“极致”观念,这就说明其实是观念害人。

写了多年代码,做了多年产品和不同的项目,笔者的感受是,这个世界上不存在完美的代码工程,尤其没有推翻原来设计而后短时间重来能写得完美的代码。

软件开发是有规律的,开发者在开发的过程中的确有很大的成长空间,但是软件产品在特定功能情境下,就应该维持其可运行状态就是最好。认为有了更强的开发能力或者更新的见解就肆意对成熟软件产品进行轻率的架构重整,只为实现本来已经实现了功能,往往因为未能理解原来设计的奥妙导致得不偿失。

“代码是为产品服务,产品是为用户服务的。”这是一个非常简单直接的道理,但是这个道理在纷繁复杂的当今社会,竟然被各种花花绿绿五光十色的词汇所裹挟与扭曲,忽视用户,忽视产品生命周期,追求虚无缥缈的所谓“极致”与“完美”,出现这样的苗头其实是非常令人诧异和心痛的。

写到这里,就非常想提一下作者十分想阐述的产品观念,对年轻的程序员和产品创业者们应该有些帮助。

首先,产品的功能多还是少,不应该是开发者自己决定的,而是下游的客户和上游的组件供货商共同决定的,成熟稳定的功能可以越多越好,但不成熟或者没有把握的功能一定要尽量砍掉。这一方面是用户体验的考虑,另一方面是要节约有限的成本与宝贵的时间。

第二,产品的开发应该尽可能敏捷,这种敏捷体现在软件产品上,就是从第一版成型的应用或者系统开始,都应该是可发布的。在发布之后的每个后续阶段,都保持有随时可以交付的产品,交付的产品可以做加法或者减法,但是千万不能出现说因为几个功能还未实现导致不能交付的拖延情况。

第三,不要制定遥远漫长的工作计划,如果做不到高瞻远瞩,那就尽可能把最重要的功能实现,保证系统可运行,其他的,寄希望于天才的援手和用户的体谅。

这三条都是大白话,产品的开发有很多经典的书籍作为指导,作者简单地归纳一下,算是作为给予新人和年轻的产品经理们由衷恳切的建议箴言。

话说回来,谈论“极致”这件事情,本意上就是想指出开发过程中的产品思维,产品思维应该是简单而直接的,务实而非务虚。产品经理,或者一个产品创业者,都不应该把“极致”作为开发路上的某种图腾或者指南针,创业团队首先要跳过一个又一个泥潭与陷阱,至于是否“极致”,还是生存下来之后,任凭好事者评说好了。

天渐渐凉了,每到年尾,又有很多项目即将面临着交付,面临着来自客户最终的验收,或者面临放在公开的市场上等待用户的选用。无论哪种情况,产品都是一个技术人交予这个世界的一段心路历程。由衷的希望,在一个又一个和我回忆中并不相同的会议室或者办公间里,经过一番深入的讨论,你们的团队可以得出一个和我们当年不一样倾向的结论,进而开始一段和过去的我不一样的旅程。

   
次浏览       
 
相关文章

中台产品面面观
如何在互联网产品中建立中台?
什么是产品生命周期管理?
产品设计之前,如何分析业务需求和用户痛点?
 
相关文档

产品经理是怎样炼成的
APP产品规划方法
产品经理培训文档
产品生命周期管理PLM
 
相关课程

产品经理与产品管理
卓越产品经理训练营
产品需求分析与管理
基于用户体验的产品设计
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   

统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

某博彩企业 产品经理与产品管理
面向产品的需求分析与管理
中国民航 产品经理关键技能
深圳 产品经理与产品管理
某通信企业 基于互联网的产品创新
某知名互联网企业 产品管理
世纪高通 创新创造突破性产品
更多...