My Profile

  • 暱稱:gipi
    現職:某軟體公司研發主管
    專長:軟體架構設計、產品開發、產品整合
    Plurk:http://www.plurk.com/gipi

My Awards

  • (ASP.NET 2009第四季)

最新回應

[嘀咕]八千萬的警惕

千萬不要告訴我,這是不可能的

千萬不要告訴我,那是誰的問題

千萬不要告訴我,只有誰可以處理

千萬不要告訴我,沒有人找不到人

千萬不要告訴我,優先節省成本是天條

千萬不要告訴我,還沒開跨部門解決會議

千萬不要告訴我,跨部門會議開了也沒用

千萬不要告訴我,客戶已跳腳你還沒出門過

 

這是前年老闆寄出來的『八千萬的警惕』,這對於每個人其實都適用的,當初我對這八個千萬其實非常有感覺,以下大概列一下當初到現在的一些想法。

 

 

不說不可能

不管事情有多困難,前面的障礙有多大,沒有人喜歡聽到『不可能』這三個字,因為這三個字代表的是不管我如何努力,結局都是一樣的,但其實有多少的事情是不可能呢?你會回答我『很多』,但若我再問,你依據的是什麼呢?你可能無法提出真的能說服我的理由,因此我認為『這件事情在某些折衷或者溝通下是有可能被達成的』。

 

我們最常拿來講的,專案要在縮減人力、時間的狀況下完成相同範圍、品質的產出,可不可能?自然不可能,但你總要給個說法,並將配套的解法加以說明,該刪減哪些項目應該要清楚條列,雖然最後產出可能是相同的,但給人的感覺是完全不同的。

 

我的職場觀念裡,只有很困難困難簡單,沒有不可能。

 

 

不是別人的問題,就是你的問題

這部分可以看我之前寫過的兩篇文章,出狀況時只要你是客戶面對的窗口,你就該將整個問題處理完;若你是PM,專案延遲就是你的問題,你就該負起責任,專案失敗你也一樣要負擔起責任。

[嘀咕]誰該為進度延遲負責?

[嘀咕]對的起你的專業

 

 

很難替代不代表不能替代 

『這個問題只有XX會處裡,他今天請假,明天再幫你處理。』

 

若你的團隊中只有一個A咖,只有他可以解決某些問題,那你該有所警惕,你對這個人的依賴性會過大,甚至有可能影響到你的組織運作,如果其他人都無法追上他的水準,那多培養幾個B咖總有機會分擔掉這些風險,每個團隊的工作都該有人可以互相cover才對。 

 

我很少讓某項工作只有某個人會處理,若有個機密程式只能讓其中一個人維護,那部份的程式我也一定會深入了解,只要他請假,出問題時我就會幫忙處理;至於其他的工作則大多會考量到overlap的問題,在學習上就會讓彼此可以cover對方部分的工作。

[嘀咕]談談Team work這件事

 

 

客戶問題優先

工作中問題有分內外,對內的工作決定你的績效,因為KPI大多從這些工作中訂出來;對外的工作決定你的價值,因為客戶對你的評價往往可以決定你的職涯順遂與否。

 

之前我遇過許多的研發人員非常討厭到客戶端,因為他認為他自己的責任在研發上,而非服務上,這一點我認為有待商確。

 

組織適度的分工可能可以培養出不錯的技術能力,但我認為依台灣的中小企業狀況,很難在100%的分工中發展出出卓越與切近市場的產品,很多大公司可以將市場、服務、產品開發、研發等等做很完善的分工,讓最後勤的研發單位也能完整的獲知市場的需求,形成一種很良善的循環;但對大多數的中小企業來說,要做到這一點實在是不容易,加上人員的流動,時常都會出現市場、服務或者產品開發單位的人力流失,這時候體系中就出現了缺口,要彌補並不容易,因此在中小企業中分工開始有所改變,市場、服務、研發人員間的區隔再也不是那麼明顯,這部分可以參考下面這篇提到的內容:

[嘀咕]IT人員的職場小嘀咕(二)

 

回到主題,由於一個產品服務客戶時常常會牽涉到多個單位的運作,這時候不同單位的成員應該有個一致的觀念,客戶的問題永遠是應該被優先處理的,而且這些處理動作應該在客戶跳腳前。

 

 

