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

研發(fā)測(cè)試

這個(gè)階段的參與者？

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

作為產(chǎn)品經(jīng)理，你一定不要成為淪落到只寫 PRD 或只畫原型。因?yàn)槿绻皇羌冊(cè)O(shè)計(jì)，不參與開發(fā)過程，很多設(shè)計(jì)問題你完全是意識(shí)不到的。比如：我們?cè)谧霾僮魅罩镜臅r(shí)候，有個(gè)規(guī)則是角色「管理員」可以看到所有人的操作日志，其他角色只能看到自己的操作日志。

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

• 當(dāng)前登錄用戶非管理員時(shí)，只有「操作時(shí)間」；
• 當(dāng)前登錄用戶為管理員時(shí)，「搜索項(xiàng)」為：「操作人」、「操作時(shí)間」。

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

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

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

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

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

每個(gè)角色在當(dāng)前階段都需要做什么？

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

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

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

（1）研發(fā)階段

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

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

（2）測(cè)試階段

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

項(xiàng)目啟動(dòng)

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

項(xiàng)目啟動(dòng)時(shí)要準(zhǔn)備什么？

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

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

項(xiàng)目啟動(dòng)時(shí)要說什么？

所謂的項(xiàng)目啟動(dòng)，可以理解為把需要參與這個(gè)項(xiàng)目的人拉在一個(gè)會(huì)議室里開個(gè)會(huì)，告訴大家：

1. 我們要開始做這個(gè)項(xiàng)目了，嗯，只是告知。
2. 為什么要做這個(gè)項(xiàng)目？
3. 這個(gè)項(xiàng)目的目標(biāo)是什么？
4. 這個(gè)項(xiàng)目要做哪些功能？

嗯，是的，這里沒有說明「Deadline」。如果你定了一個(gè) Deadline，而你的團(tuán)隊(duì)成員都不認(rèn)可，其實(shí)這個(gè) Deadline 是形同虛設(shè)的。我們?cè)谧鲰?xiàng)目的時(shí)候，都是在啟動(dòng)會(huì)之后給團(tuán)隊(duì)成員半天到一天的時(shí)間熟悉需求，然后讓大家來領(lǐng)任務(wù)，然后每個(gè)人預(yù)估時(shí)間，預(yù)估完成之后進(jìn)行最后的調(diào)整，并設(shè)置一個(gè)大家都認(rèn)可的 Deadline 作為項(xiàng)目的截止時(shí)間。

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

項(xiàng)目啟動(dòng)，又見需求

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

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

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

如果一味地往一個(gè)項(xiàng)目里增加需求，一來團(tuán)隊(duì)成員總覺得需求做不完，可能打擊團(tuán)隊(duì)成員的積極性，二來項(xiàng)目啟動(dòng)其實(shí)就沒什么意義了，因?yàn)殚_不開效果是一樣的。

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

需求必須要變動(dòng)，怎么辦？

需求的變動(dòng)包括以下幾種情形：

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

研發(fā)過程溝通

為什么要溝通？

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

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

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

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

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

測(cè)試用例評(píng)審

誰(shuí)要參加測(cè)試用例評(píng)審？

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

產(chǎn)品經(jīng)理參與是為了保證測(cè)試?yán)斫獾男枨蠛妥约合胍囊恢?，因?yàn)楫a(chǎn)品最終是由測(cè)試來驗(yàn)收的，如果測(cè)試和產(chǎn)品經(jīng)理理解的不一致，那最終出來的產(chǎn)品會(huì)和想象之中差距比較大。

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

跨部門溝通

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

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

因?yàn)榭绮块T合作的時(shí)候，經(jīng)常出現(xiàn)所謂的「責(zé)任不明確」現(xiàn)象，文字留底是為了保護(hù)自己。

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

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

相關(guān)閱讀

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

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

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

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

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

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

#專欄作家#

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

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

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