zhaoenweiex的博客

OKR的制定不是一个简单的事，重要的也不是最后这个OKR文档，而是在于让大家能够主动思考关于如何能够更好的推进组织的业务的过程，真正的参与到组织建设和成长中来，而不是仅仅作为一个看客。

OKR实际上是一种目标管理的方法，但能否发挥出这种方法对应的效果取决于使用者对于其的掌握程度以及团队文化的适配性，同时OKR的落地需要一系列的实践来支持。记住想要落地OKR远远不仅仅是制定OKR，还要确保团队成员都关注它，定期推进，对齐，评价和回顾。

近期由于新上马的项目以及主要技术人员休假，于是只能各处救火，参与到多个项目的多个疑难杂症的解决以及临期项目的关键节点的推进，感觉对于解决问题的认知又有了些许新的认知。

背景近期又有一个小伙伴要解决一个性能优化的问题，过程比较经典，所以在这里跟有缘人叨叨几句。案例近期有一个用户连续多次反馈界面加载很慢，而且还反馈到高层管理那，于是找到现场同学确认，发现确实比较慢。【问题发现的过晚，直到用户连续反馈，更反馈到高层那边，这个现象本身就说明整个项目团队的沟通时存在问题的，这个我们先放下不谈】于是，既然是高层关照过的，自然要更加关注，于是找来开发同学，要来系统的地址和账号，亲自感受一下。额，这个界面整体加载完14s以上。。。【原地爆炸】打开页面开发者面板，再来一次，这可是带

背景单机版软件到现在已经超过5年了，基于Java开发的单机软件。主要功能就是数据上传下载以及跟主站的交互。原开发人员在处理其他项目。排查问题已经花了快一个月了。为了拯救现场同学和严重拖期的进度，这件事必须得我来亲自参合一下了。PS：以前的开发同学也提供了相当大的技术支持，但软件毕竟已经超过5年了历史了，什么情况都可能发生。时间轴用户漏扫发现了使用5年的单机软件存在安全漏洞，年初新接手的开发同学应急升级5.1，2.15用户反应新版本出现大量的上传中断问题，3.1有位同学现场支持，安抚客户，3.

前言由于一些不可抗拒力，从2.28开始为期居家隔离两周的生活，从而开启了为期两周的远程办公模式。之前已经有过一段时间的远程办公的经验，想着应该不会有什么问题，但发现还是有很多问题，在这里记录一下，也算是一种经验的分享吧。不同之处由于居家隔离，因此14天完全不能出门，还有门磁导致连开门都要跟居委会打招呼，导致我现在准备结束隔离后连开50次门助助兴；跟家人一起进行的居家隔离，因此生活跟工作不可能分的开，虽然书房关着门，但小朋友还是很可能欢快的跑进来找你玩或是给你看什么神奇的发现；这次远程办公只有我自

背景长大后每个人都有很多关键的决策要做，比如：要不要考研？要不要出国？要不要接受某个offer？要不要跳槽？要不要买房？我最近刚刚经历了一个重要的决策，思前想后感觉有一些收获，写在这里也许能够帮助有缘人。一些原则忌急躁，宜冷静人类的大脑进行决策时会受到所处环境的影响，所以遇到重要决策千万不要着急，只要条件容许找个没人的地方冷静一下，甚至可以把这个事搁置几天，过一段时间拿出专门的时间来考虑或决策效果会好很多。紧急情况下的决策往往后悔的情况特别多，还记得有多少次要交卷的时候临时改错题目么？轻定性，宜定

前言说时迟那时快，转眼间我也35了，9年了还没有年薪百万确实很惭愧，今天就借这个机会聊聊这些年的经历吧。核心问题:我是谁？我从哪里来？我到哪里去？现状航天集团下属某单位的软件团队leader，主管研发。个人内向偏技术特别不喜欢喝酒，感觉跟我大航天集团的传统有点格格不入，能走到现在这个阶段也算是各位领导宽宏大量了【战术狗头】。单位算是正经的国企，应该也算央企吧。团队有差不多20号人，正在带团队主攻一个产品平台，未来有望多个项目借这个平台孵化。日常工作呢目前也就保证30%精力在开发上，其余大多

