小芒果導讀：產(chǎn)品經(jīng)理的日常少不了和各個部門的同事打交道，那么該如何與工程師、UI等協(xié)作呢？

之前寫過一篇《我的產(chǎn)品設(shè)計流程》，很受歡迎，這是它的續(xù)篇，講一些PM與其他崗位協(xié)作的經(jīng)驗。

1、

在大公司里，往往技術(shù)的人坐一起，產(chǎn)品的人坐一起，UED的人坐一起，這很糟糕。首先，PM的座位應(yīng)該緊靠著工程師，近到有任何問題，工程師只需要喊一嗓子“XX，你過來解釋一下”。如果距離遙遠，必須依賴文檔、郵件、IM溝通，這會大大降低工程師與PM溝通的頻度與深度，把工程師的角色從“討論實施”拉低到“接單執(zhí)行”。

其次，UI的座位也應(yīng)該緊靠著工程師。一個視覺效果是否容易在技術(shù)上實現(xiàn)，走過去問問就知道了。而工程師研發(fā)時找到視覺稿上的問題，只需要喊一嗓子“XX，你過來看看這個”。UI設(shè)計師與工程師的緊密溝通，不僅提升了研發(fā)效率，也提高了UI的技術(shù)敏感性。

歸根結(jié)底一句話，緊密團結(jié)在工程師的身邊。

2、

一個有經(jīng)驗的PM，應(yīng)該能搞清楚哪些產(chǎn)品細節(jié)偏界面，需要和UI設(shè)計師一起討論決定；哪些產(chǎn)品細節(jié)偏后端，需要和工程師一起討論決定，而不是大包大攬在自己身上。

蟬游家的產(chǎn)品是這樣的，我出主干設(shè)計，然后UI設(shè)計師會提各種界面修改意見，工程師會提各種功能與算法修改意見。有些甚至會反過來，比如我列舉功能清單，工程師來設(shè)計后臺，然后我提界面與交互修改意見。又或是我提出影響排序的5個要點，我和工程師頭碰頭地討論兩三個小時，一起把排序算法給定下來。

對PM來說，借力很重要。人家專業(yè)就讓人家來嘛，讓UI設(shè)計師和工程師一起設(shè)計產(chǎn)品，不僅效果更好，也增加了隊友的參與感。但如此簡單的一個道理，在拆分成產(chǎn)品部、研發(fā)中心、UED這三個部門時，卻很不容易實現(xiàn)，被畫地為牢所困。你是提單找麻煩的，人家是接單擦屁股的，早點做完這一單再接排隊的下一單，誰跟你是隊友。

3、

蟬游家基本上沒有PRD……我跟工程師是老搭檔，我先出Axure原型，UI設(shè)計師用Skech轉(zhuǎn)成視覺稿，前端效果對著視覺稿講一遍，后端功能在Tower上列出來就可以了。工程師不明白的地方，隨時吼一聲，我隨叫隨到。這倒不是我懶得寫PRD，而是工程師懶得看PRD，反正PM是犬科召喚獸，隨時叫過來當面講解，比看文檔輕松多了。

雖然沒有PRD，我卻要寫測試用例。蟬小隊沒有專業(yè)QA，我就是QA。我的測試用例用Mindjet來寫，相當之簡陋，但覆蓋了全部的測試分支，且層次清晰。寫用例對于PM整理思路大有益處，經(jīng)常發(fā)現(xiàn)一些漏掉的功能點，又能實現(xiàn)PRD的存檔價值。

更重要的事情是PM自己來做測試，通過測試流程，逼著PM反復(fù)使用產(chǎn)品，反復(fù)把玩每一個細節(jié)，反復(fù)體會是否達到了設(shè)計時的用意，然后快速修改細節(jié)，調(diào)試到滿意的地步。指望設(shè)計稿“一步成型”是不現(xiàn)實的，總有設(shè)計時考慮不周全的地方，在真實使用中才能找對感覺，而測試就是對“真實使用”的模擬。

