关于技术管理的一点点思考
去年调任北京研发中心，负责整个部门的研发管理工作。从这个时间点开始，真正和管理这件事情有了一些关系。当时因为心态、工作安排的原因，也没有系统性的思考过管理的细节，大部分是凭自己过往的经验和感觉，按着野路子做事情。没有经过系统性思考的执行其实大部分都会碰壁，前段时间偶然机会读到一份PPT，专门讲技术管理的，内容特别接地气，细节也挺多，反复阅读并进行了消化，也借着这个话题，我把自己的思考也整理了一下。（管理本身是一门非常宏大的学科，深度和广度都不是现阶段的我能够说明白的，我这里的话题也仅仅局限于中小型团队的技术管理）
作为「技术管理者」，确实有着特别的一些挑战，非常认同分享者重点列举的这3个：
挑战1：队员做的工作没有自己好，花时间去沟通还不如自己去做。
挑战2：感觉自己的技术在退化，长期不写代码觉得自己没有价值。
挑战3：认为管理没有什么技术含量，只要能把队员管理好就行了。
分享者的整个PPT的内容也是围绕这3个挑战展开的，指出了在面对这3个挑战的时候，大部分的人会犯的错误，以及应该用什么的方法模式避免这类错误。
我从另外一个角度看待技术管理这件事情，视角上应该更能完善这3个挑战所描绘的边界。首先给出我对技术管理这个事情的基本思考：
管理的本质是「管事+理人」。「管事」落在事情的执行上，保证项目成果的交付；「理人」落在人际协调和资源调度上，为「管事」提供支撑。
「管事」有一整套的方法论，主要包括计划制定、任务分配、节奏控制等，这部分依赖管理者对项目专业知识的储备以及对项目组人员的熟悉度，相对来说简单一些。
而「理人」部分，相对来说就比较复杂了，上文说到的几个挑战，其实都属于「理人」的范畴，技术管理领域的人际关系，主要可以用如下的图来概括：
这里面，我认为最核心的就是要把自己、老板这部分给理顺，然后才是搭档,队员。
自己
对于技术人员而言，刚开始接触到管理工作时，自己这一关，最大的挑战确实就是：
感觉自己的技术在退化，长期不写代码觉得自己没有价值。
这里发散来讲的话，有这么一些点：
- 认清岗位价值，以前是自己做，现在是带领团队做，更有挑战了。
- 自己很少写代码，才有更多的时间提高团队的代码质量。
- 将自己熟悉的工作教会队员去做，自己去做感兴趣且不熟悉的工作。
在认知上提升了对管理岗位价值的的理解，确定自己喜欢（至少不排斥）管理工作，那就应该义无反顾的选择技术管理工作，将自己从相对熟悉、比较繁琐的代码工作中解放出来，去做自己不那么熟悉但是感兴趣，更能提升研发质量的技术管理工作。
除此之外，其实还有个挑战也是大部分人都会有，而且也是比较关键的点：
为什么会是我？
这个挑战来自于不自信，感觉自己对编码工作可能比较熟悉，至于管理工作嘛，完全是另外一个领域，能做好吗？在心理学上有个著名的`冒名顶替综合征，很多人倾向于对自己进行否定。
我不行，大家都被我蒙骗了，大家都觉得我厉害觉得我优秀，其实只有我自己知道根本不是这样的，我取得的成就靠的都是偶然的运气，我不配得到别人的认可和称赞，我就是个名不副实的骗子，是个能力有限没啥本事的冒牌货，不值得获得成功。
有这种综合症的人无法将自己的成功归功于自己的能力，无论再强大再成功，也会觉得自己的成功不是理所应当的，自己是运气好、被高估了。
对此，分享者有个很不错的结论：
- 老板的安排没有错，是自己思路没有转变过来。
- 只要老板认可了你，你就有这个能力。
- 应该抓住这次难得的机会，好好锻炼自己的管理能力。
自己这个维度，把「岗位价值」、「自信」这两个问题解决了，这一关基本上就算过了。
老板
分享者没有太多谈到老板的维度,我认为在这个点上需要完善一下。对于技术管理者而言，老板的意图和目标其实非常重要，这部分直接决定了管理者如何分配资源和设定优先级，尤其一些大的方向上，更要和老板多沟通，确保理解上没有偏差。
就我自己的经验而言，初阶管理者在这个维度首先碰到的第一个挑战会是：
热衷于执行性事务，每一个大小事务都继续等着老板发号施令。
技术人员的需求来源和任务相对比较明确，老板，产品经理等都会持续输出需求，技术岗位的日常工作就是按计划实现这些需求，完成任务就可以了。而作为管理者，恰恰部分进入了需求输出者的角色，这时候需要思考项目、产品的下阶段方向和目标，想法成熟以后，需要表达出来跟老板确认可行性，进一步推动在团队内执行。这个转变其实比较大，从技术岗位的被动执行变为主动思考，向上沟通，向下推进。这个问题，应该从如下方向进行调整：
- 培养自己从细节中抽身的习惯，将实现类工作安排给队员，自己的工作要专注于对全局的思考。
- 不要等着老板发号施令，自己主动为团队设定目标，目标正确性提交给老板评审。
- 将目标拆成多个阶段，向老板阶段性汇报进度和成果，及时调整方向和目标。
在管理岗位上，有一个最明显的感受，就是事情的变数往往比技术岗位更大。一方面来自于一些敏感信息更早传递到管理层，另一方面则是因为管理岗位处理的事情本身不确定性因素会大一些，不像技术岗位的事务，确定了方案就是往前推进就行了，在项目过程中基本上不会插入其他的事情，也不会突然宣布项目方向要做变化。所以我在这里比较强调阶段性汇报，及时向上沟通，有助于资源争取和方向上的及时调整。
老板这个维度，全局思考、目标设定、向上沟通是几个重要的关键字。
搭档
管理岗位其实挺孤独的，如果你有一个搭档，那么恭喜你，你是幸运的。搭档的存在，一方面可以共同承担压力和职责；另一方面，两个人的思考碰撞其实比一个人孤独的瞎想效果要好太多，抛开运气差的原因碰到了无法认同的同事，到了管理岗位，其实搭档基本上都会是气味相投才能长期持续共事下去的。对于搭档，我比较认同分享老师的几个观点：
- 和搭档建立信任关系。「私下对他说:我觉得咱们兄弟俩合作，一定天下无敌!」
- 认可搭档的重要价值。「私下对他说:这个项目如果没有兄弟你，恐怕就无法完成了。」
- 极力称赞自己的搭档。「在众人面前说:我跟他一起合作，学到了很多东西」
搭档这个维度，最重要的关键词就是认可、称赞。从内心上真正认可对方的价值，和他私下也建立信任关系，并在人前称赞他，那么，这个搭档一定会在你的职业生涯中助力，也能推动自己的成长。
队员
队员是管理人员最重要的资源，他们构成了你的团队，决定了你的整体执行能力，也是一线管理者最需要关注的部分。这里大家经常会碰到的挑战,我很认同分享老师的说法：
队员做的工作没有自己好，花时间去沟通还不如自己去做?
在这个挑战下，一般人的做法往往是：
错误 1:帮队员调整代码
错误 2:替队员完成任务
错误 3:催队员提高效率
这些做法，把队员推向了自己的对立面。每个人都有自己的自由意志和尊严区域，当老大表现出对自己工作成果的不信任，插手到自己的工作内容的时候，造成的后果就是：
你帮助了他，可他并不认为你是在帮助他。
这里面，既有认知思维的问题，也有为人处世的问题，对应的处理方法简单归纳如下：
以
指导模式（而非自己动手）提升队员的工作能力。第 1 步:赞扬他最近的工作业绩。告诉他:你当前的任务完成得很漂亮，我非常满意!
第 2 步:激励他得到更好的成长。问他:你是否希望自己能做得更好?我有些经验可以与你分享。
第 3 步:指导他把工作做得更好。告诉他:你不妨借鉴一下我的经验，你一定会从中受益。
从心底尊重队员，从帮助队员提升的起点出发（而非简单完成任务的角度），调整自己的心态。
降低要求，关注进步，只看增量。
要学会“授人以渔”，教会他思考问题的方法。
项目延期了，不是人有问题，而是项目管理方法有问题。
用
授权模式表达目标，确定有效沟通机制。第 1 步:清晰表达工作目的与内容。（这项工作的目的是什么?要做的事情是什么?(不要告诉他怎么做)）
第 2 步:得到授权方的确认和反馈。（问他:你是怎么理解这项工作的，有什么疑问吗?）
第 3 步:与对方建立定期沟通机制。（问他:我们多长时间沟通一次?每次沟通什么内容?）
做到了这几点（指导,尊重,授权），基本上队员这部分也能解决80以上的问题啦，对于20-30左右的团队，这个理论完全可以支撑的。
管理很宏大，而且是以实践为主的学科，我今天应该算是第一次系统性的整理这方面的思考，以后在日常工作中多多思考和实践，完善这套体系吧。