分级实习级普通级技术负责人副总工程师总工程师方向后端开发前端开发测试人员职责通用职责积极响应用户需求，交付业务价值，包括但不限于开发代码，测试功能，编写文档，用户交流等定位并修复系统问题主动思考，发现组织研发过程中的不足，并提供建议或反馈主动落实提高研发效能的措施改善研发基础设施主动学习专业知识后端开发职责进行项目或产品的系统设计编写编码，实现后端服务，并为前端提供可供使用的接口编写单元测试，确保开发服务的正确性与前端联调测试提交代码前进行自测试确

前言总结近两年在团队中落地OKR遇到的一些问题，并提供一些调整思路。OKR使用现状总结OKR在我们团队推广已经是用了很长很长时间了，差不多有两年了。个人接触OKR更早一些，大概17-18的时候就进行过相关书籍的阅读以及资料的学习。在个人使用一年之后，在团队进行了一些列的分享后，引入了团队。效果确实是有的，至少能在整个团队的范围就想做什么达成一致。我们团队的OKR落地模式基本分为以下三步：每年进行一次年度的团队OKR制定，团队讨论和确认，正式发布。根据团队OKR每个成员进行个人的OKR制定

前言不知道有多少小伙伴最头疼的事就是给团队的小伙伴打绩效，尤其是年终的大考核时，总是有一种如履薄冰的感觉。根据我的观察和了解，大部分管理者打绩效的方式都还是比较原始，完全凭借着主观印象进行评价的，也就是大家常说的拍脑袋。这种方法可能会受到各种奇奇怪怪的因素的影响，比如要是打绩效时心情不错，那这几个人分数可能不自觉的偏高，大部分情况下是无法意识到这一点的。这里呢，介绍一种我们团队刚刚开始实践的改进的360环评方法来提高绩效考评的可靠性和准确性，至少可以降低管理者的工作难度以及拍脑袋导致的脑震荡几率。尝试的

说实话很久之前曾经尝试过进行研发效能的改进，但并没有取得很好的效果，最后各种实践也都逐渐“遗忘”，最后只剩下，站会和回顾会议得到贯彻。但近期有了专职的PO以及重新看了《研发效率破局之道》感觉也许可以再试试，万一成功了呢。什么是研发效能研发效能，是团队能够持续为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三方面。简单来说，就是开发者是否能够长期既快又准地产生用户价值。谈起研发效能，总是有人喜欢把绩效问题也一起

背景近期由于项目需要，需要实现服务的自动主从切换的功能。之前服务都是尽量做无状态设计，状态一般放到数据库层面来实现，这样的需求实际上还是头一次碰到。实际上这个自动主从切换就是一个多实例选主的过程，自然想到了zookeeper，普通的选主功能自然是没有问题的，但我们这个自动切换还有很高的时间维度的要求，于是只能先做架构的验证。代码示例由于Curator已经封装了选主的操作，只需要继承LeaderSelectorListenerAdapter即可，因此实现起来还是十分简单的。特别主要注意在start()之

理想情况，付钱，使用现实情况，免费，没人用付钱，定制使用如果作为一个独立的组织肯定要考虑生存问题，所以一开始的定制模式是必然选择，也就是传统的项目模式，但随着产品成熟度的提高，不同的用户的需求出现了明显问题表现如何处理项目与产品的冲突？实际问题，目标不明确，对于组织现场没有一个清醒的认识这个模式其实就是类似于用友的产品模式...

背景自从读了许式伟的《团队的共识管理》以及乔新亮团队管理的一系列的文章后，一直觉得确实团队内总有一些规则没有说清楚很多事情也没有一个明确的说法，再加上公司层面的远景和使命也迟迟不能出现，那就在此一并解决，于是编写了这个团队共识的初稿，在此公布出来也算是正式投入运行，也许你也在考虑类似的问题，希望可以帮上忙。具体内容愿景成为一支具备行业顶尖水平的能够持续优化且行事透明的自组织软件研发团队团队价值观真正有价值的事情都是做出来的，而不是说出来的任何团队成员都应该主动推动可以改进团队研发效能的事

