最近在主管领导的强烈推荐和热切关注下断断续续的读完了一本书：《职场晋升第一课：交办的技术》。坦白的说，在读此书之前，我对这种直觉上属于职场社科的书是有所不屑的。我总觉得除了专业能力之外，在职场上自己的经验和个人的理解才是最深刻、最有价值的东西，模仿不来也很难借鉴学习，所以怎么做，全凭个人见识与反应。平心而论，我觉得自己还算是一个不错一线技术人员，但是在组织更多的人、一个技术团队去应对各种问题去良性发展，我会感到自己能做的比较有限。很多具体的事情总会感到无法放心的交给其他的同事去做，事事都需要亲力亲为，然后自己的时间被具体细碎的工作无限的占据，在更高的高度上即便心有余而力也不足。这本书正是针对我目前所处的工作状态下所总结的策略，即：如何把事情合理的交办给下属。
“有很多时候团战输了，总感觉队友不给力”
一个多人合作的技术团队，不同人之间的技术能力总是有差异；遇到某些棘手的业务，会感觉到交给其他的人去做非常不放心，觉得他没有思路、没有灵性把事情办好；即便让他最终去做完了，回顾他的实现的方式，也往往会感觉不是那么称心如意，说不出的难受。“总感觉队友不给力”——这可能是程序员的自傲甚至自负吧！
放手让他做
但别忘了，游戏是五个人的游戏，团队也不是一个人的团队。第一件要学会做的事情，就是放手让他去做，让他在挑战和困顿中磨练成长。对于我而言这更多需要一种心态上的转变，需要挑选合适的人做合适的有挑战的事，并且留出可能失败的空间给到对方。那么具体到实际业务中，团队是否能承受一定程度的“失败”，比如说实现的非常丑陋甚至有不易察觉的 BUG？当然，这种肯定要极力避免，但不代表说为了避免它我就全都自己来干。只要这些问题发生在过程中，那么通过代码审查及测试用例，应该能避免问题最终到线上。开发过程中的问题的确也会带来人效的降低，但这也许是一种代价：为了培养员工能力的一种代价。
- 给予放手去做的空间：人都是在遇到了各种问题、想办法去解决的路上才能更快的学习进步成长的；
- 允许失败：做好代码审查和用例测试，卡好最后一道关卡，避免实际产生难以承受的失败后果。
如何让他去做
很多开发人员是盲目的，在做业务是建立在既有的范例或自身过往的经验，不能结合实际现状思考更合适的做法。那么在交办任务时，需要把任务的想明白、说清楚。不一定包含具体怎么做，但是可以有一些自己看待问题的思考和担忧，从而激发执行任务的人的思考能力。要有足够的交付标准，让他在此范围内发挥到极致。
- 允许在交付标准范围内具体做法差异的存在：不必一定要求他人的实现都和自己去做的方法是完全一致的，只要在合理的交付标准下，应该都是能接受——如果不能接受，需要考虑下交付标准是否制定的合理，以及从架构流程上是否有足够强的客观约束能力；
- 不推卸责任，不过分苛责，面向未来而不是面向既已发生的失败：不要总是去追究说这个代码是谁写的 BUG 以及要如何处罚，而是要思考将来如何避免类似问题的发生；
- 充分信任，不随便干预：尽量避免以建议甚至命令的方式去表达意见，更多应以自己的看法、观点交流等更主观的方式沟通——当然还是上面所提及的，最后一段关卡应该有的还是不能少。
工作不能都在”救火“
将工作内容按重要与不重要、紧急与非紧急的纬度，可以分为四类：
- 紧急且重要：核心业务，保障最基本的工作利益的任务，需要立即投入实施；
- 紧急但不重要：应付类工作，比如某些会议、汇报材料等，这些往往比较耗时，尤其是担当了一定的管理职责后。如何减少这些时间呢？
- 重要但不紧急：没有期限的工作，例如思考当前项目的技术规划路线，改善工作流，解决某些长期的技术债务等等。这些虽然不能直接的影响核心工作利益，但它更多的属于”投资预防活动“——这类往往难以着手。如何才能真正有让这些事务投入实施呢？
- 不重要也不紧急：等待，发呆，闲聊等。
重点思考一下这些重要但不紧急的”没有期限的工作“。比如目前的业务现状存在大量的技术债务，但是从长远规划和架构设计合理性上，的确有不少不错的思路和方向和手段。虽然按照既有的模式，一切也都能走的下去，没有太大的问题，但不改变现状，可能就不得不每一天都在现状里挣扎，工作就会无限恶性循环，变成无尽的救火，身心俱疲。
如何才能将这些“重要但不紧急”的事项执行下去呢？书中给出了两个方法：
- 将复杂的事情拆解为可以一步一步进行的小的工作点；
- 设立里程碑，给任务制定期限。
这样一来，重要但不紧急的任务也会逐渐变成重要且紧急了，也许这样才能让改变发生。
总结
全书内容不多，只有 150 页，但在具体问题分析上，从转变事必躬亲思想、交办下属、培养团队能力、思考和组织工作内容等方面，的确有很多切合了我所正面临的实际问题，适当的停留下来阅读思考还是颇有裨益的。事在人为，还是需要有更大的勇气和魄力去承担具体业务之外的更宏大的事务，这样技术上才能有所突破。