腾讯高级产品经理讲述一个产品中的重要环节也是被忽视的环节

在AI这个赛道上,如果用程序员的数量来衡量一个基础平台是否成功,那显然大家都还在起跑线上。

很少有一个职业像程序员这样在短短20年间更迭3次,这3次更迭事实上正对应着平台的根本性切换。从DOS程序员到Windows程序员代表着Windows近乎成为大一统的平台,从Windows程序员到Web程序员折射的是互联网的兴起,从Web程序员到App程序员反映的是移动互联网迅速展开。现在我们正在面临第四次更迭:过去不管那一种程序员,都因为技能集过于单一而不足以面对AI所带来的挑战,那我们可以讲我们再一次面对基础平台的变更么?

程序员的变迁是基础平台变更的核心表征

程序员是一个很特殊的职业,本质上讲程序员们是在固化各种思维和逻辑,把这些思维和逻辑用一种计算机所能理解的语言设计并表达出来,但这种固化的过程绝大多数时候其实是依赖于程序员所使用的工具的,而所谓的工具则是另外一批做基础工作的程序员创造出来的。这里说的工具就包括编程语言,编译工具,API等。

程序员具体用那种工具完全取决于这种工具所对应的平台究竟有多大商业价值(特殊的程序员另论)。所以苹果的兴起反过来就带动了Objectiv C这样此前比较生僻的编程语言以及独属于自己的一套API。而每种平台开始运作之初,核心的诉求都是吸引足够多的程序员在自己的平台上开发应用,这才能形成应用和平台间的正反馈,此前微软和苹果两个公司极度纠结的就是苹果总希望Office能跑在自己的系统上,但同时两者在OS层面又有一定的竞争关系。到终局时一旦某个平台成为最终的默认选项,那这个时候程序员反倒没什么选择空间,比如现在为Android或者iOS开发应用,事实上已经没的选择了,过去的选择已经成为一种必须遵从的规则。

反面例子则是黑莓那类系统,用户减少会导致为其开发应用的程序员减少,进一步会导致体验变差,然后整个生态就会死掉了。

所以说程序员究竟在那儿事实上是一个平台正在诞生、成长、鼎盛或者衰亡的最直接的表示。现在这个时间点,真的越来越难找到Windows程序员了,这反过来也就折射出Windows已经越来越不是一个主流的平台了。

API上的争夺战

当我们说Windows,Android等的时候我们说的究竟是什么?

一个当然是我们每天都在用的各种功能,比如设闹钟、看微信、定位等等,但延续上面的思路,从程序员的视角来看,我们说的其实是一组足够强大的API。正是基于这组API,程序员才开发出来五花八门的各种应用。谁打造并控制了一组API,并让这种API成为特定领域事实上的标准,谁就真的打造了这个领域里的基础平台,制定了标准。

在过去即使是BAT也还没到这个层次,BAT所做的事情更像是内容型的平台而非这种基础性的工具平台,我们常说的几个工具型平台,要么是国外大公司所主导,要么是开源社区在主导。

API的争夺战并不是说出5个API就会变的足够有资格(这个道理通用适用于微信小程序等),而是说一旦API数目膨胀,变的无所不包,同时这些API的使用自身也成为一种技能的时候,那不同的API集群就会变的彼此互斥。根据过往经验,在同一个品类下面,这种API集群并不会有多个,是一个赢者全拿的游戏。在PC上,虽然理论上讲Linux也可以自成生态,但实际上还是Windows一统天下。

这除了和用户习惯有关,很可能也和程序员群体的投入有关,毕竟在特定时期,程序员群体一共就那么多精力,投到A上估计就不会投到B上了。

AI正在呼唤新的平台

如果我们把目光放的更加长远,那我们就可以清晰的看到未来一定会崛起新的巨型工具平台。

假设机器人成为我们生活中的必备设备,那这种机器人几乎一定不是基于现有任何一种平台的,而是需要一种专门为机器人量身定做的OS以及开发平台。在这种平台上,应该更容易创建或导入地图,设定运动时基本的规避措施等。

