SCRUM：静态到动态的转变

Posted 2021-04-25 我的技术售前经历

1. 对SCRUM价值观的理解

按照SCRUM创始人之一，杰夫.萨瑟兰，也是敏捷宣言的签署者之一，的描述，SCRUM是实现敏捷宣言四大价值观的框架。回顾一下敏捷宣言的四大价值观：

• 个体和互动高于流程和工具

• 工作的软件高于详尽的文档

• 客户合作高于合同谈判

• 响应变化高于遵循计划

对于这四大价值观，我可以认为前面代表的是动态是运动，而后者代表的是静态是静止，这也符合世界是运动着的本质。为了应对VUCA时代，我们的思维与行动也应该是动态的，讲究小步快跑。不是说以前的经验，比如瀑布法、PDCA（PLAN, DO, CHECK, ACTION）等，没有用武之地了，而是说把它们的周期缩短，内容减少，快速地迭代，让矛盾快速地暴露出来，能够看到动态而不是在一个阶段过长地停留，看不到摩擦，也看不到矛盾。

大家在课本上都看过刻舟求剑的故事，如果我们应对的计划、需求等是过去某个时刻的，那就有点刻舟求剑的意思，只不过故事的主人公没有考虑水的运动，而你没有考虑市场、用户、技术、客户心理等的运动。

2. SCRUM如何化静态为动态

为了更灵活、更积极、更准确地感知变化、应对变化，SCRUM讲究：

• 需求，多变少：需求以用户故事的方法按照优先级及实现难易度等分组，然后每次仅实现少量需求，使得需求尽快经历从涉及到成品的过程

• 需求，点变面：把需求转化为用户故事的同时就看考虑此故事的方方面面，使得需求尽快转化为可使用的成品。至少要包括前中后台的操作流程，这是线。

• 流程，长变短：原来的项目流程分为分析、设计、架构、开发、测试、发布等几个步骤，每个阶段周期长，修改后把这些流程步骤或全部或部分浓缩到1到4周的短周期。通过短流程、快迭代的方式取代以往的长流程的方式。把大量无用的文档要么取消要么简化，消除资源浪费。

• 团队，大变小：团队一般不超过9个人，避免网状沟通的高成本、低效率。

• 思维，需求为中心变用户为中心：快速迭代，用户检验成果，不惧变化的心态，取代了严格按照死需求且抵制变化的心态。同时，时刻围绕着为客户“提供最佳价值”。

• 问题，混沌变透明：问题及障碍的可视化使得阻碍流程的因素尽早暴露，去除及改正成本低。每日立会就为大家提供了暴露疑难、请求与提供帮助的机会

3. SCRUM在售前工作中的运用

对于售前工作而言，一般分为客户拜访、需求调研、方案验证、开标、实施项目跟踪等几个大阶段。如果按照一般的流程那就与开发软件的常规流程类似了，但也可以用SCRUM的精神去展开工作。

主要运用以下几点：

• 以用户为中心，提供最佳价值

• 故事连线功能，价值一目了然

• 持续迭代需求，及时响应反馈

• 团队共享信息，保持目标一致

下面主要针对这几点谈谈支持过程。

3.1 以用户为中心，提供最佳价值

客户的每一个项目都是为了为自己或为他的客户提供价值，而我们的方案是为了在低成本短周期内为客户实现这些价值提供方法、路径。那么说服客户采纳自己的方案就是证明自己的方案可以帮助客户实现这些价值。

既然一切是围绕客户与价值，那我们就需要时刻挖掘与分析客户的潜在价值及客户摆在明面上的期望的价值。

如果客户主动启动了项目，而与你沟通时不知道或说不清楚需要的价值是什么，那你需要警惕是否找对了人，或这个项目是客户给某个供应商的礼物、或需要还给某个供应商的债。不要自以为搞懂了价值而让客户点头。

一个售前的阶段或许很长或许很短，我们需要抓住机会与客户讨论价值及价值的实现方法，及时得到反馈。方案的优势未必是客户需要的，你努力证明的未必是客户关心的，你不以为然的可能就是关键。

3.2 故事连线功能，价值一目了然

各个企业目前都在销售场景、销售故事，有些是感性的，有些是理性的。这里面其实都想体现价值，隐藏技术细节及琐碎的功能集合。

我们在与客户交流的过程中需要故事，但我们的故事既有虚的也要实的，因为目前的客户既关心整体价值也关心价值能否落实。个人比较喜欢把价值融入客户环境中讲，把把关联的人、系统加进来。面向客户的故事是整体的，不是敏捷开发时的简短故事。但对于我们分解的工作就是简短的故事。通过故事的形式确认价值，当然了有些技术性强的就不用，不能一概而论。

优先级也代表价值的重要程度，需要用户确认价值的同时确认优先级，但这需要正确的客户，否则你的方案就是答非所问，我就有深刻体会，相当尴尬。

3.3 持续迭代需求，及时响应反馈

对于我们的工作事项转化为故事，多次迭代，及时响应客户反馈，拉近与客户的关系。调研、整理需求、系统架构、测试场景等都可以多次迭代，从而尽力避免结果与客户期望不符。

3.4 团队共享信息，保持目标一致

销售的过程涉及销售、售前、产品经理、市场等多种角色，鉴于大家大部分时间可能都不在办公室，每日立会不太现实，但定期的或基于事件的沟通很有必要，这可能是销售牵头也可能是售前牵头，取决于项目特点。但如果大家都有及时沟通、及时排除障碍、及时提供信息的共识那就可以。

4. 静态转动态的关键

需求、方案、架构、实现、甚至价值等是死的，人是活的，它们变是因为人让他变，所以尽快与各方人员多联系，让矛盾尽快体现，矛盾就不会上升到冲撞，而是激烈的讨论。矛盾的暴露需要团队甚至跨团队及上层领导的帮助，这是好事，不至于在一片看似清澈实则混沌的状态下到项目关键时刻了才互相指责、大伤和气。人都说家庭里小矛盾不断大矛盾不现，所以在项目中不能让矛盾在暗我们在明。在静态中找到相关的另一方，然后沟通、行动、检查、改进，持续地迭代。

个人觉得只要与客户及团队持续地沟通，保持信息的透明而不是什么都藏着掖着，也不要有唯恐别人从你这学走什么、拿走什么的态度，那团队之间就有持续的、健康的信息交换，这就是动态就是运动，就会有好的结果。