为什么团队交付时,需要功能清单
编辑导语:在产品设计流程中,虽然我们在需求评审环节就已经将具体的功能要求解释给技术和团队,但后续验收时,技术并不是一定按照我们的想法来设计——毕竟双方的沟通是有差异的。
这种情况下,如何避免双方理解不一致的问题?提交功能清单,或许是一个比较好的解决办法。
当产品经理依照功能结构制作原型时,要求是一个管理员列表页,我们会想到什么呢?
首先要在页面展示管理员表格,有相应的增删改查操作;
其次,需要针对表格字段设置相应的搜索入口,方便数据查找。
这样看来,该页面的功能已经完成,如图所示。
在团队验收项目之后,可交付成果被提供给客户,这时客户方发现某一搜索入口存在问题:当用户输入管理员姓名想要搜索数据时,只记得管理员姓什么,这时输入姓氏,结果却显示为空。
于是客户提出bug修改意见,开发检查代码后发现,是因为该搜索入口设置的是精准搜索导致,这给产品带来了不好的使用感,也降低了客户的满意值,最后功能遭到返工。
项目复盘时,团队成员针对这类情况进行讨论,发现存在这种情况的原因是,在产品设计阶段,产品经理并未对这一点的设计进行标注。可能是主观认为该功能点一定是前后模糊搜索,又或是落下了对这一细节设计的思考。
结果就是开发未接收到产品经理的想法,开发过程中根据自己的理解做成精准搜索,最后导致客户搜索不到数据。
而且就算开发想到了用设置模糊搜索,那么模糊搜索还分前后模糊搜索、前模糊搜索、后模糊搜索,1/2的比例猜对后,该功能点还有2/3的比例可能被返工,一来二去项目效率就被降低。
这时如果有一份可以将功能细节明确,规范记录的功能清单,将搜索框的配置要求进行标注,记录逻辑功能设计要求,就显得格外重要。看到这里你也许会问,功能清单是什么?在这之前不是已经有功能结构图了吗?
一、什么是功能清单
功能清单也可以叫需求清单、功能列表,是一种将项目功能需求通过文字的形式记录,方便团队成员查看的交付性质的文档。
相比于通过使用思维导图整理的功能结构来说,功能清单主要以excel的形式存在,涵盖功能模块、功能点、功能描述等多个维护字段,其交付质量越低,开发时间就会产生越多损耗。
比如注册页面存在上传文档的功能,产品经理调研后认为文件上传需要支持jpg、pdf、png、tif格式,并且字段必填,将功能清单交付开发后,开发可以对这一功能的细节需求清晰明了,降低不必要的返工率。
二、功能清单的优点
功能清单的存在,在开发期间为项目维护带来了些许便利,主要体现在以下几点:
1. 提高开发效率
开发过程中,如果只参考原型制作,当遇到一些未进行明确标注的设计,比如搜索入口的配置。
看起来精确搜索和模糊搜索都可以将内容搜索出来,但实际上,精准搜索显示的内容数量较少,甚至可能出现搜索结果为空的情况。
这样的功能设计一旦错误,就可能会对产品产生不好影响,需要开发二次修改。如此反复修改代码,调整项目逻辑,开发效率就会被大大降低。
当遇到此类原型上不易表达的内容时,如果存在功能清单作为标准,将这些设计要求通过文字的方式记录;
如:这个搜索入口要求设置模糊搜索,即可让开发清晰的了解到某个功能点的细节要求,降低返工率,增强工作效率。
设计过程中遇到的细节功能点,可以思考调研后,通过功能清单进行记录,供开发及其他团队成员查看,提升工作效率。也方便后期检查功能是否做错,是否对产品的使用产生不好体验感,使得开发期间功能不遗漏、无错误,不影响产品使用。
2. 释放产品经理的时间
项目开发期间,当开发编写程序,遇到一些细节问题,比如一个搜索入口的搜索配置,可能需要去询问产品经理具体的设计思路。这时如果没有功能清单,产品经理自己可能也会忘了调研某一细节,或者没有记录调研结果,忘记了当时的思考内容。
就需要再次结合设计情况,思考该功能点的需求,然后告知开发,工作时间被无必要的增加双倍甚至更多。而且没有一个规范的记录,很可能每次的思考会被他人的话术所干扰,造成每次的思考结果不一致,对产品的使用造成了不好的影响。
但如果在设计初期就将这些细节记录呢?当有开发经理询问时,产品经理可以直接将文档交付开发,解决后期还会存在询问其他细节的可能;并且在设计期有文档进行了细节记录,也可以防止产品经理自身漏掉对一些细节功能的思考。
所以,产品经理需要对产品设计需求进行管理,也就是编写功能清单。
与注重视觉交互体验的原型相比,功能清单重点在于补全原型、细节设计。
编写功能清单,将字符长度、排序规则等不易在原型显示的内容通过功能清单记录,使得功能设计规范,不出错;也方便自己与他人查看,释放更多时间去做别的事情。
3. 保障团队氛围
团队氛围很容易便能展现这个团队是否有凝聚力,大家都希望自己所在的工作环境轻松而愉快,但这种氛围很容易被打破。
当项目交付后,发现本应该模糊搜索的功能做成了精确搜索,使得搜索内容不全面,影响产品使用,就需要产品经理去和开发沟通,安排返工。
开发可能会不愿意,已经做好的功能不愿意因为一些小细节去二次修改,但产品经理不是不讲道理的人,如果是一些能够接受的,不影响使用,但与产品经理设计初衷不一致的功能,其实并不会返工。返工的往往是那些,对产品有不好影响的功能。
这时一份记录全面的功能清单便可降低此类情况的发生概率,通过功能清单,将细节记录,比如列表页面的搜索入口全部设置为模糊搜索,这一记录的内容就是该功能的设计标准。
开发期间,一切除特殊情况,都按照标准来制作,避免一些没必要的讨论,也节省大家的时间。
对于团队来说,沟通是在所难免的,适度的沟通有助于团队内成员之间的交流,改善了团队成员信息不对称的问题。
功能清单就担当起了部分的沟通作用,将可能存在的问题点提前思考并标注,如若再出现问题,需要有人出面承担相应责任时,直接拿清单进行对比,避免了一些没必要的冲突,团队氛围得以维护。
作者:桃浪;公众号:桃浪产品日记
本文由 @桃浪 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
其实只要有细心的,在prd上就可以做功能清单的内容。如果是内部项目,将功能清单拿出来重新做一份是不是有点多余了?
可以灵活一些,根据实际环境去调整
这在prd里是必须要有的说明
功能清单和prd有什么区别呢,会不会重复工作?
功能清单是对prd的补充