本文近3.8千字，來自跨界學習
“君子生非異也，善假於物也。”——荀子
曾經，遇到團隊中的兩個問題：
一個是：發生bug之後，每個領導都在羣裏問來問去表達關心，結果擾亂解決問題的主線進度（或者是不懂，或者是刷存在感）。
另一個是：一些具備項目屬性的大“需求”，上游直接丟給下游（一羣人），缺少項目儀式感和明確的責任歸屬指派。
這兩個都會導致事倍功半！且團隊越大，效果越差！
“人效工效”提升的基本保障，是要有規範的制度。
你看宇宙星辰燦爛，但只要恆星給行星軌道，就能吸引對方並有序運轉！
否則任何一個芝麻點大小的問題，都經不起“成本放大效應”，甚至引發“集羣效應”！
那麼容錯率要求更低行業，比如建築行業，是怎麼“正向”和“逆向”面對類似問題的呢？
今年二月，意外參加了“二級建造師”考試。學習中，感覺跨行業的一些方法，完全可以複用到互聯網中。
荀子說“君子生非異也，善假於物也。”詩經說"他山之石，可以攻玉。”
本文從項目思維切入，分享這段學習備考後的感受！
原文出處：公衆號 jjyypm
01
“項目思維”是古老的智慧
前214年（秦始皇三十三年），一項即將歷時5年的，極爲雄偉的防禦建築工程——“萬里長城”的修建拉開序幕。
利用地形，沿黃河、陰山，材料就是生土、黃土、夯土。
用今天“建築工程”的話說，建設方是始皇帝，工程總包是蒙恬，監理、分包單位，以及大量的勞務“分包”給了士兵、農民等等三十萬人。
這是一項充滿不確定性、風險、極大成本，卻又利在子孫的事業。
可以想象進展中一定在有意無意地摸索着最高效的項目管理方式，以克服內部外部的矛盾、惡劣的自然條件和外敵侵擾，以期儘快交付。
這或許是最古老的建築工程項目之一。
歷史如此相似，埃及的金字塔、古羅馬的供水渠、汴梁古城的復建，近代美國的曼哈頓實驗、登月計劃、阿富汗計劃、中國的08奧運會等人類恢弘建樹，都是舉不勝舉的項目案例。
項目，就是用組織思維，在有限的時間和資源下，冒一定的風險，幹一票獨特的大事。
項目管理，就是應對重大事件、複雜體系、難測風險等的有效管理手段。
項目化管理，是有意無意都在執行的管理標準。是一種循序漸進地持續優化資源配置的行爲。
02
各行業如何對待項目？
萬事皆可項目，三百六十行皆可項目思維。
互聯網行業剛起步的時候，管理管理主要還是用在傳統行業。
比如製藥行業。（我就是從藥物研發行業轉行的）。
在國外新藥專利到期的前幾年，就要做專利和市場調研，定下仿製品種項目，然後調研研發工藝、專利申報準備……藥品研發週期基本15年以上。
又比如現代的建築工程行業。
圍繞着五方主體（建設方、施工方、設計方、勘測方、監理方）的牽制和糾纏。
面臨較多的人身財產事故風險、隱蔽工程質量風險、爛尾風險、合同風險、物權債權風險、投資成本工程款風險等。
瞭解了其他行業，其實互聯網項目並不是最棘手的，但它有自己的難。
簡單分析互聯網項目的三個難點：
1、節奏快、週期短、人員變動高頻、影響範圍廣，人員壓力大。
2、信息的密度大，細節過多，存在轉瞬即逝的不確定性，溝通成本之高是前所未有的。這也是很傳統領域最大的區別。
3、雖然沒有“五方主體”，但是也林立各種角色之間的矛盾，或者權利不匹配，就連項目經理本身，可能都是產品經理兼任的。
產品經理是圍繞着需求展開工作，不斷調整決策，確保“做正確的事”。切換到項目經理角色，則是對整個項目負責，確保“正確地做事”。
而很多時候，很多公司就是這麼項目⇆產品混着用。
03
從“建築工程”項目中借鑑
建築領域的工程項目管理，與互聯網的項目管理對比，除了理論上的相通，比如“掙得公式”、“進度網絡圖”、“組織論”之外，還有很多工程管理的特色點，可以借鑑到互聯網項目管理中。
學習“建工”項目之後，感覺很受啓發，不少方法可以借鑑到工作中。開頭的兩個問題，也能找到答案！
1、“香蕉圖“
在工程網絡計劃中，如果按照工程網絡計劃中每項工作的最早開始時間繪製整個工程項目的計劃累計完成工程量或造價，即可得到一條S曲線（ES曲線）。
而如果按照工程網絡計劃中每項工作的最遲開始時間繪製整個工程項目的計劃累計完成工程量或造價，又可得到一條S曲線（LS曲線）。
兩條S曲線組合在一起，即成爲香蕉曲線。
如果接近ES曲線，那麼延期風險小，但是過早將資金投入進去，不利於資金最大利用。
反過來，接近LS曲線的，有延期風險，但是資金可以用於前期投資其他項目，可以實現最多資金效益。
在項目的實施中進度控制的理想狀況是任一時刻按實際進度描繪的點，應落在該"香蕉"型曲線的區域內。
所以並不是越早完成就一定是越好的。
在多個項目並行的矩陣式管理團隊中，資源平滑、平移，表面是爲了平衡各個項目，但本質也是“香蕉圖”的體現。
Tips：
在一次項目中，項目主管不斷催促一個定製項目，理由是能提前的爲什麼不提前做。
產品經理心知肚明，這個項目出力不討好，沒必要做那麼早。於是產品經理拿出了“香蕉圖”，很快就說服了項目主管：資源過早投入，不僅影響其他事項，而且會導致客戶不斷加需求致使“尋求膨脹”！
2、“監理”制度
曾經合作過一個互聯網團隊，百十號人的程序員，但基本從來沒人管理過代碼質量。
有次遇到一個表格功能，居然累積了三千行代碼，接盤的開發人員直接大叫“看不懂”。更別說接口“傳參”不過濾，返回冗餘等問題。
爲什麼就沒人關心下代碼質量呢？
反觀在建築行業，監理由第三方監理單位擔任，爲建設方把關，類似古代的監軍。
監理不參與施工，但是會監督施工。比如：
見證工人抽樣檢查、實驗取材的真實性、合理性。
旁站，監督“隱蔽工程”的工序是否合適。比如鋼筋籠是否扎呈“八”字型的，是否漏綁紮了。不然一旦澆築混凝土後，就難以檢查隱蔽處的質量了。
所以在正規的互聯網公司，代碼的質量監督也是一項大事。需要定期抽查代碼的質量，發現底層結構的風險，將監督到的問題彙報整理。
3、“四不放過”原則
在互聯網領域，“拼的是腦子，不流血”，但在建築中，人身、財產損失危險還是比較常見的。
爲此，規定了質量事故的“四不放過”：
事故原因未查清不放過。
事故沒有得到切實可行的整改結果不放過。
事故責任人未受到處理不放過。
事故責任人和廣大羣衆沒有受到教育不放過。
用在對互聯網產品bug或質量事故的管理原則上，是不是很合適啊。
4、工程量清單
工程報價的方式主要有三類，有固定金額，有的是“固定成本+酬金”，還有一種是按“工程量清單”。
“固定成本+酬金”類似於互聯網中的基本工資+項目獎金。幹完得越快、質量越好、成本越低，則獎勵越高。
“工程量清單”的話，那就是將工程，量化爲統一單位的數值。以此代表工作的多少。再定出單價。將來之後實報實銷。
在這個過程中，就有點類似於產品開發的工時制度。
工時制度的評判，有多種方式，比如制定最小顆粒度的工時規則，分解項目後執行；也有類似“德爾菲法”的撲克牌法，也就是背靠背評估出對該需求的工時，取平均數。
工時的好處是，量化工作難度，但要注意標準和經驗的客觀性。
只聽團隊成員一句“做不完”，往往是不可控的前兆，會讓項目變得無法把控。
5、施工流水節拍
建築的工序，比互聯網中更重要。每一個緊後事，都要求前置條件確認無誤。比如：
“基線找平—>基坑開挖—>坑槽驗收—>地基基礎—>綁紮鋼筋—>支架模板—>澆築混凝土”等等。
而大樓每一層、每一棟之間往往相似或相同，這就意味着：
各組人馬可以按計劃依次進場；
可以實現多班，輪流施工；
於是理論上就可以得到儘可能不“窩工”的橫道圖，如下圖：
這種流水節拍施工計劃表，一目瞭然。不管用在互聯網多團隊項目還是其他工作中，都大有裨益。
6、“專家論證”
一些在其他互聯網團隊中可能比較成熟的功能，換個團隊做得很慢。
原因是程序員單兵作戰的情況下，遇到技術問題沒有及時組織技術評審或技術攻堅。
導致實現方案繞彎路，技術落後，或者自以爲觸摸到了技術瓶頸。
而在建築領域，也是有很多工藝和技術的，比如混凝土模板中就有“爬模、滑模、飛模”等設備，施工中有“泥漿護壁鑽孔”技術、“二次抹面工藝”等。
建築團隊會制定標準，滿足標準的必須組織專家論證，比如“四新”（新工藝、新材料、新設備、新技術），比如水下工程、5米以上深挖基坑、50米以上的幕牆工程等。
同樣，在開發技術團隊，也應該有這種判斷標準。避免半小時的工作，去做寫兩天的代碼。
7、第一責任人
在工地上，第一責任人通常是工頭，也就是“項目經理”。所以明確的授權是一件很重要的事情。參考RACI模型。
太多的思維說明這個的重要性，比如：“羊羣效應”、“志願者困境”、“旁觀者效應”等
8、預驗收
在工程驗收階段，監理帶着施工方先驗收通過後，再找建設單位進行驗收。類比開發先自測。
9、不越級彙報
工程的總承包，將任務分包給分包單位的情況下，分包很多時候不能直接和建設方（出資人）彙報。類似的情況很多，這種規範讓事情有序，避免不必要的麻煩。
10、主體工程不能分包（鋼結構例外）
主體是建築中最核心安全係數最高的部分，這部分必須由總承包方完成，來倒逼確保項目的質量有保證，縮短干係主體鏈路。
小結：
借鑑其他領域的知識理論，有時候是“雜交優勢”。
除了建築上上述之外，我還常常用醫藥上的“質量過剩”表達產品的冗餘功能，類似醫療的“過度治療”。用“循證醫學”對比用戶大數據碎片觀察統計等。
同時，互聯網信息技術也一直在輔助傳統行業。典型的如將“數字孿生”技術用於基建工程在修建高速公路、橋樑等基礎設施。完成數字化建模，評估工程。
跨領域理論的掌握，除了輔助自己把事情安排妥當之外，還有就是說服別人做理性決策。
正如俞軍說的，理性決策的前提是要把對方拉到和你一樣的知識水平，否則他怎麼也不懂你。
加號主，進產品微信羣
和一萬產品經理共拓職場可能