10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

0 評論 8701 瀏覽 8 收藏 17 分鐘

編輯導讀:工作中我們常會運用到項目思維,并運用它來管理我們的項目。本文從項目思維的起源,各行業對待項目的三個難點,以及從建筑工程中借鑒到的十種方法鋪開陳述,來展示互聯網項目的跨界方法論,一起來看看。

“君子生非異也,善假于物也?!薄髯?/p>

曾經,遇到團隊中的兩個問題:

一個是:發生bug之后,每個領導都在群里問來問去表達關心,結果擾亂解決問題的主線進度(或者是不懂,或者是刷存在感)。

另一個是:一些具備項目屬性的大“需求”,上游直接丟給下游(一群人),缺少項目儀式感和明確的責任歸屬指派。

這兩個都會導致事倍功半!且團隊越大,效果越差!

“人效工效”提升的基本保障,是要有規范的制度。

你看宇宙星辰燦爛,但只要恒星給行星軌道,就能吸引對方并有序運轉!

否則任何一個芝麻點大小的問題,都經不起“成本放大效應”,甚至引發“集群效應”!

那么容錯率要求更低行業,比如建筑行業,是怎么“正向”和“逆向”面對類似問題的呢?

今年二月,意外參加了“二級建造師”考試。學習中,感覺跨行業的一些方法,完全可以復用到互聯網中。

荀子說“君子生非異也,善假于物也?!痹娊浾f”他山之石,可以攻玉。”

本文從項目思維切入,分享這段學習備考后的感受!

一、“項目思維”是古老的智慧

前214年(秦始皇三十三年),一項即將歷時5年的,極為雄偉的防御建筑工程——“萬里長城”的修建拉開序幕。

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

利用地形,沿黃河、陰山,材料就是生土、黃土、夯土。

用今天“建筑工程”的話說,建設方是始皇帝,工程總包是蒙恬,監理、分包單位,以及大量的勞務“分包”給了士兵、農民等等三十萬人。

這是一項充滿不確定性、風險、極大成本,卻又利在子孫的事業。

可以想象進展中一定在有意無意地摸索著最高效的項目管理方式,以克服內部外部的矛盾、惡劣的自然條件和外敵侵擾,以期盡快交付。

這或許是最古老的建筑工程項目之一。

歷史如此相似,埃及的金字塔、古羅馬的供水渠、汴梁古城的復建,近代美國的曼哈頓實驗、登月計劃、阿富汗計劃、中國的08奧運會等人類恢弘建樹,都是舉不勝舉的項目案例。

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

項目,就是用組織思維,在有限的時間和資源下,冒一定的風險,干一票獨特的大事。

項目管理,就是應對重大事件、復雜體系、難測風險等的有效管理手段。

項目化管理,是有意無意都在執行的管理標準,是一種循序漸進地持續優化資源配置的行為。

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

二、各行業如何對待項目?

萬事皆可項目,三百六十行皆可項目思維。

互聯網行業剛起步的時候,管理管理主要還是用在傳統行業。

比如制藥行業。(我就是從藥物研發行業轉行的)。

在國外新藥專利到期的前幾年,就要做專利和市場調研,定下仿制品種項目,然后調研研發工藝、專利申報準備……藥品研發周期基本15年以上。

比如現代的建筑工程行業。圍繞著五方主體(建設方、施工方、設計方、勘測方、監理方)的牽制和糾纏。

面臨較多的人身財產事故風險、隱蔽工程質量風險、爛尾風險、合同風險、物權債權風險、投資成本工程款風險等。

了解了其他行業,其實互聯網項目并不是最棘手的,但它有自己的難。

簡單分析互聯網項目的三個難點:

1. 節奏快、周期端、人員變動高頻、影響范圍廣,人員壓力大

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

2. 信息的密度大

細節過多,存在轉瞬即逝的不確定性,溝通成本之高是前所未有的。

這也是很傳統領域最大的區別。

