【軟體PM大小事】:為何RD跟你的想法不一樣 ? 關鍵在於「溝通認知差異」

此篇文章,將針對以下兩項議題,提出個人的見解: 1.如何有效縮小PM/RD知覺印象的差異,避免溝通認知的差異? 2.如何避免在最終產品開發完成後,才發現與預期結果不同?

這幾年的軟體PM工作經驗中,其中一項我認為很重要的事是:「確保PM制定的產品規格與RD最終生產出來的產品內容一致」。這件事不但是訓練PM在溝通表達上的能力以外,也是追求工作效率提升的關鍵因素。

因此,此篇文章就針對個人過去的軟體PM工作經驗,提出有效避免此錯誤的實際方式。此文章以PM & RD兩方面角色為例,當然亦可運用在PM與UI/UX、Technical Writer等人員溝通上。

談談此議題之前,我們必須先了解「溝通認知差異」導致的事後成本所造成的損失有多嚴重。在公司裡,溝通不良的代價很大:造成時間成本的浪費、人力資源的浪費、效率更低、挫折提升、顧客流失、反應緩慢、無法將時間投入其他更重要事項、個人績效達成率不佳等等。

有一間大公司算過,溝通代價的損失造成每位員工每週浪費了3.5小時的時間成本,對一家五百人的公司來說,相當於每年損失數百萬美元。

此篇文章,將針對以下兩項議題,提出個人的見解:

1.如何有效縮小PM/RD知覺印象的差異,避免溝通認知的差異?

2.如何避免在最終產品開發完成後,才發現與預期結果不同?


如何有效縮小PM/RD知覺印象的差異,避免溝通認知的差異

首先,您必須先了解的第一件事是:「這件事情隨時都在發生,無所不在,也無法避免」。與其事後花時間在爭論誰對誰錯,不如在初步溝通時,透過有效的方法,來減少、縮小彼此的知覺印象差距。 — Stuart Diamond

有效的減少溝通誤解的方式,提出以下幾點供參考:

1. 面對面溝通,搭配Wireframe流程圖:

PM在產品規格擬訂後,會開始與RD進行產品規格討論,此時較佳的作法是,請RD主管與負責的RD一起找間會議室,面對面直接就細節討論,PM並將準備好的初步規格內容、Wireframe當作重要輔助資料說明。

溝通方式百百種,例如:透過電話、Email、Skype等等,或許每個人有自己喜歡的溝通方式。但我個人還是推薦,針對較重要的事項,若時間環境許可下,還是建議直接以「面對面」的方式來做溝通最有效率,避免語氣、文字上的揣測,造成誤解。

最後,多想想對方的溝通風格,盡可能貼近他的風格。

2. 進行角色對調的練習、並做歸納和摘要:

當PM針對某項規格提出想法並解釋後,可以試著請RD就自己聽到的認知,用自己的方式,說明解釋一次。此方法可避免單方面認為對方已經理解自己的意思,事後卻發現彼此有所誤會。此外,若當場有白板的話,可以直接在白板上劃出構想流程、規格內容、版面配置等資訊,並透過手機拍攝起來,方便日後確認。

另一個好方法是,在討論過程中,時常做出歸納和摘要。經常歸納您聽到的資訊,用自己的話覆述一次給對方聽。這樣做的好處不僅能顯示您重視對方,也能確認你們的認知相同。若您覆述時內容有誤,也可以讓對方明確的更正錯誤的地方。

3. 將討論結果詳細撰寫至規格中:

“盡可能”的將預期的規格、使用行為、討論結果,詳細的紀載至您的規格文件中,並搭配UI設計圖稿或是Wireframe輔助說明。根據過去經驗,只能以「盡可能」的方式來呈現,畢竟在PM工作時間有限的情況下,很難達到所謂完美無缺的規格文件。但若文件本身過於簡略,造成知覺認知誤差的可能性則會大幅提升。

文件撰寫後,務必請RD親自瀏覽過每項細節,針對有所疑慮部分(不確定是否RD能明白之處),可以特別用comment方式註解,請RD務必過目,避免日後實作差異導致爭議。

*小建議:針對新手PM,時常遇到的問題是,無法確認自己撰寫的文件規格是否夠詳細?此時,有幾個方式可以避免此困擾,如:可以主動去參考、模仿資深PM撰寫的SPEC文件內容、與RD討論是否夠詳細,哪方面不足需要再補充。久而久之,自己便能針對不同的RD與專案,寫出盡可能完美的文件。

如何避免在最終產品開發完成後,才發現與預期結果不同

根據過去經驗,新手PM常犯的錯誤是當RD將產品開發完成後,才發現預期的產品規格或呈現方式與當初想像的不同。此時,若要再回頭進行修正,不僅RD可能會質疑您當初討論的說法,也會造成開發時間成本的浪費,並增加彼此的不信任感。

為避免新手PM造成此錯誤,提出以下方法供參考:

設立檢查點,定期確認進度與成果

在與RD確認完規格內容後,即會開始進行RD開發實作階段。此階段執行前,務必先與RD確認該規格的「總體完成時間」與「階段進度完成時間」。

舉例來說:若要開發一套影音播放軟體,可事先將整體規格切分為多個階段項目,如:登入畫面、主頁面功能、影片分類功能、播放器功能等等內容。在正式開發前,先與RD確認每個階段預期完成時間。

當該項目完成後,可要求RD將初步完成的結果給PM確認。此時若發現與當初討論的構想有所差異,則可以馬上進行修正調整。好處除了能讓RD及時進行修正調整以外,PM也可以藉此了解與該RD團隊溝通方式是否可行,以做相對應的調整(如:SPEC撰寫方式是否夠詳細、是否需要提升溝通的頻率)。

備註:PM需要針對不同專案性質、RD團隊,制定檢查節點、檢視頻率,此部分也能與RD做事先溝通。

以上就是「新手PM如何避免最終產品結果與預期不同的解決方法」,用以下幾個小結論,來做個總結:

1.不斷持續保持溝通,並找出您認為最有效率的溝通方式

2.盡可能採用各種方式避免認知差異的產生(角色對調練習、善用問句確認)

3.預先設立檢查點,更頻繁地確認溝通認知實際結果是否正確,以適時做出調整

謝謝閱讀,若您有更好的方式,也歡迎留言提出!一起打造出更完美的PM作業流程~~

原文出處:「軟體PM大小事」如何確保最終產品開發結果與預期認知一致 ? 淺談如何避免溝通認知差異

作者簡介:

Bennett Cheng

高雄人,為了生存而成為了北漂青年。求學時就讀於台灣科技大學企研所,曾在捷克當任交換學生。目前於科技品牌廠擔任軟體產品經理一職,擁有敏銳的人際敏感度、跨團隊溝通和高效的時程控管能力。興趣是旅行與閱讀,人生至今遊歷過23個國家,偏好商業管理與人文書籍。為一名正向樂觀主義者,深信朝著對的方向前進,旅途中的收穫與結果將都燦爛!

主圖來源:unsplash.com

若有轉貼需求,請來信(service@pmtone.com)討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。

覺得這篇文章好嗎? 請分享給您的朋友吧~

Facebook
Twitter
LinkedIn
Email
列印
編輯嚴選

編輯嚴選

我們是網站的小小編輯群 專門負責挑選、刊登好文章 歡迎部落客、寫手們投稿至 editor@pmtone.com

延伸閱讀