之前寫過一篇《我的產品設計流程》，很受歡迎，這是它的續篇，講一些PM與其他崗位協作的經驗。
1、
在大公司里，往往技術的人坐一起，產品的人坐一起，UED的人坐一起，這很糟糕。首先，PM的座位應該緊靠著工程師，近到有任何問題，工程師只需要喊一嗓子“XX，你過來解釋一下”。如果距離遙遠，必須依賴文檔、郵件、IM溝通，這會大大降低工程師與PM溝通的頻度與深度，把工程師的角色從“討論實施”拉低到“接單執行”。
其次，UI的座位也應該緊靠著工程師。一個視覺效果是否容易在技術上實現，走過去問問就知道了。而工程師研發時找到視覺稿上的問題，只需要喊一嗓子“XX，你過來看看這個”。UI設計師與工程師的緊密溝通，不僅提升了研發效率，也提高了UI的技術敏感性。
歸根結底一句話，緊密團結在偉大的工程師身邊。
2、
一個有經驗的PM，應該能搞清楚哪些產品細節偏界面，需要和UI設計師一起討論決定；哪些產品細節偏后端，需要和工程師一起討論決定，而不是大包大攬在自己身上。
蟬游家的產品是這樣的，我出主干設計，然后UI設計師會提各種界面修改意見，工程師會提各種功能與算法修改意見，我忙不迭地說：改改改。有些甚至會反過來，比如我先列舉功能清單，工程師來設計一整個后臺，然后我去提界面與交互修改意見給他。又或是我提出影響排序的5個要點，我和工程師頭碰頭地討論兩三個小時，一起把排序算法給定下來。
對PM來說，借力很重要。人家專業就讓人家來嘛，讓UI設計師和工程師一起設計產品，不僅效果更好，也增加了隊友的參與感。但如此簡單的一個道理，在拆分成產品部、研發中心、UED這三個部門時，卻很不容易實現，被畫地為牢所困。你是提單找麻煩的，人家是接單擦屁股的，早點做完這一單再接排隊的下一單，誰跟你是隊友？
3、
蟬游家基本上沒有PRD……我跟工程師是老相好，我先出Axure原型，UI設計師用Skech轉成視覺稿，前端效果對著視覺稿講一遍，后端功能在Tower上列出來就可以了。工程師不明白的地方，隨時吼一聲，我隨叫隨到。這倒不是我懶得寫PRD，而是工程師懶得看PRD，反正PM是犬科召喚獸，隨時叫過來當面講解，遇到有爭議的需求當場討論，立即修改，自然比看文檔舒服多了。
雖然沒有PRD，我卻要寫測試用例。蟬小隊沒有專業QA，我就是QA。我的測試用例用Mindjet來寫，相當之簡陋，但覆蓋了全部的測試分支，且層次清晰。寫用例對于PM整理思路大有益處，經常發現一些漏掉的功能點，又能實現PRD的存檔價值。
更重要的事情是PM自己來做測試，通過測試流程，逼著PM反復使用產品，反復把玩每一個細節，反復體會是否達到了設計時的用意，然后快速修改細節，調試到滿意的地步。指望設計稿“一步成型”是不現實的，總有設計時考慮不周全的地方，在真實使用中才能找對感覺，而測試就是對“真實使用”的模擬。
我經常會遇到這么一類情況，某個交互細節，測試時第一次通過這里，隱隱覺得不對勁，但又講不出來。第二次，第三次，第四次，第五次，終于別扭得受不了了，然后才能總結出來，哦，原來是這個原因，改改改。如果我沒有兼任QA，僅僅是最終驗收，就沒有這種“反復把玩”的機會，停留在“隱隱不對”的認知盲點上，無法找到答案。
所以我有一個粗暴的觀點，PM不愿意兼任QA就是偷懶。雖然專業的QA能做更細致，更偏僻的測試，也能做PM搞不定的技術向測試，但即便有了這份保險，PM還是應該親手測試，在產品發布前給自己一個發現與改正錯誤的機會。
4、
蟬小隊在產品調試階段高度依賴Tower。先開好項目，比如“蟬游攻略iPhone版”，按產品模塊創建十幾個任務分組，然后在分組里填寫功能需求與產品bug，每項建一條任務。需求和bug混在一起，再用#1.2來作版本號標記，用！來做優先級標記。由于在一個頁面上平鋪開全部任務，排序整潔，又有分組與標記的索引，看上去十分清爽。
隨后工程師篩選出自己名字下的任務，把當前版本的任務全部清掉，有問題就回帖(進入編程狀態后他們懶得理我)，最后通知我去驗收。我把已完成任務挨個測一遍，發現沒達到要求，就備注一下重新打開。整個過程行云流水。
每一個大版本，當Tower上的任務從100+減少到0，版本就完成了。我不愿意設置嚴格的deadline，如果時間卡得太死，會影響工程師的情緒，急著做完，而不是和我一起耐心調試細節。版本發布早兩三天，晚兩三天很重要嗎？我覺得不重要。大致保持一個月一個版本的節奏就好了，為了趕半周時間搞得情緒緊張，很劃不來。
5、
有人在微博里問我，如果PM兼任QA，如何有時間準備下一個版本的PRD呢？
不不不，我這邊根本沒有“準備下一個版本的PRD”這個環節。
剛才講過，我習慣把需求和bug混合寫在Tower上，按產品模塊分組，這里的需求既包括當前版本，也包括后續版本。我想到任何值得做的產品點，立刻發布成Tower上的一條任務，把Tower變成需求池。而工程師只管當前版本號下的任務，沒標記版本號的就略過不看，再加上我會按任務優先級拖動排序，即便一個項目里堆積了上百條任務，看上去也不會顯得凌亂。
因為我是個急性子，哪怕是很久以后才能排上的需求，只要我有空，就會提前把原型畫出來，提前拉工程師、UI和運營過來討論確認。于是我會有漫長的時間，對原型設計進行反芻，在開發之前發現各種改進的可能，同時也將每個版本設計分解到碎片時間來逐一解決。
既然需求與原型都已經搞掂，在一個版本，比如1.2版本研發的開始階段，我只需要花10分鐘，把Tower上的未完成任務看一遍，給其中一部分標記下一個版本號，比如#1.3，再請UI設計師出圖。這樣當1.2版本完成后，1.3版本的視覺稿已經準備好了，我跟工程師當面講一遍1.3的需求，研發開始，無縫銜接。
6、
我就知道，這篇經驗總結到最后會寫得跟Tower的軟文一樣。雖然我跟Tower的老沈很熟……但確實沒收他的錢，不僅沒收錢，我還往Tower賬戶上匯了2000多元買付費服務。以我現在對Tower的依賴性之強，他家的服務一旦掛了，簡直天崩地裂如喪考妣。蟬小隊除了產品協作之外，運營管理，編輯管理，行政管理，甚至包括團建，全部通過Tower來進行。我最近空降到一個項目組，就連“空降過渡”這種事情也用Tower來潤滑，效果奇佳。這時你一定很好奇，空降就空降，和Tower有毛關系啊？很久很久以后，我再寫文章來講這個故事吧。