背景2020已经过去了，个人感觉，英雄榜是实施的颇有成效的一个活动，孵化了UMP的完整的运维系统，UMP的ELK日志聚合系统以及自研的轻量级三维GIS-ZMAP。所以2021这个活动接着搞起来。英雄榜介绍英雄榜是一个类似于游戏中的悬赏任务榜，可以由有任务需求的人向其中投放任务，并标以悬赏的代币，团队人员可以领取英雄榜中的任务，当任务完成后任务发布方给完成人员代币。任务完成方不但要完成指定的任务，而且要把相应成果进行展示和分享算作真正完成任务。目前英雄榜以项目的形式托管在码云上。英雄榜上投放的任务主要

前言本周进行了处于异地内部网络的JGDQ系统升级，发现了不少的问题，非常值得记录和改进，有不少东西不去现场实际操作和体验一下，真的是想不到要改进，趁着这个机会进行一下复盘，以便日后改进。结果初步定位和解决之前操作系统无法启动的问题完成系统升级完成现场测试赴现场1人，实际升级共计4天，其中交通2天，升级1天，测试1天升级准备，共计1人2天优点在订机票前及时检查了大数据行程卡状态，发现异常，避免退票费用甚至不必要的隔离人员行程异常的情况下，依然完成升级任务不足在现场升级后发现有

前言去年已经做过一次低代码平台的分享和调研，当时看到OutSystems时感觉变革可能要来了，但到现在还是没有太大的变化。但最近看到低代码的平台又有不少新的报道和消息，作为重点跟踪的技术，今年有必要再进行一次进展跟踪。先总体的说一下，从泛用性和实用性上来讲，OutSystems仍然是一骑绝尘，而且还在持续的完善细节。国内的平台更多的面向一个领域来解决问题。我其实更加倾向于国内的做法，OutSystems的做法有点过于理想化了，这一幕让我感觉有点像唐吉坷德向风车冲锋。短期内，低代码平台可能发挥业务价值的地方

总体说明本次绩效评价由以往的线下纸质模式改为线上模式，此举为总公司统一安排极为仓促，如果遇到问题请及时提出。大体分为四个阶段，第一个阶段是员工岗位业绩责任书填写，第二个阶段是述职和评估，第三个阶段是绩效反馈，第四个阶段是确认。具体时间安排请参考《通知》。第一阶段的岗位业绩责任书你可以理解为要求，第二阶段是按照要求来评价。对了，据说2021会实施先填写责任书年终再考评的机制，这样将合理的多。填写要求 关键业绩指标（kpi）建议填写 3-6 条，不得少于 3 条，占比 70%（填写权重为数 字，不需要

一些基本情况团队成立距今已有7年团队成员20人码云企业版使用时间超过2年+华为云DevCloud使用时间1年+Teambition使用时间3年+华为的DevCloud集华为研发实践、前沿研发理念、先进研发工具为一体的软件开发平台。我们则是由于地方政府和华为合作，获得免费使用的机会。覆盖开发，构建，测试，部署，发布以及运维的全生命周期。费用方面倒是不高，如下图所示。常见应用场景基本功能组织机构的管理看板，专门给组织管理者准备的。个人工作台也是必不可少可以通过思维导图的

前言之前聊天时有不少人问我每天是怎么安排的，才能每天有时间看书，但其实我觉的每天保持看书其实不是特别一件困难的事情，只是设定好两个闹钟的事情，真正困难的是怎么让每天的学习或是看书对你产生真正的作用，这也是我这几年再做计划时的重点。今天就在这篇文章里跟大家聊一聊个人2020的每日规划，经验教训以及一些改进思路。学习资源情况在介绍每日规划前，我觉的有必要把个人所能调配的资源说一下。毕竟所有的规划都是建立在对应资源上的。纸质书直接采购和图书馆借的；跟团队共享的极客时间的VIP年卡，能够看所有的课

前言之前已经介绍过我们微服务开发的落地和迁移过程和各种经验教训，这次来聊一聊更加主观的东西。微服务有没有简化开发微服务通过将原本单个应用拆解为独立的子系统，降低了单个应用的复杂度，但整个系统的复杂度并没有因此下降，而且额外带来了单体应用没有的数据一致性，网络中断等问题，即单体复杂度< <各个微服务复杂度+微服务间复杂度+基础设施复杂度由于整个服务被分为几个独立的微服务，那么服务的切分与API设计是设计的重中之重，这对于架构师的能力要求极高，什么你们团队没有架构师，那希望你们团队都是架构师

