引言:去年以及今年由于工作需要,参加了公司请的美国管理协会的《高价值经理人》及敏捷 OKR 绩效管理的培训课程,此外也阅读了《格鲁夫给管理人的第一课》、《架构即未来》、《技术管理之巅》、《OKR:源于英特尔和谷歌的目标管理利器》几本书。总体来看很多管理的理论其实日常自己也在实践,不过这些书的确让自己形成了自己的管理体系,能够有序有法的进行一些管理实践。本文从

管理是推,领导是拉,领导设定目的地和通往目的地的路线图,管理设法达到目的地。

任何工作都有产出,需要设定好指标衡量产出。疏与度量注定事情永远不会改变。

前者是规律化的,是有必要的,可以选择效率高的方式;后者是临时的,需要尽量减少此种会议。

全体会议一定要有一个主持者,避免陷入两人交谈。主持者最好是一个职位较高的人,可以避免同级全体综合征。

需要建立有效沟通机制和处理问题的模式,如例会,避免下属缺乏反应问题的渠道而抱怨。

对于第一象限的人,需要提供其更多的机会,做好适当的监督即可;对于第二象限的人需要给予工作上的指导,使其能够走到第一象限;对于第三象限的人,需要解决其心理问题;对于第四象限的人则需要谈话改进。

可以把权利下放,但必须对其结果承担所有的责任。把赞扬留给团队,承认失败并公开的承担责任。

推行某种制度/规范的时候合理的做法是先降一个力度,等适应后再 100%推行。

亚马逊的两张比萨饼团队:任何一个团队的规模不能大过两张比萨所能喂饱的人数,超过则需要拆分。

AKA(All Know All Things)。要营造一种公开、公平的氛围,不搞遮遮掩掩的事情,让大家都知道所有的事情。

混血性组织(组织之间有人员交叉,在不同的组织中担任不同的角色)需要双重汇报。

使用 KPI 做绩效考核如果遇到诸如难以打分、沟通不畅、抱怨强制分配等问题可以采用 OKR 做考核管理。

借鉴 Google,可以采取半年绩效考核(自评+他评)+OKR-总分的方式做考核。

其中采取半年的节奏是一方面是为了和 OKR 季度回顾的频率错开,另一方面对于某个重大失误可以凭借后续的其他贡献做中和;自评是需要自己陈述考核周期内的工作,他评需要被考核人邀请和自己工作相关的 n 个人给自己打分/评价;OKR 部分的最终得分只是作为参考;总分最后由直属 Leader 综合考虑几个方面打出。

努力的成本是团队规模的平方。so,技术团队的规模需要控制,人数过多的话需要考虑分拆。

技术需要与业务高度融合,需要培训懂业务的技术专家,切忌离开业务空谈技术。

十人以上技术团队可以采取轮岗来提高大家的技术热情和技术广度,但需要做好岗前培训,尤其对于技术门槛较高的岗位。

以价值为导向,建立需求管理闭环,给业务需求方设定信用分,价值预估,上线后进行价值验证以判定价值达成率,从而直接影响信用分。

面试可以采取行为面试法,即给予实际案例看其解决问题的专业能力和思维能力。

技术团队超过 300 人需要建立职业发展体系、能力发展体系以及培训发展体系。

技术管理者需要发展三方面能力:专业能力、领导能力以通用能力(沟通能力、执行力、团队协作、责任心等)。

飒然 Hang,《Java 工程师修炼之道》作者。重度 Java 使用者,专注于 JavaEE、系统架构、分布式等后端技术。维护博客 ()返回搜狐,查看更多

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注