先肯定一個前提，你作為PM，你的工作你的決策你的制衡你的項目行為都是為了讓項目按時按量更好更快完成。所以不論對項目團隊還是虛擬團隊的控制，都應如此。當然特定環境下你可能要考慮立威、拉攏、人際制衡等項目之上的問題。但若沒有，請不要熱衷於鬥爭，你不是來尋求尊重的。不説PM的職業技能，只針對團隊管理説幾點。
1、瞭解美術/前端/後端工作原理。
如果你知道美術設計主菜單懸停二級的不規則投影會浪費前端大把的時間調試，你還能想像前端看到了多難過，你就及時建議改用規則統一透明度的投影。如果你知道後端用for循環輸出 20條左右結構的新聞列表，你就讓前端用css控制自動左右佈局，而不是左右拆成兩份。他們去到其它團隊時，會懷念你的。
2、給團隊成員足夠的信息和空間。
這三個職業都不是工具，尤其後端攻城師。再初級的程序員也會嚮往人月神話，他們能為你提供合理的高效的架構設計。你要給予他們足夠多的信息，給他們留出恰當的時間，讓他們完成合理的架構。前後端工程師大多對複用和高性能保有成就感，你儘可能提供多的信息，由他們來處理。這也是為他們後期維護和迭代提供便利，你不要有所保留!如果你真的思維不縝密，藏不住的，最後連朋友都交不成。
3、勇於溝通和學習。
工程師跟你説以後用velocity來編輯頁面，你不理解，那麼就問。如果他鄙視你，那麼是他的問題，也可能是你的問題。大多數工程師願意給你講解的，他們也害怕表達，這是雙方的修為。
如果工程師説必須從mysql換成oracle了，你問為什麼，他説無法承載了，你問要多久，他説要兩週，你崩潰了但是問為什麼，他説要寫數據轉換腳本，你問為什麼，他説兩個數據庫之間數據類型不同需要有一些轉換，索引規則也不同，你問什麼是索引……這都是可以的，你要帶着學習的心態而不是問責，否者他越答越反感。最後你若懂了，他會覺得你理解他。
4、小心處理需求變更。
這是個永恆的話題，出了各種凡客體愛情買賣體來鄙視需求變更。你可以坦誠表達：需求變更是難免的，是不斷探索和調整而來的，作為PM我自認無法一次性想到最好，很抱歉。
接着就是技巧活了，原則是儘可能避免反覆修改。如果有一個頁面的'數據呈現，你無法想象怎樣更好，你可以用chrome開發者工具先去調整查看，別直接讓技術修改並當作你的參考。如果你不會用工具可以去學，實在複雜你就懇請技術輸出兩份效果給你比對，而不是改了説不好再改回去。
第二點就是，如果有的數據呈現模塊要裁剪，但有可能日後換個形式換個地方呈現，你就要跟技術説明白，讓他只是註釋暫時隱藏。你不知道一個簡單的數據呈現它用了緩存還是別的什麼。
5、成就感是你能給予的共鳴。
你要知道各位同學都在意什麼，物質需求可能你無法給予，吃個飯之類的其實是順理成章，不必刻意。各位同學踏入互聯網江湖，大多想在各門個派混出個名堂。如果你有機會，不要吝嗇這樣的稱讚。代碼註釋，產品主創介紹，向上彙報各同學的技術成果，鼓勵同學往各渠道分享技術心得。同時適當認同各位在架構性能上的新想法新思路，包括交互體驗上也應該給前端人員發揮空間如果他們願意。
其實最根本的，你要熱愛產品並竭盡所能，產品的受眾範圍和影響力是個天然的成就感。
6、勇於擔當。
你多承擔一些考核壓力和物質壓力，同學們才能更有精力投入到工作中。同為打工的你，能做的不過如此了。特別是當項目失敗時，怎麼可能跟你沒關係，該推的不該推的都不該推，早幹嘛去了?若出現項目成員能力問題和態度問題，儘早反映，説按此下去結果最好只能如何，把問題丟給你的頭。那麼他要麼換掉你，要麼換掉該成員。
