产品经理如何判断研发评估的工期合理性

不同公司对产品经理的职责定位不尽相同，产品经理这个岗位本身职责范围也比较宽泛，本文主要针对的是那些被认为是产品OWNER的产品经理们，简单点说就是产品的第一负责人，就像是一个总统对于一个国家而言，而这个总统还只有背锅的责任，没有指挥造锅的权力！

前些年曾有过产品经理要不要懂技术的套路，很多人是偏向懂技术不是产品经理的必备技能，只是加分项。可如果你是被定义为产品的第一负责人时，你不懂技术，往往在工作推进中，会有诸多障碍，比如你的产品方案是否具备技术可行性、实现起来的复杂度又决定了经济可行性，在与研发伙伴进行battle时，你是否能说服对方，甚至研发小伙伴会不会故意刁难你。今天我以曾经产研团队leader的身份，告诉产品经理们如何拆解产品的研发工作，防止研发同学信口开河漫天要价式的工时预估。

开始具体内容之前，说一个哲学性的问题，如果一个工作不知如何下手时，记得一定要做分解！就像我们初高中学习数学那样，多元多次方程，向一元一次方程去简化，然后各个破解。

一个项目的研发工时预估，一般分前端、后端两块工时，我们也分开拆解预估方法。

一、前端工时拆解

前端工作量的大小，最简单的判断方法就是页面数量，一般页面数量多的工程，前端需要的工时就会越多；当然，越简单的判断方法，判断误差就会越大，这个简单的方法有个前提，就是页面实现复杂度相似的情况下才成立。所以接下来我们再拆解页面复杂度怎么去判断。

一个页面前端的工作内容可分三大块：页面元素制作和排版，效果实现、数据嵌套，这三个维度都是内容越多越耗时间。

一）页面元素：

就是指这个页面的组成由多少区域块，区域块越多、纵横交错越多，复杂度就越高，但这个相对而言，工时还是比较容易估算的，毕竟就是排版，确定性还是比较高的。

二）效果实现：

最难的是效果实现这块，它的模糊边界最大，不同人给出的工时可能差个几倍都是有的。效果实现指的是动画效果，布局效果，自适应效果等等，一般要基础编程来实现，这也是前端工程师比较值钱的地方（现在纯页面制作的职位基本消失了，页面制作是纯使用标记性语言，如html,而带效果的页面一般是要用编程语言完成的，如Javascript）。

这一块的工时预估，主要看要实现的效果是否为常见的，也就是网上能找到开源实现的，如果是新效果，这个就别和研发去争论工时了，能不能实现都会是个问题。如果是比较成熟的效果，比如说轮播图、日历、瀑布流排版等等，这些基本网上一搜一大把，他再给你要个1~2天的工时，你就可以怼他了。

三）数据嵌套：

是指页面有动态数据，需要与服务端交互来让页面数据活起来，这个一般也比较耗时，需要与服务端进行联调；一般的实现方法就是前后端定义好接口，前端开发的时候会用假数据先实现页面，等服务端开发好了，直接替换就行。这块工作一般也比较确定，评估就按接口数量多少进行预估就行。

二、服务端工时拆解

服务端与前端一样，也可以进行分类拆解，对应前端的页面数量，服务端就是接口数量，可以数一数工程需要的接口数。当然，服务端的拆解相对前端要复杂一些，不同编程水平的服务端开发量是有较大差别的，好的架构设计可以减少很多工作量，可维护性还高，这个不在本文讨论范围内，这儿只说普通的应用型项目的服务端。

对于单个接口的工作量，可以分解为数据控制、逻辑处理和数据存储三块。

一）数据控制：

主要是指数据接入、数据输出，数据接入是指前端传过来的数据，包含要存储的数据、查询的数据、上传的文件等；数据输出，主要是查询结果输出。

涉及文件上传一般看是否为项目第一次做文件上传，或者公司是否有共用的上传服务，比如使用阿里云存储服务等，如果是第一次使用，涉及存储服务调试，时间要长一点，多给个一天时间；没有特殊的处理，一个普通的查询接口一般1个小时就差不多，尤其是一类接口放在一起写，一天能写完一批；带数据上传的接口，一般耗时要长一些。

二）逻辑处理：

这块与前端页面的效果实现一样，跨度很大，有些逻辑需要跨表读取数据并有先后顺序，逻辑处理的整体规律，增加一个维度，难度就翻倍，工时也会相应增倍。不过在逻辑处理这块，产品经理因为对整体很了解，是最容易参与并能给技术提供思路的。

一般情况而言，常规应用都是有成熟的解决思路的，复杂度也是可以衡量的。比如，一条动态的评论，如果是直接按评论的时间进行排序，这种逻辑处理基本为0，而如果是允许对评论进行回复，这种就会复杂度翻倍，还会涉及到数据存储表结构的变动。

三）数据存储：

分为请求数据的存储和效果，缓存存储和数据库存储。

请求存储用到消息队列的建立和消费，这块看是否为第一次实现，第一次多给点时间，项目中已经用过了，一般都已经是封装好的方法，几行代码就搞定了；缓存层也是类似的，封装好的服务挺多的，搭建好了就是几行代码就可以实现了；数据库存储方面，涉及表的结构设计，一般项目前期，表的关联比较少时，比较简单，越向后期越复杂；尤其需要多表联动时，表设计也会复杂，如上面提及的对评论进行回复，如果是才用双表设计时，效果最好，复杂度相对所有评论按时间倒叙排列，要高出数倍。

三、总结一下

看到这不知道你是否有些失望，我并未给出具体一个页面、一个接口或者一个项目，大概需要多少人天的工时，这儿不给这个数字，如果你仔细看上面的内容，你可能也就能理解，因为范围太宽泛，给的值也不能做参考。写这一篇内容，主要是为产品经理在和研发进行工期约定时，多一些讨价还价的方法，千万不要越俎代庖，拿自己的业余去挑战别的饭碗！

上面的方法，是我有一次实在受不了研发团队给我的工期，我就拉上服务端的研发同学，把他评估的2天一个接口，现场进行分解，接口的controller要多长时间，需要做那些逻辑处理，数据库要建什么表，一一进行拆解，最后工时压缩了一半。但故事并未到此结束，一旦走到这一步，基本双方的关系就很僵了，后面的配合就会很难。希望产品经理们灵活并谨慎应用，以理解和尊重的态度去探讨，以帮忙和助力的目的去协商（不少研发同学、甚至是研发leader是不知道如何去预估工时的），让他们知道你在这方面不是一窍不通的，不是随意可以忽悠的就可以了！

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！