讲师专访 | 敏捷诠释了什么叫真正的客户满意度

王琨老师个人简介：

1、清晖资深讲师。

2、创业者。

3、PMI认证的项目管理专业人士（PMP）。

4、信息化高级项目管理师认证。

5、敏捷管理专业人士认证（ACP）。

6、产品经理认证（NPDP）。

7、咨询师、项目管理培训顾问。

01.邂逅敏捷

Q：王琨老师您好，非常感谢您百忙之中抽出时间来参加我们《敏捷人CLUB》的专访，相信大家都知道王琨老师当前已经是比较资深的敏捷项目管理的老师了，教学经历和敏捷实战经历都非常的丰富，今天一定要多聊聊，让我们多学点东西。

王琨老师：大家好，我是王琨，很高兴接受这次《敏捷人CLUB》的专访，资深不敢当，也只是自己的一点点理解，今天我也会根据经验分享一下我对于敏捷管理的理解，希望能对大家的学习和工作有帮助。

Q：王老师能和我们分享一下您的从业经历，以及怎么开始接触到敏捷的吗？

王琨老师：我以时间的顺序来讲下，在07年时候做过一个对日的开发项目，现在回想起来，才知道客户是一直带着我们做敏捷的（部分敏捷）；当时用的就是迭代的思路，但是PO在日本，每天是通过skype开电话会议（其实就是每日站会的内容形式，每个人回答三个问题，只不过是坐着开的。）

2014年正式接触了敏捷项目（互联网购物APP）；从需求到运营，每天都是面对面的办公，其实是完全按照Scrum的流程走的，但是还是没有完全敏捷化；因为企业文化的原因吧，中层特别热衷敏捷，但是没有高层的支持，高层领导听不懂大家的思路，后来大家都散了。

2016年我接手了一个政府平安城市的项目，因为需求变化大，那时候我确实也已经听了很多敏捷案例，看了许多敏捷的书，所以再一次尝试Scrum，我是SM，招了个懂业务的PO，开发团队4人，测试1人，然后就驻场搞起来了，还是比较成功的一次项目经历，一周一次迭代，因为客户比我还着急，所以每周都能给客户看到东西，客户对于结果的反馈也跟满意。其实这里也体现了敏捷的精髓：敏捷诠释了什么叫真正满意度。

02.敏捷的深入解析

Q：在现实环境中很多企业会出现一种现象，就是刚开始用敏捷没有成功，然后就直接放弃再也没有启用。针对于这种现象，您觉得企业为什么要用敏捷？它和传统的模式的区别是什么？

王琨老师：Agile直译成中文就是“敏捷”，它的理念和我们汉字表达的意思一样的，比如我们形容一个人：这个人身手敏捷，其实就是快的意思。项目中的敏捷的理念也是：迅速响应需求，快速反馈结果。

相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。

至于企业为什么用敏捷？首先不是所有的企业都必须要用敏捷，不同的公司要有不同的用法，瀑布到现在也还是有市场的，比如去年我去深圳看到的核电项目，这个完全没有用敏捷的必要。但是目前市场，产品的生命周期是变短的，这个大家都有感触，你看看去年主打的电子产品，今年已经过时了；所以尤其那些创新型的已抢占市场先机和快速满足用户需求的公司，敏捷无疑是最好的选择。

Q：您在刚开始实施敏捷，有遇到什么困难吗？当时是怎么解决的？

王琨老师：第一个是领导的支持：就像我刚才提到的14年做的项目为什么最后团队都解散了，就是来自韩国的几个高层不支持；甚至于买个白板都很困难，领导说会议室有，买什么白板？很明显是不愿意在上面投入资源的。

16年的项目情况就完全不同，那个时候我自己在企业里有话语权，且正在搭建项目部，所以几乎所有的现在看来比较正确的文化都是那个时候形成的，比如服务式领导；敏捷的专注其实对团队来说就是不要太分心，包括不要同时做过多项目，甚至不要有其他生活上的干扰，这在很多公司都做不到；当时我们是要求HR关心员工的生活的，比如和女朋友闹别扭，公司都会有人帮你去哄的；所以创业期前三年骨干都是没有离职的，虽然当时给的待遇只是业界的平均水平。

