分類
管理

成本20億->270萬日圓,只需一個點子?是神話與管理陷阱!

這新聞在講東京都營地下鐵如何省下台幣4億2千萬,變成57萬就能完成,像台北捷運那種月台閘門系統的「職員創意神話

不可否認,在車門上有QR CODE,然後透過月台掃描,確定車到定位後就開閘門,確實很有創意,但待過大企業或公部門的都知道

職員創意大多數時候是沒用的!

我所謂的沒用是指「不會實現的機率很高」!因為變革和採用新方案,伴隨而來的挑戰是很多:

  1. 質疑聲音很多(外觀太醜! QR因為玻璃髒掃不了?)
  2. 替代方案很多(司機員、月台人員 或 行控 按開就好? 畢竟肯定還是有人去決定關門)
  3. 出問題誰能負責?負的了責嗎?

相信這些問題,內部都會討論得很激烈,因為曠日廢時爭執不下,除非一定要改不然最終通常會維持原狀

假設勢必得改那會用哪個方案?

現實世界中難有絕對最佳方案,只有存在「主事者認可的方案」,這個方案還是職員原本的想法嗎?其實通常是被加油添醋過的版本吧,為了這版本可能又開了幾十次會與花了大量驗證可行的成本

但最可怕的是,這種「創意神話」都「刻意忽略了 溝通與驗證成本」!

我相信20億日圓的絕對是成熟的解決方案,而所謂的270萬(台幣57萬)方案,則明顯拿來付5個人開會的薪水都不夠,更別說投入驗證

不管 研發創新 或 推動執行 都很燒錢,把這些實際發生但又可隱藏的成本 刻意忽略後,就會打造出「職員創意神話」,即使那並不真實,但卻是很好對外宣傳的故事

而後別家企業或機關主管看到後,就會覺得「人家員工有用,我家的只會燒錢動作又慢」很氣

殊不知其實大家都差不多,只是自己對外的神話包裝時刻還沒到而已,外國月亮沒有比較圓,看清內部現狀穩定去做

別傻傻的以為群祖傳這些神話會激勵到員工,誰細算都會發現水分有多少,反而打擊士氣得不償失

神話當茶餘飯後話題笑笑就好😄

新聞原始網址
https://tech.udn.com/tech/story/123153/7585459

分類
信賢經驗談 管理

專案管理轉型困難的解方-發酵式管理學

從土法煉鋼到預測式、Scrum、Kanban…上了數萬起跳的各種專案管理方法拓展了管理思維,但得到更多的是難以推行的挫折,你精心為團隊設想的方法很好,但你需要加上「發酵式管理學」,讓你真的能推動轉變

分類
信賢經驗談 管理

從麵團學專案管理

成功的專案都是從一團亂開始,「做麵團」是最能具體體會這「從充滿懷疑到專案完成」的演進,讓我們來場「可以吃的專案管理Workshop」吧!

分類
信賢放棄學 信賢經驗談

成功的臨界點,解決習慣放棄 | #聰明不是關鍵 #史丹佛心理研究 #臨界點理論 #信賢經驗談

非常聰明才能成功嗎?史丹佛大學的65年長期研究顯示並非如此!讓平凡人成功的關鍵其實有更多因素。

大家都知道只要放棄就一定不會成功,但你可能不知道放棄的原因通常不是因為太困難,反而無聊、沒看到成效才是放棄的最大原因。

有足夠成效通常就有動力堅持,因此重點還是能不能看到成效,但大家可能更好奇的是「要多聰明才能夠成功」?

成功不用超聰明-臨界點理論 Threshold Theory

史丹佛大學心理學教授推孟(Lewis Terman)是 20 世紀教育心理學的先驅,在1921年開啟了<天才的遺傳研究>計畫,之後的65年追蹤結果證明:

高成果 = 高於門檻的水準 + 持續實踐

簡單說就是不用極度聰明,只要能跨過該項目的基本門檻,剩下的關鍵就是執行的夠不夠熟練

成效總在突破臨界點後

高成果的要素之一是「高於門檻的水準」 但這裡並非狹隘的指智商,假設要追求的是健康人生,相信不用太高的智商,要考量的因素還有:

  • 可以做的活動
  • 時間
  • 強度
  • 飲食
  • 休息

不同項目會有不同的標準,重點不在有哪些共通項目,而在「達到臨界點的量」,也可以稱為「推動改變的動能」,更簡單說「做多少才有成效」。

看到高成效才繼續,讓你無法成功

只要有努力,改變在看到成效前其實已經開始,只是通常「沒有察覺」或「沒法流暢使用」。

以要流暢用英文Email溝通為例:

  1. 學習英文沒學完26個字母,就無法拼出所有常用的單字。
  2. 不知道常用的單字,就很難了解英文使用者書面的意思。
  3. 無法了解意思,就不可能流暢的用email溝通。

