## 產品設計體會(四八)——資源戰爭與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
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