上一篇?我們已經(jīng)確認了 PRD 和 UI，接下來我們繼續(xù)了解「研發(fā)測試」的過程。

研發(fā)測試

這個階段的參與者？

雖然標題是叫「研發(fā)測試」，但是大家千萬不要以為這個過程只有研發(fā)小哥哥和測試小姐妹的參與。是的，作為產(chǎn)品 owner 的產(chǎn)品經(jīng)理和參與設計的 UI 同學都是需要參與「研發(fā)測試」這個過程的。只是產(chǎn)品經(jīng)理參與度比較深，需要和各個角色協(xié)同溝通；UI 同學參與度稍微比較淺，大多只需要和前端溝通，保證前端同學最大還原自己的設計稿。

作為產(chǎn)品經(jīng)理，你一定不要成為淪落到只寫 PRD 或只畫原型。因為如果只是純設計，不參與開發(fā)過程，很多設計問題你完全是意識不到的。比如：我們在做操作日志的時候，有個規(guī)則是角色「管理員」可以看到所有人的操作日志，其他角色只能看到自己的操作日志。

當時，我在設計【操作日志】界面的搜索時，就是統(tǒng)一按照「操作人」、「操作時間」做為篩選項，但是在真正開發(fā)過程中，由于需要對「操作人」做權(quán)限判斷，就稍微比較麻煩，最后經(jīng)過討論，我們將「搜索項」拆分為：

• 當前登錄用戶非管理員時，只有「操作時間」；
• 當前登錄用戶為管理員時，「搜索項」為：「操作人」、「操作時間」。

其實如果不是深度參與整個開發(fā)過程，一些設計的問題自己可能很難發(fā)現(xiàn)。當然，類似的例子還有很多。

那 UI 為啥要參與研發(fā)測試過程呢？

之前聽過這樣一個例子，領(lǐng)導把研發(fā)做的最終界面發(fā)到群里：“這是誰設計的界面”，群里一片寂靜。做設計圖的 UI 跟我講，因為研發(fā)做出來的效果和自己的設計圖完全不相符，甚至可以說是兩張圖，那我為什么要承認。

我不知道這位 UI 在說這句話的時候有沒有意識到這個問題，但是我相信有很多 UI 面臨著相同的疑惑。研發(fā)不按照我的設計圖開發(fā)的時候，應該怎么做？

其實 UI 參與研發(fā)測試的過程就可以解決這個問題了，作為 UI 千萬不要認為你的圖做完了，你的事情就做完了。我之前一直在考慮 UI 設計的終點，是完成 UI 圖？還是驗收前端開發(fā)結(jié)果？甚至是跟蹤線上用戶反饋，并根據(jù)用戶反饋改進設計？雖然我還沒想到更合理的答案，但我認為從完成 UI 圖到根據(jù)用戶反饋改進設計，每往前走一步，對 UI 來說都是一個里程碑式的進步。

每個角色在當前階段都需要做什么？

我們以瀑布開發(fā)模式為例，簡單粗暴地把這個階段分為：研發(fā)階段和測試階段。

研發(fā)階段和測試階段的分界點，可以簡單通過測試人員是否介入來判斷。如果測試人員沒有開始測試，那就是研發(fā)階段；如果測試人員開始測試，那就是測試階段。

瀑布開發(fā)模式瀑布開發(fā)模式，也叫瀑布模型（Waterfall Model），是指軟件開發(fā)過程是按照一系列順序展開的，剛開始是需求分析，然后是產(chǎn)品設計，然后是編碼，然后是測試，然后才是上線。因為開發(fā)過程是一步一步進行的，所以才被成為瀑布模型。和瀑布模型相對應的也是現(xiàn)在業(yè)內(nèi)比較流行的是「敏捷開發(fā)」，感興趣的小伙伴可以了解下。

（1）研發(fā)階段

每個角色在研發(fā)階段需要做什么：

• 產(chǎn)品經(jīng)理：跟蹤研發(fā)過程，合理調(diào)整需求；
• UI：跟蹤前端開發(fā)過程，合理調(diào)整 UI 設計；
• 研發(fā)：設計數(shù)據(jù)庫 + 定接口及編寫接口文檔 + 編碼 + 單元測試；
• 測試：整理測試點和測試用例。

（2）測試階段

• 產(chǎn)品經(jīng)理：跟蹤測試過程，評估 Bug 優(yōu)先級、是否需要在當前版本修改、以及修改建議；
• UI：對前端開發(fā)成果予以驗收，并提出具體的改進意見；
• 研發(fā)：改 Bug；
• 測試：發(fā)現(xiàn) Bug + 發(fā)版。

