IT人的拖延——别让“需求沟通”耽误了你的正事

IT人的工作，很多“需求沟通”的场景，而在沟通需求时，又会因为沟通的不顺畅，没有结果而产生烦躁的情绪或者是悬而未决的不能开始行动，进而间接地造成了拖延。这种拖延的原因，需要从需求沟通的根源来找方案，让我们以程序员的视角来看看几个典型的“需求沟通”导致拖延的例子吧。

典型表现

1. 需求理解模糊：当需求文档不清晰，或者口头传达的需求含糊其词时，程序员可能会感到困惑，不确定从何下手，因此推迟开始工作，寄希望于需求会自行澄清或他人会提供更多信息。

2. 优先级混乱：在需求频繁变更的情况下，程序员可能会对当前任务的优先级感到困惑，不知道应该优先处理哪一项，这种不确定性促使他们采取“等等看”的态度，避免开始“可能很快会被废弃的工作”。

3. 沟通成本高：当发现每次沟通需求都需要花费大量时间和精力，尤其是跨部门或与非技术人员沟通时，程序员可能会因惧怕这一过程的繁琐和低效而拖延，希望能一次性得到所有清晰的指示。

4. 信任度降低：频繁的需求变更可能引起程序员的不满和抵触情绪，特别是当他们已经投入大量工作后。如果团队中经常出现需求不明确或变更的情况，且没有有效的沟通机制来解决，那么团队成员之间的信任度就会降低，这种信任度的降低也会导致他们对后续的沟通和任务执行产生消极态度，从而拖延响应新的需求。

5. 避免冲突：需求不明确或者变更时，程序员可能会选择逃避沟通和冲突而选择拖延。他们可能会觉得沟通和解决问题会引发不必要的冲突或者矛盾，因此选择回避，而不是积极解决问题。

6. 任务碎片化：由于需求不明确导致的频繁中断和任务重组，使得程序员难以维持工作连贯性，这种碎片化的任务状态让人感到无法高效工作，于是选择先处理其他更明确的任务，或将工作推迟。

这些症状或场景都表明，对于需求的不明确、变更等场景下不知道怎么沟通，又因为需求不明确或信任度降低引发程序员的拖延行为，需要从需求和沟通两个角度来找方案，让我们还是以程序员的视角来看看这些拖延表现背后的原因是什么。

5大原因

1、需求不明确：模糊的场景，不确定的人、事、物

当项目需求描述含糊不清，涉及到的场景、人物角色、需要解决的具体事项以及所需的技术要素没有明确界定时，程序员就如像被蒙上双眼，每一步都走得犹豫不决。这种情况下，为了安全起见，他们往往会采取“等待更清晰指示”的策略，而这也给拖延提供了很好的基础。

2、需求变更频繁：不安定的创作环境

项目需求的频繁变更，如同建好又拆的积木，给程序员带来了深深的无力感。每一次变更不仅是代码的重写，更是心理预期的落空，让人产生“做了可能白做”的挫败感。这种不确定性导致的不安全感，是拖延的另一大诱因。

3、优先级不明确：并行任务的困惑

在多方需求同时涌来的情况下，优先级的不明晰让程序员陷入选择困难。面对多个“紧急且重要”的任务，缺乏明确的执行顺序，会让人感到无所适从，从而选择暂时逃避而拖延。

4、缺乏目标感：失去前进的动力

目标是行动的灯塔，当程序员不清楚自己的工作如何贡献于整体项目目标时或者不知道对自己未来的职业发展有什么价值时，很容易失去前进的动力，进而产生拖延行为。

5、缺乏及时反馈：黑洞中的摸索

在没有及时反馈的环境中工作，只是自己单方面的做事，没有来自外在的反馈，做事的人就如同在黑暗中摸索前行，不知道自己的努力是否有效，这会大大降低程序员工作的积极性。

