進度條

Android還是iOS,你的工作是侷限在身分,還是侷限在天分

Android還是iOS,你的工作是侷限在身分,還是侷限在天分

作者: Vincent Ke 更新日期:

參考文章:https://quip.com/blog/quip-engineering-team-structure?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

 

相信身為工程師的一員,對玲瑯滿目的104求職條件一定不陌生,舉凡隨便一間大公司,每一個團隊都是用平台來做劃分,像是“iOS工程師”、“Android部門”、"Front-End Team"等,在具備一定的專業技術累積前,不可避免的的確需要一些共通性的技術基本盤,才有辦法成為一個專業的"平台工程師"。

 

 

以餐廳為例,工作上一定會有外場服務生跟內場廚師等區分,就像產品會區分成Android及iOS一樣,我們都需要不同的角色,並且具備一定程度的專業水準,才有辦法把產品在各個面向做到完善,做到面面俱到,就像餐廳的生產鏈一樣,廚房內有人切菜,有人掌廚,外場有人點餐,有人接待,尊重每一個專業才可以把服務和產品做到面面俱到。這就是團隊誕生的理由,但同時你的員工卻也被組織給定義著。

 


但這真的只能是唯一解嗎?

 

 

在大型公司裡也許這樣的分工是必然的,而小型新創團隊裡,這樣的分工難道真的是必須嗎?

 

Quip就不這麼認為

 

 

 

 

相信有用過Google doc和EverNote的朋友,對Quip一定感到熟悉,他是由Facebook前技術長Taylor和前Google員工Kevin Gibbs一起開發的一項雲端文件產品,他不僅翻轉過去大家對共享文件及共編的概念,更推出APP版本,並支援多人線上修改、版本控制,更開發評論的功能,讓團隊之間的溝通可以更加暢通,這聽起來似乎是一個依賴技術走向的新創產品,那這個團隊是如何開發產品的呢?

 

 

資料來源:www.quip.com

 

 

Quip認為,這樣的分類方式,只為讓團隊和組織來決定產品的面向,使用分工的方式不僅讓工程師變得隔離,團隊間的討論更會變得冗長。舉個例子,同樣的產品必須在Android與iOS上同步推出App,但重複的功能在分工的方式之下,不僅冗長的會議就占了大半時間,各個功能(如API等)又需要透過其他的會議來做檢討、核對,一層一層的溝通之後,當中的遺落與落差最後還需要一位稱職的產品經理來做檢核,在協調好各部門開發與配合的時程後,不知不覺中,產品上線的時間已經變得冗長。

 

那Quip做了什麼來改善現狀?

 

他們聘請的工程師多半具備不同平台的經驗,也許並非是單一平台上的專家,卻願意投入大量的資源和協助,並且讓工程師參與各種不同平台的開發,當然分工的方式並非是用平台而是用功能來做劃分,所以今天不管是做UI功能還是資料庫,這些都可以讓你在不同平台上去開發,去實現,而其中每一個團隊也會透過程式碼的共享來做同步。

 

與現行機制大相逕庭的是,Quip並非把員工當作開發的資源,而是願意為了開發,投入資源並讓員工成長。

 

透過這樣的分組模式,不但可以使平台的開發較為一致化,透過功能分組不僅可以對功能的掌握度更高,讓它們可以更快速地將功能建置在平台之間,也可以解決過去開發功能時,平台與平台間串接、討論所耗掉的時間更可以大幅減少,讓工程師可以專心地在功能開發上發揮所長。

 

這樣的方式也使工程師不再扮演螺絲釘的角色,而是扮演著每一個功能的實際開發者,而這樣多變化性的工作,更可以讓工程師的視野變得更加寬廣。這樣的開發力道不僅精準而更確實,重要的是,你的價值不再來自於你的身分而是來自於對於工作的挑戰以及自我成長。

 

 

如果你有幸在這樣的公司就職,試著不要再拘泥角色,而是拘泥在自我的充實,來提高團隊的產能吧!!

 

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