如何在敏捷转型中克服阻力 – 邀请的力量

Bob Jiang
几乎所有的敏捷转型项目都遇到了来自经理(管理层)、员工或其他部门等的阻力。在这篇文章中,我们将解释为什么你会遇到阻力,以及如何消除或减少这些阻力。 为什么我们会遇到敏捷转型的阻力?这难道不是为了改善人们的工作环境,让他们更有效率吗?让我们假设敏捷是一个好主意。那么,我们将它引入组织的方式有什么问题呢? 一、推送产生阻力 “像往常一样转变”的关键挑战是,变革被推到人们身上,而他们没有参与决策。这样他们常常会拒绝变革。 二、推送对你有什么影响? 有很多方法可以产生阻力,这就是推的变化。当你读到下面的文字时,想想当某个当权者对你做出这样的行为时,你的感受: 告诉 销售 迫使f 说服 对大多数人来说,这些话会感到不舒服。 我们不喜欢别人告诉我们该做什么。我们不喜欢有人强迫我们做某些事。我们不喜欢别人试图向我们推销什么或说服我们相信他们的观点。当这些事情发生在我们身上时,我们会自然地抗拒。 三、敏捷转型反模式 结果是每个人的反应都和我们一样。我们推得越多,就会产生越强的阻力。下面是一些关键的反模式,可以帮助理解我们是如何通过创建阻力来推动失败的敏捷转型: 授权整个组织/部门变更。很多人认为这是一个巨大的成功:”欢呼,现在每个人都必须做敏捷”。但是,这场胜利是空洞的和短暂的,因为很快变成了一个普遍的”货物崇拜(19到20世纪中期在大洋州的许多土著社会中兴起的一种文化复兴运动)敏捷”案例,许多人在做这些事,但除了名字之外,什么都没有真正改变。 敏捷福音。在我们的领导力培训中,我仍然遇到很多人,他们认为自己是敏捷福音的传道者。积极的方面是想把事情做得更好。消极或破坏性的方面是推销和说服。这造成的阻力和伤害通常超过积极的。我所见过的每一个成功的变革都不仅仅是敏捷。 敏捷指标(敏捷警察)。另一种出于善意的方法,以衡量”敏捷”团队的程度,并为他们设定了”更敏捷”的目标,在实践中犯了严重的错误。这很清楚地告诉人们,做敏捷比敏捷本身更重要。如果你想在这里取得成功或者获得奖金,你就必须采用敏捷。这表明这个过程比人更重要——与敏捷正好相反。 四、敏捷是关于拉动的 深入到敏捷真正的核心——敏捷不是基于推送,而是基于拉动。与精益一样,Scrum团队会拉动下一个冲刺(Sprint)中完成的工作。看板团队在准备就绪时拉动。 五、推送无法创建拉取 我们如何用推送的方法来创造一个支持”拉动”的环境呢?这没有任何意义。有证据表明,使用推送是行不通的。当然,我们也许能创造出一些表面上看起来起作用的东西。然而,对于那些拉动工作所需的积极,敬业的人才,实际上,需要一些不同的东西来实现行动的深刻转变。 六、什么是拉动? 与推送列表类似,我们可以创建相反的拉动列表。 当您阅读以下单词时,请思考他们的感受: 邀请 倾听 激发 共同创造 对大多数人来说,这些话都是积极的。这就是我们想要在组织中创造的促进成功的效果。 我们喜欢有选择的自由。我们喜欢别人邀请我们,这对我们来说是可选的。所以我们可以自己决定。我们喜欢别人听我们说我们想要什么。当我们为某事受到鼓舞和兴奋时,感觉真的很好。我们喜欢参与那些影响我们的决策。你能想象当人们有这样的感觉时,你的改变计划有多有效吗? 七、拉动成功模式 看我们做错了什么要比看我们做对了什么容易得多。让我们看看使用拉动的一些关键成功模式。如果您不熟悉这些,或者对此持怀疑态度,我们将邀请您进行实验来尝试它们。 倾听。大多数人想要成功。大多数团队都想成功。一个巨大的挑战是,我们经常不会花时间去倾听他们想要什么和他们的想法。花点时间去倾听他们想要什么。满足他们想要的东西。在告诉他们你的想法或想要什么之前,先给他们列出清单,这样你会得到更多。 去有活力的地方。创造广泛成功的方法是取得小的成功,并在此基础上再接再厉。与那些现在真正需要帮助的人或团队合作,给他们想要的帮助(倾听),并帮助他们成功。过一段时间,其他人或团队可能准备好了,或者他们可能会看到正在发生的事情。 共同创建解决方案。敏捷是关于协作的,对吗?如果我们遵循敏捷方法,我们是否会与人们就转型本身进行合作,这是不是很明显?我喜欢共同创造这个术语,因为它让受变革影响的人参与到变革当中。这类似于精益变革和开放空间敏捷所倡导的方法。我所看到的工作的一个不同之处在于管理者和主管们也需要与员工一起参与这一过程。当然,这通常需要对管理人员进行培训,以便他们学会如何以帮助和不伤害的方式放弃权力。 八、推与拉 下面的图片有助于对比我们在敏捷转型计划中与员工和团队合作时的选择。 查看原文 将我们的思维模式转变为这种新的工作方式(敏捷)的一个关键挑战是,这让人感到不舒服。特别是,我们通常在”拉动”这个模式的技能水平很低。真的要花点时间看看你是如何不经意地用”推”的模式来制造阻力的。一旦我们明白了”推”这个模式真的不起作用,我们就有勇气成为一个使用”拉动”模式操作的新手。关于以一种友好的(拉动)的方式运作还有很多要说的,所以如果你认为这不是全部,你是正确的。 九、敏捷是关于人的 敏捷的核心是”个体和互动高于流程与工具”。敏捷的核心成功模式是,当我们更多地关注人而不是流程时,成功就会到来。大多数敏捷的转型都是本末倒置,把重点放在了流程上。通常的推送行为清楚地表明,大多数”敏捷转型”实际上根本与敏捷无关。 十、敏捷的第2次浪潮 我们需要对敏捷进行根本性的反思,以克服当今的挑战。我们称之为敏捷的第2次浪潮。这意味着把人放在首位,邀请变革。放弃破坏性的推送行为,这不是要让所有人这样做。这是关于我们的领导者自己开始模拟我们想要在其他人身上看到的行为。你准备好加入敏捷的第2次浪潮了吗? 十一、明天做什么 注意其他人使用推送行为的方式以及它对你的影响。 注意您使用推送行为的地点以及它如何产生阻力。 增加”敏捷/拉动”活动,看看人们如何反应。 译者:年志君 审校:Bob Jiang 英文原文