现在的状况是想做机器人的人每个人都会做一套自己的系统,这从整体来看效率肯定是低的,很像在DOS时代每个人都会做一套自己的GUI系统,当Windows出现后,这些自建的GUI系统纷纷变成垃圾,那怕有WPS这种很强大的应用做支撑。

相对于以往,当前AI赛道上最为有趣的事情是,这种基础平台很难再像以往那样,直接把国外已经完成的东西拿过来做深度定制,而更多的要依赖于国内自己的公司。一是大家实际上处在相同的起跑线上,一是像语音交互这样的分支实在牵涉太多需要本土化的东西,三是新型的平台本身并非纯粹的工具,而更多的和内容等绑定在一起。这些因素堆积在一起就导致AI赛道里缺一个真正的系统级的平台企业。

其次在于这种平台注定是一种端+云的结构。这会让已有的互联网公司感到不舒服,很像是自家地盘里突然来了个闯入者,同时互联网公司把持着非常多的内容,如果最终的产品是深度内容相关,而非深度工具化,那么内容会变成一个非常难以解决的问题。但这点在工具本身就是价值的领域上并不成立,比如最开始的Windows拼的并非是内容,而是更多的应用来丰富整个工具生态,Office丰富的是办公场景下的工具,Photopshop丰富的是画图场景下的工具。

最后这种平台必须挑战更多的硬件差异化。手机和电脑都近似于标准化之后的设备,但显然的机器人或者其他智能设备所要涵盖的场景会更加宽泛,有的场景需要比手机还强的计算能力,有的场景则只需要手机几分之一的算力。

以及产品经理该如何与测试人员协调。提前表明一点:产品人员必须要严格进行测试或协调测试,才能使得产品尽可能流畅使用,因此了解测试工作是非常必要,下面进入主题:

common_core_tests

先从测试的基础讲起,软件测试是在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程(名词释义)。通俗点来说,测试更多是去发现产品相关的bug,帮助产品完善相应的漏洞。更像一个质检员一样,最为质量把控的重要一员,往往带有极强的专业性和对产品效果的严谨,其环节关键性自然重要。从两个纬度谈起:测试流程和测试协调。

一、测试流程

我们先来看看测试工作做的是什么,首先根据产品需求文档了解整体的逻辑,然后根据需求写明详细的测试用例,后通过各种手段(白盒、黑盒等)去检测,基本上也是产品上线的最后几关。在这过程中,更重要的是发现问题,提交相关实施人员。事实而言,这种流程模式只是最基本的测试工作,会是合格的标准。那么真正的测试是什么呢?分为三部分:

  1. 根据文档或用例测试软件相关bug,提交工程师或设计师;
  2. 分析问题产生的原因和趋势,帮助开发者发现当前软件开发中的缺陷;
  3. 会从用户体验的角度去思考产品体现的概念,提出可行性改进意见。

第一点主要是最基础性的工作。测试人员首先会根据prd等产品开发文档编写详细的测试用例,在这期间往往会提出一些严谨或极端的用例,如数据崩溃现象,字符最大值等问题,这些元素有些会在需求文档中说明,有些则没有。虽是细节性的问题,但往往可能因为其中一点而使得软件使用变得很差劲。如果我们从整体角度看待,产品做的会偏重于整块的工作,测试会注重流程和细节反馈问题。因此好的测试环节必然少不了对整块需求的理解。从整个行业来看,至少一半以上的工作量都在于发现软件问题,提交并再次检验,保证软件质量。

到了第二点,基本上是一个测试工作的提升环节。我们从一个产品的本质上去思考,为什么会测出各种各样的问题,测试往往是对代码结果检验。只是尽可能地发现错误与问题,毕竟不会存在百分百无漏洞的软件。即便是最专业的测试水准,从大众的不同角度看来,也存在不同的问题。因此从测试中找出问题的成因会更加重要。因为这往往会带动一些开发过程中的效率和质量保证。举个例子,程序开发往往会注重实施的结果,通过不同的方法编写代码,达到产品需求的实现。但从个人意识去判断,很难发现代码自身的问题,很多时候也是因为时间的紧张。因此测试若能分析一些漏洞产生的原因,自然会对整个流程体系把握更加到位,甚至在很大程度上告诉开发者的问题,以便达到再次开发的过程优化。

