[讀書心得 part4] 交辦時，務必說清楚、想明白

大家好，我又來分享讀書心得啦 ^^
今天跟大家分享訣竅三

1. 勉強他的能力，不要勉強他的意願
• 話說沒有意願，能力再好都是枉然，可見意願的重要性。所以平常一定要跟member混熟，指派工作的時候，一定要了解他的能力是否有辦法完成這個交辦，如果有辦法完成自然比較好說服，如果比較難完成，那在指派的時候也一定要想辦法說服他。我很常會用的招式是:你把這件事情完成，你就會學習到以後該怎麼處理這樣類型的工作了。目前看起來成效很爛(冏)
2. 他有沒有個人目標，會影響工作成敗
• 說真的，我也覺得這點很重要，但問題要讓member有個人目標其實真的還蠻難的，我也曾經幫member訂過目標，但效果其實不符合預期，或許我該找時間好好來跟member談談他的目標到底在哪?
3. 不合理的工作要求，交辦給誰最好呢?
• 我覺得交辦給誰都不好，所以如果可以把不合理的工作要求合理化，那交辦出去的機會可能會大一點。例如寫程式，一隻程式可以花一天沒架構沒規劃的方式寫出來，也可以花三天好好的規畫寫出來，當時間急的時候，你要一個很有sense的member花一天寫出來，你該如何說服他?去年我就常遇到這樣的事情。那時候跟我合作的member能力非常好，但對程式撰寫有一定程度的潔癖，說真的，要我寫出一個很糟的程式，對我來說也是一種虐待。所以我會先跟他討論，跟他說目前事情的急迫性，以及目前會跟老闆報告說現在的方式會產生的問題，日後我們需要再額外花時間來refactor目前寫的程式，讓老闆知道。還好那位member跟我交情還不錯，我們就這樣完成了大多數的程式，之後有被refactor的部分也有80%以上。
• 所以我寧願先讓事情盡量合理化，再來做所謂的交辦，萬一不行，也跟member討論出平衡點。
4. 他不是你的分身，做法不一樣，千萬別跳腳
• 話說寫程式裡有一個流程叫做code review，通常是組織裡比較資深的member幫比較資淺的member review code，review的過程中，可以提出建議的做法，以及指出有問題的地方。我覺得code review 對我來說也是練功的一種，有時候可以看到自己沒想過的作法，當然有時候也會看到讓自己氣得跳腳的寫法。從寫程式就可以知道，針對同一種需求，不同的人去寫程式，通常不太可能寫出一樣的code，但只要知道目標在哪(這真的很重要)，確定過程中都是往目標的正確路徑，我想就算中間稍微停頓看個風景也不為過。