CSM Training 记录、收获与心得

Bob Jiang
转自学员Leon的总结 5.16 ~ 5.17 参加了捷行与 Bob 老师组织的 CSM 双 CST 讲师认证课程,收获远超出预期。 我是编程出身,11 年开始,一直从事互联网行业,17 年正式使用 Scrum 作为敏捷开发框架,也开始接触 Agile,过程中慢慢学习、摸索和运用 XP、TDD、BDD、DDD 等思想和方法,从 Coding 到 Team Leader(兼职 Scrum Master),到现在全职做 Scrum Master。 本以为自己”经验丰富”,对 Scrum 框架的理解”非常透彻”,想通过 CSM 认证后,向 A-CSM 进阶。然而两天的课程下来,还是给我带来不少收获。 两位老师都有各自的风格,Jim 老师有国际软件公司的经验,Bob 老师有一线互联网公司的经验,两位老师轮流教学,虽然部分内容会重合,但是在不同的场景与角度下,总能让人 ~ Aha / Wow / Ya。 记录 因为疫情的原因,我们两天的认证课是通过 Zoom 在线学习,我们小组在共创的过程中,还用到了石墨和 Teambition。 在线的好处就是打破了地域的边界,能和不同地方的学员一起交流,以北上广深居多,学员们来自各行各业,除了互联网行业,还有制造业、传媒业,金融业等,有开发、技术管理、项目管理、咨询师、数据分析师、产品经理(噢!为什么不参加 CSPO)等。虽然大家对 Scrum 的经验各有不同,但都有强烈的好奇心和学习的热情,哈哈。 在线的坏处就是互动不方便,有时候会受网络波动的影响,当然两位老师设计了不少互动的环节,通过 warm-up、在线画画、分组交流、小组课堂练习、课堂提问等,让大家保持互动与反馈,当网络抖动的时候,也会停顿休息下,保证课程的质量。 课堂中老师会通过画布,边讲边画,让课堂变得有趣,从而抓住大家的注意力,很赞。 两天的学习内容很多,节奏也很紧凑,从 Agile 的思想,到 Scrum 的 3355、PBI、DoD、Kanban 等等,经过这次体系化的学习,让我把所积累的知识再串联与梳理一遍,特别是 Day 2 下午的课堂练习,模拟了 3 个 Sprint,让我们每个人都 Inspect 自己的学习成果,十分受益。

