如何推进一个项目，如何做好项目推进

当遇到不合理的业务需求，项目流程或方向不符合自己的预期时，你会如何应对呢？笔者回顾了自己的项目，提供了两个版本的分析，总结了相关的经验和教训。

您在项目过程中是否遇到以下问题？

企业总是面临着不可能的挑战，产研部门苦不堪言，销售人员也不总是按照既定流程操作系统，给自己带来了“不可能的挑战”，功能要么不落实，要么必须落实。或不。根据需求重新设计一个项目；上线前的承诺，上线后立即更改，然后一遍又一遍地修改；我最近遇到了这样的问题，但最终项目上线时我能够提高性能并运行项目进展顺利。

项目本身需要在内部添加一个“订单审批”功能，这看起来没什么大不了的，但我们产品机制的复杂性以及底层订购模块的参与意味着这个功能并不那么容易。它并未作为市场上的一般批准功能来实施。

该项目有两个主要版本，虽然版本1在上线过程中遇到了很多问题，但版本2非常顺利地融入到业务流程中。

为什么两个版本会有如此大的差异？我们在设计版本2时做对了什么？

我回顾了这个项目并总结了我非常重要的经验与大家分享。

让我们开始吧。 （老规则：粗体字可以帮助你更快地阅读）

背景：我负责一个在线教育公司内部开发的系统，这次使用的功能是订单录入+审批功能。

1. 版本1 - 设计阶段该要求最初是在公司想要添加新的挂单时开始的。

所以这个项目的第一个版本只是创建一个输入订单的功能。

这很简单。销售人员在后台输入订单，订单激活，客户使用，订单完成。

然后，从财务风险管理的角度来看，需求发生变化，不仅包括输入，还包括审批功能。

我当时就是这么想的。 “嘿嘿，这不是很简单吗？”审批功能是常见的功能模块，市场上已经很成熟，并不难。

完成前期研究工作后，我立即与相关部门召开了初步会议，确定了本项目的目标如下：

我们在开始产品设计时就考虑到了这两个目标。

这个过程并不复杂，我们通过借鉴市场上现有的批准设计，在LaLa 中完成了产品设计的第一个版本。

一些链接已被省略，以便任何人都更容易理解。

现在我有了第一个版本，我已经开始了第二次调整。

问题从这里开始。

会上，业务代表提出了特殊要求，但出于各种业务原因，希望订单生效，审批推迟。该图的简化版本是：

这个要求在我看来非常“不合理”。如果订单没有得到履行，授权就只是一个骗局。授权本身的目的是为了控制风险，但授权的目的是什么？

经过一番交涉，销售人员以他们有很多需要立即下单的客户为由击败了我们。

所以，我们只能设计这个功能。我立刻注意到了问题。这种设计可能会降低客户体验。

简单说明一下，有相关产品。如果产品订单被拒绝，所有相关产品都会出现问题。在某个时刻，客户意识到所有订单均不可用。

这段时间我感觉很奇怪。第三次会议召开了，但公司和财务官员仍然什么也没说。我认为如果你被拒绝，客户体验不佳是可以接受的。

也许他认为监督很重要，但时间和精力已经无法完成监督的任务了。

所以当对方做出保证的时候，我们都需要保持怀疑的态度，并做好一些后备计划。

3.版本2——设计阶段一年后，内部调整导致该功能再次失败。六个月前，我们开始了各种“面对面会议”，讨论如何协调新版本的批准。

我强烈反对继续实行“教师效应审查批准”流程，并列举了该流程已经存在的各种问题以及对客户情绪造成伤害的例子。

企业官员强调需要立即产生效果，并且他们正在提供数据来证明这一点。我们认为，确保客户体验应该成为产品的考虑因素。

这期间我们曾多次会面，但始终未能达成共同结论。

最终讨论没有进行下去，领导又叫来了最高业务经理一起讨论。

该企业总经理同意该命令应在生效前获得批准，可能是因为地理位置的原因，并愿意考虑公司的利益。然而，他必须处理下属报告的问题。

最终，在总经理的协调下，我们采用了如下折衷方案：

具有相关关系的产品无法验证，必须等待财务审批。订购简单的产品首先必须对客户有效。听到会议结果我真的很高兴，产品设计进展很快。

然而，“订购简单产品需要教师效率”的问题仍然存在。

这一次，我也学会了不要埋头苦干。在与其他团队成员和领导讨论后，我们意识到这个功能可能不需要太复杂。

直到现在我们都无意识地认为输入订单就是生产正式的产品（课程）供客户使用。