Q：其实这个目前很多企业是达不到的，但是我也想做敏捷，该怎么办呢？

王琨老师：其实是这样的，敏捷刚开始的时候，我们所有都是小团队去做的，规模化的敏捷是在后面的，我们现在讲的敏捷导入，一开始都导入的是小团队，就是敏捷里面的7加减两个人也就5到9个人这样的，就是一个人做好这些人的后勤服务是完全可以的，这个Scrum Master来做也可以。

有些不太大的企业，你的HR可以帮你去做这个事情，如果你企业很大，HR分担不了这些事情，就是Scrum Master做，我们可以帮你做司机，可以帮员工去买下午茶，可以帮员工做更多的事情，比如说你生活上有困难等等，都可以。甚至就比如说有员工现在有困难大家合伙起来帮帮他，这是一个凝聚力的一个体系。

Q：这样的话我们在团队组织之前就要和管理层商量好，我们就是需要很大的灵活性。

王琨老师：对，所以对Scrum Master的要求也很高，第一他情商要高，他要懂这个公司里面所有的流程，以及上面几个领导的脾气秉性，他能把这个东西玩转了的，如果是个很死板的人，就算他知道规则是什么，他也做不好，所以说Scrum Master他是即能玩转于规则之上又能所有人都不得罪的一个选手。

Q：了解了，那我们继续上面的问题，实施中您遇到的困难。

王琨老师：实施中的困难，第二个是自组织团队：我理解自组织团队和企业文化有很大关系，很多企业导入敏捷的时候，就是没有自组织团队，所以会导致实行敏捷困难重重；其实大家都不知道什么叫自组织团队，自组织不是说毫无章法，随心所欲的去做任何事，没有任何约束和不顾及任何后果的团队；自组织有个前提就是：必须认同公司文化，认可公司战略目标；这点做到了就会有主人翁精神，就能从被管理转到自管理阶段；如果能制定团队规则和团队目标，那么就又到自设计团队；如果能通过团队协作去达成目标，这才是自组织团队。

所以我们尝试了多种方法，后来摸索出一条：面试的时候更加看重态度和激情、自己设计绩效考核项、自己评价、自己领任务、甚至对个别人可以自己要奖金和工资，只要你能保证你自己要的钱能达成我们共同商量的结果；当然这里面有很多细节要注意，比如绩效考核，如果不是团队自己设计的绩效考核，那么协作也做不成，每个人都会自扫门前雪。所以总结下来是：管理需要给自组织创造合适的土壤，提供合适的条件和支持，这样自组织的团队才会成为可能。

Q：其实这个对于企业来说也是很难的，比如说像您刚才说的，自己的绩效自己来定，它就会出现一种现象，随着时间的推移，对自己绩效原有设定的满意度，比如说，我工作一段时间后发现大家定的都比我的宽松，这样是不是就会导致大家的意见不同？这种后续是怎么沟通的？

王琨老师：其实没有人定的绩效就是非常非常满意的，不是说定的绩效自己就一定能完成，所有人的绩效都是有压力有挑战的，就是有一点压力，伸伸手能够得着的感觉，其实管理层要做的事情就是你定了这个内容，我要衡量一下我公司的支撑能力范围内能达到百分之多少，就是我们所有人包括公司每年做的商业计划也不可能100%达到的，我们能达到80%今年就是成功的，员工也是这样的，就是你如果定得低了，那我肯定往上加一下；你定的高了我可能往下压一下。

就是领导者和这个员工他们俩共同来制定的，具体步骤一般是员工先自己制定，然后和领导沟通，沟通完了之后，在这些点上商量清楚就可以，也不可能说放任所有的人都自己制定，这个是不现实的。

人员的管理方面，对于企业来说，所有员工都应该管一下的，只是说程度不同，有的程度更重，有的程度更低，比如说你这个人是个非常有干劲有激情的，那你定了一个很高的目标，那么这个时候我也要管一管，这个内容没有必要这么压抑的，因为你做不到反而对你自己增加了负担，这个压力不影响我们正常的流程和进度，还不如降一降。