Scrum培训感想

Bob Jiang
研究生期间,我在北京一家咨询公司做过三个月的实习生。当时负责的项目采用了敏捷方法进行项目管理,这让我对于敏捷有了一个粗略的认识。回到学校后,我总会在课堂中以及与项目小组成员讨论时,或多或少会听到敏捷以及Scrum的概念。所以我慢慢的认为敏捷项目管理一定是未来信息系统项目管理的发展方向,尤其是在这个科技日新月异不确定性极强的时代。 回到中国之后,我的第一个项目就是政府的智慧城市相关项目,这个项目真的完全让我震惊了,因为一个几百万的项目所聘用的团队连基本的项目管理都没有。在这样的团队中工作,个人的感觉就是被动、混乱与疲惫。所以我想学习最新的项目管理方法,来改进我们团队的工作方式同时也提高自己的工作效率。于是在朋友的推荐下,我就来参加 Bob Jiang 和 Jim Wang的Scrum Master 的培训。两天的培训让我顺利的拿到了CSM认证,在我看来,这次培训是非常不错的。 首先,Bob和Jim老师都是具备丰富的项目经验以及教学经验,在课堂上老师们会主动的分享自己的案例与实践,让同学们更好的掌握Scrum。同时,他们注重理论与实践的结合,在每个知识点讲解之后都会安排小组练习,确保同学们都能充分的了解知识点。 除此之外,课堂练习的设计也是非常精妙。课堂中让我印象最深刻的就是小组成员们一起制作视频的课堂练习。这对于每一个小组都是一个艰难的任务,尤其是每个Sprint只有10分钟的情况下。在这样极端的情况下,我们全部小组成员立刻就拿出自己的十二分精神,快速的进行Scrum中的各个环节:计划、执行、评审、总结、再计划。在一次次不断地迭代中,最终我们终于完成了在B站上传视频的任务,我也有幸成为了一名Up主,这真是人生中不可多得的一段经历。 两天的课程过得非常快,培训结束之后,我对Scrum有了更深刻更完善的理解。这种理解不仅仅是理论层面,更多的是实践层面。但是如果你要问我,这个培训之后,你的痛点有马上解决吗?这个我不能马上给出反馈,但是可以肯定的是,我已将敏捷的思想牢记于心,在日常的工作中会用敏捷的方法来约束自己,小步快跑,快速实现团队和自身能力的提升。 来自学员 Huan CSM信息大全 想要约 CSM 课程,扫码 –

如何讲好故事

Bob Jiang
我最近在申请EHF - 新西兰的创业移民项目,在写申请材料的过程当中,我深刻意识到了讲故事的重要性! 下面跟大家分享一下我的例子。这里特别感谢我的好朋友丹尼尔(Daniel Bar)。以下的第2个版本就是我的好朋友丹尼尔帮我做的例子,受到这个讲故事手法的启发,我才写了这篇博客,也希望把好东西分享给有需要的人。 原来的故事 2019年我去尼泊尔和孟加拉交付了两次培训课程,还分别在这两个国家进行了两次敏捷演讲的分享,通过这个事情我连接了东南亚的当地敏捷社区。 怎么样读了上面的文字,你有什么感受呢? 改进版本的故事 中国是一个快速发展的国家,在中国敏捷已经慢慢得到普及。但与此同时我意识到东南亚的很多国家,也急需要敏捷来帮助他们改变工作与生活的平衡,改变他们的行业,改变他们的公司。我相信敏捷一定可以帮助他们得到更好的生活,也一定可以帮助他们改善现有的工作状况。所以2019年我受到尼泊尔和孟加拉敏捷社区的邀请去交付了两次演讲的分享,同时也做了两次培训课程,为当地人民带去了目前全球最新的思想和知识。 这个版本呢,读完之后有什么感受? 很明显,第2个版本更像是一个故事,从讲我自己的价值观,再到讲我的心路历程。这样更容易打动读者的心,更容易让人相信你说的话。而第1个版本只是描述了一个事实,可能有人就会问那又怎么样?与我何干? 所以讲故事的核心:要和自己的价值观连接到一起 总结与反思 - 黄金圆环 大家还记得西蒙西涅克的黄金圆环吗? 讲故事也遵循同样的黄金圆环原则。 如上图所示,黑色箭头是第一个版本的故事,主要讲了事实(what)。 如果只是讲事实,这就是属于什么(what)的层面。只是告诉了别人一个事实又怎么样呢。 多数人讲故事是这个套路,难以打动人。 而如果我们从为什么(why)开始讲(如上图红色箭头)。则会完全不一样。比如为什么会去做这个事情,我的动机是什么?然后再讲怎么做的,得到了什么结果,这样的故事会更加的强大,更加的具有感染力。(这里面也离不开what,具体的数字和结果) 所以下次你再讲故事的时候,要不要也试一试呢,先讲出你的动机,你的价值观,为什么会去做这件事情。 把这些交代清楚之后再来描述你要讲的故事,看看会有什么样的效果。

