上週的阿里軟體pd交流會旺旺的劉庚聊了乙個pd如何與工程師合作的話題，很有共鳴，正好本週**的交流會是我組織的，所以也整理了一下自己的想法，並且通過乙個需求採集的練習，讓各位工程師、qa、pd、ui把對合作溝通的期望提了上來，當時只是做了一些簡單的整理，這次的週報不妨再順一下。
第一，綜合大家的需求，權重最高的居然是乙個很大的話題：「流程」,但仔細想想就一點都不奇怪，一群理性的人很明白「沒有規矩，不成方圓」的道理，當事情由人來控制的時候，總給人一種不安全、不穩定的感覺，而有流程可依的時候，心裡就比較踏實。（人治和法治的區別也就在此）
具體到實施方面，大家再次認同，需求確認的時候相關人員一定要都參加，以免後期再發生qa、開發對需求理解的脫節；如時間允許，開發應該盡早參與到需求評審中；……
另外有一點提到非常多的就是需求變更的流程，說明大家對「需求總是在變」這件事情已經是深惡痛絕並且有些恐懼了，但同時又意識到需求的本性就是「總在變」，所以非常希望有乙個流程化的規定來嚴格控制這件事情。
但好的流程是需要執行的，感覺在實施的時候還是有些困難，**現有的發布流程不能說完善，但很簡單實用，如果能做到嚴格執行，相信已經可以減少很多問題了。
第二大的問題就是「溝通」，團隊合作必不可少的乙個環節。站在pd的立場上，我們會把自己作為產品的中心，這個角色注定要和各種各樣的人交流，客戶、老闆、開發、運營、測試、客服、合作部門等等。
開 發們提出了很有意思的一點，希望大家在交流的過程中避免情緒化。人性的弱點決定了在爭論的過程中每個人都希望自己得到認同的，而這點往往導致思路的變形， 不再是考慮產品怎麼做更好，而是去想如何說服對方。我自己是覺得溝通中還有一點重要的就是每個人都要主動一點，這樣才能形成互動的氛圍，也可以減少資訊不 暢引起的問題。
第三點是pd要不斷提高自我修養，大家希望pd給出的文件在質量再更進一步，準確、全面、簡潔，即時更新、保持最新。我自己覺得還有另外幾點也是需要pd自己不斷努力的，比如考慮問題的全面性，有空多了解一點技術等等。
話題太大，時間有限，不再多言。
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...
產品設計體會（十二） 少而精
長假回來，這兩天基本在全力做 批量定時上架 的需求，n多的pk 評審 確認會搞得頭昏腦脹，不過終於算是把需求確認掉了。其中有些關於功能做多做少的爭論，這個話題在體會 三 中有所設計，但說的不深，這裡再寫點。一 個功能的多次需求會議中，必然有這樣乙個過程。開始對乙個功能想的不完整，說著說著大家都想把這...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...