Q：这个是部门共同制定还是个人和领导单个制定？

王琨老师：部门讲原则和目标，绩效个人自己去制定，然后领导和个人沟通。什么是领导？管理学是讲管理半径的，你不可能一个人领导20个人，如果你领导20个人，那么你下面培养出3个leader来，你就管这3个人就行，这3个人每个人领导7到8个人。每个人管理7到8个人，他能沟通的过来。

Q：自组织团队是大家一起讨论的目标是吗？这个点团结一致会难吗？

王琨老师：企业目标是从企业战略上下来的，比如公司的目标是什么，然后分到分公司目标是什么，在然后分到部门目标是什么，会一层一层往下分。那什么叫战略目标？战略目标就是公司宏观，它这个要往下分，总量是没问题的，但是总量下来之后，你自己定的目标是不是对标是我们需要考虑的，所以我们讲绩效考核和绩效管理的时候，有一个上下对标的一个说法。

Q：刚才有说到在企业中是怎么应用敏捷的，那么在整个的敏捷项目管理应用的流程中，您认为最重要的部分是什么？

王琨老师：我先给举个场景例子：在软件开发项目中，开发需要等设计，测试需要等开发，前端需要等后端，所以在迭代的头几天里，设计和后端忙的不可开交，前端和测试无所事事；而迭代的最后几天，测试加班加点，设计无聊得发慌；所以大家常常抱怨工作不均衡。这个就是没有理解敏捷价值观的第一个：个体互动高于流程和工具，翻译过来就是“以人为本，重视个体间的合作互动”。

其实，这只是因为大家还没有完全摆脱瀑布式的阶段开发流程。在敏捷开发中，设计必须以开发人员提出的解决方案为基础，同时测试人员也必须明白客户的原始需求（而不是根据设计“推测”）；API等接口定义应该是由前后端共同商议决定，而且在接口确定下来（必要的时候甚至可以由测试人员提供一份模拟数据）之后，前后端可以尝试并行开发；测试人员写完测试用例也应该分享给所有人，一则帮助开发人员思考用户用例，也可以向设计师确认需求。这才是真协作！

就是大家要更多的跑起来，更多的互动起来，沟通起来，让工作并行。这是很多公司比较难的点，他其实用的是一个假敏捷的理念，就我们今天开了一个每日站会，用了个敏捷的流程，就认为是敏捷了，但是他们实质上并没有遵循敏捷的那几个价值观，大家用的还是传统的小瀑布的模式，所以我觉得最重要的还是一个观念的改变。

Q：在现实的开发环境中会出现这种情况，就是我们团队一起已经把需求和下一步工作计划都做好了，但是实际工作的时候还是会有，在某个时间段中主要的就是设计的工作，那不是我们还是需要等着吗？是怎么解决这种情况的呢？或者说我们是否是可以多个项目并行的？

王琨老师：多个项目并行？其实是不建议的，是这样，你说的这种情况是存在的，我们会建议我们大家能帮设计一起推进，如果说我们确实帮不了忙，但是团队之前不是已经开过项目会议了吗？需求和项目的内容大家都了然于胸了，我不看到设计图，其实我心里也有一个大概的内容在，所以对于开发人员来说，字段，数据库，接口，都已经可以同步进行了。

Q：大多数情况下，设计出来的产品客户看过后，不会变很多是吗？

王琨老师：是的，即使后面客户说不满足需求，一般也不会差的很多，所以开发并行做的内容，是不浪费的。另外一方面如果多个项目并行做的话，也会导致设计认为这个东西不着急，反正你们也在做其他的项目。

甚至说边设计边开发的时候，测试这边case已经写完了，我们现在不是有讲TDD嘛，就是说测试已经跑到开发前面了，前面会告诉开发你要做的代码我是会这样测的，开发看到你写测试代码反而更清晰我要怎么写了。

Q：奥，理解了，不过还是会存在这种现象，很多测试他是做不到这点的，甚至他们的测试工具就是开发提供的，比如说，我写好代码后，我自己会写一个小程序就是用来自己测试自己的代码功能，我结束后交给测试时，我甚至需要把我自己写的测试工具，提供给他。

