说明：本文是我基于前端多年工作中积累的管理、被管理经验而做的总结，仅供参考。
目录
一、几个核心概念
1.1、要事第一、结果导向
说句俗一点的，对于大部分公司而言，公司花钱招你过来就是搞业务的，不是让你搞技术情怀的（做好业务的基础上，情怀也是加分项）。所以，前端管理者最重要的事情（即“要事”）是做好公司的业务：
- 保证公司业务正常迭代。
- 通过各种技术、非技术的方式提升团队业务迭代效率。
- 提升前端产品的用户体验。
基于这个前提，我们要同时兼顾两个原则：
- “要事第一”：理论上我们可以有很多目标，但是每个目标的重要性是不一样的，要把有限的精力花在最重要的事情上。
- “结果导向”：即便我们把精力都花在重要的事情上了，那只是说明我们在做事，但是如果光做但不关心结果显然是不行的。
1.2、OKR、目标对齐
OKR，全称是Objectives and Key Results，即目标与关键结果法。OKR的方法论，于2014年传入中国，在15年后陆续被百度、华为、字节跳动等公司推广使用，它对于我们做好“要事第一”、“结果导向”是非常有帮助的。通常一个OKR由1个目标和3~5个关键结果组成。
OKR = 1个目标（目标需要是有意义的、定义明确的） + 3~5个关键结果（成果应该是可量化的）。
OKR一般分个人的、团队的、公司的。作为团队管理者，制定团队OKR时，需要和下属一起对其目标，根据团队的OKR来指定下属的个人OKR，避免出现团队内部力没往一处使的现象。
1.3、持久、健康的团队战斗力
作为团队管理者，不再是单兵作战的身份了。你需要整合团队资源，提高团队整体的作战能力。这种战斗力的提升，不能只考虑眼前的短期战力，我们需要的是一种持久的、健康的战斗力。
工作时长的博弈
如果我们只考虑提升短期战斗力的话，直接延长工时不就好了吗？实际上有不少管理者也是这么做的。延长工时，本质上，是剥削者与被剥削者之间的一种博弈。如果博弈得当，确实能提升团队的战斗力。如果博弈不得当，则会显著降低团队战斗力。说个有意思的，在工资给的高的大厂里盛行996的时候，有小公司也学着996。大厂996因为薪资也高，员工在博弈中能接受这样的被剥削。但是小公司如果你薪资给的本来就很一般，这样只会把少数技术还可以的下属给赶走，团队战斗力不仅不会提升还会下降很多。在这种博弈中，拿捏好尺度是一门学问。过分压榨员工劳动力并非明智之举。
工作时长过长还会导致一种恶性循坏。增加每周工作时长后，短期的一两周内可能会给管理者带来一种团队战斗力被拔高的感觉，但是这种战斗力是不可持久的，因为人的精力都是有限的，长期大工作时间长最后只会演变成【低效率*长工时】的状态，大厂亦不例外，因为都只是凡人而已。加班多的公司，上班节奏一般都会比其他公司慢。
合理的技术梯队
每个部门的人员预算总是有一定限制的。这里我们不妨直接算一笔账，假设我们现在有12万/月的预算（简单起见，这里不考虑交税问题）。并且假设招一个高级需要24k，招一个中级需要18k，招一个初级需要12k。另外，假设管理者自身有着资深/专家水平，所以不需要再招资深、专家级别的程序员。
那么，12万/月的预算，如果都招高级开发，可以招5个高级（24 * 5 = 120）。
在相同的预算下，我们可以换成2个高级、3个中级、1个初级（2 * 24 + 18 * 3 + 12 * 1 = 114）。根据项目的实际情况，可以调整各个级别的比例。
如果我们现在的业务场景是有专题活动页要开发，然后还有公司核心产品的各个模块要开发。那么我们就需要至少一名初/中级开发来接触专题活动页的开发，如果你让高级开发做这个事，一来浪费钱，二来如果人家想做技术含量高一些的活的话一直做这种活容易加速离职。
多数场景下，我们需要的是一个有一定技术梯队的团队，并不需要全盘尖子生。在一个有技术梯队的团队里，技能强一些的同事更容易在工作中收获成就感，技能差一些的同事更容易感觉到自己的进度，这些软性的方面对团队的稳定性也有助益。
如果你们公司的预算很充足，也可以不招初中级开发，从高级起步，道理也是一样的，只不过上面的例子里，你需要把高级换成专家，把中级换成资深，把初级换成高级。
1.4、做好批评者
会夸奖员工的领导60分，会合理批评/惩罚员工的领导90分。
二、项目管理
2.1、敏捷开发相关概念
先来看下维基百科中的一段描述：
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
敏捷软件开发（或称快速程序开发RAD）描述了一套软件开发的价值和原则，在这些开发中，需求和解决方案皆通过自组织跨功能团队达成。敏捷软件开发主张适度的项目、进化开发、提前交付与持续改进，并且鼓励快速与灵活的面对开发与变更。这些原则支持许多软件开发方法的定义和持续进化。
“敏捷”（Agile或agile）一词由“敏捷软件开发宣言”（Manifesto for agile software development）中开始推广，“敏捷软件开发宣言”定义了相关的价值和原则。敏捷软件开发的框架不断的发展，两个最广泛被使用的是Scrum与Kanban。
Scrum
Scrum是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework) 。最初着重于软件开发，之后已被用应用于其他领域，包括研究、销售、营销和其他先进技术领域。 一个 Scrum 团队建议为十名成员的团队而设计的，他们以迭代(iterative) 与增量 (incremental) 式的方式交付工作，每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月，通常是两星期。Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 (Sprint Goal)，每天的 Daily Scrum 团队中的开发人员 (Developers) 都检视朝向这共同目标的进度，和调适当下的计划。在 Sprint 结束时，团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划，这是互相资讯交流的机会。最后，团队会进行 Sprint 回顾 (Sprint Retrospective) 来持续改善。
Kanban/看板
“看板”是一种精益制造工艺，为了管理生产过程和提高工作效率。由1940年代的丰田汽车公司发明。名称源自日文“看板”。在软件开发过程，可以使用“看板卡”（经常用即时贴）来执行看板。这些卡片不是作为提高生产量的信号，而是用于记载生产数量和标记生产过程。在虚拟看板系统中，会使用虚拟看板卡。在软件开发中，可以采用虚拟看板系统来限制在制品。
2.2、项目管理实施步骤
不需要教科书式地去执行一些管理步骤，应结合团队和公司的实际情况，有选择的实施项目的管理。切记管理本身也会占用团队资源，在有效的前提下，管理所占的资源越少越好。这里写一个实际可参考的操作SOP（Standard Operating Procedure）。在下面这套操作程序了，我觉得最大的亮点是master的角色是由团队里的成员轮流来做的，这样大家的参与感会比较强，不容易流于形式。如果可能的话，这个master最好不要局限于前端团队，而是按业务迭代来，同一个业务迭代里的前端、后端、测试、产品都要轮流去做master。
第一步：确定产品迭代周期
一般2周一个迭代较为常见。
碰到过没有固定迭代周期的公司，其实不建议这样，因为你让一个程序员去评估一个项目要多长开发时间的话，误差是很大的，有些人可能估得太保守，有些人可能估得太激进，而且每个人的编码能力及对项目的熟悉度，一个每个产品经理撰写的需求文档质量都是不一样的。这样的迭代最后导致的情况就是：
- 产品倾向于把需求文档写得大而全，颗粒度不够小。因为假设产品经理A有个大需求a，然后将其分解成多个颗粒度较小的需求a1、a2、a3，开发者完成A的需求a1后马上就接了产品经理B的大需求b（未拆解成多个颗粒度较小的b1、b2、b3子需求），因为b需求颗粒度较大，所以会占用较多的开发者资源，这样的结果是产品经理B的需求一次性被做完了，产品经理A的需求迟迟没完整做完。劣币驱逐良币，最后就会导致每次迭代的需求量变得过大。
- 开发人员倾向于把迭代周期定的长一点。一是因为上面说的原因需求容易变得越来越大，二是因为时间定短了到时候进度跟不上容易被甩锅。那些开发效率高一开始排期倾向于给少一些的开发者，在吃过几次亏之后就会把开发周期排久一点了。
而如果采用2周一迭代这种固定迭代周期的方案，产品经理可能还是会倾向于将需求定得大一点，但是开发者会主动和产品砍需求，因为不砍需求最后迭代会延期，这种反向的推动力，可以促使需求不至于过大，使得产品功能可以以较小的粒度稳定迭代。这更符合敏捷开发的特点。
第二步：选择master
第三步：master撰写迭代excel，内容根据产品需求来定，此外还可以追加技术部门的内部需求
第四步：master组织每日站会过进度
第五步：提测前由开发者组织code review
第六步：上线前master组织大家过checklist
第七步：master在上线结束后组织大家回顾本期上线中的问题，查看之前发生的问题是否有改进，选举下一期迭代的master
三、团队管理
3.1、管理人性
太容易得到的不会被珍惜。奖励不能泛滥。对执行者而言太容易达成的目标不值得领导去表扬。
差异化产生激励效果。（每个人都奖励10000）VS（一个人奖励6000，其他人奖励3000），后者产生的激励效果更好。
只要意识到被外部关注，员工就会刻意改变一些行为。就比如没有code review习惯的团队，代码质量就会比有code review习惯的团队差，因为有code review习惯的团队，大家在编码的时候因为会意识到之后别人会一起看这些代码，所以会倾向于主动提高代码质量。
宣泄后人的工作效率更高。不能压制不让下属说话，要创造一些渠道，让员工将不满、牢骚、抱怨适时发泄出来。
在工作中往下布置任务时，如果你想下属或团队成员更积极、更有主观能动性，就要营造出一种由他自己主动想做而不是你逼迫去做的氛围。如果在布置任务时有一定的调配空间，你还可以将几个人一起叫过来，让他们自己选择各自想做的任务。这么做，他们也会觉得是自己想做的，而不是你硬性分派的。
人们厌恶失去。如果抛硬币是正面时对方可以得到1500元，是背面时对方需要支付1000元，很多人也不愿意参与这个游戏——尽管这个打赌其实是对对方更有利的。假设现在有两种奖励方案，第一种方案是告诉对方如果本月不犯错会奖励对方5000元，一种是先奖励对方5000元并告诉对方如果如果犯错会收回5000元，往往第二种方案的激励效果会比第一种好。
3.2、管理代码
master权限要有控制。代码合到master的操作需要由核心人员操作，亦可以考虑双人复核。
代码要有code review的习惯，code review需要由开发者主动约会议室召约小伙伴一起code review，而非每次由领导来组织（领导需要在团队里制定这样的规则并让员工们知悉此事）。
代码要通过ESLint等进行检测。
分支命名需要有统一约束，长时间不用的分支需要删除。
3.3、管理技术
产品的技术不用追求最新，但一定不能滞后太多，否则欠下的技术债太对多后期人员招聘、技术升级的成本都会非常大。一定的技术目标对用户体验的提升、对团队技术能力的提高，都有提高。
