前言
从硕士研究生毕业、工作至今已有10年。最初从一名工程师到今天的架构师、技术团队负责人，逐步认识到技术管理的重要性。尤其是在互联网公司的技术团队，当所面对的业务发展快速变化且对技术又需要其能很好支撑的时候，技术管理就成了“事”和“技术人”之间的催化剂与润滑剂。无论对于技术团队的成员，还是技术团队的管理者，能够在意识中认识到你所在团队的技术管理是怎么样的，是如何推动“事”和“人”向前发展的，你是如何在这个过程中成长并达到你想要的未来（这里有个问题，看到这个文章的你想清楚你想要什么了么？ 😀），都是一件重要的事。
为什么谈技术管理
首先，我们所在的组织，比如互联网公司，为了推动业务发展，技术水准及支撑能力都需要技术团队不断的完成这样一个轮回：发现问题---设定目标---完成目标。那么，如何能让技术同学在这些目标下，完成工作达成业绩，同时又对自身的技术成长（包括软能力的增强）带来正向反馈，并不断地更好地促进新的目标的完成，就需要管理来催化，来催化“人”；
其次，“公司也是一个社会系统”，有其业务发展的“意识”，而企业的员工也有其自身的“意识”。这两者间的意识相互交融，尤其是组织目标和每个人的目标与期望不一致的时候，就会带来复杂性（而这种复杂性也会经常出现）。好的管理，能够让企业老板和员工“上下同欲”，大家一起真心实意的为客户满意给客户带来价值而努力、好好的研发自己的产品（好的用户体验及好用的功能，解决用户痛点），从而获得自己想要的回报与未来；相反，也有可能让某些员工觉得，“... 这只是一份工作而已... ”， “...这个问题关我啥事...，我才不管，...”，“目标就是做这个，但我不知道为啥是要这么做，这对我有啥好处，就这样吧，...”。
因此，我想这里需要的是管理的方法和文化，对于技术团队的“技术管理”，同样也是需要的。但无论怎样，本质上对于组织和人来说，可以概括为那么几点：
- 对于员工来说，需要你的行为符合研发团队的文化并完成组织业务发展的目标。正如技术团队的研发文化所讲的，首先需要你来适配组织发展的需要：
- 对于组织来说，也需要不断变革，通过给予新的机会来适配员工发展的需要，进而获得组织更大的发展。有的员工不想做螺丝钉，希望能够有更大的成长、更多的参与感、获得感和认可度。
因此，只有当两方面达成共识，不断相互调整，彼此相互促进，将“事”才能推向更好的层面。不然的话，结果就是被动出局或者主动离开。
技术管理方法论之我见
公司中，每个人都会属于一个团队。有同级的员工，下属，也有老板。这就组成了一个“场”。在这个“场”中，需要团队成员共同协作努力，去推动“事”的发展。
先识别出“事”和人
在面对这些“事”的时候，你是否能识别出这些“事”的边界、机会、复杂度在哪里，以及需要什么样的人、什么样的方法去办。首先这一点要先认清。
其次，是识别人。上面那个由圆环组成的人，其中他们有可能既是管理者又是员工。之所以是一个环，意思是这些团队内的员工彼此之间所应该具有的“连接”属性且平等，并在“技术管理”这个催化剂下，不断的增强连接（人与人，“事”与人），如：
- 相互平等且坦诚沟通的连接属性；
- 在共同目标（多目标）下，人员（几个人）共同努力协作完成目标的连接属性；
- 彼此间相互理解，能够胸襟开阔，能够发现彼此间成员身上的优点（可学习之处）、能力和特点，形成共同努力提升自己的能力水平及价值的比拼连接属性；
- 不断的推动“事”的发展
那如何推动这个这些“连接属性”，彼此促进，最后推动事情，同时场中的“人”又能够不断成长，发挥更大的价值呢？
构建“结构性张力”
除了薪水之外，可以真正驱动团队成员努力上进的是什么呢？按照得到“刘润老师”讲的概念 -- “结构性张力”，讲的比较透彻，即成员想要改善（改善自己和“事”）的“期望”（差距）。 管理者，需要能够构建一个“结构”，让成员在这个结构中，通过获取资源，自发地努力不断的达成“期望”，有时还要不断地帮助成员，改变“结构”，增强“正向回路”抵消“调节回路”带来的影响。具体来说，
- 对管理者
首先，肯定员工能力与价值，同时设置好的榜样，设置好“期望”，并通过放权，给予负责某些事情的机会（下放权力），给“种子”成员放到核心位置，让成员将“事”的完成变成自己的“期望”，让他成为发动机；
其次，在员工推动“飞轮”旋转的时候，管理者需要能构建改善“调节回路”的机制、流程或者制度。比如，“技术方案脑暴讨论会”、“目标讨论会”，“One-on-One Talk”等，及时发现问题、纠偏、调整，及时给予正面的认可和反馈，帮助员工一起推动问题的解决，保护好原始的那份“期望”。另外，也需要沉淀工具、沉淀项目管理方法、沉淀系统设计与开发的方法，让员工能基于部分过去的成功经验做事，减轻实现“期望”的阻力；
第三，管理者与员工一起工作时，要将自己的心态摆平。找机会能与团队成员一起共事。比如，共同开发项目coding并一起协作。但也不能大包大揽。要有机会让员工自己提出设计、方法和代码。一般情况下，架构设计没有对与错，但一定有好与坏，且好的架构原则是有共识的，好的代码和编程规范都是有共识的。过程中，需要平等沟通达成共识，并坚持共识的执行。同时，留有一定的空间，允许一定的偏差的发生，但通过事后补尝回来；
第四，对“事”，管理者要能不断的开创新目标并进行规划，给产品在公司内/行业内定影响力，能够对产品系统架构提出优化与发展的方向，并建立强有力的自身技术影响力，能够让员工看到自己有技术成长的空间，同时技术上有先进性。员工通过做事，自身技术能力及价值有提升，带来更多的获得感和成就感，并获得认可；
- 对员工
首先，员工自己要强化自身的底层“操作系统”。一方面是自身软素质：诚实、聪明、正能量（乐观）、“成年人”（情绪管控）、努力肯干积极、有追求和想法、沟通（含向上沟通）、认识自己；
其次，员工自己要不断的不停的学习。不断扩展技术的深度和广度，重视总结。联想项目中的问题与技术实现：“...其本质需求是什么...”，“...技术架构有没有其他选择？这样一种架构和技术实现，在相关的其他应用场景里是否适用?...”，“...我们是不是能拓展一下边界，把其他系统整合起来提升效率和整体稳定性...”。
第三，能主动发现问题和目标，并增强自己推动解决更多事情和问题的能力，这也是往前走的前提。
最后
有了方向、方法、认知，最关键的还是那句话 --- “知行合一”，即有实际行动。只有行动了，才算是真的知道了，所谓的“方法论”也才算是真的有用的方法。共勉！
