从08年入职IT行业从一名程序猿到项目经理,如今转做产品经理,经历了传统公司,互联网公司,传统+互联网公司,历数经历过的需求评审会。

一、传统公司

传统公司:业务类型为传统行业IT技术服务,需求以客户实际业务居多,大多为项目型开发,需求收集完成后,由客户,售前,技术,项目经理,测试,实施,针对需求文档进行功能模块的工时评估。开评审会以项目经理为主导,相关人员参与,需求的吸收者着重为售前,客户,技术,测试。

客户:从满足实际业务需求角度验证需求满足度

售前:从销售经验角度验证需求广度,深度

技术:从实现功能模块,技术经验角度,评估工时

项目经理:从项目进度,客户要求工期角度验证需求合理性及实现可行性

测试:从测试复杂度,测试周期角度评估工时

实施:依据预估工时,预估实施工时

评审会议结束后,需要参与人员签字确认,确定需求边界,以此结果为上线依据,延期或需求变更做另外处理。

优点:功能明确,工期明确,权责明确。

缺点:需求以纯文字描述,不够直观和细化,容易出现细节上理解的偏差。权责明确后,因细节产生的需求变更会增加。依据需求量及现在讨论满足业务需求度,评审会议存在反复评审情况。


二、互联网公司

互联网公司:业务类型以产品为核心,着重实现产品价值,从公司战略,用户,竞品,运营等规划产品功能形成产品原型,原型中标注功能细节,交互形成需求。开评审会以产品经理为主导,对需求进行讲解,需求的吸收者着重为UI设计,技术,测试,运营。

1.UI设计:有的公司UI也负责一部分交互,所以根据原型中每个页面元素及交互评估工时

2.技术:依据以往经验,需求复杂度评估工时

3.测试:依据功能节点,测试复杂度评估工时

4.运营:主要验证需求满意度

5.产品:经过需求梳理后,以形成的原型为依据,对产品需求工时,实现进度进行跟踪

优点:快速,灵活,技术及技术响应及时,当天结束并给出工期

缺点:互联网公司运营需求变化较快,方向也随时调整,需求变更及冗余功能频次较多


三、传统+互联网公司

传统+互联网公司,业务一般为传统公司转型,通过+互联网达到升值目的,存在将传统业务搬到线上,一般做升值的公司规模较大,传统业务已线下固化,转变产品思维举步维艰,产品从需求梳理角色入手较复杂。评审会需要业务部门,产品,设计,技术,测试,运营参与,需求主要吸收者为实际业务部门和运营人员。

1.业务部门:从业务部门利益,实际线下业务,历史问题兼容性,验证需求满意度及工时

2.运营:从运营角度验证需求广度及深度,及工时

3.设计:从交互,UI,平面,对产品整体风格等评估工时

4.技术:依据以往经验,需求复杂度评估工时

5.产品:以原型设计为依据,讲解需求中的功能模块,需求吸收者主要为设计,技术,产品规划上线后需要对业务,运营人员进行培训。

优点:原型直观,评估工时较快速,线下业务已稳定,业务流程相对不会大调整

缺点:传统行业做+互联网会牵动已有业务部门利益,推行不易,产品需求收集上存在配合度不高,当天评估因线下实际业务人员本职工作等外部因素,评估工时不能当天出,一般三天左右


四、其他

最近经历了一场不一样的评审会,作为产品经理的我在更新迭代了七版需求后,依据以往评审经验,需求讲解完后,技术给出工时,平均二天后才能给出,而且预估工时明显存在水份,实现需求时总是反复询问确认需求及流程。特殊时期特殊对待,采用了如下方法:

上午依据原型讲解需求,设计,技术,测试,明确到相关人员是否理解需求,理解后进行下一个功能的讲解。

下午依据原型,设计,技术,测试,产品,拉到微信群,针对每一个人对需求的理解,预估工时,去掉最高工时,去掉最低工时,计算平均工时,当天完成需求讲解,工时评估,需求理解度,避免实现需求时对大流程及功能模块反复确认。

优点:需求理解度提升,评估工时当天出

缺点:会议时间过长,参与人员不够投入,评估工时由于存在无关人员投票,存在一定偏差。


·【大仁爹】一只产品汪

·未经同意不可转载