必读｜如何判断一个功能的复杂度？-轻识

我们做产品经理，总是会面临一个固定问题：

这个需求/功能到底复杂吗？

评估功能复杂度是非常重要的，因为这影响了我们的需求优先级。

同时功能复杂度如果不会评判，就会浪费团队资源甚至是延期项目，尤其是对于老板、产品经理来说很容易蒙在鼓里。稍微提一个需求就是一个月或者更长时间，难免让需求提出人、产品经理们觉得黄花菜都凉了。所以我们对于一个功能的复杂度评判的需求是非常刚需的，我们急需要一个好的技巧方法来帮助评判功能的复杂度。

掌握功能的复杂度判断也就是知道了问题的解决成本，但对产品经理来说，功能复杂程度由开发同学来评判的，自己很难有话语权。99%公司的产品经理，离开了开发什么都不是，只能任其开发宰割，影响了业务发展。

都说产品经理要懂数据分析、商业化、增长等多向，但我始终认为评估1个产品经理评判对1个功能的复杂度能力是其核心工作价值体现。

其实不仅是产品经理，运营等业务部门也同样需要知道功能复杂度评判的能力，比如运营需求、数据需求，也会需要有开发介入才能完成。

为了写这篇文章，我也查找了不少网上的同类文章，发现很少有产品经理去分享这类，反而是开发同学们分析技术的多。

所以我这里分享5种方法，可以帮助你快速评判一个功能复杂度。

第一：交互越多越复杂

如下面这2个图，一个是PMTalkApp首页信息流、一个是提问内容编辑页面，看这2个页面其实包含了多个功能。

左边的页面是PMTalk app的首页，包含了推荐、作者投稿、问答、原创榜、本周精选功能，组件有导航栏、搜索框、文章标题、文章头像、点赞、阅读量等，元素比右边多很多。

右边则是包含了标题输入、问题详情描述、图片上传、话题选择、还要匿名，看起来右边的元素更少，那么你认为左边的功能更加复杂还是右边呢？

实际上右边的开发复杂的多，左边的却简单。

左边的我们可以称之为纯数据展示页面，信息流里面包含的每个元素是固定的，由后台提供对应的接口进行数据传输，其余的就是重复展示工作了。

对于纯展示页面，前端开发只需要处理好页面的样式，就不用考虑其他问题，看起来这个文章排序很多，实际上就是相同的结构不断重复调取接口数据。

你可以抽象为下面的样式，是不是就很简单了？

前端开发只需要把这个结构模版写好，填入头像、标题、名称、话题、点赞数、喜欢数、封面就可以了。

交互包含两类，一类是动画交互效果，没有后端服务数据；另外一类是有后端数据的交互，比如下图会有数据的读写操作，就属于这一类。

右边的简单的填写框、图片展示就是第二类交互型，开发需要处理点击前后、悬浮、用户输入特殊字符、图片插入、其他格式文件插入，用户的这系列操作后，又需要怎么展示都需要服务端的实时数据查询，标题输入和问题描述输入看起来两个差不多的输入框，实际需要分别校验

输入的字符长度
标题有没有重复
内容是否为空
内容是否有违规词（需要安全系统审核）
图片是否要压缩，什么样的尺寸进行预览

这都是在需要用户行为在后台交互的，元素少实际上开发成本高。

第二个是组件化程度越高，越简单

做产品经理的同学如果有用过原型工具应该可以快速理解这个道理，我们在做需求的时候如果涉及到导航栏、时间、筛选器、分页这类组件，最快的方法是用现成的部件库自带组件去完成这类需求的原型设计工作。

功能的开发复杂度也是一样，越是组件化程度越高的需求，功能开发越简单。比如上传文件、弹窗、toast提示等等，都是一套组件，可以大大提升开发效率。

尤其是我自己用的组件库，就是经过工作几年积累的，覆盖了B端、C端各类功能，你可以在本篇公众号回复：“Kevin的部件库“获得下载地址。

第三点：浏览器/设备终端兼容

这一点是仅针对前端、客户端同学来说，比如WEB类产品，我们经常会出现要求网站浏览不是适配的情况，而在非IE浏览器就正常，是因为这类WEB产品没有对IE做兼容处理，导致出现功能缺失、页面展示不正常。

凡事需要IE兼容的需求都不简单，建议尽可能不要提出满足IE浏览器兼容，因为IE浏览器对某些交互动效难以运行，即使支持了也会渲染慢，很多头部门户类产品会放弃对IE的支持。

设备终端的App也是同样道理，尤其是安卓机型海量，我们难以有精力去做每个设备的屏幕、尺寸进行适配，所以这类涉及到对多样终端兼容的需求也很复杂。

第四：横向跨系统数

一个功能如果刚开始就涉及横跨多个业务系统，那这个工程也是浩大的，比如一个用户登录注册的账户体系，公司必须要考虑未来会有其他业务线会使用这套账户，因此账户体系往往开发时间都会要在1个月左右。

如果账户体系涉及到权限、第三方登录、用户信息录入、用户管理、数据统计开发时间就更长了。

跨系统同样还有跨功能数，功能之间是否有权限、有二次认证等。往往不同的功能服务业务不一样，所以我们还要考虑对方使用的技术框架、功能逻辑，保证用户体验一致。

所以在涉及到的需求尽量少横跨系统。

第五：是否需要硬核技术

在做产品设计的时候，为了符合时代需求，我们总需要一些新技术的能力，比如我们提到的AI、音频识别、直播、图片识别、云存储这类，这类99%的互联网企业都会选择第三方进行采购。

因为自己研发的成本太高了，所以才会有所谓的saas、开放平台，通过付费接入的形式获得稳定的能力，比如保利威直播提供了直播相关的SDK，允许企业快速接入。

这类功能就不需要自己研发了，而且就算做出来了也难以达到主流的用户体验。

如何提升自己判断功能复杂度的能力？

如果你问我，怎么总结出来上面5个点的，其实方法很笨，但是也很简单，那就是多体验产品。每做一个需求之前除了体验竞品，还要在日常生活里养成拆解产品的习惯。

当然随着工作时间久了，我们也能积累功能复杂度的经验，但这是被动的经验获取，因为你需要不断的花时间在工作里做需求，踩坑后就可以知道了，自然就做过各种各样的功能，尤其是对于5年以上的产品经理，你很难给他去沟通擅长什么样产品设计，因为5年后的产品经理做的多，也体验的多，什么C端产品、B端产品、还是数据产品无非就是代码来实现的，因此都擅长。

同时有开发基础的产品经理是非常好的优势，尤其是有后台开发的产品经理，这将帮助你快速评判功能的复杂度，增加和开发沟通的效率。

即使技术在瞬息万变，我们也能用不变的开发基础来进行沟通。

还有一种就是不断的打怪，随时把自己的工作投入在产品研发中，就可以积累不少功能的复杂度评判经验。

今天的分享就在这儿。

参考图示：

functional complexity mesureme