沒有「限制」,意味著沒有目標與計畫

沒有「限制」,意味著沒有目標與計畫

限制,對許多人來說都是一個負面詞彙,因為限制代表著約束,代表著邊界,代表著有許多事不能做。

有本書叫《美麗的限制》,書中作者希望人們正面地去看待限制,他在書中舉了一個簡單的例子,我覺得蠻貼切的,這也算是生活中的洞察。

如果在一個遊樂園裡,幅員廣闊,四週都沒有任何的籬笆或圍牆,你會發現多數人都會聚集在特定的位置上,但當你把人規範在特定的範圍內時,你會發現人們往往會在這個範圍的四處探索,籬笆跟圍牆其實就是限制,他限制了你的行動範圍,但可能反而讓你探索了更大的區域,這是一種有限制與無限制狀況下可能發生的現象,以下我從專案管理來敘說我的觀點,在無限制的狀況下你不見得能做出好的東西,反而當我們把一些條件限制住,你更能找出最好的解決方案,

沒有時程限制,你不會思考最有效率的方法;
沒有經費限制,你不會思考最佳而非最貴的解決方案;
沒有人力限制,你可能不會思考什麼樣的團隊組成與人數才是對的,你不相信人月神話,但你可能反落入人月神話的陷阱。

造一艘太空船

想像一下,老闆有一天跑來跟你說:「Gipi,你去做一艘太空船出來。」

身為專業的 PM,你一定會這樣問:「老闆,請問你製作這艘太空船的目的是什麼?你想解決什麼問題嗎?」

老闆說:「沒有,你就是把太空船做出來。」

你還會接著問:「有沒有什麼樣的功能是一定要做的?」

老闆說:「你就去研究一下別人的太空船有什麼你就跟著做就對了。」

你不死心,還想追問:「老闆,那你希望我什麼時候交貨?我大概可以動用多少費用?」

老闆說:「你看你什麼時候做好就什麼時候給我,經費的事情不用擔心,老子有的是錢。」

這個案例中,你會發現你似乎完全沒有限制,範疇、時間、成本都沒有明確的規範,完全的自由,想怎麼搞就怎麼搞,乍看之下很棒,但這其實是最糟糕的狀態

聰明的 PM 在此時會給自己先設定一些限制,例如兩年,20 億,弄一艘跟 SpaceX 一樣的太空船,然後去跟老闆說明你的計劃,只有把老闆的期待給釐清了你才會比較安心的往下做

缺乏限制,其實是沒有明確的需求

我曾經歷過幾個在無限制條件下所發生的錯誤結果:

第一個案例就是老闆跟主管說,人你儘管找,我不限制你 headcount,你把事情做好做到最重要,這主管聽了如獲至寶,開始大量的招兵買馬,人數大幅的增長了 3 倍,但 3 倍人力很理所當然的被要求要有更多的產出,此時這位主管才發現自己團隊的人力組成是有問題的

首先,原先應該是 50% senior 配 50% junior,但卻發現自己手下 junior 占了 80%,所以那些 senior 必須要花更多的時間指導 junior成員。

其次,做規劃的人力竟然多於開發的人力,導致一堆東西規劃好但沒有足夠的 PG 來開發,帳面上人數很多,但其實完全無法發揮應有的戰力,盲目招人的後果肯定就是要開始砍人了。

回過頭來想想,如果一開始老闆就設定了一個 headcount,這位主管理當會比較審慎的去確認每個晉用的成員是否符合團隊編制的需求,又假設老闆並沒有限制,這位主管自己盤點了工作量,幫自己設定了一個人力編制計畫,並依此計畫去招聘,那結果也會完全的不同。

第二個案例,老闆跟研發主管說想要搞一個社交平台,他的要求是「跟 facebook 很像就好,不用太複雜。」。

這位研發主管也很有種的接下來了,於是團隊就開始研究 facebook 的各項功能,探討功能性需求與非功能性需求,初步排了一個計畫是 20 人做半年可以推出第一個版本。

歷經半年,終於弄了一個跟 facebook 操作介面很像,功能性也幾乎相同的系統出來,demo 給老闆看,老闆問說:「好像少了廣告功能,然後這可以乘載 100 萬人同時上線嗎?」。

團隊緊接著又花了 3.4 個月的時間把廣告功能跟高併發的架構實現,再次端到老闆面前,老闆說:「好像比上次好一些了,壓力測試報告也有了,但我本來是想要把這東西做成企業跟個人都能用,可以把企業用的功能加上去嗎?」

再次接獲任務,團隊很快的又去研究了市面上 Enterprise Social Network 的功能特性,又花了半年多的時間把功能也做了上去,做好之後發現企業用的跟個人用的之間有很多的功能會發生衝突,所以再花了半年調整設計,終於才把企業功能與個人功能給清楚分開。

這個故事最後的結果是可以猜想的,一年多的時間,facebook 跟 ESN 的功能又有很大的進步,團隊又要開始追趕,而這個系統正式上線的時間始終未知,這是一個很典型的範疇蔓延,也可以說是初期並沒有設定清晰的目標,其實目標本身就是一種限制,告訴你我要的是這個,在這個時間發生

合適的做法應該是先確認老闆的目的,包含要解決的問題,需要滿足的需求,以及在企業經營上所處的戰略位置,何時要讓這產品上市等等,否則所有的投入可能都會有極大的誤差

上述兩個都是在我身邊發生過的真實案例,文章最後我們再拿專案金三角:範疇、時間、成本來結尾。

假設正三角形代表的是專案的最佳狀態,當我們沒有做任何限制時,你的時間可能會無限的延長、成本會不斷墊高、範疇會不停膨脹,這樣的專案多半收不了尾,要不就是最終長成了一個三邊極長的正三角形,這是很多大型專案的寫照。

