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

时间 2019-11-05

原文原文链接

去年七月份离开了上一家公司，在那里度过了对我职业生涯来讲相当重要的4年。期间遇到了不少给我巨大帮助的朋友，我感受除了技术的提高，心智上也获得了成长，也从最初的一枚菜鸟慢慢成为可以独当一面的团队骨干。在后期也开始接触一点点管理，主要是带新人。由于难度不大，并无什么积累，更谈不上什么管理经验。来到如今的公司以后，才开始正式接触管理，一年多的时间里遇到了各类各样的情况，也解决了形形色色的问题。主要想从我我的的角度出发，记录一下本身在这一年多的时间里的一些感悟。前端

1、转换角色

由于确实没有什么管理经验，入职后我给本身提了个要求：坚持不按期地和老大主动沟通。有一次和老大面谈时，他问了个问题：为何感受大家团队只有你本身总加班，其余人并无那么忙？我才突然意识到本身这个问题。不得不认可本身当时仍然停留在团队骨干的阶段，分析了一下缘由，主要有两个：nginx

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

缘由二：很差意思给他人分派工做。
在团队成员手里有需求的时候个人这种表现尤其明显，后来我分析了一下，彻底是一种不自信的表现。其实，只要把需求排期控制好，即使是有需求重叠，咱们经过均衡每一个人的任务队列，正常分配便可。若是仍然有疑虑，能够经过不按期沟通来确保任务的进度。数据库

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

2、完成需求 `VS` 把事作成

这二者的区别仍是很是大的，尤为是通过这一年多的时间，感受越发明显。缓存

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

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

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

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

3、必定要作时间管理

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

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

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

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

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

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

能够说，虽然咱们处于不一样阶段时，技术对咱们的做用不一样，但从咱们自身的价值来讲，技术始终是第一位的。

基于个人观察和经历，我以为：对于技术领域的管理，技术好不必定能作好管理，但技术差必定作很差管理。

技术领域的管理仍是很是须要硬实力支撑的，正所谓“一将无能，累死三军”。因此，目前为止，我仍是要求本身必定要坚守技术，极力避免出现吃老本的不堪境遇。

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

5、持续学习

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

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

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

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

另外，测试领域的一些思想和方法也很是值得咱们学习。咱们的自测不少时候都是跑通就行，其实咱们提测前用测试的思惟思考下，可以规避掉不少问题，好比说场景法测试、边界值测试等。

除了学习后端和测试领域的一些技能外，学习一些与人打交道的软技能也很是必要，好比沟通、协做以及寻求资源。软技能的学习要比技术的学习更复杂一些，没有统一的标准，每一个人的风格又不同，因此更多的须要咱们本身去多总结。我以为软技能的惟一衡量标准：是否有效。因此，无需过多纠结于细节，有了想法就去验证，而后再根据反馈的结果及时修正，这样就能快速创建起本身的一套软技能体系。

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

6、最后

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

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

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

感受管理是一门很是高深的学问，以前也尝试过找一些关于管理的书来读，多是本身水平有限，彻底没有任何应用，甚至都不如一场面对面的公司培训来的生动。目前的主要学习方式仍是多观察，多思考，而后多尝试，期待本身有更进一步的提升吧。

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