王琨老师：你这是小瀑布啊，就是开发先做→开发自测→提供给测试测。其实，在传统里面测试部门分好几种，上来就自己先点的简单的测；也包括自动化测；做完之后集成测；有问题回去改，改完后的回归测，就是很多种测试。

我举一个简单的例子，测试驱动开发，就是测试先写测试代码，测试代码学完后是跑不起来的，那么开发在测试代码里加正式的代码，写好后能跑通，能跑通就证明你写的是对的，你这块代码没问题，没跑通可能代码写的就有问题，这叫测试驱动开发。

Q：所以，敏捷对测试人员的要求还是很高的。

王琨老师：会有好几种测试，比如白盒测试黑盒测试，白盒测试的待遇要大于开发的，当然还有比如功能性测试性能测试，只需要点一下按钮或者页面的，这种测试待遇就会低很多。包括自动化测试，就是你写完之后，我是不手工测试的，我直接就自动化跑起来了，所以其实人工就释放出来了，就持续集成，当然这是另外一个话题。

所以，测试和开发是一样的，你做你的开发，我搭我的测试环境，我做我的自动化测试环境，我搭我的测试case，你这个开发做完之后马上就跑起来，马上结果就能反馈给你。

而且在往高一点讲，自组织里面都讲通才，通才的意思是一个搭T形的，你的专长是测试或者开发，你上一步的内容你也要懂得，就像测试工作做完了，开发工作做不完，测试可以直接上就去做开发的内容的，这才是自组织团队，开发可以做测试的活，测试也可以做开发的活，测试开发都可以梳理需求设计需求。相当于每一个人有一个专精，然后其他方面也要懂，这才是协作。

Q：其实是整个团队成员的要求都是很高的。

王琨老师：所以为什么很多企业实行敏捷实行不下去，它会是实施当中最难的。

Q：在实施项目的过程中您认为企业最普遍遇到的问题是什么？对于这个问题有什么解决或者预防的建议？

王琨老师：第一个是开会！程序员最烦的就是开会，而敏捷开发的会议实在太多了，每日的站立会议、每个迭代开始前的需求讨论会议、迭代开始时的计划会议、迭代结束时的验收会议、之后还有回顾会议，以及各种数不清的小范围会议。

比如一个迭代为期两周，10个工作日，80个小时，这些会议就要占到20个小时以上，程序员哪还有时间写代码。更加讨厌的是，代码写到一半被叫去开会，一下午都没有效率可言了。大家有这样的感受，说到底还是没有从思想上转变过来。敏捷思想是一种深刻的文化变革，真正的敏捷需要团队成员以及客户之间及时的沟通与紧密协作。一味低着头写代码，回头才发现做出来的功能不是客户想要的；又或者写了半天前端代码，才发现后台的API已经变了，原来的参数都不能用了；又或者调查了半天的bug，第二天才知道整个功能都被删除了；你不禁在心里怒吼：“为什么不早点告诉我？”而敏捷就是要通过及时频繁的沟通，快速地对变化做出反应，将损失和风险降到最低。

Q：会议会有固定时间吗？

王琨老师：大部分的会议是有固定时间的，但是在现场办公，客户随时就过来了，客户随时会打断你，这种现象Scrum Master有两种协作，第一个有紧急的bug过来之后，我们也有紧急应对，这个可以打断；第二个有些客户就是大事小事随时就打断你，关于这种情况，Scrum Master就要做些事情，我们有一个词叫教育客户，敏捷里面是敢教育客户的，就是我们讲自动化或者说机器人的时候，我们就训练机器人，就把机器人训练成人的思维模式。你想让一个客户慢慢适应过来，跟着我们的团队走，要教育他，就是说要告诉他，有些不紧急的事情，你打断他，会影响他今天的产出，你先告诉我就行，我来帮你汇总，紧急事情打断开发我们是接受的。

Q：这个事情的把控主要是Scrum Master来做？

王琨老师：Scrum Master，所以Master是个人精，他比之前的项目经理更精，以前的项目经理要懂得各种管理，Master是要玩转人的，第一他要非常懂得敏捷的理念，第二他要懂得客户和我们团队内部的这种关系，人的性格是什么，但是PO可以不管。

