## 產品設計體會(十)——團隊合作
上周的阿里軟件PD交流會旺旺的劉庚聊了一個PD如何與工程師合作的話題,很有共鳴,正好本周網店的交流會是我組織的,所以也整理了一下自己的想法,并且通過一個需求采集的練習,讓各位工程師、QA、PD、UI把對合作溝通的期望提了上來,當時只是做了一些簡單的整理,這次的周報不妨再順一下。
?
第一,綜合大家的需求,權重最高的居然是一個很大的話題:“流程”,但仔細想想就一點都不奇怪,一群理性的人很明白“沒有規矩,不成方圓”的道理,當事情由人來控制的時候,總給人一種不安全、不穩定的感覺,而有流程可依的時候,心里就比較踏實。(人治和法治的區別也就在此)
?
具體到實施方面,大家再次認同,需求確認的時候相關人員一定要都參加,以免后期再發生QA、開發對需求理解的脫節;如時間允許,開發應該盡早參與到需求評審中;……
?
另外有一點提到非常多的就是需求變更的流程,說明大家對“需求總是在變”這件事情已經是深惡痛絕并且有些恐懼了,但同時又意識到需求的本性就是“總在變”,所以非常希望有一個流程化的規定來嚴格控制這件事情。
?
但好的流程是需要執行的,感覺在實施的時候還是有些困難,網店現有的發布流程不能說完善,但很簡單實用,如果能做到嚴格執行,相信已經可以減少很多問題了。
?
第二大的問題就是“溝通”,團隊合作必不可少的一個環節。站在PD的立場上,我們會把自己作為產品的中心,這個角色注定要和各種各樣的人交流,客戶、老板、開發、運營、測試、客服、合作部門等等。
?
開 發們提出了很有意思的一點,希望大家在交流的過程中避免情緒化。人性的弱點決定了在爭論的過程中每個人都希望自己得到認同的,而這點往往導致思路的變形, 不再是考慮產品怎么做更好,而是去想如何說服對方。我自己是覺得溝通中還有一點重要的就是每個人都要主動一點,這樣才能形成互動的氛圍,也可以減少信息不 暢引起的問題。
?
第三點是PD要不斷提高自我修養,大家希望PD給出的文檔在質量再更進一步,準確、全面、簡潔,即時更新、保持最新。我自己覺得還有另外幾點也是需要PD自己不斷努力的,比如考慮問題的全面性,有空多了解一點技術等等。
?
話題太大,時間有限,不再多言。
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