概述

这篇的随笔主要给大家介绍，在项目管理中如何引入变化？现在比较流行的敏捷开发是什么以及有什么地方需要注意的。

如何引入变化

其实，想要引入变化，你并不一定非要是项目经理，或者是有多么大的影响力。今天，我会给你介绍一些每个人都可以学得会的实用方法，帮助你更好地引入变化，尽可能地降低你在尝试过程中的碰壁概率。新手上路，要想引入变化，简单来说，你需要“天时、地利、人和”。

首先是“天时”，也就是合适的时机。时机或早或晚，都会让引入变化的阻力成倍放大。早了，大家还没意识到问题；晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为理所当然。很多同学都觉得，自己的项目组中有着这样那样的问题，而且，问题简直太多了。于是呢，自己一看到问题就想去改变，就想去整治，就觉得这是一个机会。实际上，问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机。有同学给我留言说，自己跟老板反馈了一堆问题，老板虽然是认同的，但最后往往就没了下文。其实，之所以不能产生改进动力，只能说明，你还没有抓准痛点。所谓痛点，简单地说，就是必须及时解决的问题，包含着强烈的迫切感。判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦。

要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点，这才可能一击即中。那么，怎样才能抓到痛点呢？我跟你分享几个方法。

1. 访谈法，也就是直接问。

针对不同干系人的问题列表，你可以参考一下。其中，最重要的问题是，“你认为项目组当前最大的风险和问题是什么？从你的角度出发，最迫切需要解决的是什么？”

2. 观察法。

实际上，与其看别人怎么说，不如看他怎么做。很多时候，人们会说这个很重要，但是一两个星期过去了，他也没有投入任何精力，那么这就是个“伪痛点”。这里有一个简单的方法，就是去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点。

3. 同理心和倾听。

只有你用心倾听，设身处地去理解他人，你才能够准确地感知到他最大的痛点。需要注意的是，抓痛点的过程，并不是一蹴而就的，你需要多观察、多了解，通过非正式的聊天，了解他们对潜在变化的态度，找到合适的契合点。实际上，在变革的早期，最重要的就是寻找到早期支持者。围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了。由早期支持者形成的变革核心团队，就会成为你在推动变化过程中的重要支撑力量。

其次是地利，你要学会因地制宜，结合团队的实际情况，为团队定制适合的解决方案，而不是照搬理论或所谓的“最佳实践”。实践中，你首先要去理解每个团队现有做法背后的历史原因和必要性，结合每个项目团队的现状，做好本地化的场景适配，这样才能获得好的效果。

因地制宜的适应性调整，并不是向环境妥协，而是创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效！

现在，我就要讲到引入变化的第三个关键点了，也就是“人和”。研究表明，企业变革失败的最常见因素就是人的阻力。面对变革，每个人都有与生俱来的情绪反应。这个情绪，是自动触发的，跟变革的大小无关。大到企业战略转型，小到仅仅是改变一个会议的方式，只要是引入变化，就会触发情绪反应，人们总是需要一个接受的过程。那么，如何在引入变化的过程中，最大程度地创造出“人和”的局面，让大家更容易接受呢？解法就是多聆听彼此，充分理解，找到共同的出发点。现实中，很可能你觉得是对的事情，不同人去看，会产生完全不同的看法。在沟通时，你要因人而异，针对不同的人，采用不同的策略。那么，如何选用合适的沟通策略？答案是，先判断立场！立场，是指人们在认识和处理问题时所站的位置。立场不同，看问题的视角就不同。在具体操作时，你可以把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响。你要做的就是，找出更多的积极因素。比如，通过开站会，测试可以更及时地获知和影响开发的进程，这对于测试来说，就是一个积极因素。同时，对于变化所带来的消极因素，你要提前引入相应的工具或方法来规避或改善。除此之外，就算是立场一致的两个人，也会因为基本假设和价值观的不同，对同一件事有不同的解读，从而呈现出截然不同的态度。所以，在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法。

小结：首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通。如果你想成功地把学到的那么多的项目管理方法引入团队，最难的其实不是那些招数，而是招数背后的你的发心。之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么。只有解决了大家的问题，这个变化才能最终被所有人打心底里接纳。所有这一切的发生，必须建立在信任的基础上。这个信任不仅仅是对你能力的信任，更重要的是，你是否能够站在对方的角度设身处地地思考问题。当你是在真心为他着想，为他解决问题的时候，对方自然会愿意接受你所带来的变化。

敏捷开发

