技术管理：不只是代码，还有诗和远方
当从技术领域决定跨入管理领域时，我们的目标已经不仅仅是代码，而是在这个交叉领域下的诗和远方。
动力源泉：外在推力与内在魅力
外在驱动力，这玩意儿有点像是被逼的。比如，IT界的“35岁危机”传说，好像一到这个年纪，编码速度就得输给年轻人似的。但别忘了，我们还有内在驱动力，这是一种“我想要更多”的冲动。不只是敲代码，而是创造牛逼的产品，提供一流的服务，甚至是推动企业的数字化转型。面对这些挑战，一个人的力量显然不够，团队合作才是王道。找到那份内心的小火苗，保持初心，技术管理的路才能越走越宽。
技术管理者的产出：不只是数字游戏
说到技术管理者的产出，很多人会简单粗暴地等同于团队的产出。但等等，这只是冰山一角。真正重要的是管理者对团队的影响力，比如营造的氛围、塑造的文化，以及如何打造一个高效的团队。
一个高效的团队，可不是仅仅开发速度快那么简单。它意味着高价值、高绩效，包括业务价值和技术价值。想象一下，如果一个团队只是机械地接受任务，不思考业务价值，不衡量开发性价比，那这个团队的价值就完全取决于分配给他们的项目了。这样的团队，就像是被项目好坏牵着走的木偶。
所以，技术领导者和每个团队成员都需要思考业务价值和开发性价比。对于那些低价值的需求，我们得想想怎么释放开发资源。比如：
- 遇到老系统的Bug，能不能找个巧妙的解决办法，而不是硬碰硬？
- 面对短命的项目，能不能通过沟通和资源调配来快速响应？
- 面对重复的任务，能不能用自动化工具来解放团队的双手？
技术管理者方法论：目标、任务与创新
制定目标：5W2H与跨级思考
制定目标时，5W2H分析法是个不错的助手，它能帮我们全方位考虑问题，避免遗漏。跨级思考也同样重要，这意味着我们要站在老板甚至老板的老板的角度思考问题。当决策层的期望和理解一致时，我们的方向才不会偏离。
分配及执行任务：对齐目标与数字化流程
动员团队为共同目标努力时，可能会遇到不理解、不认同的情况，这就需要我们持续沟通（沟通、检查、指导）去解决。将团队的日常工作数字化、流程化，共享信息、沉淀知识、为量化提供数据源，比如通过Azure Boards、JIRA将需求管理、研发/测试进度数字化，通过CI/CD将发布测试流程化。
没有量化就没有绩效目标，也就无法细粒度地优化/控制目标。通过团队产生的数据，找到低效的原因并改进，持续这个过程，不断优化团队效率。
可控的失控：试错与创新
允许团队试错，可以激活团队的创新力。因为需求方案的不确定或者技术实现方案的不确定会造成理解差异，这个时候不一定要抹平差异，而是需要给每个成员表达观点的机会，允许试错，来提高他们工作的主动性以及创造性。同时，我们也要控制出错的影响范围以及准备Plan B。
组织架构：敏捷与无为而治
- 面向业务目标的组织架构：通过敏捷开发的方法，让组织更加灵活。
- 不让leader成为团队瓶颈：在技术成熟的团队，技术leader更多的是无为而治并且保持技术视野，通过与成员的沟通来辅助自己决策。
- 组建能力阶梯型团队：团队接到的需求有难有易，当团队的能力呈阶梯型时，管理者能更好地分配任务及发挥团队价值，让合适的人做合适的事，同时考虑用人成本。
- 坚决更换价值观不符合团队的成员：价值观是团队成员面对事物态度的总和，如果一个成员出现问题，它会影响整个团队，甚至产生破窗效应。
- 人多不一定是好事：团队随着业务增加而扩展，但盲目增加成员会增加团队复杂度，因为人比项目更难控制。有时，通过更多资金和设备支持更多的用户、流量、数据反而比增加人力资源成本低。
基于Cloud Native的技术团队：技术与文化的融合
云原生不仅仅是微服务、容器、CI/CD，更多的是workflow和团队文化，这可以提升团队的技术下限，保证团队的研发效率和交付质量。云原生对团队的核心影响是控人、去人化，将以前由人决策转变为由工具/流程决策。
基于Cloud Native的团队特点包括：
- 架构：弹性伸缩、微服务、Kubernetes、敏捷基础设施、Docker、分布式
- 研发流程：自动化测试、DevOps、Code Review、Pipeline
- 团队文化：扁平化、积极、透明、公开、学习型组织
技术管理者的个人成长：守、破、离的旅程
守、破、离的路径：从融入到超越
- 守：融入当前的环境，找到归属感，找到认同感，解决目前的问题。
- 破：在原有的基础上优化、推翻或引入更好的解决方案，不要在原来的限制中做事情，Think something bigger。
- 离：在破的过程中，沉淀实践的经验，转化为可复用的通用经验，从而提升个人价值。
保持技术视野：底层逻辑与知识关联的重要性
技术视野不仅可以帮助管理者做出技术决策，也是向下沟通的沟通语言，所以这要求技术管理者要保持更广的技术视野。但人的精力有限，技术管理者更应该关注知识的底层逻辑、以及这些知识的关联。在计算机软件领域，绝大部分的技术都是新瓶装旧酒，只底层基础设施不变，上层的变化更多的思维的转变。
此外，技术视野也能让技术管理者更好地规划团队的技术栈，在考虑技术栈时我们不仅要考虑支持当下的业务，也要考虑3年后的业务。如果不向未来考虑，那么团队的技术负债就会越来越多，团队的技术也在一直迁移，这是导致团队不稳定以及没有生产力的核心因素之一。
从MVP向PMF的转变：从验证到市场适应
在做产品时，技术管理者通常会使用MVP（Minimum Viable Product）原则来验证技术和产品的雏形，这并没有什么问题。但是当MVP验证成功之后，技术管理者应该更多的考虑PMF（Product Market Fit），找到市场，迭代产品，更多的关注业务价值是作为管理者需要承担的责任。
提升心力：阳明心学的智慧
脑力、体力、心力是一个人的基础能力，脑力帮助我们更好地进行技术决策，体力是执行力的前提，而心力（或者称为精力）是我们常常忽视的。
技术管理者通常会感觉到忙和杂，既要考虑技术，也要考虑业务。比如会考虑到关键岗位的核心能力缺失、考虑竞争部门/对手的压力、客户的压力。这时，个人内心的稳定性尤为重要，面对繁杂的外界因素，技术管理者需要提升心力。
可以通过学习阳明心学来提升自己的心力，王阳明心学有三个部分，心即理、知行合一、致良知。
- 心即理：理不必外求，由内心赋予。
- 知行合一：理一定要与现实发生联系才有意义。
- 致良知：求得内心之理，然后去行动，去思考。
通过这样的润色和扩写，文章不仅更加轻松有趣，又不失专业性，希望能够吸引更多的读者，并启发技术管理者在他们的旅程中不断成长和进步。