Scrum未完待续

Bob Jiang
把每件事都当作一个项目来推进,是我之前参加的一个线上课程的结束语,这句话在软件行业体现的尤为突出。过去我们关心的是如果快速的交付需求,很少考虑如何快速应对不断变化的需求。 还记得一开始学习软件工程的时候还只有瀑布模型、需求分析、系统设计等这些传统软件工程内容,但是经过十几年的发展,在软件项目中,敏捷开发、持续集成、微服务等这些新兴内容已经开始在软件项目中占据越来越重要的位置。从19年开始我通过网上的资料知道了敏捷知道了Scrum,也开始逐步的在现有项目中引入一些敏捷的实践,一开始我们只是通过几种项目管理工具帮助团队同步项目的进度,一段时间以后项目管理工具就变成了日报填写工具,大家每天都在上面填写这一天的工作和明天的工作计划,再后来项目没有看到敏捷带来的好处,敏捷推广也就无疾而终了。现在看来我们当时只是拿着别人用过的一部分实践复制到了我们的项目中,距离真正的敏捷还差得远。 2020年年初通过朋友介绍参加了敏捷家的几次线上分享,通过嘉宾的分享逐渐的对敏捷和Scrum有了更多的了解,也逐渐有了想要更加深入学习Scrum的想法,之后就顺利成章的报名参加了Bob的CSM课程。 从5月16到5月17两天的课程,BoB从敏捷的概念,Scrum的概念、原理、价值观再到我们常说的“3355”一步步的进行了讲解。每个概念讲解结束后都会安排小组进行讨论分享,在无形中我们每个小组通过讨论进行了多轮交付,每次交付其实都是对于Scrum不同方面的实践。相比与枯燥的照本宣科,这样的教学模式印象更加深刻,也在一定程度上解决了远程教学注意力分散的弊端。在第二天的课程中Bob介绍了在其他公司的Scrum实践,帮助我们在课程结束之后尽快的将所学引入到公司项目中。整个学习过程紧张而有节奏,回顾整个课程学习我感触最深的有以下几点: 一是对于DoD的定义,以及DoD和AC之间的区别。这些是之前项目迭代过程中一直忽略的地方,没有定义好DoD就没办法进行高质量的交付。 二是课程中介绍的什么项目适合开展Scrum,Scrum不是适合于所有项目,要有选择的机型Scrum推广。 三是如何对User Story进行切分,每个Story多长时间最为合适。 课程的结束只是代表着对于Scrum的初步了解,距离真正的CSM还有很长的路要走,只有在项目中实际应用Scrum才能更加熟悉每个流程环节的作用和价值。Scrum未完待续。 来自学员 Qihui CSM信息大全 想要约 CSM 课程,扫码 –

再次强调完成的定义(DoD)

