一个程序员初试管理的一年多

去年七月份离开了上一家公司，在那里度过了对我职业生涯来说至关重要的4年。期间遇到了很多给我巨大帮助的朋友，我感觉除了技术的提升，心智上也得到了成长，也从最初的一枚菜鸟慢慢成为能够独当一面的团队骨干。在后期也开始接触一点点管理，主要是带新人。因为难度不大，并没有什么积累，更谈不上什么管理经验。来到现在的公司之后，才开始正式接触管理，一年多的时间里遇到了各种各样的状况，也解决了形形色色的问题。主要想从我个人的角度出发，记录一下自己在这一年多的时间里的一些感悟。

一、转换角色

---

因为确实没有什么管理经验，入职后我给自己提了个要求：坚持不定期地和老大主动沟通。有一次和老大面谈时，他问了个问题：为什么感觉你们团队只有你自己总加班，其他人并没有那么忙？我才忽然意识到自己这个问题。不得不承认自己当时仍然停留在团队骨干的阶段，分析了一下原因，主要有两个：

原因一：对团队不足够了解，不足够了解就很难充分信任。
当有一个需求时候，尤其是较为紧急和复杂的需求，内心会纠结：交给他会不会有问题？他能不能按时搞定？我自己做是不是更有把握？这种纠结一旦出现，最终结果往往是：算了，还是我自己来吧。在公司的起航培训时，老师说这种现象在刚开始接触管理的人群中非常普遍，它的后果也很明显：自己累，同时也剥夺了他人成长的机会。我后来经过一段时间思考后，采取的解决办法是对任务拆分，既然觉得整块交出去有风险，那就通过拆分来分解风险。随着对团队的熟悉和团队成员的自身成长，拆分的粒度慢慢放大，直至每个人都能独立负责一整块需求。现在团队的每个妹子基本上也都达到了这个要求。

原因二：不好意思给他人分派工作。
在团队成员手里有需求的时候我的这种表现尤为明显，后来我分析了一下，完全是一种不自信的表现。其实，只要把需求排期控制好，即便是有需求重叠，我们通过均衡每个人的任务队列，正常分配即可。如果仍然有疑虑，可以通过不定期沟通来确保任务的进度。

把自身定位思考清楚本身就是一件很难的事，想要及时的感知变化更加困难，但旁观者清，身边的同事绝对是我们最好的帮手。及时收集反馈，非常有利于我们自身的改善。

二、完成需求 VS 把事做成

---

这两者的区别还是非常大的，尤其是经过这一年多的时间，感觉愈加明显。

完成需求，是从一个开发者的视角来看，对自己最基本的考核标准，也是整个的开发过程（需求讨论、开发、测试、上线）中的其中一环。

把事做成，则要求跳出开发者的角色限制，从整个需求层面有一个宏观的把控，而不应该把视野局限在自己仅仅是一个前端或者后端开发者的身份。

记得年初做主站前端重构，这完全是一个技术自发的需求。我当时作为需求发起人，保证前端重构开发的完成是我最基本的工作，同时还需要申请产品资源作为业务支持，协调后端对模板变更，以及申请测试资源确保上线前的质量，甚至于包括后期灰度计划的制定和推进。在这个过程中，深刻地体会到了owner的含义，当你把目标集中在如何把事情做成的时候，中间每个环节都是你要负责的部分，这比单纯的完成需求难度要大很多。另外一方面，当想着把事情做成的时候，中间的过程是否要严格按照流程就显得没那么重要了，比如申请产品资源受阻时会立马调整策略：自行梳理问题后找产品确认，无需产品同事的全程参与。还有非常大的一点感悟：在大公司环境下，大家互为资源，如果想把事情做成，协调能力是非常重要的一项技能。

上面的例子是技术发起的需求，其实对于日常的产品需求，也可以试着打破对自己身份的限定。在整个过程中，只要发现有任何不合理或者值得改进的地方，作为参与其中的一份子，都应该及时发声，提出自己建设性的意见，比如这个需求点是否符合用户预期，接口这样设计是否便于以后扩展，返回的数据结构是否可以整合等等。大家都本着把事情做成的态度，对于这样的参与热情，相信不会有人忍心浇凉水。

三、一定要做时间管理

---

随着负责的事情越来越多，每天戴上耳机安心敲代码已成为奢求，总会被各种排期、需求评审、技术方案讨论打断。曾经有一段时间，感觉整个人都有一种撕扯感，被折磨的焦头烂额，但一天下来又感觉什么都没干，尤其是这一天没怎么写代码的时候，焦虑倍增。痛定思痛，感觉自己的时间管理应该是重点思考的事情了。结合以前的工作方法，我做了一些整合，以周为单位，把每天的事情通过表格的形式罗列出来，包括具体实施时遇到的问题等，具体如图所示：