很多人认为，每天开站会，有固定时长的迭代，有自己的“Scrum Master”，就是在开展敏捷实践了，其实不然。具备敏捷之形的团队有很多，但是，真正掌握敏捷精髓的，却并不多见。这是因为，敏捷方法属于 simple but not easy（简单但并不好做）。结合我这么多年的体会来看，与其说敏捷是一场研发方式的变革，不如说是一场思维方式的变革。

敏捷的特点，就是小即是美（Small is beautiful）。这个小而美，体现在人、事、时间三个方面：

人：拆分成小规模（5～7 人）、跨职能的小团队；

事：拆分成一系列小而具体的交付物，按优先级排序，增量交付；

时间：拆分成固定大小的短迭代（1～4 周），在每个迭代结束后，对可工作的产出进行演示。

总体来说，就是用小团队在小块时间，做出小块的东西来，并且周期性地集成组装。为什么我们当时会考虑引入敏捷呢？这就要从第一个版本的发布讲起了。这个新业务的第一个版本，原本预计在春节前发布。我们基于 WBS 做了完整的项目计划，用两个月时间进行模块开发，然后用一个月的时间来做发布前的联调、功能及性能测试。开发联调开始之前，一切都非常理想。我们有自认为完备的计划，有周会、周报和各种文档，还有任务系统的监控报表。我们从种种途径获取到的信息，都在告诉我们：“一切正常！”直到有一天，我们开始代码集成，准备测试了，“嘭！”各种意外超出了我们的想象，项目越来越不可控：

集成联调比我们想像得要更复杂；性能稳定性调优花了更多的时间；有一名主要开发人员离职；这期间赶上了过年，要放十来天假；测试人员是个新人，还在学习期；

痛点一：发布时间不可控（快速的增量交付）

考虑到项目的实际背景，我们把迭代周期定为一个月。我们每个月都会跟内部客户一起做 Sprint 计划及 Review 演示。这种做法，给我们带来了哪些改进呢？

提早集成与测试。这让问题得以及时暴露，带来了更快的反馈及应对；

及时规避风险。意外仍然会有，但大多数情况下，我们可以在 Sprint 内部消化掉，避免更大的影响；

快速响应变化。在 Sprint 1 演示会后，我们收到了新客户提的紧急需求，立即做了相应的调整。如果按照之前的模式，这个时候，可能很多事情我们都只做了一半，想调头没那么容易。短周期让我们可以灵活调整方向，每个 Sprint 都是潜在可交付的产品。

另外，在 Sprint 3 之后，我们临时安排了一个小的 Sprint，用来快速地将“潜在可交付”变为“真正可交付”。我们发现，在每个周期内，能够真正把事情做完，跟我们的最终用户一起分享阶段性成果，对团队来说，也是非常好的激励。这时，发布周期的问题已经基本解决了，我们的交付灵活性高了很多，客户也更满意了。那么，我们是否可以号称是个 Scrum 团队了呢？

痛点二：摆脱“接力综合征”（从对抗走向协作）

经过仔细地观察和总结，我发现，团队各个角色之间的协作方式仍然存在着一些问题，我把这叫作“接力综合征”。虽然交付周期变成了每月一次，但大家却仍然在按照过去的方式工作。具体表现有以下两点：

1. 宁愿选择等待。每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作。比如，我经常听到这样的说法：“需求文档还没理清楚，急啥？”“接口设计文档还没确认，怎么做啊？”这种情况，在传统的项目管理中是很正常的。但是，这些空耗的时间，并不能给产品带来直接的价值。

2. 角色间泾渭分明。每个人都觉得，只要把自己份内的事做完就行了。比如，开发把工作做完了，也不管做得效果咋样，心想：“反正要丢给测试，我先撤了，测出问题再说。”测试测出来 Bug，心想：“等开发全部修完，我再接着测，反正我都测完了。”在这种情况下，各角色之间是有一定的对抗的。项目中的任何一件小事都有可能造成冲突。最终大家都耗在那儿，每个人更在意的是“这是你的问题，不是我的问题”，却没有把焦点放在达成整体目标上。在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务，疏通对抗情绪，并解决随之而来的突发问题。但在敏捷的情境中，更加快速的交付压力，使得这种等待和界限变得越来越不可接受，我们不得不改变思路。敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分。虽然彼此之间有分工，但作为一个 team，进球才是最关键的。敏捷也是一样。我们从敏捷思想中得到启发，开始进行一系列的改进。首先，开发和测试把位置搬到了一起，并且设定了共同的 Sprint 目标和完成标准。开发做完了工作以后，如果发现测试进度被卡，就会跟着一起着急，一起想办法解决问题，因为这影响到了整体的进度。其次，从“你完成 - 我开始”，到我们一起完成。在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时在写的。往往代码刚“出炉”就测上了，而且只有在测试结束并确认没有 Bug 的时候，开发的工作才算结束。