Q：那PO的主要任务呢？

王琨老师：需求，就是这个项目要做什么？龙舟赛船见过吗？团队就是划桨，前面有一个敲鼓的，有一个掌舵的，掌舵的就是PO，他要把这个舟带到哪儿去，他的方向在哪里，敲鼓是激励人的那就是Scrum Master。

Q：那企业里面会把两个职位让一个人担当吗？

王琨老师：能遇到，但是它是一个致命的错误，就像开发和测试是同一个人，你想想你自己开发，自己测试，你能测试出来什么？

从内心讲Scrum Master是团队内部的一部分，PO可能是一个客户的代表，可能市场部派一个人，那么从另外一个层面，Scrum Master可以把你当客户对待，我和我的团队要打造你的要求，因为到最后的评审会议，大部分是PO代表客户去验收的。

Q：OK，理解了，我们继续企业普遍遇到的问题还有什么？

王琨老师：常见的问题第二是，每日的站立重点不是汇报工作，而是沟通感情：敏捷开发最简单也最容易实施的莫过于每日的站立会议，但是人们往往把这个会议当成了工作汇报会议，这其实是一个严重的误区。

一般，每日的站立会议包含三个问题：

√  昨天的工作内容；

√  今天的工作计划；

√  遇到的困难。

实践过程中常见的形式：

√  昨天的工作成果汇报（昨天我忙了一整天）；

√  今天的工作计划（今天我也很忙）；

√  没有困难（我只负责写代码）；或困难很多（抱怨……）。

然而，这个会议真正的目的是促进团队之间的沟通：

√  昨天的工作内容：这个API我做完了（前端可以用了）；这个功能我做完了（测试可以开始了）；这个问题解决了（谢谢各位的帮助）；等等。

√  今天的工作计划：今天我要做这个画面（如果API有问题我可能会找后端开发）；今天我要做这个API（前端很快就能拿到了）；今天我要做这个测试（有问题可能会给你们bug票）；今天我要和客户开会（可能需求或计划会有变化）；等等。

√  困难：我的这个画面在等API（后端你可能需要调整工作优先顺序或加快速度）；我的设计在等客户反馈（你们可以先看看设计，但可能还会有变化）；我今天会联系客户（帮你问问那个问题）；等等。

这个短暂的会议应该更像一个小广播，每个人都可以接收到与自己的工作相关的最新消息。同时在你遇到困难时，也可以通 过这个小广播引起所有人的注意。

第三个是形式主义假敏捷害人：很多公司举行每日的站立会议，以两周的Sprint为迭代周期，再加上Jira等管理工具，就堂而皇之地说已成功转型成了敏捷开发。然而仔细一看却发现：在分任务的时候，有的用户故事（user story）只有一个故事点（story point），而有的却有十几个（两周的时间只有十个工作日！）；在定义需求的时候，一个页面上有几十个字段，也不管这些字段的重要性以及将来会不会使用，就与客户挨个进行讨论，就是没有排优先级。这种形式主义根本无法贯彻敏捷的基本思想，结果只会适得其反，团队成员在两种模式的夹缝中束手束脚。

Q：就是会有一个主要的需求是吗？

王琨老师：对，所以PO要做一个事情，来了很多需求，我需要确认这个客户看中的是什么价值，最简单的就是性价比，这个需求投入的工作量少，但是客户觉得这个东西重要，那我就往前提；还有风险相关的，这个风险太大，那就把它往后排，比如说这个需求和一个先进的技术有关系，这个客户又不太看重，就可以往后排。

所以一个迭代做哪些东西是从需求的优先级从最上面往下来取的，首先你要对所有的需求点做一个估算，每一个需求有多少个点，如果我这个迭代是两周的话，我能做几个点，综合情况排优先级，然后从上面取一个需求，然后团队来认领，认领之后去做这个迭代。

但是现实往往不会那么顺利，可能的情况是这个迭代时间不够没做完，也有可能是领的少了都做完了后面闲着，那这个时候在回顾会里面就会体现，就要讨论出现这个问题的原因，下次就要改掉。

Q：其实团队会越做越顺。

