一、Review常见土话
Review的初心是赋能员工,让员工感知自己的不足,进而给到一个修炼场给予进步的力量。
Review的过程不是让员工遍体鳞伤,而是要在一个地方捅出血,这样员工才更深刻的反思。
Review是阿里的老鸭煲,原本只是一个绩效沟通工具,但阿里把这个工具用到了极致。
任何不能赋予员工力量的Review都是耍流氓。
二、Review场景再现 某老员工与业务老大的review场景。
某位在江湖上摸爬滚打了三四年的老销售入职阿里巴巴,参加第一次正式的Review。这位老销售以为所谓Review,就跟以前的述职一样,说说业绩,谈谈计划,表表决心……其实不然。 业务老大:聊聊你这小半年的感受吧! 老销售:总体上,我觉得公司的氛围很好,个人成长空间也很大,目前业绩只能说60-65分,继续努力,争取下个季度再上一个台阶…… 业务老大:兆头不错啊,该表扬鼓励一下……我们来谈谈价值观吧!关于客户第一,你是怎么理解的? 老销售:客户第一啊,就是做什么事情都要考虑客户的利益,因为客户是衣食父母。 业务老大:那你觉得你这几个月做了哪些事情是基于客户第一这条去做的呢? 老销售:……(不知道从哪里说起) 业务老大:客户第一应该这样解读,首先你的本职工作是不是得到了客户认可?做到了,只能说是符合期望的,或者说,勉强符合期望,超出期望才是真正的客户第一,怎样做到超出期望呢?比如…… 老销售点头,其实有点茫然。 业务老大:接下来,我们来谈谈团队合作,关于这一点,你觉得这几个月做得怎么样? 老销售开始从郁闷中走出来:我觉得挺好!我从xx过来才一个月,就和xx这边的同事打成一片了。 业务老大:那你说说看,你跟哪些人很熟?哪些人不太熟?他们都是什么情况,都是什么性格,你帮助别人做过什么,别人帮你做过什么?…… 这就是Review的现场回放,有的只需Review几十分钟,阿里曾经有个Review超过8个小时的记录,话如果不说透,是不让出门的。
三、Review的“三招九式法” 对于员工review,阿里文化布道官王建和总结过一个 “三招九式法”。 “三招九式”是什么?三招包括准招、重招、后招,每个招对应三式。 第一个是准招,是在员工的表述方面;第二是出重招,是指管理者与被Review人员的双向深度沟通。第三是有后招,是管理者的指导。 1、准招——员工表述三个层面
员工在review的第一个环节,一般需要被Review的员工用10到20分的时间呈现并讲解PPT,一份规范的PPT模板包括三个方面内容:过程、结果、规划。
(1)表述过程。要求能够跟对过程数据抽丝剥茧的深度思考,会要求团队伙伴根据阶段数据、业绩和成长点的表述,把这个数据背后的问题来拎出来。 (2)表述结果。结果是对整个事情的完整复盘,从目标的共识,到过程的层层分析,再到核心关键点指标的提升。这样一步步下来,基本就把整个事情的全貌看的清清楚楚,哪里做的好、哪里有问题也一目了然。 (3)表述规划。阿里有句土话叫:今天最好的表现是明天最低的要求。不管这次Review你做的多好,它已经是你过去的表现了,要有对下个阶段你的详细工作规划内容说明。 2、重招——沟通的三个维度
所谓重招,是要剥开过程的表象,深挖问题的本质,发现问题并反复确认问题,最终达成一致,为下个季度在方法方面、数据方面、结果方面全部给到支撑。 重招时,我们同样从三个维度来沟通,第一结果维度、第二过程维度、第三规划维度。 (1)结果维度 A、谈目标。首先要回顾上个季度的目标, 先要明确刚开始设定的阶段性目标是什么。目标就像指南针,方向错了,所有都会错。 B、看结果。看看实际的数据结果是否达成目标,这是唯一的标准。在过程中,没有苦劳,只有功劳,一切用结果说话。 C、给评价。根据结果给予及时的表扬肯定和批评。惩罚要清晰明确,奖就要奖得心动、罚就要罚得心痛。 (2)过程维度 A、结果好过程好。马上让他总结分享,全面扶持,成为标杆。 B、结果好过程不好。要做警醒,帮员工去找出影响结果的关键因素。 C、坏结果好过程。要透过现象看本质,到底是过程造假,还是技能存在问题,一定要把这些核心的东西抓出来。 D、坏结果坏过程,先看意愿度,如果意愿有问题直接棒喝。必要时候要签署绩效改进书,持续两个季度如此直接作出辞退,心要慈刀要快。 (3)规划维度A、聊目标。根据季度Review的总结去制定下个季度的目标,根据总结规划,清晰接下来的目标,并深度探讨目标的可行性。 B、聊目标。要让员工自己去规划自己下个季度成长,他对于自己的成长的期许是什么,规划是什么?要有可明确落地的动作。 C、聊团队。聊对团队的建议和期许,聊团队因我会有什么变化。 3、后招——管理者三大心法
后招指管理者一定要帮助员工去成长,要给到具体可执行的方法,这是阿里巴巴领导力修炼的三大心法:揪头发、照镜子、闻味道。 (1)揪头发揪头发就是要帮助提升他的眼界、提升他的视野、提升他的格局。 如果是员工,你要让他上管理者的视角去看问题;如果是管理者,你要让他上到总监、总裁甚至上到集团事业部这样的层面去看待问题,不要总是小圈子主义,不要总是屁股决定脑袋。 (2)照镜子照镜子就是要让员工明白自己内心的想法,明确现在的工作是不是他的喜欢和热爱、明确今天做的事情能不能做成你今后10 年、20年拿生命来换的东西,只有让员工知道他的喜欢热爱,他会全力以赴的投入。 (3)闻味道闻味道就是了解员工对于公司倡导的价值的理解,这个员工是不是我们同类人,是不是志同道合,是不是可以一起走得很远?这些都是可以通过味道明确的。 四、Review的八个步骤 “五年陈”劫十三写过一篇《教你如何让review更有效》,文章认为,对于业务管理者定期的业务述职或汇报(review),重点是检核的是leader本身的全局观、体系化思考模式和直面问题的决断力。 劫十三认为,管理者共有9个review步骤,可供借鉴。 (1)一张图——把团队带到什么高度。 身为leader,要有一张清晰描绘下月或季度、半年度甚至年度的战略脑图。要把你的团队带到什么高度,一定要想明白。比如作为城市经理,为了达到这个高度,具体每月的子目标是什么? (2)弄清现状——以便对症下药。 弄清楚现在是什么情况,客观的认清现状,是对症下药的前提。这里面的现状主要围绕业务现状和团队现状两个大维度展开。 (3)以终为始——制定阶段性小目标。 目标要遵循“订定盯”。订——是把leader想要和驱动团队共同想要的过程;定——是一个权责明确、把why讲透和给足方法的过程,仪式感和氛围很重要,戏份要足;盯——是落地,leader在这里要做好编剧和导演。 (4)定策略——有业务策略和团队策略 需要提醒的是,目标达成路径很多,策略没有最好,只有更优。没有完美的策略,只有完美的执行。 (5)聚焦策略——让策略有落地的抓手支撑 策略是大方向,解决的是定性问题,抓手是定量,解决用法用量程度的问题。 以提高人效为例,假设在不改变现有团队规模情况下,提高人效的策略是——抓拜访量、抓抓技能训练、抓陪访都是策略,策略是判断正确的事儿,抓手是正确的做事。 (6)认清潜在风险——凡事都有两面 仍以提高团队人效,抓有效拜访量为例。数量背后的质量如何,可能潜藏的业务风险有:单商户重复拜访频次高滥竽充数,虚假拜访等。 (7)应对风险——有解决方案 仍以提高团队人效为例,可以遇见的业务风险是: 风险一、一味追数量而降低质量 针对这个的风险抓手,日常主要有:检查拜访内容、复盘当日拜访细节、陪访、商户抽样回访等。 风险二、虚假拜访风险 除了销售管理制度,团队内部引入第三方,定期巡检或较差检核,也是一个不错的方法。 (8)准备清单——列出需要那些可行性支持 会哭的孩子有奶吃,需要有理有据的哭,才能得到有效的资源支持。 以上review八步法,是一个比较完整的review思路,让现状、问题、风险、思考与决断、策略与抓手、资源支持与目标推进等客观、完整、全面、清晰的呈现在团队面前。
相关推荐
以下是对"code review 怎么做"的详细说明: 1. **Code Review的目的**: - **发现错误**:Code Review可以帮助识别编程错误,如语法错误、逻辑错误、异常处理不当等。 - **提高代码质量**:通过审查,可以确保...
帮助别人review代码,团队管理利器
我一直认为CodeReview(代码审查)是软件开发中的... 然而对于我观察到的大部分软件开发团队来说,认真做CodeReview的很少,有的流于形式,有的可能根本就没有CodeReview的环节,代码质量只依赖于事后的测试。也有些
【标题】:“加餐三 | 聊一聊Google是如何做Code Review的1” 【描述】:“本内容探讨了Google的Code Review实践及其对技术成长的重要性,并分析了国内企业不重视Code Review的原因。” 【标签】:“设计模式” ...
2 方便开发团队进行Code review。 3 方便教师审查学生代码。 不能做的事(其实本意就是不允许做的): 1 下载文件。 2 查看二进制文件(或许下个版本可以^^)。 特点: 1 全配置文件方便扩展和修改。 ...
代码审查是软件开发过程中不可或缺的一环,它能够帮助团队发现潜在的缺陷、提高代码质量并促进团队成员之间的协作与学习。同行代码审查作为软件工程中的一个关键环节,对于提升软件产品的整体质量和可维护性具有重要...
【外研版一起小学英语五上《Review Module Unit 1》教案】 这是一份针对小学五年级上学期英语复习课程的教案,主要内容是复习全书的知识点,包括名词性物主代词、形容词性物主代词、一周天数和月份的表达,以及用...
Merge-Request是GitLab中一个核心的代码审查功能,允许开发人员在将代码变更合并到主分支前,提交一个合并请求(Merge Request),供其他团队成员审核。与之相对应,GitHub使用Pull Request来完成同样的过程。两种...
- **安全代码审查准备**:介绍进行安全代码审查前需要做的准备工作,包括对开发环境的理解、熟悉应用架构等。 - **SDLC中的安全代码审查**:解释如何将安全代码审查融入到软件开发生命周期(SDLC)的不同阶段。 - **...
为什么团队成员总是感觉做了很多事情,但却没有沉淀积累?为什么团队成员不知道大家都在忙什么?为什么团队没有清晰的目标? How 要解决这些问题,我们需要找到团队的北极星指标,也就是找到团队的目标和方向。...
Slack是一款流行的团队沟通工具,通过rbintegrations,可以将Review Board中的事件(如新审查请求、评论或状态更新)实时同步到Slack工作空间,使团队成员能在他们熟悉的环境中关注代码审查进度。 2. **Jenkins...
8. **Demo**:在每个迭代结束时,团队展示可工作的软件版本,获取反馈并为下一轮迭代做准备。 9. **测试阶段**:进行全面的测试,包括单元测试、集成测试和验收测试,确保产品质量。 10. **线上Bug修改流程**:...
4. **rbt update**:用于更新现有的代码审查请求,当你在本地对代码做了进一步修改后,可以使用此命令将新改动推送到Review Board。 5. **rbt status**:显示当前工作目录的代码审查状态,包括与Review Board服务器...
[其他类别]silverlight访问数据库汇总_review.zip源码ASP.NET网站源码打包下载[其他类别]silverlight访问数据库汇总_review.zip源码ASP.NET网站源码打包下载...3.适合小团队开发项目技术参考适合小团队开发项目技术参考
3. **避免不必要行为(F-3)**:确保代码没有执行任何不应该做的操作。这有助于防止意外行为或安全漏洞。 4. **代码简化(F-4)**:评估是否有更简洁的方式来实现相同的功能。简洁性不仅提高了可读性,也有助于减少...