前言在本篇文章中，项目负责人PO，项目经理PM的含义基本一致，但跟传统定义的产品经理还不一样，主要是带领大家搞项目那个人，不但要定义项目或产品，还要管理整个过程，确保最后的成功。上一次我们聊到了需要一个什么样的项目负责人，感觉还是意犹未尽。这次我们继续这个话题，主要聊聊项目经理从哪里来到哪里去的话题。项目负责人这个概念其实一直没有一个清晰的概念，但至少可以明确的是，项目负责人是在项目中有决定权的那个人，如果只是写写文档，做做预算，搞搞策划，但是遇到事都要请示领导，只能说你是一个伪项目负责人。项目负责

一提到项目经理PM广大程序员朋友就从心理冒出一丝不屑，同时回想起无数个“我有个idea就差个程序员”的创业神话。项目经理是啥？项目经理是一个项目的推进者，项目成败第一干系人。他主要负责项目管理，进度监控，风险评估以及与干系人沟通。具体来说大部分工作是：跟用户打交道，沟通需求跟领导打交道，报告进度或是风险跟团队打交道，分派任务或是日常互撕在一个公司里技术好的程序员往往是很好分辨的，他们腰板仿佛是铝合金制的总是挺得很直，因为凭着本事吃饭。与程序员的硬技能相对比，项目经理更多的是软技能。比如沟通技

个人感觉网上大部分文章都在讨论如何能够成为一个卓越的管理者，如何能成为一个卓越的员工，这个视角都是从自身的角度来审视管理者或是员工的。管理学已经这么多年了，真正卓越的管理者却少之又少，方法论和课程总是一套一套的，实际却总是难以落地。今天我们换个更接地气的角度，从被管理者的角度来聊聊对于大多数人来说到底需要一个什么样的领导。为什么需要领导领导是不是必须存在呢？其实并非如此，假如说有一家工厂，实现了高度自动化，工人都是流水线上工作，工作成果都是自动统计。工人每天按时上班，下班。工厂按照工人每天的产品产出发工

前言最近在看《深入核心的敏捷开发》这本书，发现确实有不少干货的，能够解答我不少问题，特别是其中对于展示会的论述很到位。七宗罪准备工作没做好由于参与展示会的目的是展示迭代成果，参与人员大多是关系到项目成功与否的关键人物，因此会有不少的上级领导或客户代表等大佬，他们时间都很忙，所以如果到了预约时间无法进行演示那么情况就不好了，你能想象你的老板盯着你花了半小时才的启动好系统，却发现数据不对么？可能给团队带来极为负面的影响。没有上下文铺垫同样的原因参与展示会的大佬普遍缺乏对于本周期的任务的了解，所以你直

前言国内疫情早就趋于平稳，是时候找回节奏了。在这里更新个人OKR。强化自组织，持续优化和开放透明的团队文化6.15前辅助全员完成下半年OKR制定覆盖全员月度评审季度复盘6.30前改进基础设施确保每个项目的演示和测试环境团队内任意成员在研项目可在5分钟内启动并演示本周期功能9月前新人进入后10分钟内完成开发环境的生成利用虚拟机来保证linux开发环境，物理机工具包前端，docker，node后端，docker，java测试技术进阶实现3%目标7月前实现参与的项目镜像化比例高于90

本来已经实施的OKR计划因为突如其来的疫情打乱了节奏，现在团队已经没人能够记得自己的OKR是什么了。目前国内疫情早就趋于平稳，是时候找回节奏了。在这里更新团队OKR团队内任意成员在研项目可在5分钟内启动发布版本，并顺利演示主要功能技术的KR在研项目全部镜像化部署软件质量的KR软件工程化的KRO2O3...

背景我们总是说要重视职业规划和职业发展，但到底如何落地，大部分人都是一筹莫展。本文将主要探讨这个问题公司想要什么样的人？自己能干活能赋能他人干活能找到活干实际上公司上希望能带来利益的人，无论是完成直接任务的程序员还是要带领公司赢得市场的CEO都是一个目标。但这个利益可能是直接的利润也可能是长远的市场利益。职业发展的原则挑我所爱、选我所长、取我所利、择世所需挑我所爱、选我所长，要发展为稳定兴趣以后，再做选择，而且更重要的是，要有能力促使兴趣和擅长的发展和转化。取我所利，就是找收益大的职

