88 lines
9.7 KiB
Markdown
88 lines
9.7 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
大咖对话 以产生价值判断工程师贡献--读者留言精选
|
||
你好！
|
||
|
||
欢迎来到本周的“大咖对话”环节。不知不觉，“技术领导力300讲”专栏已经更新了4个月，走过了三分之一的路程。
|
||
|
||
在这四个月里，我们邀请到了近40位CTO、技术VP、有技术背景的CEO等技术领导者来分享他们的实践与经验，话题涉及技术领导者的核心能力、高效技术团队的打造、高效研发流程的建设、技术团队的考核与激励、技术团队文化的建设、空降管理者该如何平稳落地、技术领导者的产品思维等多个方向。
|
||
|
||
不少读者踊跃留言，分享了他们的观点，也留下了他们的疑问。本周的“大咖对话”环节就筛选出了往期留言中具有代表性的问题，并邀请了相应的大咖来回答。你可以点击文中链接，回顾之前的文章。
|
||
|
||
在[《如何高效管理8000+规模的技术团队》]一文中，有读者留言问道：“文中提到要打造一个数据化管理体系，把IT管理的对象数据化，想请教一下，数据收集的具体维度是什么呢？如何衡量一个工程师的贡献度到底有多大呢？是看代码量，修复bug数量，还是攻克关键问题的数量等，能分享你们的具体做法么？”
|
||
|
||
苏宁易购IT总部执行副总裁乔新亮：我们数据收集的维度分两个方向，第一个是数字化资产，第二个是工程师对数字化资产的贡献。
|
||
|
||
首先，数字化资产会包括产品、系统、服务等资产，以服务中的用户体验为例，它的数据化考量维度就是响应速度快不快、异常情况多不多、服务可用性高不高、响应时间的SOA满足率怎么样等。
|
||
|
||
其次，每一个数字化资产都会对应到某个工程师或工程师团队，他们会负责这个数字化资产的开发、测试、维护等，因此，衡量工程师的贡献度，是从结果出发的。读者提的问题可能更多的是站在开发者的角度，衡量他做了什么，而我们是从整体的、偏宏观一点的角度出发，不管他写了多少代码、解决多少问题，只看他最后产生了什么价值，比如他参与开发的系统响应速度控制在了多少以内等。
|
||
|
||
另外，我们的衡量细度也不是具体到人，而是看具体贡献情况，看是以小团队为单位还是以人为单位，如果是以团队为单位，那就是公司将评价数据分配给团队后，再由团队分配到个人，得根据具体的情况调整。
|
||
|
||
在[《让细节的“病毒”感染你的团队》]一文中，有读者留言问道：“关注细节的确有益于把控系统，但如何保证当技术领导者介入细节后不让团队成员对你形成依赖呢？另外，越级介入一些系统，是否会导致基层员工的不创新、不思考呢？”
|
||
|
||
白山CTO童剑：第一个问题，如何防止团队成员形成依赖，我们可以从以下几个方面出发：
|
||
|
||
|
||
培养关注细节的文化;
|
||
建立制度，使细节变成一种流程;
|
||
多提出问题，让团队成员来思考解决办法，给他们空间让他们按自己方法去解决;
|
||
启发式引导，不要一上来就告诉他问题和办法，而是要引导他们发现问题，启发出解决办法；
|
||
管理者是逐步退出的。
|
||
|
||
|
||
第二个问题，如何避免形成基层员工的不创新、不思考，我们可以从以下几个方面出发：
|
||
|
||
|
||
管理者并非越级介入，关注细节的文化形成后，团队中每个人都重视细节， 高层与中层确认细节即可，不影响底层开发。
|
||
管理者对细节的关注和参与，就像教练一样，是传授给员工更好的做事方法。
|
||
管理者对细节的关注和参与，也是以身作则，给员工做出示范，既给员工压力，也让员工有榜样学习。
|
||
对于基层员工，鼓励创新与思考，管理者对其开发细节的关注，是为了帮助基层员工更好的完成开发。
|
||
基层员工更多是从开发的角度思考，而中层和高层的领导者需要从使用者的角度设计产品功能，领导者的参与过程中会给基层员工带来更多的视野，对基层员工本身也是一种提升与培养
|
||
文化是一种彼此交流的基础，我们有招聘的“洁癖”，大家有共同愿景，不会因为上层的过多介入而失去主观能动性，乔布斯说“A级人才的自尊心不需要呵护”，同样“对于A级人才也不必担心上层介入会对其产生负面影响”。
|
||
|
||
|
||
在[《建立有效的员工淘汰机制》]一文中，有读者问道：“对于“合格但不合适”的员工，要怎么处理呢？又该如何确定赔偿方案呢？”
|
||
|
||
好买财富平台架构部技术总监王晔倞：在我的经验中，这种情况一般分为两种，“试用期”与“正式期”：
|
||
|
||
1.试用期阶段，这时不需要客气，直接说明不合适的原因即可，也不需要任何赔偿 。这种情况的发生很大程度上是由于公司和员工对岗位职责的界定不清晰而引发的。
|
||
|
||
为了预防这种情况，如果试用期为6个月，可以采取2个月考核一次的方式，前2个月可以安排对方做一些验证其技能的工作，甚至可以设定一些无中生有的任务，后2个月可以安排对方做一些验证其价值观的工作，如项目经理等推动与沟通偏多的工作，最后留出1个月，如果对方不合适的话，留出让其重新找工作的时间，这样做基本可以达到好聚好散的目的。
|
||
|
||
2.正式期阶段，这时有两种做法，硬开和不硬开。硬开的话，按照劳动法，肯定是按照N+1的方式来赔偿的，如果对方非常较真，一般情况下是无法拿出量化的具体依据来证明其表现不好的。 不硬开的话，可以通过谈话、调岗等手段进行，至少让他觉得你们的企业还挺Nice的，不至于产生负面印象。
|
||
|
||
所以我觉得，关键在于试用期的把关，如果无法守住这一关，光想在正式期采取“有利于公司”的方式开除员工，既不合理，也不可取。
|
||
|
||
在[《定制高效研发流程》]一文中，有读者留言问道：“特赞币的做法确实挺好，不过这个虚拟货币的价值是什么呢？各角色为什么要去获取它呢？”
|
||
|
||
黄勇：特赞币只是一种工具，它用于解决研发和业务之间的高效协作问题，业务提需求需要“花币”，业务提反馈可以“赚币”，币的总数是恒定的（在一定条件下会考虑增发），币在业务与研发之间进行流通。
|
||
|
||
这样，业务提需求是一件需要付出成本的事情，确保所提的需求都是真正的痛点，同时，研发也能尽可能快地收集业务反馈，进一步验证产品的价值。对于优先级较高的需求，业务也可以花费更多的币在这项需求上，研发也会更加重视该需求。
|
||
|
||
在[《 验证研发团队价值的绩效考核机制》]一文中，有读者问道：“关于个人OKR部分想请教一下，个人OKR分为个人成长和团队贡献，那制定的个人成长和贡献怎么来评估是合理的，可执行的呢？”
|
||
|
||
黄勇：我在“组织架构篇”中提到过“职能团队”，该团队主管的职责就是帮助队员制定合理的 OKR，目的就是帮助他们得到成长，只有队员成长了，主管才会成长。
|
||
|
||
另外，每个人将自己的 OKR 制定完毕后，需要在对应的职能团队中分享，其他队员或主管可提出一些要求，修正或丰富这份 OKR，可以将其看做是 OKR 评审，而这样的评审可以是正式会议，也可以随机探讨，可以一次也可以多次。
|
||
|
||
OKR 均由自己制定，并由职能团队评审，当大家觉得没问题了才算合理，其实这里包括两方面，一是个人的追求，二是团队对自己的期望。
|
||
|
||
在[《CEO实话实说：我需要这样的CTO》]一文中，有读者问道：“您提到CTO需要有进化的能力，我理解就是学习能力，大家平时也都会学习，但多数是学了、理解了、用了，就完了，是否需要以学位、证书等方式加持呢？”
|
||
|
||
乂学教育创始人栗浩洋：我说的进化能力，绝不仅仅只是学习能力。它其实更多的意味着一种自我摧毁和自我扭曲的能力，就好像老鹰要把自己身上的羽毛全部啄光一样；就好像一个打乒乓球的奥运冠军，要学打网球的時候，完全不能用自己过去的套路，不能用手腕，而要用整個腰身的力量一样。进化是要改变自己过去的思维习惯，完全变成另外一种物种。
|
||
|
||
这个时候其实会遇到很多不习惯、不舒适甚至是痛苦的地方，当然也能从中发掘很多有趣的地方。所以我觉得学位、证书的加持只是一小部分，并不是必须的，重要的是他是否真的学会了知识、开拓了思维。甚至可能他只是完全的自学，或者是跟身边的人去学习，也能够完成进化。关键是他自己了解了新的知识，在进化到新领域时转变了一些旧有的思维、行为习惯，以及能夠驾驭新的环境。
|
||
|
||
结语： 本期筛选了管理细度、研发流程、绩效考核、员工淘汰等多个方向的问题，希望作者们的回答也能解答你的疑问。
|
||
|
||
感谢你陪伴“技术领导力300讲”专栏走过这四个月的时光，如果你对专栏有任何意见或建议，欢迎后台留言，留言被选中的同学将获得极客时间10元代金券。
|
||
|
||
感谢你的收听，我们下期再见。
|
||
|
||
|
||
|
||
|