|
最近在看李笑来推荐的《领导梯队》。其中描述了从管理自己到管理他人的转变，其中一项不容易适应的事情是要懂得授权和分配工作。 懂得授权和分配工作是成为管理者道路上要习得的首要技能。因为这点非常重要，并且是不少人第一次从个人贡献者转变成一线管理者时做得不好的地方。 目的授权和分配工作任务其实只是手段。这样做的最主要的 目的是多人协作，达成目标并同时提高每个人的能力 。 心态人要适应变化，首要必须是心态上的调整和适应。很多人没法把一件事情做好，很多情况下是因为心态没有改变过来，而不是他没有那种能力。其实如果能把握好上面说的目的，心态已经是调整好一大半了。 在个人贡献阶段，每个人基本只要为自己做的事情负责，做得又快又好就行。这个阶段对个人硬技能的修炼提高是比较明显的。所以，个人也能比较容易得从中获取安全感和成就感。 一旦个人能力提高到一定程度，很多公司就很自然的让他领导或者管理他人一起做事情了。那么，他用自己的专业技能来做事的时间比例就会减少，有相当一部分，甚至可能是大部分的时间都要花在管理和协调上面。 这种转变其实对个人的心理变化会有很大影响。因为，这意味着他要舍弃熟悉和一直依赖的专业技能，去做一些虚而杂的管理，心理安全感上面会有很大的压力。特别是近年来全球都推崇组织扁平化，削减不必要的层级，还有一些管理人员失业后不好找工作的消息，让不少刚上升或准备上升一线管理的人都心有顾忌，放不下自己的专业技能。所以，很多人对这种转变是心有抵触的。 但是，软件开发领域，一旦涉及多人协作，少至两人，尤其当你是担当组织领导这样的角色的时候，必须懂得如何授权和分配工作。并不是说你一定是成为管理者后才要习得的技能。 再说，这样做对自己也有很大的好处。你可以把自己熟悉，但是对别人来说有挑战的工作交给别人尝试，然后自己腾出时间来做更有挑战的工作。但是，这并不意味着授权和分配工作就是把自己厌恶的工作交给别人做。下面会说到这个问题。 那么我们要如何授权和分配任务呢？ 授权，首要的是要能放心 。如果你的下属，没有一个能让你放心的话，是没法授权的。放不下心是很多管理人员做不好这点的原因。但是，我们要搞清楚，放不下心是下属的能力，做事态度的问题，还是我们自己的心理问题而已。 一般来说，你带领的团队，可能能力会比你弱一点，你也才会担当或者被任免为领导角色。所以，如果只是下属的能力还暂时不胜任，你要做的是指导他，让他的能力慢慢提升，从而胜任工作并解决问题。而不是你觉得他做的不够你快和好，就自己下场抢了下属的工作来做。这样的话，他永远无法提升，你也无法放心。就软件开发而言，下属要下场写代码，你最好只是审查他的代码，分析他哪写的逻辑不清晰，需要重构等。 方式如果你能做到放心，并且愿意授权和分配工作了，那应该怎么分配呢？ 分配原则擅长什么做什么软件行业一直有前端，后端，数据库管理，测试和运维等分工。所以，按擅长的领域来分工也是很明显和自然的一种方法，当然你的下属可能也会按这样的原则来揽任务。再说，项目期限紧的情况下，多是只能这样安排。 不擅长什么做什么可能不是很多人会采取这种策略。而且，不少技术人员，尤其是比较资深的，有一些不恰当的歧视心态，并且不愿意走出舒适区，只想干自己喜欢的技术。比如，开发看不起测试，后端看不起前端，XX 语言看不起 YY 语言等。 但是，如果时间充裕，在培养新人或者有机会挑战自我的时候，我都会时不时专门挑下属不熟悉或者不擅长的领域，让他去死磕一下。一方面可能是我在的公司团队都比较小，要做的事情都比较杂。无论是前端后端，数据库等都要自己搞。另一方面，我也想通过这种手段来让大家有机会扩充知识面，并了解不同的领域有什么不同和相通之处。并更好的理解上下游合作伙伴，减少歧视的心态。 想做什么安排什么这就没什么特别好说的，只要团队内沟通协调良好，大家互相支持，尽量都可以这样安排并结合上面两点来考虑。 不能长期把垃圾工作交给他人这一点是特别要注意的地方。当你承担了分配工作的重任，不是说随心所欲的按自己喜好，下属亲疏来分配的。所以，即便上面说了，可以把自己熟悉的工作分配出去，但不代表你可以把你不想做的垃圾工作都给别人。一方面，这样做并不能锻炼你的下属，他的能力无法得到提高。另一方面，他会对你这个领导产生厌恶感，你和团队之间凝聚力就会变差，而且以后他还会很不愿意听你的安排和意见。 相反，我通常是把垃圾工作自己揽过来处理。真要交出去的时候，可以和下属讨论怎么减少这类型的工作，或者有没有什么好办法来解决。比如说写一些自动化的脚本或者工具，运用新的技术等。这样，就可以将无聊的事情变得有趣，并且对大家的能力，眼界也有所提高。 跟进，不是放任自理其实，我觉得授权和分配工作只是第一步。重要的一步是如何跟进和指导，不是分配完就不管，最后到期限时追进度而已。 目标明确其实这点不能说是在跟进时才考虑，因为一开始分配任务的时候，也应该清楚的解释好工作任务的内容和目标。不同的任务类型，处理手段或隐含的目标是不同的。而且，有些人做着做着，可能就深入细节，偏离了大方向，延误了进度。所以，跟进的过程中，要时不时确保目标明确。 之前我安排一个下属通过 POC (Proof of Concept) 来确定 Solr 是否可以用来取代数据库 SQL 查询以提高性能，另一个下属是做一个新功能的页面原型，和通过 POC 来确定初步构想页面结构和操作能否实现，有没有技术难点，并让业务分析人员尽早确定。你们觉得各自的“目标”是什么呢？他们清楚吗？ 虽然两个任务都涉及技术的 POC，但是分析角度和要求有细微不同。 第一个的任务，因为是针对旧功能的改造。首要的是充分了解旧的 SQL 查询是怎样的逻辑。如果换成用文本检索的方式，新的数据存储结构和字符的模糊匹配特性，能否完全模拟出原来 SQL 查询的功能？即便不行，那是否还满足当前业务的要求？这边对技术细节的理解和对比要相当清楚，以免换技术方案后，对原功能造成大影响。 另一边的页面原型，主要则是把握大的方向没有问题，主要的交互功能点能实现出来就可以了。一些很细的技术边角，即使后面真的出现并无法解决，可能再和业务商量一些替代方案就好了。而且还处在我们向业务方出提议阶段，时间上希望能尽快先有一个版本。如果业务对我们提议的页面原型有些修改意见，原先的技术问题可能都不用解决。 授之于渔当下属遇到问题不知道怎么样解决的时候，我看过不少领导直接上来就给具体方法或者答案，手把手教怎么做，代码该怎么写，有什么 API，哪里有类似的代码可以抄等。 可是，我是相当不喜欢这种方式。因为：
看到下属遇到问题，我一般至少准备分两三次来进行指导。
这里要把握好中间间隔的时间，提示的程度需要看情况而定。项目的松紧，人的能力等都要考虑。 不接受意见怎么办？当你对下属做出指导，提供意见或者别的方案的时候，他可能并不买帐。 这种问题其实很难解决。要降低这种问题出现后能温和的处理，首先当然不能粗暴地命令。正如上面所说的，解决问题的答案不止一种，就像编程语言和框架一样。所以，你往往需要从技术或者业务上， 真诚和耐心的详细分析 ，你们的方案主要区别是在哪里，为什么说你的考虑可能在目前情况下更优。有些时候，可能真的是技术上来说他们的方案确实更完善。但是从项目性质或者进度上来考虑，需要舍弃一些东西，没必要做得太复杂。有时我们还可以尝试寻求可测试或可量度的手段来进行比较，又或再拉几个人来讨论，发表见解和投票等。 一般来说，优秀的 IT 人员，在摆事实和讲道理后，都会接受合理的意见的。如果作为领导，一直都是很真诚的教导下属，更容易共同寻求最终两方都能接受的方案。 |
|
|
来自： mentor1974 > 《授权》
