起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識手把手教你組建一個低效產品團隊
編輯導語：如何搭建一個高效的團隊是每個企業老板都為之苦惱的事情。很多事情從正面想不出辦法來的時候，從對立面開始思考或許會有新的發現。如何搭建一個低效團隊？這篇文章為大家總結了九個組建低效團隊的方法。感興趣的朋友一起來排排雷。
查理·芒格說：“反過來想，總是反過來想?！?/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協議。
哈哈哈哈另辟蹊徑，思路清奇，但是我喜歡?。?！
小公司。
不一定，有的小公司效率相當高
但是，有的大公司集體摸魚反而不易被察覺
可以說是絕絕子，無數畫面回閃在眼前哈哈哈
我懷疑，你在寫你的經歷哈哈哈哈
哈哈哈 這樣的公司要火速逃離
說黑話哈哈哈，所以還是要多用用專業術語，顯得高大上一些是嗎？
不管工作還是生活，想要提高溝通效率都應該使用對方容易理解的語言。專業術語有時候不得不用，比如在找不到精準替代的時候，或者雙方都更容易理解的時候。但是滿口莫名其妙的黑話，我感覺主要因為說話人沉浸在”我是互聯網人“這種人設里。
哈哈哈哈哈，還真是另辟蹊徑，說的太好了，點贊點贊，
這不是很多公司日常嗎
能一次性滿足文中9項的公司，也不是凡司。
文章實用性是真的強。
引以為鑒吧，文章真不是杜撰出來的。有時候現實還會更夸張。
絕了
點贊
作者說的太對了，真優秀，但我好想罵死了他，哈哈哈哈
你過分！哼
絕了絕了