我曾經以為，一個好的管理者，就像一本雜誌的「總編輯」...
最近剛當小組長, 有時候看著一個一個commit漸漸的和需求越來越偏
忍住不取糾正真的很難,尤其需求又是需要趕快完成的.
想鼓勵又覺得當初自己也是靠自己跨過這個坎.
公司比較沒有很正式的員工訓練/制度
待人這一直都是我的困擾, 很想跟您請教
當組員是junior的時候, 您通常會怎麼去帶領他呢?
聽起來是科技業. 若是這樣的話junior可能就真的得帶了. 每一個task應該要有明確的deadline, 驗收條件, 甚至實作方向(要多細得看情況). 然後要一一驗收點交 並對有問題的東西提出疑慮要求改到好為止, 並給予範例與教材/方向說明什麼叫做好東西&要求.
會跟面對senior不太一樣, 因為若你是專家對方不是而且只是junior那很自然的你會有點變成師父/學長的角色 跟教練不太一樣 中間會有需要拿捏的地方
不是科技業, 但是職位是後端工程師~
我原本都是先講解pm規格給junior聽, 然後讓他自己有問題來問
但效果不太好, 有時候junior會不知道怎麼問
我先嚴格實踐回覆中的
1.明確的deadline + 驗收條件
2.給予範例與教材
朝這個方向努力看看 謝謝!!
是的關鍵是對於驗收方式的規劃, 然後最好設計成他自己也能驗 先驗得過才來找你
(1) 驗收條件做成他自己能先驗先改直到驗得過為止---節省你的時間
(2) 驗收條件要跟你最後成果(i.e., 以你的例子來說應該就是pm規格)越接近越好---這樣他做完以後只要驗得過就能夠用是最好, 節省你的時間
我的經驗裡---若驗收條件的規劃做得夠好 不只junior, 連外包/工讀生/實習生都能夠即戰
看來我之前的想法都有點不對
我雖然會驗收但都是用code review的方式來發現問題(費時)
沒有很明確的驗收條件, 想一想應該也會讓新人很困擾...
我會重新整理一下, 先從小的需求先去訂驗收條件,接著再發派出去.
先試看看再跟您回饋~ 謝謝!!
最近剛當小組長, 有時候看著一個一個commit漸漸的和需求越來越偏
忍住不取糾正真的很難,尤其需求又是需要趕快完成的.
想鼓勵又覺得當初自己也是靠自己跨過這個坎.
公司比較沒有很正式的員工訓練/制度
待人這一直都是我的困擾, 很想跟您請教
當組員是junior的時候, 您通常會怎麼去帶領他呢?
聽起來是科技業. 若是這樣的話junior可能就真的得帶了. 每一個task應該要有明確的deadline, 驗收條件, 甚至實作方向(要多細得看情況). 然後要一一驗收點交 並對有問題的東西提出疑慮要求改到好為止, 並給予範例與教材/方向說明什麼叫做好東西&要求.
會跟面對senior不太一樣, 因為若你是專家對方不是而且只是junior那很自然的你會有點變成師父/學長的角色 跟教練不太一樣 中間會有需要拿捏的地方
不是科技業, 但是職位是後端工程師~
我原本都是先講解pm規格給junior聽, 然後讓他自己有問題來問
但效果不太好, 有時候junior會不知道怎麼問
我先嚴格實踐回覆中的
1.明確的deadline + 驗收條件
2.給予範例與教材
朝這個方向努力看看 謝謝!!
是的關鍵是對於驗收方式的規劃, 然後最好設計成他自己也能驗 先驗得過才來找你
(1) 驗收條件做成他自己能先驗先改直到驗得過為止---節省你的時間
(2) 驗收條件要跟你最後成果(i.e., 以你的例子來說應該就是pm規格)越接近越好---這樣他做完以後只要驗得過就能夠用是最好, 節省你的時間
我的經驗裡---若驗收條件的規劃做得夠好 不只junior, 連外包/工讀生/實習生都能夠即戰
看來我之前的想法都有點不對
我雖然會驗收但都是用code review的方式來發現問題(費時)
沒有很明確的驗收條件, 想一想應該也會讓新人很困擾...
我會重新整理一下, 先從小的需求先去訂驗收條件,接著再發派出去.
先試看看再跟您回饋~ 謝謝!!