大家好，我是连续坚持阅读1750天的卡萨巴。这篇是个人#154篇博客。喜欢的话就点个赞吧。之前说要给学弟学妹们做一次分享，当时具体内容没有想好，于是回想当初自己需要一个工作了好几年的人分享什么时就有了思路，那就是从学生到职场人士转变的过程

海南白沙项目GIS升级项目广西项目防灾减灾项目

背景当前某个项目进行的异常艰辛，需求分析始终无法取得突破性进展，总感觉客户对于我们有所保留，这一方面先按下不表。另一方面，开发工作则完全是无法推进，因为作为有一个开发基础的YF平台始终无法拿到进一步资料，客户近期更表示可能要到3月下旬才能拿到相关信息，要知道第一个节点是5.31啊，这是要被坑死的情况。所以事到如今也不能等用户了，搜集了目前掌握的ZY平台开始准备架空开发，即在他们的平台上建立一个...

背景这是我一直想写但却没有写的东西，因为一直以来看到的东西都太局限了，不是自己公司内部的那点东西，要不就是大厂的各大平台，对于研发的中间状态或其他路线完全不清楚。不过上周终于有机会看到了一个中型软件公司的研发平台，补全了最后一块碎片。说到最后这个碎片真的是太有意思了，真的是投入了大量研发资源，但是真的是没啥用。可惜了还有这么多研发资源的投入，更可惜的是那么多人还要不得不使用这个平台，应届生毕业...

背景经过一个周期两周的远程开发试运行，发现团队还有不少问题，尤其缺乏一个明确的规则指导，之前又看到了左耳朵耗子的《MegaEase远程工作团队协作协议V1.3》觉得很受启发，特别根据团队情况进行了一些微调形成本文。基本原则0）责任感 & 领导力团队中每个人都是 Owner，都是 Leader，每个人都是产品经理，每个人都是项目经理，如果看到团队或是项目有问题的时候，不要等，...

背景相信过去的一周一定给大家留下了很深的印象，无论是被隔离在家无法返工的同事，还是每次去买菜都胆战心惊的自己，都深深的刻下了时代的烙印，更不要提还在封城的武汉。一个小小的肺炎竟然把人类为名逼到这种地步，真是有点无可奈何，说到底现在还是人类文明还有很长的路要走。虽然百万年来已经称霸地球，但在自然面前还是脆弱不堪。额，扯远了，今天我们还是来说一下这一周的远程开发吧，相信上周绝大多数人都无法回到公司...

背景在新型冠状病毒的淫威下，公司上班时间调整到初九，而且外地归来的同学至少隔离7天，个别地区隔离14天方可上班。所以公司在开工初期肯定会出现人员不足的状态，隔离期间大家在家也实际上无事可做，所以考虑在这个特殊时期引入远程开发，其实我们团队早就想引入远程开发但限于文化和气氛没有实现，正好趁这个时候搞起来。本文就是想讨论一下我们准备要使用的工具和一些思路，可能有一些不成熟的东西。协作规范团队协...

背景2019年已经过去了，不知道有多少团队能够真正的回头看看这一年，总结梳理一下得与失。本文介绍一下我们团队组织的2019回顾会议的做法，欢迎留言讨论。会议目的增强团队的凝聚力梳理团队的工作成果梳理成员的成长实践改进的团队文化阶段划分开场，说明目的，预估耗时和主要结构热场游戏团队项目总体复盘和分析团队成员每人给出Good，Bad和印象深刻的事项并讲述重要的事注意...

魔法信用点

背景每次面试时都想考察的一点就是面试者的学习能力，但这个能力往往又十分的抽象，偶然间翻到了下面介个问题觉得还不错，记录下来供大家参考。具体问题你能够想到你最近完成的工作，它可以反映出你运用新技术去解决工作中遇到的问题吗？当时是怎样的情况？真实性验证那是什么样的问题？真实性验证你用了什么新技术？是否是真正的新技术你是如何学会这种技术的？途径是否是野路子使用...

背景