综上所述，程序员拖延现象的背后，隐藏着需求不明确、变更频繁、优先级不明、目标缺失及反馈缺乏等多重因素。下面我们来看看要怎么才能改善这种原因产生的拖延呢？让我们来看看“价值链分析”和“5个为什么”是怎么做的。

价值链分析

在互联网产品的敏捷开发中，确定每个Sprint的需求是一个关键步骤，直接影响到产品的开发效率和质量。价值链分析作为一种有效的工具，可以帮助团队系统化地识别和优化各项活动，从而更加科学地确定Sprint的需求。价值链分析旨在通过分析企业内部各项活动，识别出能够创造价值的环节，并发现优化的机会。在敏捷开发中，每个Sprint的需求确定需要考虑多个因素，包括市场需求、技术可行性、资源分配等。通过价值链分析，可以系统化地评估和优化这些因素，确保每个Sprint的需求具有高价值和可行性。主要活动包括需求收集、需求分析、需求排序、需求开发与测试、发布与反馈等。支持活动包括项目管理、技术支持、人力资源管理和采购。它的应用步骤如下：

1. 划分价值链

主要活动：

• 需求收集与分析：从市场、客户、竞争对手等多个渠道收集需求，并进行分析。

• 需求优先级排序：根据价值、紧急程度和技术可行性对需求进行排序。

• 需求开发与测试：将高优先级需求纳入开发，并进行全面测试。

• 发布与反馈：将完成的需求发布到生产环境，并收集用户反馈。

支持活动：

• 项目管理与协调：确保各团队之间的协调与沟通，优化资源配置。

• 技术支持与研发：提供技术支持，开发新技术以满足未来需求。

• 人力资源管理：培训团队成员，确保他们具备必要的技能和知识。

• 采购与外包：管理外部供应商和合作伙伴，确保高效采购和外包。

2. 识别高价值活动

通过对主要活动和支持活动的详细分析，识别出能够最大化创造价值的环节。例如，在需求收集与分析阶段，深入理解市场和客户需求，能够显著提升需求的准确性和价值。在需求开发与测试阶段，采用先进的技术和工具，可以提高开发效率和产品质量。

3. 评估和优化流程

对每个活动进行评估，发现优化的机会。例如，在需求优先级排序阶段，可以通过引入数据分析和机器学习模型，提高优先级排序的准确性。在需求开发与测试阶段，可以通过自动化测试和持续集成，提升测试效率和覆盖率。

4. 制定Sprint需求确认策略

基于价值链分析的结果，制定明确的Sprint需求确认策略：

• 需求收集：建立多渠道需求收集机制，包括用户访谈、市场调研、竞争分析等。

• 需求分析：应用数据分析工具，对收集的需求进行分析和分类，识别出高价值需求。

• 需求排序：结合市场需求、技术可行性和资源情况，对需求进行优先级排序。

• 需求确认：在每个Sprint规划会议上，基于优先级排序和价值评估，确认每个Sprint的具体需求。

举两个例子，假设一个软件开发团队正在开发一款新的项目管理工具，我们可以通过价值链分析来明确需求。

1. 需求收集

识别需求来源：从不同渠道收集需求，包括用户反馈、市场调研、竞争分析和内部团队建议。

• 用户反馈：通过用户访谈、问卷调查和用户评论收集需求。

• 市场调研：分析市场趋势和竞争对手的产品，了解市场需求。

• 内部建议：收集开发团队和其他部门的建议，了解他们对产品的期望。

应用价值链分析：

• 主要活动：需求收集和分析。

• 支持活动：项目管理（确保不同渠道的信息汇总和管理）。

比如：通过用户反馈和市场调研，发现用户希望新的项目管理工具具有更强的任务分配功能和实时协作功能。

2. 需求分析

分析需求的可行性和优先级：

• 技术可行性：评估需求是否在技术上可行，是否有现成的技术可以实现。

• 市场价值：评估需求的市场价值，是否能够满足用户的核心需求。

• 资源情况：评估实现需求所需的资源和时间，是否在项目预算和时间范围内。

应用价值链分析：

• 主要活动：需求优先级排序。