Bob Jiang
之前我写过一篇文章,关于敏捷坑人系列不清晰的完成,在这篇文章当中,描述了完整的定义和验收标准之间的区别,但是最近的课程当中依然有不少小伙伴在提问关于完成的定义,那今天的来说一下,为什么我们要设定完成的定义(即其重要性) 完成?! 在工作当中往往我们会说这个事情我完成了。当我们说完成的时候,每个人对于这个完成是有不同的定义。比如PO认为完成是需要包含完成编码,提交到代码库,完成单元测试,完成集成测试,完成功能测试,等等一系列的测试。 而开发小伙伴可能认为完成只包含代码,以及在自己的电脑上测试,没有问题就算是完成了。 那这两个完成之间是有很大的一个差距,而这个往往会造成大家对于完成的理解误区,及同时也会造成沟通上的冲突。 完成的定义 Definition of Done 在这个背景下,团队需要对于完成有一个统一的认识。这个完成会包含很多不同的层面及不同的步骤。 举例说,如果说一个产品功能完成了会包含什么?如果开发完成了会包括什么,如果测试完成会包括什么,这是不同的层面。但是在Scrum指南中完成默认是指的产品完成。 完成的定义就像是一道门槛 团队一起设好了门槛,能跳过去的功能(PBI)就是完成了,跳不过去的,就是没完成。没有完成一半或者完成90%这样的概念。 所以对于这道门槛我们要设多高,这个是看团队对于自己的要求是多少,以及团队对质量的要求是多少,这是非常重要的一一个概念 验收标准 Acceptance Criteria (AC) 验收标准更像是PBI(功能)自身的一部分,或者用户故事的一部分。验收标准和用户故事是完整的整体,且不可拆分的。 也就是我们在梳理用户故事的时候,要同时梳理出这个用户故事的验收标准。 举个例子,比如登录功能,如何这个登录功能才算是完成呢?最简单的用户名密码正确就登录成功,用户名密码错误返回错误原因。这是最简单的两个验收标准。这两个验收标准就是用户故事的一部分。 总结 完成的定义和验收标准相同点 需要团队和产品负责人共同协商确定 代表质量,不过是不同的范围 不断迭代和不断演进 完成的定义和验收标准不同点 完成的定义是关卡,对所有的PBI(功能)适用;而验收标准是PBI(功能)的一部分,仅对当前一个PBI适用 完成的定义是内部质量;而验收标准是外部质量 完成的定义一般在团队组建时建立;而验收标准在梳理PBI时提出 完成的定义一般以季度为单位进行扩展;而验收标准则在产品待办列表梳理会上进行澄清与更新 完成的定义一般作为团队工作协议的一部分;而验收标准则可以转换为测试用例(或拆分为新的产品待办列表条目) 关于用户故事和产品待办列表,在我之前的博客当中也已经有详细描述,大家可以参考。

在敏捷实践中加速成长 | 敏捷家分享009

Bob Jiang
内容来源:敏捷+社区线上直播009期,《在敏捷实践中加速成长》分享实录 分享者:平安壹钱包杨大鹏 关注本公众号回复”平安”即可获取本次分享的视频回放、下载PPT 平安集团是国内少有的,具备成体系的敏捷教练队伍的企业,从上到下拥有很好的敏捷土壤。再介绍一下我自己,我有十几年的工作经验,最初几年是做程序员,后来转向了项目管理和技术团队的管理,长期服务于外资银行和金融互联网的企业,我曾经在日本生活过很多年,非常熟悉传统的软件研发流程,也算是比较成功的 it项目管理者。我可以非常准确的挖掘客户需求,管控项目成本,管理团队,把成果物非常高品质的交付给客户。 但是后来我发现了一个问题,我不知道我交付的成果物能否为客户带来价值,项目结束结项以后,团队可能就会解散重组,我也没有办法持续地去帮助团队的成长。针对这两点我曾经非常的苦恼,后来就开始逐步学习敏捷的理论,毫不回头的走向了敏捷实践。 今天我和大家分享两部分内容,第一部分是在敏捷实践里,个人应该树立怎样的目标。第二部分我会用我自己的一个比较接地气的案例,来分享针对团队级别的敏捷实践,我怎样去具体解决一些常见的难点问题。用这个案例来分享我的思路和认知,希望能给大家带来一些参考。也希望能够帮大家少走一些弯路。 第一部分,我们现在是身处复杂的互联网时代,非常复杂,也被称为乌卡时代,典型的案例小黄车ofo,几年的时间里跌宕起伏,让人叹为观止。 查看原文获取更多材料和音频

引导式互动交流,快速沉浸学习|参加Bob线上CSM课程总结

