在軟體部份工作4年，慢慢從R&D 轉往 R&D 的工作內容，現在還在持續調整中。分享一下自已在各階段的改變
第一階段:
此時工作內容(工作百分比):
- 新功能開發設計(85%)
- 新需求收集(15%)
在R&D時，最單純的階段是接收到Task，確認內容，開工。遇到問題取手發問，遇到決策問題舉手發問。還不錯的工作內容(碼農??)
因組織的特性，此時已承擔設計項目的收集與整理，但客戶還不多，相對的項目也比較不多。
此階端並無持續太久，約半年至一年左右
第二階段:
此時工作內容(工作百分比):
- Service issue 處理(25%)
- 新功能開發設計(60%)
- 新需求收集(15%)
隨著客戶越來越多，需求與Service issue也越來越多，此時工作項目也轉變為與Service Team 的Bug收集窗口。內容為Service issue確認，處理與進度追蹤。因為也需要隊員支援，所以已開始排程給團隊成員處理。
此階端持續也約半年至一年左右
第三階段:
此時工作內容(工作百分比):
- Service issue 處理(35%)
- 新功能開發設計(50%)
- 團隊的工作排程(15%)
隨著團隊新進Software Marketing 人員與組織上的調整，在工作”新需求收集”也開始調整，此作內容轉換給Software Marketing，而我的工作內容也正式轉為軟體管理的角色。此工作的轉換變成跟Software Marketing有大量的連結與溝通，基本上就是Software Marketing對外，我對內，工作的項目是給予隊員的項目排程。同一時間，因為在處理Service issue時練的工與工作的經驗越來越多，開始慢慢變成疑難雜症處理中心。此時工作項目內已有兩個項目是屬於"排程"，新需求的排程與Issue處理的排程。
此階端持續也約半年至一年左右
第四階段:
此時工作內容(工作百分比):
- Service issue 處理(15%)
- 新功能開發設計(50%)
- 團隊的工作排程(35%)
隨著客戶的增多，愈來越多不同的問題回傳，漸漸的量開始多到『處理不完』，此階段也慢慢變成為『Service issue分析中心』。因為工作不是純軟體業，所以問題的源頭往往是機電軟的綜合問題，為了加快Service issue處理的速率，改變成將問題先初步分析，再轉發至隊友進行。當然，新功能需求排程，此時也同步進行中。
此狀態維持至現在~
回顧這幾年，發現增進自己功力最快的反而是處理Issue，從問題中找到方案並解決(練功階段)。
下一階段:
如何培養下一個人才與加強團隊的工作效率?
培養人才對自己來說蠻重要的，每個人對一樣工作一定都會怠卷感，所以轉換工作內容與屬性是一個蠻好的做法，讓隊友感到有成長的方向，也是一個雙贏的做法。
加強團隊的工作效率一直是很多團隊的好問題，每個團隊都有自己的工作文化與方式，沒有絕對好與不好。下一次也來分享我們這邊得到經驗 :)