• 支持活动：技术支持（评估技术可行性），人力资源管理（评估资源情况）。

比如：通过分析，发现实时协作功能在技术上可行且市场需求强烈，而任务分配功能的实现需要更多资源和时间。确定实时协作功能优先级较高。

3. 需求排序

根据优先级排序需求：（此处为通常规则，可根据业务具体情况调整）

• 高优先级需求：满足核心用户需求，技术上可行，资源充足。

• 中优先级需求：满足次要用户需求，技术上可行，但需要更多资源。

• 低优先级需求：满足辅助用户需求，技术上可行，但当前资源不允许。

应用价值链分析：

• 主要活动：需求排序和确认。

• 支持活动：项目管理（制定需求优先级和实施计划）。

比如：在需求排序会议上，确认将实时协作功能作为当前Sprint的主要需求，任务分配功能作为下一次Sprint的需求。

4. 需求开发与测试

详细制定开发计划和测试计划：

• 开发计划：明确每个需求的开发步骤、时间安排和责任人。

• 测试计划：制定测试用例，确保需求实现后的功能正确性和稳定性。

应用价值链分析：

• 主要活动：需求开发与测试。

• 支持活动：项目管理（协调开发和测试），技术支持（解决开发中的技术难题）。

比如：程序员根据开发计划，开发实时协作功能，并在开发过程中进行单元测试和集成测试。

5. 发布与反馈

发布新功能并收集用户反馈：

• 发布：将新功能部署到生产环境，通知用户使用。

• 反馈：收集用户对新功能的使用体验和建议，进行分析和改进。

应用价值链分析：

• 主要活动：发布与反馈。

• 支持活动：项目管理（管理发布流程和反馈收集），技术支持（解决发布中的技术问题）。

比如：将实时协作功能发布到生产环境，用户使用后，收集反馈并发现一些优化点，准备在下一个Sprint中进行改进。

通过价值链分析，互联网产品团队可以系统化地评估和优化各项活动，科学地确定每个Sprint的需求。这不仅有助于提升产品开发的效率和质量，还能确保每个Sprint的需求具有高价值和可行性，从而更好地满足市场和用户的需求。

价值链分析对需求沟通的启发

在上述的阶段中，研发同学多半会关注在技术的可行性，开发计划，发布等环节，相对来说比较容易忽视的对“需求本身”价值的思考或发问。大家可能会因为这件事是产品经理的职责，就不太关心这一部分，但是如果需求本身价值那里就有问题了，后续的开发，测试，发布做的再好，不也会跟着一起看不到想要的效果吗？其实，对需求价值的思考不需要像产品经理那种程度的分析，只需要把握住一些关键要点：

•  需求与产品整体目标的关联度：这个需求的价值符合咱们产品当前的目标吗？不是的话，是否还有其他需求是要赶紧实现的吗？
• 是否有替代的更简单、更快速的方案：这个场景中解决问题的方法只有用户故事中的一种方法吗？
• 场景出现的频率有多高：这个需求用户会经常用吗？还是偶尔用一次？如果偶尔用的话，有没有别的方法满足用户啊？
• 明确目标用户群：这个需求使用的人群有哪些啊？是咱们的重要用户不？重要用户有没有需求在等着做呢？
• 明确需求目标和当前任务的关联度：用户想要这个功能是用来干什么的啊？咱们准备做的这个功能能解决用户的问题不？
• 低成本试错：这个需求真的要全都做了才知道适不适合用户吗？有没有办法做一部分先测试下？
• 大项目要有拆分任务的思维，先做重要的：这个需求涉及的工作量和影响太大了，大改版的风险有点大？能不能拆解下，看看哪块最重要，先把最重要的先做了。
• 协作类的项目要注意协作方的资源到位情况：这个需求涉及到其他部门（第三方或合作伙伴）的配合，他们的资源什么时候能到啊？

在平时的需求沟通中，善用上述的方法来思考并沟通，可以把需求沟通的各种问题阻挡在开发之前，进而就不会因为需求沟通的问题导致自己各种状态不佳而产生拖延了。