Bob Jiang
4月11-12日参加了BoB Jiang 老师两天的CSM(Certified Scrum Master)敏捷教练培训课程,非常感谢BoB老师带来的精彩课程,收获满满! 敏捷开发是最近几年在软件和互联网产品开发领域日渐普及的开发模式,在之前的工作中,或多或少都应用到了一些具体的实践,比如每日站会、冲刺(迭代)等,或多或少在项目管理中都会有所收益。通过参加BoB老师的两天培训课,更加系统梳理和理解了敏捷框架Scrum的核心内容。 BoB老师语言幽默,两天的课程内容知识量非常大,且包含大量引导式互动交流实践环节,很容易在小组的互动实践中进入角色,深入理解并应用相关的知识技能,每个实践环节的总结部分,都是画龙点睛,对所学内容进行阶段性复盘,在最后一天的培训中通过大量实际企业中的敏捷实施案例,通过提问集中解答方式,一一解答大家在实际实践中的疑惑,提供大量宝贵参考案例。 虽然由于疫情影响,两天的线下课程改为了线上课程,但是内容丝毫没有打折扣,反而在互动交流环境以及小组讨论环节有更好的体验,Scrum 框架的核心:3355(三个角色、三个工件、五个活动、五个价值观)通过BoB老师精心设计的小视频、手写板、小组互动、小型敏捷项目实践、实际实施过程中典型问题的分析讲解等,演绎得生动形象,无论是第一次接触敏捷概念的小伙伴,还是职场经验丰富的老鸟都可谓是能够轻松吸收。 从第一天的培训课程开始,BoB老师就没有照本宣科机械介绍PPT的培训讲义,而是从敏捷的兴起创始人小故事讲起,逐步代入到敏捷宣言的提出以及敏捷宣言遵循的原则,并通过幽默诙谐的方式对其中的核心内容进行讲解。当讲到用户故事的时候,为了让大家理解什么是用户故事,以及怎样来写用户故事,通过随机分配六人小组,合作完成一个”敏捷介绍”视频制作的小实践时,同学们通过快速分配角色,共同出谋划策,在7分钟的时间内,写出10-15条用户故事,然后BoB通过对每组每条用户故事的详细点评,指出不足,再来一轮脑暴完成修订版的用户故事输出,整个过程同学们参与度极高,对用户故事怎么写有了充分的理解并获得了实际经验,相信能很快在实际工作中做得更好! 最开心的是,这个小敏捷实践过程在短短的不到1个小时的边讲解边实战过程中,所有小组的成员都完成了”交付”,很多小组都交出了非常漂亮的最终产品,获得Bob老师以及小组间的相互认可! 核心的Scrum框架内容在轻松愉快的氛围中结束后,第二天的课程更加精彩,BoB老师精心准备了大量实战案例,比如BoB老师作为敏捷教练,在自己曾经服务过的企业京东的电商敏捷交付团队,通过对实际案例中的具体实施细节以及遇到的问题的深入剖析,以及具体实施细节,比如产品代办列表(Product Backlog)、冲刺代办列表(Sprint Backlog)、产品增量(Increment)等的实际例子,详细讲解实战中过程中遇到的坑和如何填坑的过程,非常精彩! 而培训的过程远不止Scrum框架的内容,BoB还通过一些手绘以及小视频方式为大家带来了规模化敏捷的演变过程,通过对spotify大规模敏捷之路的讲解,让我们深入理解了对于较大团队的敏捷如何实施。 在最后半天的培训课程中老师还给我们带来了”彩蛋”:敏捷项目经理的职业规划。这个内容对于很多职场人,尤其是正在做项目经理,或者希望转型做项目经理的人来说,无疑是非常有指导意义的。BoB老师很谦虚的通过自己的职业转型之路,为同学们用实际案例介绍了学完CSM以后,所能带来的个人成长,以及将来可以规划的职业路线,通过对”百万收入的自由职业者”的理解和分析,定了一个格调:先要成为职业者(专业领域佼佼者),再谈”自由”的合理性,受教良多! 由于培训课程时间较短,内容多,老师并没有过多展开这方面的讲解,毕竟不是CSM培训的内容,但是课后我本人又跟老师约了时间,通话将近一个小时,说了自己的情况以及今后的想法,老师都跟朋友聊天一样,帮我分析了我的优劣势,以及今后努力的方向,并给我介绍了进阶课程进修的专家级讲师,在此内心非常感激! 最后做个简单的总结,两天课程的培训,我第一时间考取了CSM的证书,如果满分100分,我给BoB老师的课程打110分!多出来的10分,就是对老师超出培训内容所给出的职业规划建议以及给我本人的非常详细的建议,再次感谢Bob老师:谢谢老师,您辛苦了~ 来自学员 Tony Yue CSM信息大全 想要约 CSM 课程,扫码 –