痛点三：需求理解不一致 （面对面澄清及估算）

至此，团队的力量得到了很好的凝聚。在复盘会上，大家畅所欲言，共同讨论了下一个待改进项，那就是是需求理解。这应该是技术类项目的一个共性问题。当时，我们团队没有专职的策划，开发人员在理解需求时，经常会感到非常困难。我们打开敏捷宝箱，找到了一条重要的价值观“个体与交互 > 过程与工具”。相比于更多、更长的需求文档，我们决定采用更多的面对面交流来解决这个问题！于是，我们把迭代计划会分成了两个部分：

产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先级及验证条件，也就是说，在迭代结束的 Demo 演示会上，我们要给用户呈现什么。

团队估算。我们采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得出这个迭代要交付哪些内容。

队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。具体估算时，为了避免干扰估算结果，当所有成员选择好代表自己估算值的纸牌后，大家同时亮牌。同时亮牌的好处是，不会有人跟风出牌，每个人的估算都是经过独立思考得出的，这也是扑克估算的精华所在。如果估算值差距明显，代表大家对该条目的工作量没有获得共识，团队需要对该条目的评估结果进行讨论，由最大值和最小值的牌主，分别说明自己的估算理由，并重新讨论，确定最终的评估结果。经过实践检验，这样面对面的需求沟通及评估，至少带来了以下三方面的好处：

1. 需求探索更深入。在计划会上，团队会直面一线用户，需求可以得到面对面的交流和澄清。另外，团队估算其实也是一个团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做的时候，才会有各种各样的问题暴露出来。这个方法对于在早期进一步挖掘需求细节，特别有帮助。

2. 估算结果更加全面、细致。在传统的项目管理中，我们也做估算。比如，WBS 分配好了任务，然后每个人估算自己的。因为每个人都只对自己的那部分任务比较熟悉，估算时往往会有欠考虑，而团队估算，就很好地补足了这一点。每一个故事都会由全员出牌，各方从自己的角度出发想问题，可以互相补充。比如，在估算时，测试的成本也会被考虑进去。对于测试成本高的功能点，开发会主动想办法加强单元测试等白盒测试手段，这样一来，估算结果自然更细致、全面。

3. 找到了更优的整体解决方案。由于各方共同参与估算，前端、中间层、后端、测试的思路可以在一起交流碰撞，这样就非常利于找到最优的解决方案。我们团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的。从最开始缩短发布周期、经常交付可工作的软件，到应对“接力综合征”，提升团队的整体目标感和协作效率，再到探索更加有效的需求理解及团队估算方式，在增进团队交流的同时，又保障了需求质量。

敏捷实践的应用，为我们带来了诸多好处：1. 提升客户体验，更低的延误率，阶段性可见的产出，更快的反馈、适应与调整。2. 提升管理者体验。团队自主运行，管理更轻松变“赶”为“引”，为共同目标奋斗。3. 提升团队体验。更高的生产力。更强的责任感、主人翁意识。

小结：对于敏捷方法，我们并不是拿来即用的。我们所采用的这些方法，大多是以敏捷思想为指导，以敏捷方法为基础，在实际场景中不断演化，一点点改进出来的。实际上，没有任何一种方法、工具可以放之四海而皆准，每个人都需要在自己的场景中思考。真正决定一个团队是否敏捷的，不在于是否应用了那些实践，而在于实践背后是否体现了敏捷精神。通过我们的长期实践和观察理解，我提炼出了实战中三项最重要的敏捷精神，那就是：快速可靠交付，用户价值驱动，持续自发改进。我希望你能坚持敏捷精神，而不是僵化地套用特定的做法。在团队中实践应用敏捷时，也应该遵循小而美的原则，每次一小步，挑一个痛点去集中解决，小步快跑，不断尝试和优化。只要你做到了以上三点敏捷精神，那么，你的团队就是一个敏捷的团队，你的组织就是一个敏捷的组织。

总结

以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。

 

标签：小而,估算,项目管理,痛点,美的,引入,敏捷,团队,我们
来源： https://www.cnblogs.com/boanxin/p/14285679.html