5个为什么

除了价值链分析之外，还有一个方法叫“5个为什么”。“5个为什么”（5 Whys）是一种问题探究工具，源于丰田生产系统的根本原因分析方法，主要用于识别和解决问题。这种方法的核心思想是通过连续提出五个“为什么”问题，层层深入地挖掘问题的根本原因，而不是仅仅停留在表面现象上。这种方法鼓励深入思考，帮助人们超越直接的、显而易见的答案，找到隐藏在问题背后的更深层次原因。

应用“5个为什么”这一问题探究工具，也可以帮助我们在需求沟通时，快速找到关键沟通点，进而将一些潜藏的问题早点挖掘出来，减少后续做了没效果或耗精力再三确认需求的问题，也能有效避免这些原因导致的拖延。以下是结合“5个为什么”方法在确认Sprint需求时的应用步骤：

1、提出问题：明确需要解决的问题

首先，我们需要明确本次Sprint需要解决的核心问题或达成的主要目标。例如，“为什么我们要在下一个Sprint中优先开发用户个性化推荐功能？”从表面问题出发，这是我们的起点，也是我们深入探究的入口。比如，这个“为什么”的对话可能是这样的：

1. 第一个为什么：“为什么用户个性化推荐功能被认为如此重要？”

   可能的回答：“因为用户调研显示，个性化推荐能显著提升用户满意度和留存率。”

2. 第二个为什么：“为什么用户满意度和留存率的提升如此关键？”

   可能的回答：“因为当前用户流失率较高，影响了产品的市场竞争力。”

3. 第三个为什么：“为什么用户流失率高？”

   可能的回答：“因为用户反馈应用内容同质化严重，找不到符合个人兴趣的内容。”

4. 第四个为什么：“为什么内容同质化问题没有得到及时解决？”

   可能的回答：“因为目前内容推荐算法较为基础，没有很好地捕捉用户偏好。”

5. 第五个为什么：“为什么内容推荐算法没有及时升级？”

   可能的回答：“因为技术团队过去几个月忙于处理系统稳定性问题，资源分配未能顾及算法优化。”

2、持续追问：找到问题的根本原因

通过这一系列的“为什么”，我们最终发现，用户个性化推荐功能之所以成为优先级，根本原因在于技术资源之前被紧急但非核心的问题占用，导致未能及时优化用户体验，进而影响了用户留存。因此，解决个性化推荐功能不仅是满足用户需求，更是提升产品市场竞争力的关键。

3、应用发现：制定策略与行动

了解到这一根本原因后，研发团队可以采取以下策略：

• 短期：立即着手在下一个Sprint中优先开发用户个性化推荐功能，快速响应用户需求。
• 中期：重新评估并优化团队资源分配，确保技术创新与用户体验提升并重。
• 长期：建立机制，确保技术债务的及时处理，避免影响产品核心功能的迭代。

以上只是示例，实际的场景会更为复杂些，主要是要通过一定程度的发问来让大家更加明晰为什么要做这件事，怎么做这件事才能把这件事做好，才能做的最具有性价比。通过“5个为什么”问题探究方法，产品团队不仅明确了当前Sprint的需求优先级，更重要的是，找到了问题的根本所在，并据此制定了针对性的解决方案，从而确保了迭代的高效性和目标的准确性。这种方法论的运用，不仅提升了决策的质量，也为持续的产品优化提供了有力支撑。

总的来说，由“需求沟通”引发的拖延问题，主要还是要培养思考“需求价值”的思维，不需要深入，但是要明白为什么做，场景是什么，目标用户是哪些，频率怎么样，方案是否可以拆解，先做出来一点试下水，各方面的配合是否会如期等等，有了这些思维，只要在需求沟通段，及时根据具体的需求确认这些问题，就可以在开发前减少“需求”引发的问题及拖延了。讲了这么多，不练习还是记得不牢靠，赶紧练起来吧！