但如果只是再开一个“临时产品”，让客户使用，而不生成正式的订单产品数据，那么整体的开发量就会小很多。

最终我们决定采用一种简单的实现方式，将“验证”和“订单”分开。通过关闭函数本身的循环并将其与排序模块解耦，您可以减少出现问题时的影响。

我们如何得出这个解决方案以及我们的想法在方法提取部分中重点介绍。

同时，我们也从过去吸取了一些教训。在这个版本的设计中，我们尽量避免功能流程过于冗长、复杂带来的问题，做到“高内聚、低耦合”。

例如，我们删除了订单修改功能，仅保留订单输入功能。

如果信息有误，您可以在输入时直接选择错误的订单，系统可以快速填写信息并提交新的授权，而无需手动补充信息。

最后，我的转换将这个功能从6个功能模块简化为3个功能模块。

4.版本2——最终使用阶段上线后我只跑了一场训练，上线体验出乎意料地比我预想的还要流畅。

而对于训练，我们改变了之前的训练流程。

之前的培训已经让这个产品在公司里人尽皆知，所以不直接操作系统的管理人员往往会变成“外人”，出现问题就来找我们咨询，人也来了。请直接询问我们。

一线人才流动性大，需要不时回答相同的问题。

新的培训流程仅包括对管理层的培训，然后将培训分发给一线管理人员，并由管理层回答他们的问题。

该模型不仅使管理人员能够更清楚地了解系统的功能，而且还可以带来更好的学习成果，因为现场工作人员直接从主管那里接受培训。

我终于松了口气，版本2 已经启动并顺利运行，但回想起来，我在版本2 中得到了以下几点好处：

学习如何分解问题而不是将它们混为一谈。与订单有效性和订单使用一样，它们不一定是同一件事。设计产品时应遵循“高内聚、低绑定”的原则。这不仅让开发变得更容易，也为业务人员提高了便利性，他们不再需要记住如何使用它。

5.经验教训提取方法论接下来，我想分享一个基于上述经验教训的可复用的方法论。

1.从更高的角度来看，为什么版本2这么顺利，而版本1却有这么多问题？这只是我个人从整体角度思考这个项目的方式，是的，可能不准确。

1.1 公司战略

回想起来，公司在做版本1时的策略是收入比去年翻一番，所以我猜收入是公司当时的重点。

批准的需要是出于风险管理的需要，与收入无关。因此，审批要求多种多样，需要各个部门的支持，但没有公司的战略支持。

因此，实际实施时，其他部门的员工会觉得“我们会配合，但不能妨碍利润的增加”，压力很大。

该公司实施版本2 的策略发生了重大变化。重点已从收入转向控制成本并确保流程满足要求。

因此，很明显，财务人员能够在版本2 需求会议上更加自信地发言。

总之，版本2 的工作将会更加顺利，因为您的需求与公司今年的战略是一致的。

1.2 我们的程序

在版本1 中，公司没有既定的审批流程，一切都是0-1。

第二版的审批过程已经一年多了，虽然经历了一些波折，但最终还是通过了。

因此，这两点的差异导致版本2 注定比版本1 工作得更好。我们在设计流程时更加关注这一点，删除旧流程中不必要的部分而不是添加新流程。学习和沟通费用。

1.3 企业文化

这是一个非常有趣的视角，也是对其他部门如何做事的一瞥。

这个项目表明，销售部门非常关心得罪客户，即使损害公司的利润，他们也不想得罪客户。

这和指标以及他们长期的工作习惯有关。

在与多位销售代表沟通后，我们发现他们都有同样的担忧。可以看到整个部门的风格都是这样的。

因此，如果您事先看一下这一点，就很容易理解为什么卖家会在稍后的会议中取消保修。

方法论提炼：

之前读《金钱博弈》的时候，我有一个感悟：项目一旦进展到一定时间，成败可能就不再是谈判者的问题，而是背后权力的争夺。

所以从这个角度来看，就更容易理解为什么版本1有问题而版本2没有问题。

需要多个部门合作的项目，如果没有公司的战略支持，执行起来极其困难。

在开始项目之前，可以先了解公司今年的战略和部门计划。

作为个人，我们必须尽力而为。

但你还必须学会观察你在整个环境中受到的限制，以便你可以更好地决定下一步如何行动。

如果能尽早观察到这一点，后续的产品设计可能会变得更加简单，只需要专注于为财务部门创建一个监控板来分析订单数据。

本文最初由@Thea小丽发表于《人人都是产品经理》，未经作者许可，不得转载。

标题图片来自Unsplash，并获得CC0 许可。

人人产品经理平台仅提供信息存储空间服务。