但當我限制了其中一項,你雖然仍有可能會在其他兩項上無限制膨脹,但基本上你會受限於第三邊,會讓專案在一個比較可控的範圍。但當我限制了其中兩者時,第三個就被限制在一個特定範圍下了,此時你就必然要在這個限制下搞定專案;最好的是三項都定義的非常清楚,那案子就非常漂亮。

沒有限制,是所有人夢寐以求的,但這是對你最大的考驗,你必須要給自己設定清楚的目標,有計畫性的去把目標實現,而實際上,計畫也是一種限制,計畫讓你知道自己現在正在什麼位置上,接下來又要往什麼方向去。

用正面的角度看待限制,限制過多綁手綁腳,沒有限制則代表需求不明確,我們必須從中找到一個合理的平衡點。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

我讀麥肯錫的《注意力方程式》報告

我讀麥肯錫的《注意力方程式》報告

近期花了點時間閱讀麥肯錫的《注意力方程式》(The Attention Equation)報告,從中獲得了一些不錯的啟發,也跟大家分享這篇報告所提到的內容,以及我獲得的收穫。 報告背景 報告的內容大約是 20 多頁的原文,核心放在談論注意力方程式(Attention Equation)這個概念,那什麼是注意力方程式,為什麼麥肯錫要特別談論這個概念呢?首先我們得回到近幾年大家經常在談論的幾個概念: 1. 流量愈來愈貴,數位廣告的 ROI 持續下探。 2. 演算法愈來愈迷,多數的數位廣告媒介都被演算法給操控,不容易破解之虞,還經常更動。 3. 傳統的文字內容不再受到流量青睞,長影音也愈來愈沒人想看,反而短影音似乎成為新的流量王者。 過往我們在看待廣告或其他行銷媒介,或者進一步探討企業獲客(Customer Acquisition)的方式時,我們大多會談論自有媒體(Owned media)、付費媒體(Paid media)與贏來的媒體(Earned media)三者的比例,以及企業應該強化的重點。

By gipi
普通人悖論

普通人悖論

今天跑步時聽了一本書,書中提到一個「普通人悖論」。聽著有趣,因為似乎解答了我這幾年的一些自我認知的疑問。 「我們一般人....」 「對普通家庭來說....」 我們總看著成功人士的故事,閱讀那些不平凡的案例,可到最後,我們還是會回過頭來告訴自己「我們就是個普通人」。 我們渴望不凡,渴望能活出屬於自我的人生,但我們卻又認為自己無法脫離普通人的路徑。20 多歲出社會,謀得一份工作,接著兢兢業業數十年,從基層爬到高層,一輩子在職場上與人競爭。當我們看到那些跳脫這種路徑的人時,我們又說服自己「那是別人」、「那是獨特個案」。 我們心理渴望自己也能是獨特個案,但又不斷說服自己「我只是個普通人」。 這種心境,讓我們沒有勇氣去追求屬於自己的人生。 在聆聽這段時,為什麼我會特別有感觸呢? 在我今年撰寫的新書《用商業思維優化你的人生選擇》中我提到,每個人的人生都是獨一無二的。你不見得要像他人一樣功成名就才算非凡,你能做自己喜歡的是,成為自己想要成為的樣子,活出自己的人生,那你就是個非凡的人。 因為其他人很難活得像你這樣。 我內心是堅定相信這件事的。但我卻又經常在一些時刻,會將「我們一般人」

By gipi
如何快速熟悉一個產業?

如何快速熟悉一個產業?

什麼是產業,什麼又是行業? 有人會說電子業、食品業,也有人會說製造業、零售業、服務業,這兩者指的是相同的概念嗎?其實這邊隱含了兩個概念,也就是業種跟業態。 業種,是行業種類,以販售的「商品種類」區分所屬行業。例如賣建材的建材行、賣文具的文具店、賣水果的水果店或賣米的米店等。這些業種店看招牌名稱就可得知該商店販賣哪種商品。 業態,是行業型態,則是以該店家的「經營型態」區分所屬行業。例如提供即時、方便服務的便利商店;提供專櫃及流行品的百貨公司;提供量大、低價的開架式民生消費品的量販店等。這類商店,無法從其名稱辨別產品。通常是提供「一站式購買服務」為訴求,並提供其他相關的附加服務。 典型的業態,其實分兩大類,製造與流通。製造商負責製造產品,流通商負責將貨物流通到消費者手上,並因應消費者的需求,擴大產品品項,增加服務,而大家常講的零售與批發,其實也歸屬於流通範疇中。 舉例來說,生鮮食品經生鮮處理中心,將生鮮品分類分裝,這是製造的範疇,大盤商集中所有產品,

By gipi
當 vibe coding 已成必然,軟體開發會有什麼變化?

當 vibe coding 已成必然,軟體開發會有什麼變化?

當 Vibe coding 興起後,有愈來愈多的資深工程師的工作重點轉換到修復 AI 寫出的各種 bug。因這個現象,有些資深工程師們打趣地說,他們現在的任務像是專門處理這些 vibe coder 寫出來的爛 code。而這個職務稱為 Vibe Coding Cleanup Specialist。 我個人絕對支持 vibe coding,因為這是軟體開發的典範轉移,用得好的話可以大幅提升生產力,加上 AI 顛覆職場的趨勢幾乎不可逆。擁抱變化會比抗拒變化更明智。 這讓我回想起 2005 年剛出社會時,因為我起步的程式領域是 C#.net,使用的開發工具是 Visual Studio。C# 的好與壞我就不提了,但在當年,Visual Studio 這工具被稱為地表最強 IDE 應該是沒問題的。 它有多方便呢?所見即所得,元件直接拉到畫面上,出來的畫面就長那樣,

By gipi