項目啟動

枯燥的流程介紹完了，我們來看下每次項目啟動的緊張時刻。首先，這里是把產(chǎn)品的一個開發(fā)周期（或一個迭代）稱為項目。

項目啟動時要準備什么？

主要是產(chǎn)品經(jīng)理準備啦，平時我都是提前準備好 PRD、UI 圖，然后定好會議室，等待這一緊張的時刻到來。

每次都會提前一天左右準備好這些資料，但是在會前做最后的檢查時，總是會發(fā)現(xiàn)這樣或那樣的小問題。有人告訴我，今天的設計明天在來看的時候，可能又會有新的想法冒出來。嗯，總是感覺不到最后一刻，我就不會停止修改。

項目啟動時要說什么？

所謂的項目啟動，可以理解為把需要參與這個項目的人拉在一個會議室里開個會，告訴大家：

1. 我們要開始做這個項目了，嗯，只是告知。
2. 為什么要做這個項目？
3. 這個項目的目標是什么？
4. 這個項目要做哪些功能？

嗯，是的，這里沒有說明「Deadline」。如果你定了一個 Deadline，而你的團隊成員都不認可，其實這個 Deadline 是形同虛設的。我們在做項目的時候，都是在啟動會之后給團隊成員半天到一天的時間熟悉需求，然后讓大家來領(lǐng)任務，然后每個人預估時間，預估完成之后進行最后的調(diào)整，并設置一個大家都認可的 Deadline 作為項目的截止時間。

需求的凍結(jié)與變動

項目啟動，又見需求

有讀者跟我說，你這個系列講需求，都講了好多篇了，從頭到尾都是再講需求。我……沒辦法，產(chǎn)品就是離不開需求，如果你不理解，只能說你還需要修煉。

由于項目啟動的時候需要跟團隊成員講解需求，所以此時需求也會有小范圍的調(diào)整，但是大范圍的需求列表（也就是當前項目要做哪些需求，即項目的范圍）是不太容易變動的。除非老板要求這個版本提前上線，我們會臨時砍掉一些需求以保證上線時間。其它時候，不太容易有項目范圍的變動。

換句話說，項目啟動之后，需求列表就確定了，也就是俗稱的「需求凍結(jié)」。需求凍結(jié)之后，不是說需求就不能改了，只是不能再增加了。

如果一味地往一個項目里增加需求，一來團隊成員總覺得需求做不完，可能打擊團隊成員的積極性，二來項目啟動其實就沒什么意義了，因為開不開效果是一樣的。

至于項目啟動之后，需求能改動到什么程度，主要看團隊成員之間的配合。如果是初次配合，不建議改。當然，這并不是意味著配合次數(shù)多了，就可以隨意改。好吧，我更正上句的說法，不管是什么時候，最好不要更改。當然，從我自身的經(jīng)驗看，這點確實很難做到，不過，可以盡力一試～

需求必須要變動，怎么辦？

需求的變動包括以下幾種情形：

1. 減少現(xiàn)有的需求列表刪需求對大家來說都是一件好事，畢竟大家都可以少做點工作。不過，決定做這件「皆大歡喜」的事情時，還是需要跟團隊成員解釋為什么要這么做，讓團隊成員之間不要有誤會，也不要有不信任。畢竟，你想，萬一人家剛做完，你就給人把需求砍了，這誰心里會舒服啊。
2. 調(diào)整現(xiàn)有需求列表的細節(jié)最好能不調(diào)整，但是如果真的要調(diào)整，最好在溝通需求的時候就說明「這里還需要確認，后續(xù)確認之后再溝通……」，讓團隊成員心里有底。如果后續(xù)真的需要調(diào)整，大家心里也會稍微舒服點，同時，提前溝通好后續(xù)可能會有的變動，大家在預估工作時間的時候也會留有余地，免得后續(xù)因為需求的調(diào)整使得某位成員加班趕工期而導致其心里不痛快。
3. 增加需求相對來說，「增加需求」這一點最難處理。如果你直接以「老板說的」為借口，其實還是很好處理的。但是久而久之，會給別人一種「你沒有獨立思考能力」的感覺，因為你凡事都是「聽老板的」。我現(xiàn)在能想到的更合理的做法是，先「講道理」說明為什么一定要這么做，然后「重新評估需求優(yōu)先級」，因為有需求臨時「加入」，看有沒有哪些需求可以臨時移到下一個版本。這樣經(jīng)過調(diào)整之后，大家心里稍微舒服些。同時，萬一真的沒法把其它需求移到下一個版本，大家也稍微能理解。

