## 产品设计体会(四八)——资源战争与BRD
产品团队刚刚经历了一场公司内部的战争,争夺的是下个月的开发工程师与测试工程师的资源。
先说一下为什么以前没有过这样的战争吧,因为公司原来是按照产品线划分的部门,这样对于某个产品来说,有自己的PD、开发与测试等,下个月要做哪些需求,完全可以在产品经理的层面上决定;而现在公司变成了按职能划分团队,有了统一的产品运营中心(PD和运营)、研发中心(所有开发工程师)、质控中心(所有测试工程师),这样的话,下个月各个产品就都想尽可能多的抢到开发与测试,然而资源总是严重不足的,所以最终做哪些,就必须要上升到几个中心的大老板层面来决定了,而大老板的决策依据就是各个产品经理的pk,对各自产品发展BRD(Business Requirement Document)的描述,于是,战争爆发了,:)
所以前段时间,大家一起在准备BRD,这就是我们的武器,我们需要尽力说明我们要做的东西的商业价值,才能抢到各种资源,因为在pk之前,全公司的资源需求已经是现有资源的好几倍了……(一般以“人日”来简单估算衡量,有同学说一群人pk简称群p,就是多争取点~人~~日~~~,呃,很邪恶!)
武器主要包含以下几个部分:项目概述、项目背景、商业价值分析(重点!大老板最感兴趣的,一定要说在点子上)、功能需求描述、其它需求、资源评估(重点2!大老板们要看成本)、风险和对策。
当然同学们也会搞点技巧性的东西,比如卖个破绽,故意加入一些让老板砍的东西,有点类似谈判技巧里的玩意。
最后谈一下两种组织架构的各自优缺点,按产品线划分的部门对产品本身是有利的,产品经理可以按照自己的想法做,资源有保证,产品规划不会被动改变,它的缺点也就是按职能分部门的优点;职能部门对全公司的资源共享有利,确保所有资源都用在对公司最有意义的产品上,另外它能把资源战争的鲶鱼效应从产品内部扩大到公司层面,使PD和产品经理们更抓狂的去为产品的发展而苦苦思索……
记录一下漏写的:
1. 两种组织结构的变化,我的理解是公司自然发展的必然过程,随着产品的增多,全公司变成了越来越多个资源局部最优,他们之间可以互补的可能性越来越大,此时全局最优的效益越来越明显,所以打通。
2. 产品划部门的优势,还有个是沟通的顺畅,单线领导,都向产品经理负责。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录