说点技术团队管理相关内容，我认为并不是说只有项目经理才需要学习项目管理相关知识，程序员一样要了解项目管理知识与技能，知己知彼百战不殆。
传统项目管理常见概念简单介绍
本篇文章不会对下面所有内容进行细化，具体参考项目管理、沟通管理相关书籍：
- 整体管理：项目启动、制定范围说明书、制定项目管理计划、指导和管理项目计划执行、监督和控制项目活动、整体变更控制、项目收尾
- 范围管理：编制范围管理计划、范围定义、创建WBS、范围确认、范围控制
- 时间管理：活动定义、活动排序、活动资源估算、活动历时估算、制定进度计划、进度控制
- 成本管理：成本估算、成本预算、成本控制
- 质量管理：制定项目质量计划、质量保证、质量控制
- 人力资源管理：人力资源计划编制、组建项目团队、团队建设、团队管理
- 沟通管理：沟通管理计划编制、信息分发、绩效报告、项目干系人管理
- 风险管理：风险管理计划、风险识别、定性风险分析、定量风险分析、风险因对计划、风险监控
- 采购管理：采购计划编制、编制合同、招标、供方选择、合同管理、合同收尾
分小点总结
组织架构变化、研发流程变化是很正常的。研发管理没有Best Practice最佳实践只有适应发展阶段与生命周期有限的Suitable Pratice
经理角色
管理角色还可以再划分如下三个角色：项目经理、技术经理与需求经理，当然也可以一人充当多个角色。
- 项目经理：解决管理上如何做的问题，对项目的进度与质量负责。具体职责包括了：过程定义、估算、计划制定、计划跟踪与控制、风险管理、质量管理等。
- 技术经理：解决技术上如何做的问题，对项目的技术方案负责。具体职责包括了：技术可行性的评估、技术方案的确定、设计、设计验证、技术难题的解决、实现等。
- 需求经理：解决做什么的问题，对项目的需求与范围负责。具体职责包括了：需求获取、需求分析、需求描述、需求验证与确认、需求变更的管理、需求实现优先级的确定等。
项目组的所有人对进度、质量等共同负责。
技术管理方法论总结
个人提升
- 保持技术判断力（学习、调研、交流、听）
- 团队分工（根据团队规模，业务线、技术线分工。XX负责YY业务线培养新人……），也就是横向职能团队、纵线项目团队划分
- 把握整个项目流程：业务交流、产品调研、产品评审、设计评审、项目计划、项目启动、项目执行、项目验收、项目上线、项目总结
- 卓越的人才靠的是自我驱动，而不是我们的管理（使命式而不是传统的命令式）
角色认知
经典的马车模型，头马跟车夫。拉好车、赶好车。管好自己、对上下级负责。上级安排指挥更多要自己主动规划。执行，规划。是倾力倾为还是主要靠团队。过程为导向还是目标和结果为导向。平级多级合作。竞争还是合作
有则该之无则加冕：
- 过程为导向、被动执行：团队缺乏方向感，做不出有效业绩
- 大包大揽、为我独强
- 带头大哥、大保姆
- 视角单一、思维严重固化
- 自扫门前雪：个人影响力无法拓展到其他部门
- 患得患失：影响成长
技术专家日常：
- 指定技术方案
- 解决线上故障
- 经验知识沉淀、技术学习
管理者日常：
- 设立团队目标、制定工作流程
- 协调资源
- 观察进度、向上汇报报告
- 招聘培训人才
- 评定成员业绩
知轻重、重绸缪、调缓急，可以制作轻重缓急象限图
管理规划
一辆马车交给你，你会做什么？
- 这是一辆什么车？职能：你团队是干什么的？收集信息明确职责
- 你要去哪？目标：团队要出什么结果？设定目标SMART（S领域、M衡量、A实现、R资源、T时间），目标要明确，可衡量，可行，时间节点。常见问题（目标不明，目标变来变去）
- 你有哪些马？团队：你靠什么样的团队？规模、分工、梯队、成本、培养人才
- 你走哪条路？过程：需要投入哪些资源？都有哪些资源，哪些手段（自研、招聘高级人才、外包、采购、找人过来兼职）。从长远的角度考虑招聘的必要性，不要过来做一个月就没事做了。
团队建设
- 个体： 动力 跑得动 （培养人才），个体间：凝聚力 跑的快（分工协作），团队：耐力 跑的远（人才梯队、团队文化）
- 员工能力：人员技能图谱规划（会用、熟练、深入源码）、帮助员工学习与实践、为每一个团队成员做好职业规划和能力提升的规划、配备导师。推、拉、放手。
- 员工激励：表扬。有共同价值观：自主投入。提升幸福感。驱动力3.0
- 团队分工：实现专精、职责冠名、团队稳定保持归属感、分工清晰、目标明确、认同员工、专人专事一个人事情不宜太多
- 团队协作：提升归属感、加强相互了解、建立协作机制
- 团队培养：多样性、做好授权、建立良好的沟通反馈集中
- 团队文化：效率、归属、可持续。主张、追求
- 终身学习: 不然就是会有团队成员跑过来说”我学不到东西”，”我已经都会了”，”我每天都在重复”……”我想离职，换个环境……”
- 高效团队：
个体动力 * 协作水平 * 方向有效性 * 时长=（能力 * 意愿） * （默契 * 机制）*（目标 * 沟通） * 时长，而不是连自己想干嘛都不知道就搞什么996、997
任务管理
分清轻重缓急、按计划有效推进、总结流程机制
- 轻重缓急：看收益、看损失。任务安排是弹性的不要固化思维。以目标为导向
- 有效执行：目标（目标是给团队的而不是给领导的）、责任、进度、沟通
- 流程机制：原则，适用场景，沟通
管理沟通
建立良好沟通合作同道，保持信息同步，提升沟通品质与沟通技能
- 向上沟通（弄清沟通意图，本次沟通能给自己和上级带来什么价值）。信任关系
- 影响力：职权影响力、非职权影响力（信任、专业、情绪（情怀）、互惠）
- 横向沟通：寻求支持？你对对方有多大影响力？
- 向下沟通：沟通技巧，和牛人、刺头较量
- 不要仅从自己出发、换位思考。人事分清。给建议而不是抱怨
项目计划制定
- 一定要重视项目计划制定，不能敷衍了事。可以参考原先成功的项目计划不能生搬硬套
- 一定要让团队成员参与项目计划制定与管理。一旦对任务的安排达成共识，大家就能够齐心协力完成计划。而且能让团队成员对项目的总体有个比较好的了解，知道到时候对接各个模块要找哪些部门的人
- 根据不同干系人的实际需求制定对应的项目计划。比如在报价阶段没必要注重太多细节。提供给物控部门就需要提供一个单独的生产交付计划
- 项目进度计划要及时更新，以适当的频率对外公布。完成了就标记成100%，可以给人带来成就感。
组织架构划分
横向职能，纵向项目。根据需要可以建立技术委员会、产品委员会。
项目团队才有工作汇报，职能团队没有汇报，只有培养
- 项目团队帮助共识成长，员工可以拿到项目奖金（包含绩效考核）
- 职能团队帮助员工成长，为员工实现升职加薪
需求池 →（功能团队+效率团队+创新团队）→ 技术债
对于一只研发团队而言，需要拥有合理的组织架构、高效的研发流程、科学的绩效考核、良好的团队文化。我们应该做的是，从管理中最求效率，从效率中提升价值
基础职能服务团队：运营、IOS、Android、前端、C服务端、JAVA服务端，
然后项目组包含：前端、后端、运营、产品
核心团队培养
- 技术团队培养：重点培养人员，给于更多的资源与机会，激励、指导、对比、思考。带领团队成长靠的不是鞭子而是果子。根据团队情况、不能只看结果不看过程，避免团队一次次失败，给于必要指导。自己不要成为团队的天花板
- 技术专家培养：同上，攻克技术难题
- 中层管理团队选拔：优先培养选拔内部人才，根据具体团队需求，如果没有合适人选就要选择引入合适的人才。分享管理认知。培养中层，中层给力上层就轻松
成就感、荣耀、奖金、股票期权、使命感、成就他人就是成就自己
人才招聘
首先是符合公司企业文化、人才结构、符合团队价值观、容易融入团队，员工信不信公司部门能不能把事情做成很重要，学习能力（潜力，因为技术迭代太快，现在技术基本2年就被淘汰一轮），责任心，使命感，避免招聘到害群之马危害团队。初级人员主要考察基础知识，中高级人员主要考察原先工作经验的技术深度与广度、业务深度与广度、编程思维、解决问题能力、架构能力、耐心。
招聘不仅是人力的事情也是自己的事情
新入职人员提供企业文化、企业业务说明、技术框架、编码最佳实践等入门手册。
薪酬体系参考BAT的薪酬体系：
P序列=技术岗 M序列=管理岗
| 技术级别 | 基本定义 | 管理级别 | 对应薪酬 |
|---|---|---|---|
| P1/2 | 低端预留 | - | - |
| P3 | 助理 | - | - |
| P4 | 初级专员 | - | - |
| P5 | 高级工程师 | - | 15W-25W |
| P6 | 资深工程师 | M1 主管 | 20W-35W |
| P7 | 技术专家 | M2 经理 | 30W-50W+股票 |
| P8 | 高级专家 | M3 高级经理 | 45W-80W+股票 |
| P9 | 资深专家 | M4 (核心)总监 | 80W-100W+股票 |
| P10 | 研究员 | M5 高级总监 | - |
| P11 | 高级研究员 | M6 副总裁 | - |
| P12 | 科学家 | M7 资深副总裁 | - |
| P13 | 高级科学家 | M8 执行副总裁 | - |
| P14 | 首席科学家 | M9 副董事长 | - |
| P15 | - | M10 马云 | - |
阿里薪资结构：一般是12+1+3=16薪
绩效考核
关注OKR(Object Key Results)、KPI。考核成绩分为S、A、B、C
主观考核是很重要的，只靠指标就变成机器人了。主观评价战斗力、团队精神、态度以及创造价值。
团队Leader自己的OKR：
- 制定高效研发流程
- 增强业务与研发交互
- 搭建核心团队
- 合理切分边界
- 打造团队文化，气氛、原则、方式（守信、进取、高效、学习、分享，没有“你们”只有“我们”，没有Leader只有Owner，可以加班拒绝无意义加班）。参考Netflix、Google、Facebook的文化，当然并不代表他们就不会倒闭
评判自己
人才是一个企业的竞争优势，判断一个技术管理者是否做好了人才管理，用一个简单的问题来验证，你的精英是否愿意推荐他周围的精英加入到你的公司，如果大多数精英愿意这么做，那么说明你的管理是有效的。同时也就形成了精英文化，让更多的精英汇聚到你这家公司。
产品
细节、技术、质量、体验、创新（试错）
越高层的领导越注重细节，当然也有负面影响，导致团队基层不创新，不思考。所以高层要把握一个度关注关键细节，把注重细节的思想传导下去树立榜样
开发流程
瀑布→敏捷，瀑布+敏捷。传统向互联网转型？
不同环境下技术团队管理
不同组织管理，传统企业事业部各自为政？→事业部群。管理层CEO支持，量变→质变
员工淘汰
不赞同固定比例的末位淘汰，还可能淘汰掉优秀的员工。对应害群之马、不符合团队价值观、破坏团队团结的还是应该淘汰出局。问题员工不合适也不合格的也应该淘汰出局。“既合适又合格”的员工毕竟是少数。用人之长，容忍之短，所以培养与利用“合格，但不合适”，“不合格但合适的员工”。淘汰时仅对业绩不佳做出评价，不对员工性格，为人处事加以评论，竟量告知员工只是不适合公司目前提供的工作而已，任何员工都有所长有所短，明确功过得失，不能全盘否定。
团队常见问题的理解
我希望的是团队的每一个成员都能够独当一面，独立解决一些常见问题，能百度得到的，能通过api文档查询到的就不要来问我，只有经过这些渠道都解决不了，自己也想不出好的解决方法的再来找我，我只提供一个解决思路。而不是说做点简单的事情都要我把怎么做每个步骤都按文档写好，复杂的自己写，然后他们连想都不用想直接写写crud，连自己做什么，为什么这么做都不思考的。
不同驱动类型的团队还是有差异的，有的项目是以技术为驱动那么CEO最好是做技术的、有的项目是以运营为驱动那么CEO最好是做运营的、有的是以客户为导向。我偏向于希望团队以技术以创新为驱动。人类社会的进步经历了多次信息革命，每次都是有新的技术出来提升生产力（蒸汽机、汽车、挖掘机、飞机、电脑、手机）。人们可以从重复的工作中解放出来，用更少的资源做出更多的优质产品。有更多的时间思考，享受生活。