編輯導語：如何搭建一個高效的團隊是每個企業老板都為之苦惱的事情。很多事情從正面想不出辦法來的時候，從對立面開始思考或許會有新的發現。如何搭建一個低效團隊？這篇文章為大家總結了九個組建低效團隊的方法。感興趣的朋友一起來排排雷。

查理·芒格說：“反過來想，總是反過來想?！?/p>

排除掉錯的，剩下的更可能是對的，所以想要搭建高效團隊，不妨先了解一下怎么低效。

一、不說互聯網“黑話”就不要說話

日常用語會讓溝通太順暢，所以產品在工作中必須說“黑話”而且只能說“黑話”。配合不符合日常習慣的語法結構，務必要把需求方和研發繞暈。

貼心整理了一些互聯網“黑話”常用詞：

復盤、賦能、沉淀、倒逼、落地、串聯、反哺、能力、輸出、聚合、集成、抓手、拆解、打通、吃透、分發、輻射、復用、耦合、對齊、勾兌、方法論、耦合性、端到端、顆粒度、護城河、組合拳、點線面、全量投入、價值轉化、復用打法、資源傾斜……

舉例：

我們溝通下→（黑話）我們勾兌下

我盡量做→（黑話）我會全量投入

實際應用中，一句話不要只用一個黑話詞，至少要兩個。

舉個例子：

“從產品低耦合開發角度來看，當前X平臺配置應用較重，功能布局不集中，需要提高業務線基礎業務層的產品支撐能力，聚合基礎業務管理能力”。

（人話版：X平臺功能不合理，需要改版）。

二、每天開晨會，1個小時起

冗長的會議是降低工作效率的不二法門，一定要掌握。

不要擔心會上無話可說，可以讓大家匯報手頭工作，挨個來，挨個挑錯，問得越細節越好。

反正沒人關心其他人在干什么，所以不會有人發現作為team leader的你每天在問同樣的問題。

借匯報名義，除了召開晨會，還可以召開周會月會。哦對，要讓大家寫周報，這樣就可以在周會上挨個念自己的周報，有效豐富了會議內容。

三、開會要叫齊所有人

按理說，大會定小事，小會定大事。

所以要想降低工作效率，必須開大會。

比如頁面上改1個字，這種需求也要聚齊所有技術環節（前端、后端、數據、測試……）和業務方。

不要怕別人問為什么改文案要后端參會，問就是以防出現產品沒考慮到的風險。

四、處理需求的流程越長越好

上面說的改文案需求，也要走處理需求的流程。流程越長越好。

怎么制定一個最長的流程呢？

需要你發揮學習精神，搜集所有專業書、專業文章，把里面推薦的流程節點都記下來，合并同類項后取并集（注意是并集不是交集哦，交集的話你就只能抓重點了，沒辦法降低工作效率）。

然后再加一些自己臆想出來的流程節點。

舉個例子（示例流程極繁瑣，出于人道考慮，建議直接跳到第五個建議）：

1. 收集需求

必須走郵件或OA，而且要有窗口期，比如每周一收集需求，其他時間不認。

需求郵件要嚴格按照模板填寫，必須附上MRD（市場需求文檔）和重要性評估文檔（用來說明這個需求為什么重要和有多重要）。

如果一個需求方有多個需求沒有被處理，要讓對方把自己的需求先排個優先級。

假如你的需求方剛好有一些不擅長文案工作的，比如施工團隊，恭喜你，可以從源頭消滅很多需求。

2. 需求準入

拿到MRD和重要性評估后，產品先去和技術溝通，生成SOW文檔（工作說明書）。

SOW是從產品的角度再把需求描述一遍，根據和技術的“勾兌”提出一個粗略的產品預案。

注意要粗略別涉及細節，因為還要給接下來的PRD（產品需求文檔）留出存在空間。

有了MRD和PRD，還要在中間插入一個SOW是挺尷尬，但是也正好能讓團隊花更多的時間在文檔上，把注意力從真正重要的事情上轉移開。

除了SOW，還必須跟技術拿到粗估的工時，細化到各環節的人天上。

把工時和重要性對比，一起作為某個需求值不值得準入的參考，沒有人會質疑這種操作的正當性。

有了以上文檔，聚齊需求方、產品、技術開需求準入會，用來決定哪些需求可以做（只是說可以做，不要涉及什么時候做哦）。

情況理想的話，一個準入會就能消磨一下午。

3. 需求排期

需求在會上準入后，開始寫PRD，然后聚齊所有技術去宣講PRD，讓大家各自報準確工時。

同樣，叫齊所有人開排期會，又可以愉快地消磨一個下午。

4. 開發

進入開發流程，產品退居二線，主要工作是盯緊各節點時間，比如開始、提測、上線等，每天跟進并匯報。

如進度有異常，請項目經理協助處理。

5. 驗收

產品先驗收，沒有問題后由需求方驗收；如果驗收有問題，走修復流程。

6. 培訓

驗收完成后，出培訓文檔，和上線郵件一起發送需求方。

同時召集宣講會，把新功能向所有利益相關方進行宣講。

最后，流程制定出來后，要發郵件給所有相關部門，再安排個培訓大會，要簽到的那種，目的是“勒令”大家配合。

由于流程過于繁瑣，總會有人落掉文檔、錯過窗口期，這樣就能名正言順地推掉了。

五、不要信任其他部門，不要為了提高效率分工協作

接到一個新需求，追問背景+看數據只是基本操作，“負責任”的產品，不管需求有多小，深度和廣度上都要挖掘到位：

深度上追蹤數據來源，廣度上厘清所有關聯項。

比如對某個功能，銷售有自己的建議，不要參考，一定要親自調研，最好能直接約談客戶。

再比如出現一個異常，開發有自己的解釋，不要相信，直接殺到最底層，自己去看服務器日志！

在你追殺式的“需求調研”過程中，需求方很可能臨陣退縮決定收回需求，可是一個“負責任”的產品不能半途而廢，畢竟深挖需求是政治正確，就算別人指責你抓不住重點也能反駁回去。

六、時刻準備免責和甩鍋

也別忘了免責。核心是“書面證據”：即沒書面證據的都不重要。

當別人質疑你時，就能以“之前沒溝通過”、“郵件早就發你了是你自己沒理解”“以郵件為準”之類的話術免責。

七、工作內容不能透明

設置重重帷幕，才有空間夸大自己的工作量和重要性。

比如，在某系統點擊一下就能完成的工作，只要對方不知道，就可以夸大成要一整天來處理的復雜工作。

八、閉門造車

業務提出來的需求先放一放，放飛產品自己的想象力去設計。

反正做什么、什么時候做，最大決策權在產品，不要讓對產品一竅不通的業務部門來干擾你。

耗費產研團隊大量精力做出來的東西，運氣好的話，能直接作廢。

九、團隊最好能異地辦公

有條件的，可以在不同城市分設辦公區，沒條件的，一個在海淀一個在朝陽也行，總之團隊能不在一起辦公就不要在一起，尤其是團隊leader最好和成員分開，例如leader在上海，其他成員在北京。

大家不見面只線上溝通，才方便摸魚。

最好經常出差。出差最棒的是路上花的時間也算工作，在天上飛來飛去即使什么產出沒有也可以讓自己顯得非常忙。

本文由 @羊小雙雙 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 pexels，基于CC0協議。