前言
如果说技术可以是非0即1，非黑即白的科学基础的话，那么人文管理便是游走于中间灰色的边缘地带，因为人的复杂性要远远高于技术。了解我的童鞋都知道，除了工作任务要求之外，在以往的工作、生活相处中我一向不会把自己的个人思想理念灌输在童鞋们身上，因为每个人对待这个世界的生存法则不同，看法自然也不尽相同。同时，我也更懒得去争论孰是孰非，因为这些本身就没有对错。
在起笔这篇文章之前，我也只是将自身这近十年的经验分享给大家。知识与经验的传承能够让彼此少走更多的弯路。但需要注意的是，观点不在于对错，求同存异本就是人类文明和谐发展的根基。在此，我也不建议童鞋们不加判断的吸收，形成自己的独立思考才是对于自身成长最好的保障。
其实，管理也包括个人的学习成长。一个合适的项目管理者本身也需要具备快速的自我学习能力，如此才能应对更多的挑战，不断挑战更高的极限。在本期文章中，我会将内容拆分为个人学习篇以及项目管理篇，以更好地与大家分享自己归纳的知识与理念，而这其实也是对自己总结能力的一次自我挑战。
个人学习篇
建立完整的知识体系链结构
当今时代我们能够获取知识的渠道多种多样，甚至已经是信息溢出，尤其是技术知识，其中知识点繁杂交错。而我们的学习往往是碎片化学习，这会导致在掌握整个知识体系时，各个知识都是一个个孤岛。
链结构是数据结构中的一种，是由许多节点构成的，其中各个节点之间又彼此关联。不仅能通过一个节点在整个链式结构中快速看清整个结构体，同时也能顺着节点之间的联系找到自己想要的某个节点。之所以用此结构来做比喻，是因为如果能够在自己的知识领域内去归纳总结贯穿各个知识点，可以让自己更系统化地厘清整个知识体系结构，无论是后端知识体系结构还是前端知识体系结构。
建立起大脑知识库索引
新系统不断推陈出新，新技术不断更新迭代，由此我们所要掌握的知识体系只会越来越庞大。在个人时间与精力安排来看，是不可能在短时间内充分掌握一个知识体系的所有细节，因此这就需要个人在浩瀚的知识海洋中建立好知识库索引，只记住重要的知识组成部分，方法是可以记在线上，也可以用笔记。而后在未来工作生活中需要深入接触时，便能快速定位该知识，继而深化学习其细节原理。
每天成长一点点
问自己，你是一份工作重复了365天，还是365天中应对不同的挑战？
我不太相信有人会甘心活在当下而没有想法改变现状，尽管在无情现实中，星星火苗一出现便会被社会毒打回去。
那么要如何改变现状还能减少被毒打的概率呢。（注意被毒打也是好事）
- 以工作为起点衍生出新的技能树
打个比方，最简单的工作处理方案，一般都具有重复性和单一性特点。但工作本身是可以继续延伸的，以excel处理为例，增强对excel的高阶技能能够让自己更有效率的处理工作内容，如高阶函数以及宏录制的技能运用。此外，现阶段的学习途径也能让你轻而易举地获取想要学习的知识，而关键在于自己能否合理运用并坚持下去。
- 大成就短期内达不到，则以达成小成就激发自身兴趣和潜能
学习往往是枯燥而乏味的，但并不代表在学习中就不会分泌多巴胺（有成就感）。通过对小技能的掌握，将技能应用于工作生活中往往能够让自己获取满足感，进而激发自己的热情。
量变引起质变。365天乘以零还是等于零，因此别让同质的工作单纯地重复365次，那样数字的增长并不是经验，也不是价值，而只是体现在你的年龄上。
扎根底层思维，以不变应万变
社会的发展是越来越快的，特别是互联网，走在时代的最前沿，是变化最快的部分。变化得越快，意味着需要学习掌握的东西越多。今天学习structs，明天可能就要掌握springmvc，再过段时间你掌握的structs可能就过时了。这也是为什么很多人感受到年龄危机，因为技术的不断发展很可能会让你的经验在未来几个月或几年后被市场淘汰掉。
然而是不是就代表我们就此学不动了呢？
并不是，物理学中有一个词叫做“第一性原理”，指的是：根据一些最基本的物理学常量，从头进行物理学的推导，进而就可得到整个物理学体系。
用更通俗的话来说，第一性原理就是让我们抓住事物最本质的特征原理，去推导、分析、演绎事物的各种变化规律，进而洞悉事物在各种具体场景下的表现形式，而不是追随事物的表面现象，将各种所谓的规矩、经验和技巧生搬硬套，以至于在纷繁复杂中迷失了方向。
在软件开发中，同样存在这样的“第一性原理”。
绝大多数新技术其实都脱胎于一些既有的技术体系，无论是mvc、mvvm设计思想还是云计算、docker，它们都是新瓶装旧酒的技术实现。因此，我们要建立自己的底层技术思维体系，掌握这些新技术背后的思想和原理，归纳技术的本质特征和思路方法。当在更新的技术出现时，便能快速推导出它是如何实现的，即以底层思维解构新技术。
这时，掌握新技术的手段已经不是“学习”而是去“验证”。
举几个例子，spring cloud的思想是基于分布式高并发的背景产生的，但其背后依然离不开rpc、序列化、反射和注解等的高级封装；vue、react基于mvvm的设计理念包装了大前端的工程化之路，但其背后离不开getter、setter、prototype、事件监听的基础js知识，其本身也只是为了实现该理念而进行的语法结构包装；同样地，docker部署的便利性背后，也是基于最基本操作系统linux namespace的数据结构隔离和封装。
类似的例子数不胜数。需要注意的是，除非基本底层架构出现重大改革（即出现新的技术革命浪潮，直接推翻旧有的二进制技术体系），否则这些层出不穷的新框架、新技术都只是基于现有背景下的技术封装而已。
因此，当我们要去掌握一项新技术时，不要抱着应付面试（当然新童鞋还是要的=_=）、应付上级的要求去调研，而是在看到新技术之后，能够主动去思考这个工具能否用于自己项目，能否在产品研发中提升性能和效率，甚至能在新技术上再做创新，创造一个更适用的技术。
项目与组织管理篇
成为leader而非manager
在正常的公司晋升流程里面，一个人的成长一般是由于工作积极表现而被领导提拔，实现从一线员工到管理者的转变。初为管理者时，大都希望自己能让团队如指臂使，顺利地推进项目，并能带领团队做出更大的突破。
然而在现实中，管理者往往会遇到不同的挫折和挑战，如典型的技术转为亲力亲为型的管理者时，指导组员工作就是操起键盘一顿操作，完了拂衣去，深藏功与名；而不管不问型的，有工作安排就直接扔下去，但出了问题也就直接问责。
如果你是努力地去完成领导指派的任务，却也无法维系团队稳定性的管理者，那么高管也会挥泪斩马谡的。
优秀的管理者，应当是作为一名leader去领导团队，而不是像manager一样去掌控团队。在任务上传下达的过程中，要像避震器一样，既要传递部分压力，也要过滤部分压力；既要团队能够体会到压力，能够理解任务重要性并积极前进，也要维系团队的稳定性和持续性，维系团队的士气。如果只传递压力，甚至变本加厉地传递压力，那么结果很可能会适得其反。因为你不能指望基层员工，尤其是新生力量，都具有超高耐磨属性，可以在任何压力下应对自如。
那么，新管理要如何成为一名合格的leader呢。
- 帮助团队成长，解决团队问题
例如，在一个新项目技术的攻关之时，不应该做甩手掌柜直接把任务扔过去，而是与组员共同讨论方案，以自身的经验引导组员设计合理的方案。在一个团队中，组员的设计能力也间接体现其上级的能力，因为这是一种帮带，一种传承。兵熊熊一个，将熊熊一窝不是没有道理的。如果团队组员出现某个技术难题卡住了，解决不了的情况，就需要你协调另外一个高手，寻找最终的解决方案。在实现整体解决方案过程中，组织协调是你的工作，而在其中作为leader，你也会有自己的成长。
- 帮团队顶住部分压力，替团队争取资源权益
工作中压力无时不在，有时来自客户，有时来自高层，也有时来自业务。面对压力时，需要管理者在其中做好权衡，并适当地传递压力，就如前文所说，既要传递部分压力也要过滤一部分压力。只要思路清晰，顶着压力带领团队攻关，没有什么问题是解决不了的，有的也只是时间问题。
而时间问题为例又涉及一个点——如何争取资源，一是要让上级知道项目任务的紧急性和重要程度，需要更多的资源倾向或者更多的宽裕时间；二是组员表现很好但没有得到应有的奖励时，管理者也应当去为组员争取。
- 少些批评，多些鼓励
无他，即在私人场所批评指正，在公共场合鼓励赞扬。平常如你我个体，都有自己的优点和缺点。一般人会去放大他人的缺点，无视他人优点。而宽于待己，严于律人，是极其不可取。因此，作为管理者，要学习去放大他人的优点，避开他人的缺点，让他人的优点展现出来就是你工作的价值。
赞扬是一件性价比极高的事情，往往一句话就能很好地鼓励组员，增强他的自信力。而且促进组员成长成为骨干，能团队分担更多事情，即管理者要操心的事情更少，自己也乐得轻松，不是吗。
- 有勇气去背锅，有能力去填坑
没有人愿意背锅，但有些锅确实不用自己背但又不得不背。憋屈吗，难受吗，这就对了，但这并不代表是坏事。这是一种责任的担当（当然最好还是不要背），也是一种挑战，挑战自身有利于增强后续处理这些事情的填坑能力。
而填坑需要技巧和规化的。规化需要具备统筹兼顾的能力，既要满足业务需求的前提下逐步迭代，也要在填坑的过程中保证项目系统稳定和设计合理性。在实现目标的路上，遇到坑很正常，但你得有去填坑的勇气，学会把坑填好，并持续走下去。
既要有事前放权的勇气，也要具备事后兜底的底气
- 认清自己的岗位职责
中层管理以上的岗位（不直接管理基层的岗位），最重要的工作转变成了培养人才、凝聚团队力量、部门方向决策和上下级战略传导。不到万不得已，千万千万千万不要花大精力参与到具体的事项工作和业务细则中去，因为这时候不管你事情做得好不好，团队都会朝着不可控的方向发展。
这是因为，第一下属能力无法得到很好锻炼，自己累的同时还耽误他人成长；第二下属会形成心理依赖，工作心态和能力上不去你还培养什么leader？第三由于精力问题不可能面面俱到，团队的大方向把控肯定会跟丢，在时间维度上一拉长，工作方向往往差之毫厘，失之千里，而最终出来的项目不是半成品就是推倒重来，部门绩效肯定受损。因此，管理者必须学会授权，在一定时期后放心大胆地把任务交给组员去完成。
- 给团队留个plan B
授权并不代表一味地放手，必须留有预警和后备机制。例如，项目上线回滚时，人才资源互备、数据存储多备，就是plan B。这能够保证我们在进行项目迭代开发或者架构改造时，一旦出现重大故障能最低限度地减少损失。因此，能够给工作留有回余空间时一定要留，到最后墨菲定律的诅咒会让你感谢自己当初做这个选择的。
工具升级、人才降级
抛一个问题，假设团队中的骨干或者是工作一、两年的童鞋要离开团队，你的工作能否满足业务和产品给你的需求？
对于早期团队来说，人员专业要求一般都很高，上到需求的研发满足，下到底层的方案设计。但专业度要求高的同时带来的离职成本也很高，对于一个团队管理者来说，这是一件“很痛”的事。
由此，这需要我们换一个角度来看问题，按照“人才”和“工具”两个维度来划分解决方案。为什么这么划分呢？因为要解决一个问题，首先需要是“人才”，然后是需要借助一定的“工具”。随着“工具”能力的提升，“人才”能力要求也可以同步下降，由此整体成本和风险也会随之下降，即“工具升级，人才降级”。
譬如，公司目前的SASS产品服务，采用一键化、傻瓜化、配置化的产品设计理念，可以让不懂运维、开发、设计的客户也能够一键生成应用程序并持续运营，如此便减少了开发、设计、运维人员的招聘成本，也能将重心放在重要的产品运营中去。
对比之下，优惠券系统，前期需要采用代码开发各种分支来判断满足业务方不断新增的优惠券需求，不但人员开发急，业务急，时间急，重复工作还多，而且一旦出现资源跟不上的情况会拖慢整个业务的进度。因此，一套完整的优惠券系统应该升级成平台化的操作，支持业务产品自己配置新增不同的优惠券来满足业务不断发展的需要，而“人才”仅仅是完善这套系统的功能，做好功能研发、数据运营和风险控制。如此，好处之一就是对于团队成员来说，能够有精力做“更有价值”的事；之二是业务也不需要找开发提需求，直接自己配置优惠券系统；之三是团队人员流动还不会影响业务的需求迭代，最多也只是平台新功能短期内无法满足而已。
因此要谨记，作为一名开发，也作为一名管理者，要好好利用好自己的大脑和手头上的工具，因为以你手上的能力和资源是足够利用计算机来帮你解放重复性工作的。人类演化几十万年的大脑不只是让你去刷抖音和玩LOL的。
理解熵增能够让你更好的理解事务的本质
什么是熵增定律？在一个孤立系统里，如果没有外力做功，其总混乱度（即熵）会不断增大。
这里面有三个词非常重要：孤立系统、无外力做功、总混乱度（熵），而这就是熵增定律。如果要针对地球，针对一个国家，针对一个企业，针对一个系统，针对某一个人，则要加上两个限制条件 —— 封闭系统＋无外力做功。
任何一个系统，只满足封闭系统，而无外力维持，它就会趋于混乱和无序。
例如，开发系统的耦合程度在于团队对该系统的规划和用功程度。一旦一个系统陷入无人维护或者无心维护的阶段任由其发展，其内部的混乱程度便会随着时间的推移而变得复杂，而后期一个新功能的添加动作只会是牵一发而动全身，这也就是所谓的破窗效应。
如果我们不主动投入能量做熵减，系统便会脱离我们的掌控，朝着不可控的方向发展。那么如何对抗熵增？个人自律，组织调整、系统重构、规范制定便是以熵的方式在熵减。这个过程会非常痛苦，但必须要做。不能激进地做，因为过激行为只会带来更大不确定性。这也是为什么我们在进行一个产品方向的调整或者系统方向的重构时强调，既要做好产品灰度，也要保证系统更新升级时的服务稳定。
总结
书不尽言，言不尽意，即使文章写到最后我也无法做到把自己百分百的想法分享出来，迫于工作安排还砍掉了一些。但无论怎样，于个人、于团队管理者，我们都需要有自己的思考。这个时代不缺乏焦虑，但也不缺乏机会，未来我与大家共勉。