第三点说的是产品结果层,程序开发实现了效果,但到了用户层面可能是另外一种传递概念。除了产品人员要亲临现场外,测试往往也会从一线的角度去思考,毕竟测试从整体角度来看称作第一用户也没有错。目前来看,整个测试环境达到这一点的并不是很多,像类似于一些成熟的体系如谷歌等在这一块做的恰到好处。在《谷歌软件测试之道》中,测试工作从最基础的环节到了最高层的环节基本就是用户体验测试层。这也很好理解,测试人员面对开发者是发现代码结果问题,面向用户则是使用问题的记录。软件最终面向的是一线用户,用户所提的问题需要发现对的点去加以改正。因此以用户的角度去看待测试会使得软件测试工作更加顺畅,同时产品也会因为测试的直接进入尽快得到优化反馈。

总之,测试工作不仅仅是提出bug,同时也是对开发和产品设计改进的重要一步。

二、测试协调

测试协调主要是测试工作在产品、设计、研发等不同层面的协调和完成交付样本。与产品工作可看作是前后互补,产品对文档负责,协调各个资源;测试看重开发结果,指出各个环节问题。因此除了专业的规范性外,充分理解各个环节模块也是有必要的。

现在常常有一种说法,软件测试往往从开发中甚至是开发后才开始介入,这明显是有问题的。从整体上来说,一个产品只要各个环节充分了解才可能到达策划方案的效果,不仅研发、设计如此,测试人员更应该如此去实施。充分了解需求是最基本的工作。从个体角度看,如果测试人员在中期后介入,往往很难明确各个模块的业务线,对于重点测试的模块也较难把握。因此,测试至少在开发前就要介入进来,甚至是需求策划或评审时。

在产品实施中,测试该怎么样达到完美的状态呢?首先来说,一个产品在开发后的结果拆分就三种:业务逻辑、产品数据、视觉效果,分别对应前端、后端和设计层面。对于前端而言,测试需要判断业务逻辑和功能的准确性,如模块划分,反馈信息是否按照文档中去走。如果存在不合理的地方要立即记录下来。数据则是后台返回的数据,如数组排序、字段是否准确,此时往往通过极限测试发现很多问题,再次进行记录。对于视觉而言,看标注图与布局是否与实现效果一致,是否有对需求改动的地点,有误的地方也要记录出来。

实际的工作也就两条线,一是对需求充分理解后,根据用例对功能、设计、数据等层面整理出存在问题的地方,二是通过测试工具记录相应的问题并进行问题解决后的再次记录。

把握先记录,再与产品需求对比,而后统一提交各个人员。这样也不会耽误别人的思路,如果遇到问题就提肯定是影响效率的。同时在正式测试期间,不能一开始就陷入细节,如按钮颜色、话术等问题。一定要保证逻辑和功能的完全再去记录细节。从软件开发而言,做业务处理、模块逻辑关系往往是复杂的,细节问题可以随时改动,甚至花一整天时间全部修改。

很多情况下,团队中往往没有测试人员,产品人员会兼任。因此产品策划者了解测试会显得尤为重要,在不确定资源的情况下,尽可能做到了解总不会有错。如果没有专业的测试人员,则需要多考虑一些产品反馈、性能体验等问题。对于需求文档会更加细分严格,实际上本该如此,毕竟口头说的很难形成记录和最终的结果对比。在有测试人员的情况下,产品人士要充分理解测试含义,对于其提出的问题,不能一概而否,从需求的角度看是否正确,需要进行合理对的采纳,毕竟专业的人做专业的事情。

产品经理必须充分了解测试的意义所在,相互协调,最终使得产品效果达到满意化的状态。

小结

当前我们可以看到这样一种巨型工具平台的机会,但我们甚至还看不到真正选手的影子。所有已经做的事情同它所需要面对的愿景来比,很可能都还不能算是起步。也就是说在AI这个赛道上,如果用程序员的数量来衡量一个基础平台是否成功,那显然大家都还在起跑线上。

原创文章,作者:海阁,如若转载,请注明出处:http://www.pm28.com/1577.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息