我經(jīng)常會遇到這么一類情況，某個交互細節(jié)，測試時第一次通過這里，隱隱覺得不對勁，但又講不出來。第二次，第三次，第四次，第五次，終于別扭得受不了了，然后才能總結(jié)出來，哦，原來是這個原因，改改改。如果我沒有兼任QA，僅僅是最終驗收，就沒有這種“反復(fù)把玩”的機會，停留在“隱隱不對”的認知盲點上，無法找到答案。

所以我有一個粗暴的觀點，PM不愿意兼任QA就是偷懶。雖然專業(yè)的QA能做更細致，更偏僻的測試，也能做PM搞不定的技術(shù)向測試，但即便有了這份保險，PM還是應(yīng)該親手測試，在產(chǎn)品發(fā)布前給自己一個發(fā)現(xiàn)與改正錯誤的機會。

4、

蟬小隊在產(chǎn)品調(diào)試階段高度依賴Tower。先開好項目，比如“蟬游攻略iPhone版”，按產(chǎn)品模塊創(chuàng)建十幾個任務(wù)分組，然后在分組里填寫功能需求與產(chǎn)品bug。需求和bug不分類，但會用#1.2來作版本號標記，用！來做優(yōu)先級標記。由于在一個頁面上平鋪開全部任務(wù)，排序整潔，又有分組與標記的索引，看上去十分清爽。

隨后工程師篩選出自己名字下的需求，把當前版本的需求全部清掉，有問題就回帖(進入編程狀態(tài)后他們懶得理我)，最后通知我去驗收。我把已完成任務(wù)挨個過一遍，發(fā)現(xiàn)沒達到要求，就備注一下重新打開。整個過程輕盈無比。

每一個大版本，當Tower上的任務(wù)從100+減少到0，版本就完成了。我不愿意設(shè)置嚴格的deadline，如果時間卡得太死，會影響工程師的情緒，急著做完，而不是和我一起耐心調(diào)試細節(jié)。版本發(fā)布早兩三天，晚兩三天很重要嗎？我覺得不重要。大致保持一個月一個版本的節(jié)奏就好了，為了趕半周時間搞得情緒緊張，很劃不來。

5、

有人在微博里問我，如果PM兼任QA，如何有時間準備下一個版本的PRD呢？

不不不，我這邊根本沒有“準備下一個版本的PRD”這個環(huán)節(jié)。

剛才講過，我習慣把需求和bug混合寫在Tower上，按產(chǎn)品模塊分組，這里的需求既包括當前版本，也包括后續(xù)版本。我想到任何值得做的產(chǎn)品點，立刻發(fā)到Tower上，把Tower變成一個需求池。而工程師只管當前版本號下的任務(wù)，沒寫版本號的就略過不看，再加上我會按任務(wù)優(yōu)先級拖動排序，并不顯得凌亂。

因為我是個急性子，哪怕是很久以后才能排上的需求，只要我有空，就會提前把原型畫出來，提前拉工程師、UI和運營過來討論確認。于是我會有漫長的時間，對原型設(shè)計進行反芻，在開發(fā)之前發(fā)現(xiàn)各種改進的可能，同時也將每個版本設(shè)計分解掉，用碎片時間來解決。

既然需求與原型都已經(jīng)搞掂，在一個版本研發(fā)的開始階段，我只需要花10分鐘，把Tower上全部未完成任務(wù)看一遍，給其中一部分標記下一個版本號，比如#1.3，再請UI設(shè)計師出圖。這樣當版本完成后，下一個版本的視覺稿已經(jīng)準備好了，我跟工程師當面講一遍需求，研發(fā)開始，無縫銜接。

#專欄作家#

純銀V，蟬游記創(chuàng)始人，人人都是產(chǎn)品經(jīng)理專欄作家。前網(wǎng)易網(wǎng)站產(chǎn)品部總監(jiān)。一個文藝加文筆好的產(chǎn)品經(jīng)理。

本文系作者授權(quán)發(fā)布，未經(jīng)許可，不得轉(zhuǎn)載。