技术方面的领导就不能写代码？

　　之前我曾经说过，一个高效率的项目领导应该花费30%的工作时间来写代码。但是在培训这些人的课堂上，我听到的最普遍的问题就是：

　　“我有那么多的事情要做，怎么会有时间来写代码呢？”

　　我知道许多项目领导在尽量挤出时间写代码，也在尽力去做好自己该做的工作。下面是一些对我和其他人都有帮助的建议。

　　避免那些关键性或紧急的项目

　　尽管“甘特图“在IT界的名声并不好，但是它们确实对于那些关键链和关键路径提供了可视化的模型。项目领导会发现自己经常被打断，很难有整块的时间去编写代码。所以我建议要避免这一类的项目，因为这类项目通常会有严格的进度要求。

　　如果这需要技术和经验，并且只能项目领导做，那么最好和其他开发者共同完成，这样可以在项目领导忙于其他事时不至于停掉这项工作。

　　学会代表

　　代表是项目领导需要学习的一项技能，并且是一项开发者极少有机会学习到的技能。“Situational Leader Model”清晰的说明了什么时候可以。有效的方法依赖于个人的动机和技巧。这个模型解释了四个模式“告知，销售，参与和代表”。

　　代表仅仅是当一个领导人相信一个人有足够的技术和有效的动力去完成一项任务。常见的困难就是很多领导人知识单纯的信任某个人而不是基于他是否有足够的能力和动力去有效完成任务。

　　松散的结对编程

　　我不是对完全结对编程过于热衷的人。但是在这其中找到平衡也并不是什么难事。一个好的安排就是与一个人一起去完成共同的目标或者解决同一个问题，然后定期进行结对编程来看在写代码的过程中有什么新的东西或挑战。

　　这种合作方式在设计和编码时，对于那些发现自己总是在不停地被叨扰的项目领导来说非常有效。

　　避免不必要的无意义的开会

　　对于开发者来说没有什么比毫无目的地坐在会议室里浪费时间更糟糕的事情了。因为这样也就浪费了写代码的时间。所以就需要学习怎么有效开会来避免这种无意义的会议。

　　可以使用下面的5项规则：

1. 目标——开会的目的明确吗？确保每一次会议都有明确的目标。例如：分享信息，收集信息，共同探讨解决问题或达成共识。
2. 产出——当你知道开会要达到什么样的结果时，你可以缩短会议时间。定义会议成功的准则（应该和目标一致）可以帮助会议不跑题。
3. 参与者——取消/安排一个会议而不是与不相关的人开会会更好。这篇来自Esther Derby的Tweet就写的比较好。
4. 问题点——清楚的知道问题点可以使会议不越轨。
5. 进度——每一次开会都应当清楚知道该如何进行，人们期望如何参与，需要的一些特殊的规则，一个会议主导者应当明确开会的目的来满足与会者的期望。

　　学会说“不”！

　　领导的艺术是说“不”，而不是说“好”，说“好”是很容易的。——Tony Blair

　　作为一名领导，或许你总是永远承担着过多的压力。你说的“好”越多，你就有越少的时间写代码。如果写代码对你来说真的很重要（也应该如此），你就需要能分得清什么事情重要，什么事情可以让别人或者非技术人员来做。

　　规划出整块的编码时间

　　我知道一些项目领导会在日历上标记时间来确保自己可以有不被打扰的编码时间。“开发者须知”里讲了打扰带来的思维中断。并且相比于开发者，项目领导人被打扰的几率可要大的多。

　　总结

　　对于项目领导人来说花费时间写代码是重要的，但是其他的很多事情又会占用相当多的时间。保持平衡是不容易的，但是以上的技巧可以帮助你。如果你有其他的建议可以参与讨论。如果你喜欢这篇文章，你也会对这本书《与项目领导对话》感兴趣的，这是一本分享世界范围内的超过35岁的项目领导的经验书籍。现在在 Leanpub上可以看到。

　　英文：THEKUA，译者：Misslio