hiddenImg
使用者大頭照
Arthur Chiu
科技研發管理
顧問

  1. 22拍手
  2. 0受邀回答
  3. 0粉絲
  1. 拍手22
  2. 受邀回答0
  3. 粉絲0
關注
邀請回答

顯示較少

擅長能力

未填擅長能力

擅長能力

未填擅長能力

Arthur Chiu

  1. 回答33
  2. 發問0
  3. 關注0
  4. 粉絲0
  5. 肯定7
Arthur Chiu
科技研發管理 顧問
不知道這部門主管的專業,是不是真得如此不堪,但類似的描述,在一般工程師的口中,倒是常常聽到,相信不會是個案。 有沒有想過,從不同的視角,解讀的方式也許會大相逕庭?部門間溝通需要彈性,這有助於整體團隊合作效能。但主管不堅持己見,以全局為重的作法,也有可能被誤解為態度軟弱,不懂為自家團體多做爭取,總是退縮,加重自家人工作負荷。我們且試著以公司的立場來看,會比較嘉許以團隊合作為優先的團隊,還是以自身福利與工作量為優先的團隊? 主管對內要求技術專業,或許會被懷疑只是唱高調,但可比得過且過的主管好多了吧。舉個例子,曾看過一些機構團隊,覺得應付工作要求已綽綽有餘,但實際上不重視公差控制,設計時從不用工具軟體精算公差,導致經常得在產線進行二次重工。這樣的隱形成本,即使外界非專業人員看不出來,主管卻得要有擔當推動改善,增加產品競爭力,才對得起主管這職位。 團隊若成長到一定規模,容易出現三個和尚沒水喝的毛病,這時管理就顯得非常重要。主管職責包括盡力了解團隊,發現潛在問題,並協助所屬人員不斷成長。非關工作的個人對話,的確有助於建立關係增加互信,但職場實務上,主管與所屬員工間的關係,並不見得一定得是好友,不常聊天也算正常。(就像同事間共事,也不見得得先當好友啊) 好的公司自然會成長,16年前後相信已有很大的不同。建議換過角度,重新想想再做決定,終究適應變革始終是職涯上的重要課題。
Arthur Chiu
科技研發管理 顧問
會這樣問,猜想您的狀況應該是,多半對現有工作不甚滿意,但也還沒到完全過不下去的程度;另一方面,找到的新職位雖輕鬆了些,但對福利和發展方面仍有些顧慮。 試著換個思考的面向,(且先不考慮運氣這回事)如果能爭取多一些職位的選擇權,裡頭總會找到在福利和文化上都比較適合的吧? 如此就不必總是在糾結魚與熊掌的問題。或者說得更露骨些,不必一直屈就於不太滿意的雞肋選擇。甚至機會都有可能自己來敲門拜訪。 想要能夠如此,這道路簡單的說,就是累積實力抬高自己身價。憑藉年資累積的“資深”只是稱謂,不見得代表在業界的實力,換工作不見得能拿到原有待遇。不妨仔細觀察看看,非常優秀的PE會提出什麼創意的改善措施、能如何提昇稼動率?公司都會有歷史,查查看前人的成就、專利、獲獎勵記錄,應該就能明白努力成長的方向在那裡。 總而言之,提升職能是不二法門。建議您要常常盤點,履歷上能多出那些擲地有聲的記載,這才是職涯選擇上該優先考慮的項目。福利、壓力,相較之下,比較不是可以單靠自己來追逐的。 共勉。
Arthur Chiu
科技研發管理 顧問
先做簡答:是的,您該高興有這樣的機會。 組織管理的實務上,從內部拔擢新幹部時,藉由代理新職務一段時間,觀察績效再扶正,這是經常套用的模型。其實這麼做對各方都好,不見得是單純摸頭壓榨。 且試著理解看看,假設啊,真的只是假設啊,您初次嘗試管理工作,薪水也直接調升,但萬一短期內沒能適應好,部門運作不順,想想上層主管會怎麼做?若是減薪降職,您丟了面子,甚至於一氣之下走人,將成兩敗俱傷之局;若是置之不理,單位績效不好看、基層士氣低落,也是難收拾。 那如果先給機會試試呢?真能不適應時,調整工作內容就好,算是平調,比較沒面子問題,這樣對大家衝擊都小一點。如果順利漸漸適應,從代理階段變成正式職位(此時當然該加薪),則皆大歡喜。 此刻,您可以與上層溝通,代理主管的期間長短,轉正的標準,該設定個目標吧? 不同組織文化裡,這期間的確會有蠻大的差異,但一般來說,建議可以是三到六個月,最長最好別超過一年。 直接攤牌,要求調薪行不行?得先要衡量您對新工作的把握度而定,也要視上層的風險管理風格。這是比較不建議的做法,成的機率難料,也可能留有後遺症(造成事事計較的負面印象);萬一不成,到手的機會也許也不一定抓的牢。
Arthur Chiu
科技研發管理 顧問
您列出的三項,不是需要擇優的選項,更像是三種情境、面向,互不衝突,也不會同時發生,但是都該考量。 1. 跳槽。先問自己要追逐的目標為何,現有環境的養分還夠不夠,適應新環境勝算還行嗎?其實不管是換工作或換公司,對職涯發展來說,都再正常不過,有好機會就把握。噢,別只看薪水,職能成長最為重要的。 2. 爭取主管職位。如果公司的文化,是由技術能力強的當主管,那該做的和第1項差不多,先問問現在成長的環境好不好,自己夠不夠努力?實力未到,想爭取也是不容易。重點在於不斷追求卓越,這才是不把路走窄的關鍵。記得同時培養自己的Leadership. 如果公司重視在工程背景外,還要加上管理能力,那就多吸收多學習吧,同時發展這兩種能力。一般來說,若真要需擱置技術能力成長,好更專注於管理職能,這樣的分水嶺,大致出現在十年以上資歷,通常會是位於組織裡第二層以上的主管,近期應該不需為此操心。 3. 轉職 PM。這可是換跑道啊,好壞難料,先問問自己,對這角色有沒有熱情再考慮,因為沒有工作是不辛苦的。其實工程背景轉行選擇不少,何止PM,當業務能更了解產品,當FAE能更理解客戶等,但這些都不該是換跑道的主要理由,每一種專業都要耕耘才有收穫,別幻想靠工程背景就能輕鬆應付。 共勉
Arthur Chiu
科技研發管理 顧問
試著這麼想,自動化測試的目的是什麼? 引入自動化測試,是否有助於讓產品品質驗證的過程,變得快一些、好一些、省一些? 如果這些影響都是正面的,自動化對於測試工作,則幾乎是必然的選擇,對嗎? 自動化測試會完全取代人工嗎? 短期內應還不至於,由其是需要深度思考的測試方案設計,不只是驗證該有的功能都有,更要防範不該有的異常都能被攔下來。但是,關於測試的執行,在趨勢上非自動化的比例,的確只會越來越少。 有危機意識,非常值得鼓勵,這是進步的動能。管控ODM,不常執行測試工作,不見得是退化,重點還是要看個人的價值在那裡。若只是安排人力、資源、時程,要警惕能力的成長,是否在一段時期後遭遇瓶頸。若走驗證的技術職涯,可多涉獵 Validation Architect 職能。若走計畫管理的技術職涯,可多跨界延伸到(design quality相關的)Quality PM職能,或是(manufacturing quality相關的)NPI PM之類的職能。若走管理職涯,得多充實人事管理、組織管理、Leadership 相關職能。 共勉
Arthur Chiu
科技研發管理 顧問
主管的心態的確該改,但可能不是您原先想的 "調適"。 除非是只掛名但不需擔負責任的閒差,要不然 "選/育/用/留" 是當一個主管的份內職責。員工離職要看成常態,就像組織的新陳代謝一般,接著就是招募、培育、適才任事的新循環,這些都算主管的日常工作,該要認分的做好。寄望員工永不離職,以減輕主管工作負擔,基本上不切實際。 離職的個案大多數不是問題,但高離職率則是該被檢討的問題。如果公司裡的其他團隊相對穩定,如果前朝主管任內員工相對穩定,如果組織在前些年比今年穩定,那主管是不是該設法找出原因、並提出改善方案? 心態上別說 "留不住人也不是我的問題呀,為什麼都要檢討主管呢?" ,建議要改成當責心態,早點戒除這種 "打工仔主管" 的想法。 如何當責? 如果是公司環境面的因素,試著向上層建議改革;如果是部門間協同作業的困擾,要帶頭溝通;如果是組織內部規範未能與時俱進所造成,該領導改變;如果是員工觀念不正確,自然是強化教導的工作。如果是員工無法適任導致,經輔導後仍成效不彰,祝福他就好。 拉高一個層級來看,評量部門的重點還是在於運作的績效,也就是看產出與交付的品質、效率、成本,主管得讓 KPI 愈來愈好。至於人員的異動,並不見得一定是壞事,有時反而成為推動革新、讓部門產出更好績效的契機。(當然啦,若因缺工導致產出低落,要做危機處理。) 相對的,若只一味追求人員穩定不離職、組織安定,短期內的確能讓運作順暢;但長期來看,則要小心運作績效成長停滯,這可是部門主管會遭檢討的大麻煩。 共勉
Arthur Chiu
科技研發管理 顧問
可以理解您辛苦了,但試著超越自己,不執著於直覺的反應,改用不同視角看職場問題,常常能有更多收穫。 1. 您可知道,一位主管,面對專案計畫進度延遲,會做些什麼? 肯定要找 "相關" 同仁們檢討改善,但也許是採個別面談的方式。您感受到的片面責難,不見得是全貌,因為此種情形下, Project PM 若並不被要求改進,只能說是業界罕見的個案吧 (意思是,不太合理,在正常情形下不太可能)。 2. 計畫執行靠團隊合作,每個成員除了完成自己責任範圍,還要相互照看,提醒夥伴們注意問題。甚至於緊急時,即使不屬自己職則,只要能幫助到成果順利產出,仍需主動補位協助夥伴。這個重要觀念叫做 "當責" ,Accountability。想想棒球比賽裡,游擊手與內野守備員的合作,不難理解勝率高的團隊該怎麼互動。不要過於關注,"不公平、我吃虧了" 這些情緒。 3. 且撇開廣義的職責不談,單獨看份內工作,身為 Product PM,把產品規格 "移交" 給 Project PM,就已經完成任務? 產品需求定義,是專案計畫成功的基石,其質量要求沒有最高只有更高。若陳義過高、不盡合宜,或是含糊籠統,後續執行風險也高。要在市場競爭力、與專案執行力之間,取得平衡,永遠是項挑戰,需不斷取得回饋淬鍊。給您一個建議,放棄 "移交" 這種觀念,很深入地探索,您開立的 Product Specification ,在後續專案開發中,是怎麼被應用的。這將有助於您建立 Lesson Learnt 循環,持續提升專業能力。 共勉
Arthur Chiu
科技研發管理 顧問
現職是約聘,通常得採騎馬找馬策略,別放棄更好的機會。只是,機會要多久才會來 (拿到正職 Offer Letter) ,誰也不知道,所以現在就可以開始搜尋。 目標若是 Architect,光學會怎麼用 Cloud Service 可能是不夠的,不論您學會多少種,這些技術的進入門檻並不算高。(話說回來,您不妨注意一下那幾種 Cloud Service 的市占率,這通常也意謂著工作機會的多寡) 那麼高檔次的架構工程師,該具備什麼本事? 想想,如果要在 AWS / Azure 做選擇,利弊得失 (Trade-off) 怎麼比較? 如果要保留擴充性,讓服務於未來可同時架在三大家雲服務上,系統 Layer 該怎麼切割 (可參考 Agile DIP 原則),框架(Framework)要怎麼設計 (可參考 Architecture Design Pattern) ? 如果要把 OT 端 Edge Computing 接軌到雲端服務,Solution Architecture 有哪些 (可參考 Enterprise IOT) 如果要再加入 AI training / inference 之類當紅的應用,流量、運算能力的瓶頸會在哪裡? 總結來說,入門端重在應用 (現有的 API 或 Open Source),可以從訓練開始;專家級更著重於解決非功能性需求 (non-functional requirements) 帶來的挑戰,也就是靠架構來處理軟體裡 -itilities 的問題。(以上這些關鍵字,在網路上查詢,都有豐富資源。) 您顯然是會思考的人,近40年的職涯很長,若能早些知道未來要去哪裡、要接受那些挑戰,對於路徑的選擇,應該會越來越清晰。(相對於您的目標,輕易放棄知名 SI 的歷練機會,從宏觀角度來看,有些可惜,下次可要慎思。) 祝 順利
Arthur Chiu
科技研發管理 顧問
常常聽到新手主管有類似困擾,員工不主動積極怎麼辦? 成因很多元,建議要先仔細觀察評估,別急著下結論。有不小的機率,在於主管做得不夠好。(終究,主管有考績的生殺大權在手,甚至可淘汰不適任員工。) 通常先評估,員工的績效表現,是否與其職等相符? 主管(您)的期待,是否與員工的職等相符? 比方說,要求資淺的助理,要能應付困難的突發危機,或者從不顯眼的數據中看出潛在風險,自然有些困難。這時員工不是不為,而是不能。先弄清楚是意願的問題,還是能力的問題。 若表現不完全符合期待,該優先套用的模型,是"績效管理",先別管什麼態度是否積極,也別談什麼專業尊重。務必讓員工非常清楚的知道,做得不夠好的地方到底在哪裡,要達成什麼明確事項才叫及格。其實許多員工的管理問題,主管也要攤上很大的責任,最常見的就是主管把 "期望 (Expectation)" 說得抽象含混模糊,甚至沒說。若只是內心希望員工"主動",即使主管不說也能察言觀色,知道該做什麼,這有些屬不切實際的期待。舉例來說,可以要求員工於呈現數據、繪製表格時,每頁一律分析解讀並論述。沒依照 SMART 準則,說清楚什麼叫 "主動",主管自己要加油;員工沒依照要求解讀數據,這叫摸魚打混;寫出來的分析不夠精闢,這是程度不足猶待學習。 相對職能未達能自主放飛程度(Delegation Mode)的員工,其產出績效的關鍵,主要在於主管指揮是否足夠精實(符合PDCA模型)。主管先說清楚期望,接下來的責任,則是提供支持(例如經常指導、回饋),積極協助員工改善績效。 若表現符合其職等的期待,有交辦都能做好,那就可以來研究為何 "意願消極"。有時侯是老兵現象,同樣的事做久了生煩,給些新差事,就會有很大改變。有時候是環境面的問題,例如升遷不公、賞罰不分、缺乏挑戰、文化不佳、勞逸不均、下情難以上達...等,主管得探索並設法改善。 若表現超越其職等的期待,則是組織的寶藏資產,尊重、授權,不必太介意 員工個人 "積極" 這面向。但仍然要定期做職涯面談,不要總視為理所當然。至於團隊整體是否積極,通常靠主管主動推動,這也經常背當成管理職人員的 KPI。主管的價值,在於提升團隊產出績效,發展員工職能。遇到主動稱職的團隊,只能說是運氣好,不能當作管理能力好。 照說,您這一階管理 (First-Line Management) 的問題,非常典型,應該會優先請益您的上階主管,而提問的內容,多半是執行您主管建議時,所遭遇的困難才對。據此大膽假設您的組織,因是新創部門,管理的資源也許不那麼充足,所以多說了些道理,嘮叨了些,尚請海涵。惟此處篇幅有限,多看看些管理書籍,將能對團隊運作模型,早些建立正確認知。
Arthur Chiu
科技研發管理 顧問
重新梳理一下您的描述,您目前的工作相對單純,只要靠自己一人之力,即可完成上級交付的任務,最近得到了一個新的"機會",未來預計工作範圍擴大,需指揮2-4人,共同完成較複雜的任務。通常這種角色,稱做 Technical Leader。另外,您同時得到了另一個"機會",負責經營管理 2-4 人的小組織,缺人時要找人,平時要教導培育新進,考評他們的績效,並督促團隊做出最大貢獻。通常這種角色,稱做 Team (People) Manager。而您覺得伴隨這兩個"機會"而來的挑戰太大,也曾看過些失敗的前例,索性以個性不適合為理由,傾向選擇留在現有舒適圈,放棄這 "機會"。 有沒有出息,屬於情緒化的標籤,且先擱置。但要緊的是,您有沒有熱情在技術職涯 (Technical Track) 上,從目前的資深工程師,歷練成長為主任工程師 (或技術經理之類的職稱),還是打算從此原地踏步? 另外,您想不想擴充範圍,含括管理職涯 (Mangerial Track) ,學習對後進的選育用留能力? 的確,即使有熱情,相對的能力不見得很快能跟上,就會像許多先例一樣,遇上一段蠟燭兩頭燒的瓶頸。但如果熱情不夠,遇到挫折很容易選擇打退堂鼓,導致前功盡棄。所以,先讀上述說明,充分理解這機會是什麼,在意識清楚的情境下,做出自己的決定。如果決定接受挑戰,請先相信若一時做不好,只是能力還沒到位,保持謙虛歷練學習、並咬緊牙關堅持就對了,成功的先例當然不在少數。當你學會情境領導、有效授權,就可望脫離兩面不討好的壓力鍋。 另外有個建議,如果因為個性不想接管理職,或許可以找您的主管討論,先只擔任技術職的 Technical Leader,但暫不接任 Team Manager? 跨度縮小,挑戰也變得比較有把握克服。 許多公司支持 Dual Track Career Development, 在技術職上一路做到 總工程師 或 Chief Architect 或 CTO,也挺不錯的啊。事實上,先成為一個成功的 Leader,再轉任 Manager,這條職涯的路將會平順得多。 完全拒絕這些"機會",也不算是什麼罪惡,不過是您在 Work-Life Balance 上做的選擇而已。但請同時想想,在 Life 這一頭,是否要加碼些什麼。 如果只在 Work 這端單方面退縮,生命的精彩度上來看,也許有點可惜。 共勉
發問
發問