研發(fā)過程溝通

為什么要溝通？

項目啟動之后，大家就開始完成自己的任務了。作為產(chǎn)品經(jīng)理，要及時和研發(fā)溝通，以免因為設計不合理或者規(guī)則不合理導致研發(fā)任務很難完成。比如：最近我們有個「結(jié)束日期不選即為至今」的需求，研發(fā)在實現(xiàn)的過程中就遇到了很多問題。因為在很多人的理解中，「至今 = 今天」，這樣的理解會有一個潛在的規(guī)則「開始日期不能晚于今天」，否則會進入一個悖論的狀態(tài)。

經(jīng)過溝通，我才發(fā)現(xiàn)「至今」的文案不夠準確，因為我想要表達的是「開始日期之后的某一天」，而「至今」在冥冥之中增加了一條規(guī)則，而「開始日期晚于今天」在業(yè)務上是合理的。比如：我們在定 OKR 或做年度計劃的時候，「開始日期」肯定是會晚于今天的。這樣的情況在實際工作中還會遇到很多，舉這個例子只是想說明，研發(fā)過程中的溝通是十分必要的。

討論出結(jié)果，就結(jié)束了嗎？

新人產(chǎn)品經(jīng)理還會常犯一個錯誤就是，當產(chǎn)品經(jīng)理和研發(fā) A 溝通之后，然后就不自覺地認為已經(jīng)溝通完了。但真的是這樣嗎？難道不需要和團隊其它成員同步溝通結(jié)果嗎？

剛開始工作的時候，我總會忘記和團隊其它成員同步溝通結(jié)果，這就導致和 A 說過的事情，測試 B 要問一遍，項管 C 還要問一遍，溝通效率極低，而且從情緒上也會有所抵觸。其實，就是在群里發(fā)個消息，一句話的事情就能解決的問題，為啥非要搞這么麻煩呢？自此，我就學聰明了。

測試用例評審

誰要參加測試用例評審？

推薦產(chǎn)品經(jīng)理、測試、研發(fā)。

產(chǎn)品經(jīng)理參與是為了保證測試理解的需求和自己想要的一致，因為產(chǎn)品最終是由測試來驗收的，如果測試和產(chǎn)品經(jīng)理理解的不一致，那最終出來的產(chǎn)品會和想象之中差距比較大。

為什么研發(fā)需要參與？因為測試用例和研發(fā)編寫的代碼息息相關(guān)。敏捷開發(fā)中有一條就是要求研發(fā)根據(jù)測試用例編碼，以降低 Bug 率。

跨部門溝通

作為產(chǎn)品經(jīng)理，免不了要跟其它部門的人合作。那怎么處理跨部門溝通的事情呢？

• 首先，你需要知道哪些點上是需要跨部門合作的？
• 其次，這些點是完全依賴對方的工作的嗎？如果是強依賴，那就要求對方完成之后，我們才可以開始。如果不是強依賴，雙方就可以同步進行。
• 最后，一定要溝通清楚對接的具體內(nèi)容和具體的時間點，并文字留底。

因為跨部門合作的時候，經(jīng)常出現(xiàn)所謂的「責任不明確」現(xiàn)象，文字留底是為了保護自己。

下一篇我們將繼續(xù)關(guān)注「測試與上線」，敬請期待。

好的，今天這篇文章到這里就結(jié)束了，我們的《一個項目帶你走進產(chǎn)品經(jīng)理的世界》系列文章完成進度如下：黃色為當前進度～

相關(guān)閱讀

一個項目帶你走進產(chǎn)品經(jīng)理的世界（1）：從收到一個需求談起

一個項目帶你走進產(chǎn)品經(jīng)理的世界（2）：需求分析

一個項目帶你走進產(chǎn)品經(jīng)理的世界（3）：從用戶需求到產(chǎn)品功能

一個項目帶你走進產(chǎn)品經(jīng)理的世界（4）：產(chǎn)品規(guī)劃

一個項目帶你走進產(chǎn)品經(jīng)理的世界（5）第一個版本：MVP ？MDP ？

一個項目帶你走進產(chǎn)品經(jīng)理的世界（6）：設計確認

#專欄作家#

佐珥，微信公眾號：產(chǎn)品碎月（ID：pm_lab），人人都是產(chǎn)品經(jīng)理專欄作家，專注互聯(lián)網(wǎng)產(chǎn)品，樂于通過幽默詼諧、圖文并茂、結(jié)合實際的文字分享自己的產(chǎn)品經(jīng)驗，期望同大家一起快樂成長

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議