背景：公司規模較小，分工不是很明確。因爲無市場部，之前產品立項沒有流程，爲失敗的產品付了很大的代價，故成立產品部，目前有兩我的，亟待解決產品與市場脫節的問題。html
原由：因爲沒有專門的交互設計和視覺設計，之前由開發自行發揮，後來由於用戶體驗實在太差，老闆決定由產品部來完成這部分工做。web
提問者：我理解的產品管理的工做重心在規劃和立項。個人工做基本圍繞項目任務書（目標市場、產品定位、可行性分析、目標成本和銷售目標等）和產品需求包（需求描述、用戶場景、優先級）這兩個交付物。微信
遇到的問題：post
用戶註冊spa
需求：支持手機號碼註冊設計
界面：給出了手機號碼註冊的界面3d
這個功能在立項評審時，以上信息已經足夠。但進入開發階段，就會遇到，驗證碼怎樣獲取、有效時間多長、失效後怎樣、號碼已註冊怎麼提示、密碼長短組合有無限制、密碼丟失後如何找回等等一系列問題。htm
對咱們的產品來講，註冊這個功能實在是微不足道。產品核心功能所遇到的相似的問題就更多了。blog
各項需求對應用戶的操做錯誤、設備異常狀況、極端狀況以及邏輯細節，都是在立項和原型階段沒有考慮的。項目管理
研發在開發過程當中會不斷提出疑問，給出方案後要求改原型，提需求變動，甚至當開發進度失控時會以需求不明確爲藉口要求咱們提交項目延期申請。
每每產品開發進入這個階段時，咱們已經投入到下一個產品的立項調研工做裏了，面對這些問題實在不勝其煩，但又沒法說服老闆，老闆承認這些不該該由開發人員去考慮，產品部應該在前期就將產品定義清楚。
這個問題從行業角度來講，若是是面對互聯網行業，用一些User Case之類的重方法是起不到好做用的，行業變化這麼快，這麼多文字產品經理書寫完畢，就已經耗費好幾天了，更不要說思考的時間了。
這個問題從目的來講，知足不被開發罵。比起寫需求有一個很是簡單地作法，就是產品經理和開發交朋友，若是大家是很好地朋友，那麼開發就算罵你，你也不會以爲很刺耳，反而這是高效的處理問題的機會。
這個問題從題目來講，其實提問的產品經理在某種程度上有一個完成任務的心態。這個是比較消極的，認爲需求說清楚了，效果很差就是開發的問題了。
看提問人的背景應該屬於從相似華爲這樣的成熟企業來到一個2B的企業服務行業，公司規模比較小，團隊認爲用敏捷，因此文檔不重要，因而產生一些困惑。其實這裏的關鍵是如何認識到這個角度：團隊對需求的共識高於一切——這個角度纔是真敏捷。
若是從這個角度來看，並不須要仔細考慮我們的文檔應該寫到哪一步，寫到哪些細節，而是應該把關注點放在開發團隊是如何認識到這個需求要作到哪些點。
若是開發團隊有經驗，你文檔不寫，也能作到。若是開發團隊欠缺經驗，你文檔寫了，也寫不全，作不到。如何有效達成共識是關鍵，文檔其實傳遞信息的效率是很低的。
那這裏有沒有立杆見影的方法呢，答案是——有。
需求評審會由產品經理講需求改成開發人員講需求。
一般咱們都是靠產品經理講解需求，而後用投影儀逐一解釋，可是這個過程當中團隊總體是PK心態，互相對抗的，儘可能多說少作，並且很難達成共識。一般開發人員都沒有時間提早看需求文檔，更不要說理解了。
改爲開發人員講解需求後，你就會發現，面對白板。若是不能充分理解需求根本就是大腦一片空白，因此開發人員必須提早研究需求，不懂還須要找產品經理溝通，共識天然就經過會議達成了。
系列文章#
第一輯：我親歷的鵝廠敏捷轉型
NO.4 爲何敏捷團隊不要超過15人
NO.5 需求沒作完能夠發佈嘛
NO.6 如何打造稱手的武器
NO.7 QQ郵箱怎麼成爲行業第一的
NO.8 你愛上手機QQ麼
NO.9 每天系列每天見喲
文章來源：微信公衆號「老布談敏捷」(ID：bootagile)
做者：薛軍/Boots，現任：深圳市一塊兒六企業管理有限公司創始人，騰訊大學外聘高級講師，業問特聘騰訊之道講師。曾任騰訊項目管理通道委員會會長，騰訊項目管理P4專家，敏捷教練，騰訊LBS總監
本文由@薛軍 原創發佈於博客園，未經許可禁止轉載。