3. 項目?產品混著用

用雖然沒有“五方主體”,但是也林立各種角色之間的矛盾,或者權利不匹配,就連項目經理本身,可能都是產品經理兼任的

產品經理是圍繞著需求展開工作,不斷調整決策,確?!白稣_的事”。

切換到項目經理角色,則是對整個項目負責,確?!罢_地做事”。

而很多時候,很多公司就是這么項目?產品混著用。

三、從“建筑工程”項目中借鑒

建筑領域的工程項目管理,與互聯網的項目管理對比,除了理論上的相通。

比如“掙得公式”、“進度網絡圖”、“組織論”之外,還有很多工程管理的特色點,可以借鑒到互聯網項目管理中。

學習“建工”項目之后,感覺很受啟發,不少方法可以借鑒到工作中。開頭的兩個問題,也能找到答案!

1. “香蕉圖“

在工程網絡計劃中,如果按照工程網絡計劃中每項工作的最早開始時間繪制整個工程項目的計劃累計完成工程量或造價,即可得到一條S曲線(ES曲線)。

而如果按照工程網絡計劃中每項工作的最遲開始時間繪制整個工程項目的計劃累計完成工程量或造價,又可得到一條S曲線(LS曲線)。

兩條S曲線組合在一起,即成為香蕉曲線。

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

如果接近ES曲線,那么延期風險小,但是過早將資金投入進去,不利于資金最大利用。

反過來,接近LS曲線的,有延期風險,但是資金可以用于前期投資其他項目,可以實現最多資金效益。

在項目的實施中進度控制的理想狀況是任一時刻按實際進度描繪的點,應落在該”香蕉”型曲線的區域內。

所以并不是越早完成就一定是越好的。

在多個項目并行的矩陣式管理團隊中,資源平滑、平移,表面是為了平衡各個項目,但本質也是“香蕉圖”的體現。

Tips:在一次項目中,項目主管不斷催促一個定制項目,理由是能提前的為什么不提前做。

產品經理心知肚明,這個項目出力不討好,沒必要做那么早。

于是產品經理拿出了“香蕉圖”,很快就說服了項目主管:資源過早投入,不僅影響其他事項,而且會導致客戶不斷加需求致使“尋求膨脹”!

2. “監理”制度

曾經合作過一個互聯網團隊,百十號人的程序員,但基本從來沒人管理過代碼質量。

有次遇到一個表格功能,居然累積了三千行代碼,接盤的開發人員直接大叫“看不懂”。

更別說接口“傳參”不過濾,返回冗余等問題。

為什么就沒人關心下代碼質量呢?反觀在建筑行業,監理由第三方監理單位擔任,為建設方把關,類似古代的監軍。

監理不參與施工,但是會監督施工。

比如:

  • 見證工人抽樣檢查、實驗取材的真實性、合理性。
  • 旁站,監督“隱蔽工程”的工序是否合適。比如鋼筋籠是否扎呈“八”字型的,是否漏綁扎了。不然一旦澆筑混凝土后,就難以檢查隱蔽處的質量了。

所以在正規的互聯網公司,代碼的質量監督也是一項大事。

需要定期抽查代碼的質量,發現底層結構的風險,將監督到的問題匯報整理。

3. “四不放過”原則

在互聯網領域,“拼的是腦子,不流血”,但在建筑中,人身、財產損失危險還是比較常見的。

為此,規定了質量事故的“四不放過”:

  • 事故原因未查清不放過。
  • 事故沒有得到切實可行的整改結果不放過。
  • 事故責任人未受到處理不放過。
  • 事故責任人和廣大群眾沒有受到教育不放過。

用在對互聯網產品bug或質量事故的管理原則上,是不是很合適啊。

4. 工程量清單

工程報價的方式主要有三類,有固定金額,有的是“固定成本+酬金”,還有一種是按“工程量清單”。

“固定成本+酬金”類似于互聯網中的基本工資+項目獎金。干完的越快、質量越好、成本越底,則獎勵越高?!?/p>