王琨老师：对，所以说我觉得形式主义假敏捷害人，很多人是没有做对的，看了两本书就去做了，做的时候没有做好，然后就感觉敏捷没用，就相当于这个人本身认为知识已经学会了，但是他并没有理解本质，应用的时候就没应用好，然后很主观的给出一个判断，认为敏捷不适用。

我们有一个守破离的三个阶段你听过吗？你不会炒菜，不会开车，菜谱和教练会告诉你，1234每一步该怎么做，这个是守；守的过程中你会慢慢的有自己的心得，然后就破，就是我可以稍微根据情况来更改一些内容；最后一个是离，就是你已经可以形成自己的一套理念和方法了。

所以你先要做好守，守要做到熟，你要完全理解敏捷的四大价值观，十二大原则是什么。比如，你要知道PO和Scrum Master真的是不能重复的。你就按照这个守来执行，你走下来之后，会发现有个别的地方难以实现，然后我们就找问题的解决办法，所以有些时候不是这个地方实现不了，是可能方法有问题。

守的过程当中你就发现可以破，比如说人家说7±2，不要超过9个人，那我们公司不允许，我可以是十个人十一个人也没有关系，比如说每日站会15分钟，我也可以20分钟，也没有关系，这个就是破了

Q：其实很多企业应用敏捷都会破的。

王琨老师：都会破的，只有破了你才会觉得这个东西可以落地的，那前提也是只有自己实践了尝试了才知道怎么破。

Q：这样对Scrum Master的要求会很高是吗？

王琨老师：是的，所以好的Scrum Master一开始都是从外边请Coach，外边的Coach帮公司带一段时间，然后带出来之后才可以用Scrum Master，不能是简单的项目经理直接代替Scrum Master，因为很多项目经理其实是技术型的，他自己整体的改变就需要时间，刚开始带团队是有风险的，很多企业没有成功也有这个原因的。

Q：其实聊了那么多的敏捷项目管理内容，那如果让您用一句话讲敏捷，您认为怎么讲会比较合适？

王琨老师：敏捷诠释了什么叫真正的客户满意度；我们常说客户是上帝，但是上帝经常不开心，因为我们做的东西不是他们想要的，所以我们就要通过软技能，甚至商务操作等手段提高满意度，这些都是假的满意度；而真正的敏捷，能彻底以客户为中心，以满足客户的需求为最高原则，促进团队成员的沟通与协作，增强团队的自主性和灵活性，高效地应对一切变化。

03.敏捷对于职场人的作用

Q：其实了解下来，想去或者有意识去了解敏捷的，很多都是到项目经理级别的职场人，您认为项目团队中其他人员有必要学这块内容吗？

王琨老师：我觉得是很有必要的，因为不论国家也好，企业也好，创新变革的口号已经提了好长时间了。现在看，已经不是空头口号了；我们国家从改革开放就尝到了创新的甜头，现在各个行业的龙头基本上是探索型企业；创新就意味着和未知事情打交道，未知就需要去探索，去快速失败；失败了才能知道怎么成功；敏捷之所以在VUCA时代下有如此影响，就是用敏捷能早失败，快速失败，然后最终成功；听起来好像很绕，但是确实有道理的。

例如HR，平常是要和一帮敏捷的人去打交道的，所以需要有敏捷的思维，招聘时你不懂敏捷思维，你就招不到合适的人，你招聘时还是看这个人固有的能力怎么样，其实你已经错过了一个非常有潜力的人。他的能力可能目前来说是一般的，但他的思路、他的激情、他的协作，这些品质，你都错过了，所以说你如果还是死板的招聘，那你就招不到敏捷人。

所以不管什么岗位我都建议学一下敏捷，所有的东西都是一样的，万事万物都是通的，甚至就抛开职场所有人都应该懂的敏捷思维。

Q：比如说，我现在是一个产品经理，不一定是IT的，实际看来的话，它最大的作用是什么？

