技術方面的領導就不能寫程式碼？

　　之前我曾經說過，一個高效率的專案領導應該花費30%的工作時間來寫程式碼。但是在培訓這些人的課堂上，我聽到的最普遍的問題就是：

　　“我有那麼多的事情要做，怎麼會有時間來寫程式碼呢？”

　　我知道許多專案領導在儘量擠出時間寫程式碼，也在盡力去做好自己該做的工作。下面是一些對我和其他人都有幫助的建議。

　　避免那些關鍵性或緊急的專案

　　儘管“甘特圖“在IT界的名聲並不好，但是它們確實對於那些關鍵鏈和關鍵路徑提供了視覺化的模型。專案領導會發現自己經常被打斷，很難有整塊的時間去編寫程式碼。所以我建議要避免這一類的專案，因為這類專案通常會有嚴格的進度要求。

　　如果這需要技術和經驗，並且只能專案領導做，那麼最好和其他開發者共同完成，這樣可以在專案領導忙於其他事時不至於停掉這項工作。

　　學會代表

　　代表是專案領導需要學習的一項技能，並且是一項開發者極少有機會學習到的技能。“Situational Leader Model”清晰的說明了什麼時候可以。有效的方法依賴於個人的動機和技巧。這個模型解釋了四個模式“告知，銷售，參與和代表”。

　　代表僅僅是當一個領導人相信一個人有足夠的技術和有效的動力去完成一項任務。常見的困難就是很多領導人知識單純的信任某個人而不是基於他是否有足夠的能力和動力去有效完成任務。

　　鬆散的結對程式設計

　　我不是對完全結對程式設計過於熱衷的人。但是在這其中找到平衡也並不是什麼難事。一個好的安排就是與一個人一起去完成共同的目標或者解決同一個問題，然後定期進行結對程式設計來看在寫程式碼的過程中有什麼新的東西或挑戰。

　　這種合作方式在設計和編碼時，對於那些發現自己總是在不停地被叨擾的專案領導來說非常有效。

　　避免不必要的無意義的開會

　　對於開發者來說沒有什麼比毫無目的地坐在會議室裡浪費時間更糟糕的事情了。因為這樣也就浪費了寫程式碼的時間。所以就需要學習怎麼有效開會來避免這種無意義的會議。

　　可以使用下面的5項規則：

1. 目標——開會的目的明確嗎？確保每一次會議都有明確的目標。例如：分享資訊，收集資訊，共同探討解決問題或達成共識。
2. 產出——當你知道開會要達到什麼樣的結果時，你可以縮短會議時間。定義會議成功的準則（應該和目標一致）可以幫助會議不跑題。
3. 參與者——取消/安排一個會議而不是與不相關的人開會會更好。這篇來自Esther Derby的Tweet就寫的比較好。
4. 問題點——清楚的知道問題點可以使會議不越軌。
5. 進度——每一次開會都應當清楚知道該如何進行，人們期望如何參與，需要的一些特殊的規則，一個會議主導者應當明確開會的目的來滿足與會者的期望。

　　學會說“不”！

　　領導的藝術是說“不”，而不是說“好”，說“好”是很容易的。——Tony Blair

　　作為一名領導，或許你總是永遠承擔著過多的壓力。你說的“好”越多，你就有越少的時間寫程式碼。如果寫程式碼對你來說真的很重要（也應該如此），你就需要能分得清什麼事情重要，什麼事情可以讓別人或者非技術人員來做。

　　規劃出整塊的編碼時間

　　我知道一些專案領導會在日曆上標記時間來確保自己可以有不被打擾的編碼時間。“開發者須知”裡講了打擾帶來的思維中斷。並且相比於開發者，專案領導人被打擾的機率可要大的多。

　　總結

　　對於專案領導人來說花費時間寫程式碼是重要的，但是其他的很多事情又會佔用相當多的時間。保持平衡是不容易的，但是以上的技巧可以幫助你。如果你有其他的建議可以參與討論。如果你喜歡這篇文章，你也會對這本書《與專案領導對話》感興趣的，這是一本分享世界範圍內的超過35歲的專案領導的經驗書籍。現在在 Leanpub上可以看到。

　　英文：THEKUA，譯者：Misslio