工程量清單”的話,那就是將工程,量化為統一單位的數值。

以此代表工作的多少。再定出單價。將來之后實報實銷。

在這個過程中,就有點類似于產品開發的工時制度。

工時制度的評判,有多種方式,比如制定最小顆粒度的工時規則,分解項目后執行;也有類似“德爾菲法”的撲克牌法,也就是背靠背評估出對該需求的工時,取平均數。

工時的好處是,量化工作難度,但要注意標準和經驗的客觀性。

只聽團隊成員一句“做不完”,往往是不可控的前兆,會讓項目變得無法把控。

5. 施工流水節拍

建筑的工序,比互聯網中更重要。每一個緊后事,都要求前置條件確認無誤。

比如:“基線找平—>基坑開挖—>坑槽驗收—>地基基礎—>綁扎鋼筋—>支架模板—>澆筑混凝土”等等。

而大樓每一層、每一棟之間往往相似或相同,這就意味著:各組人馬可以按計劃依次進場;可以實現多班,輪流施工;于是理論上就可以得到盡可能不“窩工”的橫道圖,如下圖:

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

這種流水節拍施工計劃表,一目了然。

不管用在互聯網多團隊項目還是其他工作中,都大有裨益。

6. “專家論證”

一些在其他互聯網團隊中可能比較成熟的功能,換個團隊做的很慢。

原因是程序員單兵作戰的情況下,遇到技術問題沒有及時組織技術評審或技術攻堅。

導致實現方案繞彎路,技術落后,或者自以為觸摸到了技術瓶頸。

而在建筑領域,也是有很多工藝和技術的,比如混凝土模板中就有“爬模、滑模、飛?!钡仍O備,施工中有“泥漿護壁鉆孔”技術、“二次抹面工藝”等。

建筑團隊會制定標準,滿足標準的必須組織專家論證,比如“四新”(新工藝、新材料、新設備、新技術),比如水下工程、5米以上深挖基坑、50米以上的幕墻工程等。

同樣,在開發技術團隊,也應該有這種判斷標準。

避免半小時的工作,卻做寫兩天的代碼。

7. 第一責任人

在工地上,第一責任人通常是工頭,也就是“項目經理”,所以明確的授權是一件很重要的事情,參考RACI模型。

10個跨界方法論:產品用的上,啟發互聯網項目(含案例)

太多的思維說明這個的重要性,比如:“羊群效應”、“志愿者困境”、“旁觀者效應”等。

8. 預驗收

在工程驗收階段,監理帶著施工方先驗收通過后,再找建設單位進行驗收,類比開發先自測。

9. 不越級匯報

工程的總承包,將任務分包給分包單位的情況下,分包很多時候不能直接和建設方(出資人)匯報。

類似的情況很多,這種規范讓事情有序,避免不必要的麻煩。

10. 主體工程不能分包(鋼結構例外)

主體是建筑中最核心安全系數最高的部分,這部分必須由總承包方完成,來倒逼確保項目的質量有保證,縮短干系主體鏈路。

四、小結

借鑒其他領域的知識理論,有時候是“雜交優勢”。

除了建筑上上述之外,我還常常用醫藥上的“質量過剩”表達產品的冗余功能,類似醫療的“過度治療”。

用“循證醫學”對比用戶大數據碎片觀察統計等。

同時,互聯網信息技術也一直在輔助傳統行業。

典型的如將“數字孿生”技術用于基建工程在修建高速公路、橋梁等基礎設施。完成數字化建模,評估工程。

跨領域理論的掌握,除了輔助自己把事情安排妥當之外,還有就是說服別人做理性決策。

正如俞軍說的,理性決策的前提是要把對方拉到和你一樣的知識水平,否則他怎么也不懂你。

#專欄作家#

唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產品經理專欄作家,2019年年度作者?!逗蠖水a品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型后臺體系,社交APP。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!