管理学家德鲁克有言“管理是一种实践，其本质不在于知，而在于行，其验证不在于逻辑，而在于成果，其唯一的权威就是成就” ，因此管理重实践看效果，但如果管理实践有理论依凭，那么实践起来就会有章可循，管理经验也更容易被其他人所复制。
1. 总的思路
笔者的管理经验来自观察与实践，观察自己的上级是怎么管理团队的，以及上级的上级又是怎么管理团队的，以及自己做团队leader后又是怎么做的，总结起来有以下几个方面：
- 我们的业务是什么？ 理清整体商业模式，做好OKR目标管理，商业模式+OKR做整体牵引
- 我们需要什么人才？选择业内顶尖人才，百里挑一；用好绩效考评这个杠杆做好激励
- 我们如何让事情快速落地？掌握一些必要的项目管理技能（e.g. PMP），但最主要的还是push push push，今日事今日毕
- 我们如何提高绩效？技控而不是人控，专业的方法是杠杆的支点，找对方法并利用好
列举一些具体的点：
- 日常管理：周会，月度总结，半年度总结等，用一个在线表格持续进行
- 目标管理：每半年做一个OKR对齐。业务目标（主要是产品需求），技术目标（研发体系完善、技术组件开发）
- 绩效评估：①代码生产力（数量、质量、难度）②技术方案（总体设计、详细设计，技术难度、创新性等）③系统维护（有没有故障，出了问题有没有及时处理）④技术影响力（写专利、讲课、技术文章）⑤比较产出时，同等职级的同事进行比较
- 人才培养：注重员工成长，发掘新员工的技术潜力，让老员工有危机感
- 团队氛围：亲自下场带头做事，做技术方案，写代码等等，导向作用很重要
- 从0到1搭建团队：考察两位维度，一个是能力维度（编码能力+系统设计能力），一个是态度维度（工作投入度、团队协作）；兼顾团队的梯队与稳定性；带领团队快速适应业务变化，快速学习。
小团队的力量
干开发这一行，我们都知道人多不一定力量大，有时候小团队的战斗力反而更强，笔者过往做个许多产品特性，基本都是“1产品2前端2后台”的小团队组合。在视频会员做的一些比较成功的产品特性，比如合作平台，VIP+联合会员，数字藏品，视频一起看等，都是下面这个小团队模式。小团队作战，更适合创新，也更能迸发出战斗力。
2. 团队管理
人才的“选育用留”是HR给的框架，以这个框架为基础，笔者对过往的实践经验做了细化：
换个视角，笔者梳理的团队管理逻辑：
- 做好OKR，以目标牵引工作，平衡好业务目标和技术目标
- 引入一些简单的管理工具（例如笔者使用的3张表），管理好过程，抓好落实
- 绩效和产出强挂钩，避免靠印象打分，有些人能力其实不行，产出也不行，但就是很会表现，在一个实干的团队里，这类人应该少一点，否则就会劣币驱逐良币，真正有能力的人会另谋出路。笔者自己带团队，也近距离观察过很多团队，见识过各种状况，深有感触，这里就多说几句。
- leader学会用工具赋能人，而不是天天把自己卷进去，让工具和方法发挥杠杆作用
百里挑一
关于招聘，笔者的一些经验：
- 选人而不是育人，一开始就找到那个对的人。
- 百里挑一：每年招聘，公司的简历库都会新增大量简历。笔者一般会看100个简历，从中挑选10个比较不错的做笔试，然后选5个优秀的进入面试，最后挑出2-3个推到总监面试，最后录取1个
- 详细记录面试结果，结构化评估与综合评估两个维度相互参照，这样便于横向拉通对比
- 这套方法有效吗？过去几年，笔者按照这套方法招聘的人有15个左右，实习后留在公司的有10个左右（不一定都放在笔者所在的组），就去后续表现和绩效来看，普遍都不错。
日常管理
笔者在团队管理时，主要使用以下3表：
- 周会表：类似现金流量，主要关注项目的持续承接与交付。
- 业务盘点表：类似资产负债，主要关注业务盘点与技术负债；
- 半年绩效表：类似利润表，主要关注项目成果最终沉淀为技术平台、技术专利以及员工职级的提升
- 表格更新频率：周会表每周更新，业务盘点表不定期更新，半年绩效表每半年更新一次
这些属于日常管理，表的内容主要由小组同学维护，笔者只是例行提醒，这样不至于占用太多时间。
绩效与激励
明确评价标准：
-笔者所在的部门有很强的业务属性，但是也不能只做业务需求，一定要抽时间做技术组件的建设，实际结果就是业务与技术并重
- 既要看工作的数量，比如完成几个需求/写了多少代码等
- 也要看质量和难度，比如代码质量，通过CR来评估；比如复杂度，通过系统设计文档来把握
- 创新类/优化类/维稳类，三大块综合看
记录绩效信息：
- 用一个表格记录近半年的工作产出，每个人一行自己记录。每个人自己做的事情自己最清楚。
- 几个纬度综合看，横向纵向拉通看；新人和新人比，老人和老人比
- 这样做的好处是，避免leader一言堂，总是打印象分，从而增加考评结果的客观公正性，不容易反弹
人才培养
业务的不同发展阶段需要不同的人才：
- 业务起步阶段产品功能快速迭代，这个时候主要需要写代码的程序员；
- 到了上升期，业务在规模和复杂度上迅速增加，这个时候对开发的架构能力提出了较高要求；
- 到了平稳期，这个时候更需要创新与突破，需要不拘一格使用高潜新人，换个思路看问题
人才培养与职业生涯：
-沿着公司提供的职业发展路径，不断打怪升级。如何晋级，如果写PPT，如何答辩等，就不展开说了，别人已经说的很多了
业务发展和个人发展要保持同步，业务快速发展的时候，你最好抓住机会往上爬，没抓住机会那就是自己的问题了
作为火车头，也就是团队leader，技术能力/业务思维/团队管理三管齐下，公司会提供一些资源，但主要还是靠自己不停摸索和总结
一个人如何发展，说到底还是要看自己的积极主动，不停突破自己的舒适区，不停快跑，机会自然就多
3. 不同视角看管理
基干视角
基干的重心在技术，不在管理：
作为一线基干，主要还是靠技术（这里泛指专业能力）吃饭，管理只是辅助技术，起到一个放大器的作用。基干基干就是要撸起袖子加油干，下一线到现场，拼出来的位子才是稳的。
花多少时间在管理上？
二八原则，笔者在公司一直做开发，即便是做了leader，80%的时间都是在做技术，前面讲的这些管理，占用时间不会超过20%。
存在两个极端情况：
一种是无管理，有些leader技术很强，当了leader后也是只搞技术，对团队放任不管；一种是纯管理，个别leader脱离技术一线太久，技术一线的事基本不太懂了，只能做做管理。这两种情况其实都有问题，前者最好走TechLead路线，后者最好能晋升到更高职位。
发挥方法和工具的作用：
管理不是想当然就能做好的，认真领悟绩效改进的原则“先技控在人控”，用方法和工具赋能人。有的人机缘巧合当上了leader，然后就声称自己天生适合当leader，我信你个鬼。
员工视角
管理只是管理者的事吗？
很显然并不是。即便是员工，学习一些管理知识，例如项目管理，也能让自己做事更有章法更有效率。另一方面，并不是当了leader之后才能开始学管理，平时就应该多积累多学习，管理是一种实践，实践出真知。
管理可以很简单，一学就会
如果觉得前面说的那写方法和工具太复杂了，那就记住一个最简单的PDCA循环，某种程度而言，PDCA就是管理。
4. 疑问和思考
暂无
5. 参考文档
暂无
