服务电话
长治市捷星网络： 新闻资讯 
行业新闻高效团队技术leader必备的5点角色认知和责任
技术原点：
At the end of the day你还是一个工程师
当我们从一个工程师进化到管理者的时候，往往会有2大误区：
1、当你作为管理者的时候，你会认为管理能力的重要性，远远重于技术。
2、你会认为，管人（People management）的重要性远远重于管事(Project Management)的能力。
不能把学而优则仕，学而优则管当做常态。我并不是很赞成盲目努力，譬如让技术优秀的人去做管理岗，因为这样的结果很可能是，你将失去1个优秀的工程师，得到1个三流的管理者。
做到管理岗位就会高大上？这是一种挺大的误区。而重点其实是我们带给团队怎样的技术观和价值观。
首先，我们自己（技术Leader）保持自律。
譬如每年学习一种新的编程语言，每年深入关注一个新的技术领域，每年自己编码完成一个软件作品。
其次，了解到技术能力的的迭代和进化，对于整个技术团队的必要性。
我所看到的成功企的技术管理者，往往都是在技术领域上精益求精、不断提高自己。
会有很多人说：“我平时的管理工作挺忙的，实在没有时间去写代码，去学习技术。”大家可能听说过Google的Jeff Dean，带着3千人，但每周会给自己留半天或一天时间敲代码。
不管我们承担了多少的技术工作，还是要具体技术提高的能力，对技术的坚持，是我们应该传递给团队的价值观之一。
技术方向：721法则
技术方向是一个很核心的内容。而首先，需要明白技术和业务，是技术的2面。
1. 业务，或者说工程（Engineering），在不同时空复杂度的要求下，它会不断演变出新的技术（Technology）挑战来。
2. 警惕过度追逐没有实际问题可解决的技术热点，对于团队中类似“一直在做业务，技术没有进步”这样的困惑能胸有成竹地回答。
如何平衡业务和技术，可以参考721的法则。
团队70%的研发能力和研发资源要投入到公司的主线业务上去，这是公司现金流的主力；
20%的资源需要提供到技术攻坚上去，这类问题应该是已知且有解决方案的，只是比较有难度和深度，需要花多一点时间；
以上90%都属于一定要做的事情，需要can do的态度，而最后10%是未必能解决的，可以say no，因为它们解决的是高风险的领域，我们并不知道这个东西能否带来产出和效果，属于创新探索型工作。
很多时候，在投入最后的10%的时候，技术主管会受到很大的压力，因为财务部门希望把钱投在有营收的事情上，而业务部门希望所有的研发围绕着业务、客户的需求。这时候，作为团队的技术领导者，需要自己的坚持和参考，这件事情是否值得去冒一些风险。
“
技术的领导者需要做些前瞻性的投入，不能等到需求方倒逼。
”
比如，2017年，我们就注意到了Apache Flink实时数据处理框架。虽然流计算在Storm,、Spark Streaming等典型框架中也有体现，并不算新鲜的概念，但随着Flink在社区不断得到认可，2018年阿里开始做批流共进的计算引擎：Blink，基于Flink，但又继承了批处理能力(batch processing), 所以Batch processing+Flink = Blink，将批处理和流处理结合在一个框架里是比较有特色的。
因此，虽然当时还只是简单的技术框架，没有太多实际的业务场景，但是我们已经预感到在18年下半年开始会逐渐地有相关业务需求出来，所以我们就先一步地做了基础调研和资源投入，果然，在今年开年就基于之前的基础落地了实际的场景。
技术决策：依赖“常识”做判断
做正确的事
技术面试的时候：你对候选人不了解，你也很可能对他擅长的技术背景不那么精通；
技术选型的时候：流量、负载、容错性、可扩展性等等，都是未知但却必须考虑的因素；
技术攻坚的时候：不同的技术团队遇到的不同领域的技术难题需要你去指导解决。
技术决策里面，往往要面临的最大的挑战是不确定的情况，因为没有预先准备好的知识体系。这个时候，我们需要做到依赖常识去做一些判断，做一些正确的决策。
好的技术团队文化：重视逻辑、讲究常识、说人话、互相间尽可能平视的视角、不唯上只唯实。
“常识”工具盒
1. 评估候选人的能力（比如责任心，抗压力，创造力），而不是知识
2. 做任何决策，先问问评估成败的核心指标是什么
3. 核心指标宜少不宜多
4. 指标要尽量可量化
5. 先抗住再优化，边重构边生活
6. 持续迭代，而不是过度设计
7. 化繁为简
8. 其他人听不懂的一定不是好的技术方案
9. 让懂的人和不懂的人都能坦然地表达自己的“有知”和“无知”
10. 有违价值观底线的方案坚决不采纳
11. 先统一思想，再约束行动
技术外沿&技术人才
作为一个团队的Leader，我们要关心的不仅仅是团队的业务发展和技术深化，还有这之外的一些问题：专科申请、外部技术和影响力的建设、内部技术氛围的建设，企业基础IT的建设、成本管控等……
因为并不是所有的企业，尤其是初创企业，都具备这些职能，但作为技术的负责人，你需要主动担当。面对一些对团队有利的事，我认为：
1、有条件需要执行地坚决些；
2、如果没条件就需要创造条件执行。
最后，找到并留存技术人才，同样是Leader应该关心的，你就是团队最重要的HR主管。有人会有顾虑：招了人、投了钱去培训员工，他们走了怎么办？
没有人为企业打工一辈子，不过我希望的是，不管你是在团队呆1年还是10年也好，在团队的时间里，你是有收获的。而当你决定离开，找寻新的机会时，你是希望这个团队给你带来新的东西，帮助你提升到一个更高水平。
这样，企业完成了另一部分的社会责任，而培训是企业需要做的义务和责任。
“
Keep looking don’t settle.
”
微脉技术负责人 周志章
技术管理-提升技术团队效率
看起来人人都很高效，但组织效率不一定高
工具是组织效能的一部分，行动力也是
鼓励高效，就必须区分加班和磨洋工
如何提升技术团队效率？可以从以下几点着手：
建设或引进效率工具
工具也是我来到微脉做的第一件事情。开始的时候最大的感受就是：不快，说白了就是没有太多的工具。
因此，我们提出并做了微脉的四化 – 可视化，自动化，自助化，智能化。目前已经成型的三大工具 – 任脉/督脉/代码生成工具。
效能工具，就是让效率和能力得到提升的工具。
任脉：打通医疗行业血脉的自动化发货工具
打个比方，一些底层一线人员，往往不需要做太多的决策，但想要coding（如建一个分支），需要先邮件汇报，这个申请和回复的过程是比较久的。但是为了效率，通常来讲，5分钟需要解决所有问题，这时候，工具（任脉）就可以实现一键操作并且可以回溯查询。
通过工具，微脉实现了1个Q完成百来个需求点，是上半年的2倍。这就是工具带来的高效。
让架构设计贯穿始终
产品经理让你做什么你就做什么？这样的结果很可能就是技术在原地打转。
而架构可以确保以最低的代价完成项目需求，持续的架构治理是不重复造轮子的关键。这是做传统企业提升，对产品负责人来说最重要的点。
比业务快半步：业务判断
前瞻性：做好技术储备，提前规划产品，建立架构共识；
模块化：UI模块化，模块化建站，代码生成器，通用模块池；
评审单元：控制内审，控制变更。
梯队/能力建设
梯队占比：经营层 2% + TL层 8% + 执行层 90%。合理的梯队建设是提升组织效率的法宝之一，不一味地追求扁平化。
一方面，10%的人挡掉 90% 的干扰， 2%的人挡掉90%的政治任务。一方面，10%做前期的业务，技术沟通探索，这样执行层的90%就可以做确定性的事情。
能力建设
1）人才培养：
a. 借事修人，闭关项目
b. 因人成事，老带新
c. 教学相长，培训体系
2）招聘2大原则：
a. 中等偏上（人才标准）
b. 成就原则，5k成本预算招到工资3k的人，但是你其实发现他的能力是价值6000元的人。这种情况下，招聘者成就了人，应聘者则感觉是平台成就了自己。
针对90后招过来，管不了，留不住的问题。
我认为首先要事实求是地讲话，而不是夸大其词。其次，90后的知识体系，可能和我们并不一样，给他定个高目标，剩下的事，就是他做的开不开心的问题。因岗位设置职能，在架构线和职能线上进行调整。
最后，满意度=期望值*体验。技术负责人也要学会做PR，从而得到员工的认可。
汰换：
1、对比相对
2、因岗设人
最后，需要设置行动目标并保持优化。那么，什么是目标？被公司喊得最多的诉求就是业务目标，被研发喊得最多的诉求就是技术目标。技术负责人需要对这两种目标做一定的平衡。
“
你的意见很高效，你的团队也会很高效
