在網際網路環境下,要弄清楚開發什麼産品,準确把握并實作使用者需求,對産品人員的要求其實非常高。對于網際網路産品而言,從最初的一個想法,到确定規模化的增長模式,通常要經曆很多輪的螺旋式疊代,不斷調整。
由于前期對需求和設計沒有嚴格把關,匆忙投入開發,導緻開發的錯亂與不合理。很多時候。我們沒有辦法一步到位,但合理試錯,減少不必要浪費,仍然是可以做到的。在項目執行的過程中,想要降低偏差、減少返工,你就需要建構系統能力,在産品研發的整個過程中,建立起真正閉環回報的産品驗證機制。 關鍵資源參與的可行性分析,前期系統、全局評估需求,開發後根據回報調節。
在産品研發的整個過程中,到底有哪些實用的閉環驗證方法呢?我來給你介紹三種最實用的方法。
往往有些項目是從不做需求評審和設計評審的,産品人員找某位開發單方面讨論一下,需求就算定下來了,可以直接往下走了,這就是典型的開環系統。這忽略了系統、全局性,可能存在沖突隐患,後期風險提高。
要想執行中不走樣,你就必須把方案評審做到位。 有人會覺得評審不就是大家湊一塊開開會嗎?不,評審的關鍵在于資訊的公開共享,以及背後的決策機制。隻有決策機制清晰,職責分工明确,方案評審才會有好的閉環效果。
OARP 是 Owner、Approver、Reviewer、Participant 的縮寫,分别對應四個關鍵角色:
負責人(Owner):負責給出方案,組織各方讨論并推進做出最終的決定;
準許者 (Approver):最終準許者;
稽核者(Reviewer):負責人和準許者挑選出的稽核人。稽核者有責任對文檔進行讨論分析,并提出回報意見,負責人必須重視并給予回複;
參與者 (Participant):其他提供意見的人。參與者會收到文檔的相關資訊,可以對相關問題做出回報。

這張流程圖清晰地展示了一個典型的方案評審流程。OARP 是一套決策機制,你需要為項目中每一類方案的評審,确定明确的角色和職責,讓各角色應享有的權利、應履行的職責,都得到規則上的保障,這樣才能更好地確定方案品質,把後期的返工降到最低。(事前充分溝通,事後少返工)
Bug Bash,也叫 Bug 大掃除,最初來自微軟,是指在項目開發裡程碑的末期(比如 Beta 版釋出前),劃出一個專門的時間段,在這期間,所有參與項目的人員,集中全部精力一起來給項目找 Bug,目的是從各個次元衡量和體驗産品。(階段性掃除bug,防止bug積壓,bug的積壓可能衍生更多bug,導緻返工更加困難)
那麼,想要組織一場 Bug Bash 活動,該從哪些方面入手呢?
時間:測試類的 Bug Bash,你可以選擇在全面功能測試結束後,Bug 趨于收斂的時間段開展;需求設計類的 Bug Bash,一般會放在需求稿或設計稿完成後舉行。這個活動需要一到兩個小時的時間,你一定要提前排除所有幹擾;
地點:你需要設立一個單獨的作戰室,鼓勵參與者自帶筆記本,讓他們盡可能集中精力做這一件事。同時,作戰室可以提供一些零食和飲料,讓活動更有氛圍;參與者:除了研發和測試,産品、設計、市場、營運、銷售等項目組不同角色的人群,都需要參與到這場活動中,這樣你就可以獲得更加豐富多元的視角;
現場安排:你可以把現場回報的問題直接貼在白闆上,或者通過電子白闆,來滾動更新 Bug 或建議的排名情況。需要注意的是,營造互動的氛圍非常關鍵,如果因為空間受限,參與者做不到在同一個地點進行,你至少也要在通信群中實時更新排名情況的變化。
活動結束:在活動結束後,要直接公示 Bug 或建議數,現場給獎品,并發郵件通報全組。最後,在對 Bug 進行去重後,還要分類定級,确定哪些 Bug 是必須修的,哪些 Bug 是改了會更好的。另外,千萬不要忘記公示結果,明确修複計劃。
活動的組織,加入更多的遊戲的玩法,最大程度調動團隊成員熱情,将問題更早發現。 對于計劃越不詳細的項目,bug bash的使用頻率就會越高,越能提前發現問題,避免後期返工。問題越早解決成本越低
雖然“冒煙測試”這個概念很普遍,但是很多團隊隻是把它作為提測後的測試用例組,并沒有真正發揮其合約的作用。要想避免掉進“差不多”的陷阱,在進入開發環節後,你需要安排專門的測試用例評審,讓開發和測試對标準的冒煙用例集達成約定,這個約定就會成為進入測試的準入标準。開發發起提測以後,測試人員就會依照這個标準用例集進行冒煙,并記錄冒煙測試通過率,如果通過率不達标,就打回修正并再次提測。
如果你是在完全沒有基礎的團隊中推行這個做法,可以先從測試人員記錄冒煙測試通過率開始。接着,你要收集相關資料,和你的團隊在回顧會上一起看看冒煙用例失敗所導緻的後期返工成本,讨論出一種更好的確定品質的做法。在我直接管理的項目中,冒煙通過率的要求通常是 100%,你可以選擇從一個合适的起點開始,比如 80%,然後再一步步地逼近更好的提測品質。
冒煙用例,可以控制一定的比例,涵蓋主要功能路徑,一步一步來,前期重點在于培養開發自測習慣。