王琨老师：要看这个产品经理项目是怎么样的，如果这个产品是和盖楼类似的产品，这个时候敏捷不见得是对的，如果说你这个产品，需求经常变来变去的，比如说广告行业，你是加在客户和开发团队之间的，开发团队可能会天天和你对着干的，因为他会觉得你这个人怎么这样，你没有权威你就是一个传话筒，他们会把怨气撒在你身上，因为他们没有敏捷的思路。如果有敏捷的思路，是拥抱变革的，因为只有用户提出改变，你进一步优化你做出的东西才是客户真正要的。

所以产品经理需要有一些思路的，你跟我说需求要变，不是说我马上要变，你是需要评估的，为什么要变，客户需求到底是什么，确定要变后，还是要排优先级的，我是不是可以放在下个迭代里，或者说其他迭代里。其实就是PO的角色。

Q：职场方面在深入一下，对职场人发展的影响呢？

王琨老师：最近这两年我关注到，职业生涯规划是个很火的话题，也出现了很多的生涯规划师；但是现在的规划已经更过去完全不一样了，三年前我也没想到我会走上职业讲师的道路；所以保证个人的职业规划时刻富有极强的弹性与灵活性，以实现与现代商业环境的需求及变化保持高度同步。这本身就需要敏捷的思路！

Q：相当于说由于时代环境的快速变化，其实职场环境也是快速变化的，那如何在职场上走的更顺，也是需要敏捷思维来快速应对的。

王琨老师：对，找到自己感兴趣的点，快速的尝试，不成功的话赶紧换方向。所以你看很多创业的人就是这样，尝试了失败了，尝试下一个，找到那个点就成功了，其实只有尝试了才有成功的可能性。

包括一些比较牛的企业，你也能看到它总是可以快速的发现问题，快速的解决问题。为什么两周一个迭代，然后回顾会，发现问题解决问题，这就是敏捷思维。人是一样的，快速发现问题解决问题，才能成长的更快，相应的能力也是提升的更快。

04.对于敏捷人建议

Q：对于咱们12月要开课的学员有什么建议？

王琨老师：

放空自己，学习体系；

考试容易，实践不易；

身边高手，多多珍惜；

最终解决，得靠自己！

Q：首先需要带着空杯的心态来是吗？其实学敏捷还是蛮需要这点的。

王琨老师：对，因为敏捷和之前的思路有可能是完全相悖的，可能会有理念上的冲击，我们学PMP放空自己是因为那个东西是美国人思路，跟你说的不一样，但它不是相悖的。但是敏捷可能是完全相悖的。

Q：能给咱们的学员推荐点书籍吗？关于敏捷和管理的。

王琨老师：推荐印象深刻的几本吧。《大产品，小团队》，《敏捷项目管理》，《用户故事与敏捷方法》，《Scrum精髓》。一些基本看板的书也不错，比如：《看板方法》、《图解精益生产之看板拉动》。

《大产品，小团队》是携程出的，书里面也有很多的资源是可以参考的，我们的PBA老师于兆鹏还做过序。

Q：《看板方法》和《看板实战》两本书有什么区别？

王琨老师：《看板方法》的作者David J. Anderson是看板方法的创始人，所以你能看到最原始版本的看板。其他的书都是从这个基础上来写的。

Q：职场人大家都很忙，您平常的学习时间怎么安排的

王琨老师：前几年有个高人教我一招，一般不出差的话，我会吃完晚饭小憩半个小时，能换来晚上四个小时的高效率时间（不过真的不建议大家熬夜，对身体不好）；另外建议大家有看书的计划，一般我会在飞机上和高铁上快速的看一本书。看完书要写读后感，就是要有输出，这本书吸收的才会多一点。

Q：忙的时候是怎么释放压力的？

王琨老师：我平时有时间会发呆，放空自己；之前看过类似的方法介绍，但是我说不好，我觉得能起到释放压力的效果。

Q：敏捷人CLUB是想创造一个帮助敏捷人成长的平台，如果让您给敏捷人CLUB的读者提一些建议，您会说什么？

王琨老师：知识改变命运！学习是成年人最后的救赎！

结语：看样子还是要好好学习，非常感谢王琨老师，今天的内容非常的精彩，在愉快的聊天中学了很多东西，相信我们的读者也能对敏捷的理解更深入，再次感谢您再百忙之中接受我们《敏捷人CLUB》的专访。