互聯網產品，從產品經理開始設計產品到產品上線的過程，需要多個角色參與，例如有產品、UI、開發、測試等。在這個過程中保障各個環節的質量，最終交付高質量的產品對企業來說非常重要。這個方面有很多工具，例如PMP、六西格瑪等等。今天也不聊這種比較知名的工具，而是談一些工作中總結的心得。
我覺得要保證產品質量，主要分為兩個方面的措施：
一、制定工作協作規範
確定大家的角色、職責、分工，協作方式。這也是大家合作完成同一個任務的基礎。好的協作規範能夠提高團隊的工作效率。這一部分介紹一些工作規範方面的問題場景和應對建議。
二、工作執行過程中監控
規範有了，大家幹活的過程中具體乾的怎麼樣也需要關注。但是大家的情況各不相同，那麼在做執行過程中監控的時候，就需要根據人員進行分類，區別對待。這部分說下如何劃分員工類型和各類員工的合作技巧。
這篇先說下“工作協作規範”。
一、制定工作協作規範
先說明下為什麼需要工作協作規範，用一個場景來做示例。
產品從設計到上線，是一個多人協作完成的的工作任務。會分為產品、UI、開發、測試等多個角色，每個角色還會有多個人。從上面的場景可以看出，如果沒有好的工作協作規範，參與的同事即使很努力工作，最終工作也可能做不好。所以要根據實際情況，制定出適合自己團隊的工作協作規範。讓大家明白自己的工作任務以及與其他角色協作的方式。
下面介紹幾個工作協作約定方面的問題和建議：
（一）信息傳遞與確認
問題描述：
信息傳遞失真！
從需求來源開始，產品經理、UI要收集需求來進行設計，開發人員根據產品經理的需求文檔進行技術方案設計和開發，測試i人員以需求文檔為依據編寫測試用例、檢查開發代碼質量。各個環節環節做好工作的前提就是：上一環節信息傳遞準確，本環節成員正確理解，本環節多成員信息同步一致。如果做不到，就會發生如下如圖的例子，產品做出來一定是自己蒙圈，客戶蒙圈。
工作建議：
一堆評審會：可以包含產品需求評審會、UI設計評審會、技術設計方案評審會、測試用例評審會。
評審會佔用時間，但是評審會也是有作用的。必須產品的需求評審會，產品介紹一遍需求，有說的不清晰的地方。大家可以提問。消除疑問後大家對需求的認知達成一致。然後再開技術方案評審，就像是說：“你們的需求是XXX的，我們打算用這樣的技術方案實現，你們看看有遺漏或者有對需求理解錯誤的地方嗎？”類似三次握手，需求評審信息是”產品-->開發"傳遞，技術評審是“開發-->產品”進行信息確認。其他評審會也一樣，各個評審會的最終作用就是儘量確保信息傳遞的正確、完整。
為了確保會議開得有價值，建議對會議做一些約定。例如技術評審會，如果開發同事講了，產品同時沒有提出異議，如果方案未滿足功能，責任主要在產品。明確責任之後，大家會相對的對會議引起重視。
如果評審會只是走形式，開這種會就是浪費單位資源！下面的例子就是這種情況：
（二）各環節參與攔截問題
問題描述：
還有一種情況，就是出現問題後，發現的太晚，甚至上線後才發現。問題發現的越晚付出的成本越高。如下：
工作建議：
如果信息傳遞無誤，其實有很多環節都會對問題進行攔截。不要一提到質量問題就想到測試，測試又不是神仙，其實大家都有攔截問題的機會！例如：
▶開發同事根據需求進行單元自測時候發現問題；
▶開發團隊系統測試的時候發現問題；
▶測試同事測試的時候發現問題；
▶ 產品UAT的時候發現；
都沒發現那就可能是三個原因：1.信息傳遞失真；2.沒有明確各環節為攔截問題需要進行的工作；3.如果明確了，那就是大家都碰巧“失職"了。
所以建議通過評審會來確保需求傳遞準確，在此基礎上明確各個環節需要做的質量保證動作。
不過，即使明確了職責，現實中有問題漏網的情況也不少。這就是具體工作執行情況監控的問題了，這個在下一篇文章聊下。
（三）工作中工具統一
問題描述：
大家都知道，Axure9編輯的原型Axure8是打不開的，墨刀畫的原型也不好與Axure原型互通。還有，如果大家分別負責產品設計的一部分原型，團隊中有人用墨刀，有人用Axure，是不是會很尷尬。
工作建議：
現在各種辦公輔助軟件很豐富，很多人也願意嘗試新的工具。嘗試新事物是好的，就是需要考慮團隊協作。無論是產品、UI、開發、測試，大家一起工作的時候，都要做好工具類型、版本或產出成果格式的統一約定。
（四）團隊名詞統一約定
問題描述：
有時候開會，產品和開發明明達成了一直認識，但是開發出來還是跟需要不一樣。那是因為，僅僅是“你以為”一致了。其實大家腦子裡想的並不是一個東西。還有因為大家來自不同的公司，每個公司可能都有自己不同的叫法。例如測試環境和生產環境之間的那個環境叫啥？灰度、準生產、UAT環境？其實不同公司指的不太一樣。
工作建議：
1.各個環節梳理自己的常用名詞，進行統一約定。大家針對同一個東西都有相同的稱呼和理解。例如產品的版本、狀態名稱和定義、系統的名稱和劃分依據等。
2.或者直接拿出成果示例在會上展示，場景事例中可以直接畫出圖形，勝過十句描述。具體工作中的一些數據測算、交互動作等都可以直接給出Demo示例與內部團隊與客戶溝通。
（五）做好覆盤，不重複犯錯
問題描述：
由於性格、工作習慣、工作能力的差別，團隊磨合的過程中會出現各種各樣的問題。並且由於工作節奏加快、外部環境變化、部門職責調整等因素，會讓原本已經形成協作默契的團隊產生新的問題。
工作建議：
問題發生很正常，但是要減少同樣的問題在團隊內部多次出現。在問題發生後大家一起去覆盤一下，找到問題發生的原因，一起想解決方案。覆盤的主要目的不是問責，而是為了吸取經驗教訓，避免同一個坑裡摔倒兩次。
大家都不說問題原因或者為了怕得罪人不願意說，問題再次的時候出現大家一起被坑。
並且在找到問題原因後，要一起想好避免問題發生的解決方案。不能光靠大家自主能動性，還是要有切實具體的工作約定。
（六）儘早拿到預期結論
問題描述：
工作中會存在一些風險我們無法完全消除。例如場景中說的由於UI資源不足，並且是後臺界面，就決定請前端工程師找開源的界面套一下樣式。但是發現最終不符合預期。還有一些小概率異常邏輯的風險，不確定因素的風險。風險如果真的發生，會對項目資源造成損失。
工作建議：
儘量找到更多的“佐證”，清晰直觀的傳遞信息，並且請團隊成員參與論證。例如還是界面的問題，在提需求的時候，順便找幾個比較符合預期的軟件的界面截屏給開發看，問下能不能做。這樣在開發資源投入前，就能夠拿到結果預期，如果不行就趕緊想其他方案（做成啥樣都忍了、投入UI資源等)。
（七）職責該不該分清
問題描述：
職責不清晰，一定是一團亂。可是工作中非把工作職責分清楚，也有點問題：1.有些很難分清楚；2.即使能分清。職責分的很清晰，你幹你的我幹我的互相不摻和，但是自己如果有疏漏或能力不足是不是就不能相互查漏補缺了？
工作建議：
1.職責、任務儘量分清楚；
2.鼓勵團隊內部交叉檢驗工作成果，例如產品需求評審會前先進性內部評審；
3.出現分歧遵循“我的地盤我做主”、“專業的人做專業的事”原則。
（1）我的地盤我做主：工作負責人，為結果負責，同時有最終決策權；
（2）專業的人做專業的事：大家都發揮自己的專業性，做好本環節的質量把控。由專業人拍板。例如產品方案的分歧，最終由產品經理決策；技術方案分歧，最終由研發工程師決策。
（八）團隊內部信息傳遞
問題描述：
自己獲取到的信息傳遞不全。就像場景中描述的，組長去開會沒跟組員同步信息。
工作建議：
1.相同崗位視角一致，組內同步信息更加便於理解。約定好誰去參會，誰負責給相關人員同步信息。
2.會議做好會議記錄、錄音、錄像發給大家。
（九）腦子沒那麼牛X就多動筆
問題描述：
有些錯誤的印象或者習慣：去開會，就是當“大爺”，就是休息時間。能帶耳朵就不錯了，帶著腦子聽的就是負責任的，能做記錄的那就是優秀員工。
工作建議：
1.腦子夠聰明，用腦子記。
2.如果記不住，那就別懶。跟自己相關的細節動手記錄下來。例如自己需要跟進的問題，後邊需要處理的事項。
3.制定規範，要求會議結論及時整理留檔。可以是軟件記錄、郵件，能把信息記錄並且傳遞給干係人就可以。
工作規範會增加成本執行，所以規範一定是為了解決工作中的問題產生的。建議根據自己團隊事情情況，制定能解決自己團隊問題的協作規則!
未完待續----------
閱讀更多 開課吧產品100 的文章