因此一個英文字母沒背好的人,以「流暢使用英文做Email溝通」為目標,是難以看到成效的。

成效=成功的臨界點

成效強力驅動我們堅持,因此我們可以把「成效視為成功臨界點」或直白說就是「可觀察點」。

在達到臨界點前,怎麼累積都不會有明確的效果,而這是因為我們「累積的改變動能還未超過臨界點」,自然看起來沒有前進。

此狀態一久人自然就會想放棄,畢竟總是有其他的選擇,但頻繁轉換就不會成功,越來越沒自信淪為失敗主義者。

秘密在於適當的目標

笨蛋才只把目標訂在改變世界!我們可以改變世界,但改變世界是史詩級的目標沒法一步達到,中間要有階段,越明確的階段,你就越容易完成目標。

假設我們要改變世界拆分可能像:

改變世界->1000萬人被影響->…省略…->30個學生->社區大學教課->主動去投課->準備課程->列課綱->少看部影片

但常見的失敗點在於,一開始規畫得太細,花太多時間規劃沒去執行,執行後才發現很多計畫都會需要調整。

目標的正確拆分方法

正確目標的拆分方法,我在Youtube影片「科學化改變人生」中有詳細說明,想知道的朋友可觀看下面影片連結,從90秒開始直達拆分必須了解的部分,讓你10分鐘就能掌握正確的觀念。

成功關鍵就是正確拆分與堅持執行

我們都會遇到一面「無形的牆」,讓我們懷疑自己是否聰明到能成功,但從65年的長期科學研究知道「聰明到可以達到平均水準」,後面就是堅持的問題了。

正確的拆分目標,讓你看的到成效但又不至於沒挑戰性失去興趣,只要掌握好這點,堅持就容易多了。

獻給一直努力付出但沒有看到成效想放棄的朋友,加油!成功有臨界點,你的努力並沒有白費,我們堅持累積下去,總有突破的一天

===========
如果對您有幫助,歡迎請信賢喝杯咖啡
https://ko-fi.com/hsinken
Hsinken吳信賢
FB專頁 https://www.facebook.com/hsinkenfans
Youtube頻道

https://www.youtube.com/channel/UCgxttCHEA4-El2x3tMcjnFg
Apple Podcast 
https://podcasts.apple.com/podcast/id1530132764

分類
管理

用程式邏輯了解OKR

OKR是Google和Linkedin使用的管理方法論,由 Intel的「葛洛夫」提出,經「杜爾」帶入Google後廣為使用。

OKR = Objectives & Key Results

本篇的重點在於OKR與程式建構的關係。

系統在進行開發語言選擇(C#、Php…)、範型選擇(paradigm)與物件化規劃(Object Oriented )後,會開始設計函式

函式是程式間重要溝通單位,決定功能是否能完成的關鍵!

系統是團隊共同打造的成果,由每位程式分工後依特定流程呼叫彼此函式組成而來,類別名稱亂取會造成維護上的一些問題,但函式不能正確運作,那系統是絕對會停擺,因此非常重要。

我怎麼設計一個複雜的函式?

1. 我會了解函式的目的,通常那代表產出(output)。

2. 思考用什麼方式來獲得要產出的內容?

3. 依據採用的方式,我會評估呼叫函式時參數給的夠不夠?

4. 輸入不夠的參數是否能在函式運行中取得?例如:從DB或設定檔取得。

5. 若無法取得足夠參數視情況選擇其中一種解法:
A.解法1:選擇新方法,重新2~4流程。
B.解法2:與其他工程師協調,讓傳入時有此參數。
C.解法3:功能無法達成,重新規劃。

6. 分析重要檢核點,例如:電子簽章
A.資料、格式、順序是否正確?
B.簽章用Key否能取用與是否正確?
C.執行簽章中是否出錯?
D.檢查簽章值與範例值是否相同?

最後我就能開始執行、並在執行中提早確定能否完成與最後交付正確產出

程式邏輯與OKR關係

聰明的你一定已經發現,OKR(Objectives & Key Results)的:
1.O就像我們函式的產出
2.KR則像建構函式的第六步-分析重要檢核點

一個大系統或目標都可以經過比較小的OKR去逐步建構與檢核,只要檢核點都能完成那基本上功能80%都能完成,不行的話也能提早檢視問題做出求助或修正。

因此檢核點的設置非常重要,務必做到正確的分析並優先完成,如此你將更容易從容地完成目標。

延伸閱讀

若你有興趣更進一步了解,可參考:
OKR:做最重要的事 – 約翰.杜爾
<博客來介紹與購買連結>

一次讀懂 Google、Linkedin 都在用的 OKR 目標管理法
<想快速了解OKR,請參考 經理人雜誌 專題>


——
喜歡這篇文章有什麼想法或進一步討論或想看看我創作的其他內容
請點擊我的FB討論區連結
HSINKEN 信賢粉絲頁
https://www.facebook.com/hsinkenfans