慢慢的我发现自己已经成为了笔记的重度依赖者，当然，这没什么不好，好记性不如烂笔头嘛。一个非常大的好处就是，这每一周的记录都是阶段性总结最好的素材。不过，利用笔记最大的收益还是做到了对事情有规划，这一点非常重要，无论生活还是工作。

还想说的一点，当开始接触管理之后，可能代码的输出不再是衡量工作的唯一标准了，所以，有时候一天都在参加会议或者培训，只要这些事情在规划之列，那就无需纠结，按计划执行即可。

四、技术仍然是安身立命的根本

---

每个做技术的人应该都听过这句话，说白了就是告诉我们：一定要把自己吃饭的硬实力整上去。

当作为团队主力时，提升技术才能保证我们高质量地完成需求，同时也能给身边的人提供一些技术支持。作为团队负责人的时候，除了给自己的团队成员提供技术支持之外，还要为团队提供技术方向的引导，以及对团队的技术水平负责，另外，团队的技术氛围也很大程度上取决于团队负责人的技术水平。

可以说，虽然我们处于不同阶段时，技术对我们的作用不同，但从我们自身的价值来说，技术始终是第一位的。

基于我的观察和经历，我觉得：对于技术领域的管理，技术好不一定能做好管理，但技术差一定做不好管理。

技术领域的管理还是非常需要硬实力支撑的，正所谓“一将无能，累死三军”。所以，目前为止，我还是要求自己一定要坚守技术，极力避免出现吃老本的不堪境遇。

归纳一下，这里主要是想阐述：接触管理之后并不意味着技术相比于管理经验不再重要，相反，管理岗位对技术的要求更高了，我们应该始终坚守技术带领团队成长。

五、持续学习

---

上面说了硬实力的重要性，其实除了在自己的专业领域持续学习打造硬实力之外，还应该适当扩大自己的技术视野。

技术领域有那么的多方向，我应该学哪些？学到什么程度？这些问题曾一度困扰着我，不过，后来我思考了一段时间之后，给自己定了个准则：凡是自己工作中接触到的但还不了解的，都应该在学习范围之内，至于掌握程度，取决于和自己专业的密切程度。

前端开发日常接触最多的就是后端了，其中涉及到接口的设计、数据库的存储逻辑、后端缓存的原理、nginx的原理和配置等等。如果掌握了这些，对于我们制定和评判技术方案有非常大的优势。举例来说，网站用户登录态是个非常常见的问题，但我发现有很多同学对维护登录态的原理不很清楚，对前后端的边界有点模糊，以至于出现前后端都要维护cookie的现象。再比如，如果我们掌握了nginx的基本配置，完全可以在本地模拟线上域名，对于一些和域名相关的自测在本地就能搞定。

曾经和一个面试官讨论过为什么现在的前端岗位或多或少都要求一点后端的技能或经验，他给出的观点是，这样的同学面对整个系统时看到的层次更深，我对此深表赞同。

另外，测试领域的一些思想和方法也非常值得我们学习。我们的自测很多时候都是跑通就行，其实我们提测前用测试的思维思考下，能够规避掉很多问题，比如说场景法测试、边界值测试等。

除了学习后端和测试领域的一些技能外，学习一些与人打交道的软技能也非常必要，比如沟通、协作以及寻求资源。软技能的学习要比技术的学习更复杂一些，没有统一的标准，每个人的风格又不一样，所以更多的需要我们自己去多总结。我觉得软技能的唯一衡量标准：是否有效。所以，无需过多纠结于细节，有了想法就去验证，然后再根据反馈的结果及时修正，这样就能快速建立起自己的一套软技能体系。

至今还记得以前的老大曾说过的一句话，大意是：在学习方面，现在的投入未必会立马收效，但在将来的某一天终将受益。

六、最后

---

以上都是我接触管理以来的一些感悟，最后还想说一下现阶段对管理的认识。我觉得自己现阶段的任务就是能够带领团队前进，如何才能做到呢？我总结了一下，就是“信服”二字，可以拆开来看：

信
即信任，关于信任在团队中多重要感觉无需赘言了，主要想说一个关于信任的客观规律：可能需要做好一百件事情才能建立信任，但毁掉信任可能只需要搞砸一件事情。这是我亲身经历后最深刻的感受，所以，对于别人的信任要心存敬畏。

服
即服众，一方面体现在团队负责人必须以身作则，无论是对技术的追求，还是对约定的遵守。另一方面体现在团队负责人的硬实力上，当然，这并不是意味着团队负责人的每一项技能水平在团队中都是最高的，但团队成员需要帮助的时候，必须要给出行之有效的解决方案。

感觉管理是一门非常高深的学问，之前也尝试过找一些关于管理的书来读，可能是自己水平有限，完全没有任何应用，甚至都不如一场面对面的公司培训来的生动。目前的主要学习方式还是多观察，多思考，然后多尝试，期待自己有更进一步的提高吧。

本文参与了 SegmentFault思否征文「一起分享你的故事」，欢迎正在阅读的你也加入，分享你的故事。