不要讓跨部門會議只是會議

跨部門會議往往有幾個讓人無奈的地方:『缺乏效率』、『向上呈報』、『責任切割』。

 

一場跨部門會議開下來,有時候只要兩個主管談妥就好,但若牽涉到多個部門,有時候除了要協調主管的時間外,對方的主管或者關鍵人員的時間也要敲定,一場會議常常一安排就是兩個禮拜後召開,效率十分的差;如果討論的事項對方無法決定,或者兩方無法取得共識,往往會透過向上呈報的方式請兩邊的主管來決定,若仍無法決定最後甚至會請出大老闆來做決策;組織分工是必要的,但有時候我們也會遇到急於切割責任的人,會議一開始對方就不把這件事情當成與他有關的議題,會來參與會議只是因為奉命前來,抱持這些心態都會讓我們的會議無法得到滿意的結果。

 

『會而不議,議而不決,決而不行』是開會討論最大的忌諱,但偏偏跨部門溝通的重點不是在於事情有多重要,而在於你有沒有為對方想過,這部分可以參考之前我的文章:

[嘀咕]跨部門溝通

[嘀咕]同理心:站在對方立場

 

 

系統有Bug才不是理所當然

開發系統久了,我們自己都知道要寫出完全沒有Bug的系統有多困難,甚至可以說是不可能了,即使經過6 Sigma的檢驗,製造業的產線仍可能製造出品質異常的產品,軟體產業畢竟還需仰賴較多的人為處理,因此在品質上的控管變得更加困難,但『系統有Bug』這件事情仍不該被視為理所當然,你有聽過微軟、Google跟你說有Bug是正常的嗎?對一般客戶來說,沒有Bug是理所當然的;對有經驗的客戶來說,有Bug是可以理解的,但不管面對什麼樣的客戶,我們都該對我們的Bug致歉,並持續改善我們產品的品質。

 

專注在重要的事情,認真看待看似不重要的事情。


分享
推到 Plurk!

2010/2/3 22:38| 閱讀數 : 1919 | 1 人推薦 我要推薦 | 5 Comments | 文章分類: 嘀咕 訂閱


關連文章

回應

  • 坎尼 2010/2/5 上午 12:05 回覆

    # re: [嘀咕]八千萬的警惕

    贊同! 若是某項 domain 能力只有 team 裡一個人會,或是一個超強的人在維持整個 team 的運作(寫code、debug...)
    那麼這個 team 在可運用人力及發展上就會受限,實在是很危險的一件事

    不過以基層個體來講,大多數的人都不想被取代,因此有時會 hold 住某些特定知識,以保住自己的獨特性

    此刻就需要仰賴知識分享及知識管理的運作,讓死水可以活起來,健全整個 team 的運作

    (對不起,跑來撒野了 (blush)
  • gipi 2010/2/5 上午 12:28 回覆

    # re: [嘀咕]八千萬的警惕

    to 坎尼 :
    你回覆的很中肯,今天有個team member幫team work下了個定義,我很喜歡:團隊不是互相幫忙,而必須要每個人抱著必死的決心,貢獻自己所有的能力...

    我個人非常不喜歡藏私,你不把東西交給其他人,那你肯定也沒時間去學新的東西,因為有些事情就只有你可以處理,從這個角度想對自己是好是壞呢?

  • shunyuan 2010/2/5 上午 01:13 回覆

    # re: [嘀咕]八千萬的警惕

    千萬不要坐而言,而沒有起而行
  • Opa 2010/2/5 下午 05:58 回覆

    # re: [嘀咕]八千萬的警惕

    Hi,我是兵器連10班的人。看了你的文章,真的覺得很棒。雖然沒有聯絡,還是跟你說謝謝你分享了這麼多寶貴的東西哦!
  • gipi 2010/2/5 下午 06:12 回覆

    # re: [嘀咕]八千萬的警惕

    to Opa :
    哈,既是同梯的,我們應該對彼此有印象,留下名字來,說不定我還記得你阿...呵呵...

標題 *
名稱 *
Email (將不會被顯示)
Url
回應
登入後使用進階評論
Please add 6 and 7 and type the answer here: