没有范围边界的项目，产品经理做起来有多累

最近一段时间，忙着一个项目的上线，也算是全程跟到尾，其中的累，想必跟过项目的人懂的都懂。

真心说句实在话，想做成任何一件事情，都没有想象中的那么容易。

不知道大家有没有遇到这样的情况，就是一个项目，没有明确到底要做什么，要交付给客户的方案始终来回变化。在这样的背景下，还是时间紧任务重，要求项目成员抓紧开发上线。其结果，也就可想而知。项目里的人感觉到“累”，也就理所当然了。

一、没有边界带来的问题

先来说说一个没有范围边界的项目，在推进执行的过程中会遇到的问题。

1. 需求不能确定

很显然，不用多说，范围不明确，首当其冲的就是需求的不确定，这可就难倒产品经理了。

其实，无论是外部项目还是公司内部产品，明确的范围是前提，在这个前提下，才有能够生根发芽的土壤。

在项目制的运行体系下，一般都会有项目经理这样的角色，TA在前期的主要作用，就是要和甲方明确对方的需求，然后给出相应的解决方案。这是作为项目经理这个角色所应该做到的，也是必须要做到的。

在有了确定的范围后，接下来要做的，就是产品经理根据对应的需求内容，提供相对应的解决方案。在这个阶段的时候，如果产品经理有不明确的地方，其实是可以直接面对甲方的。

那如果项目从一开始，就没有清晰的目标，在这样的情况下，产品经理该如何展开工作呢？我们能做的，就是根据项目经理目前能够掌握的信息来规划产品，尽自己最大的努力，提供目前所知的最好的解决方案，也仅能如此而已。

以我们自己的项目来举例，最开始的时候，项目经理提供的信息是项目会分成1、2、3期来分期实施，但是每一期里到底要实现哪些功能并没有敲定。比如说1期里，刚开始说不要A模块，过了几天，又说A模块要有，再过几天又说A模块可以先只实现其中的几个功能，再后来又说因为技术对接原因A模块又要做调整。

在我们的项目中，像上面的情况比比皆是，产品方案改了又改，技术评审提了又提。要知道，每一次的改动和变化，都会带来很大的机会成本，会造成很多的资源浪费，也会消磨掉大家的热情。在来回改了3、4次后，有个开发同事说的话，很能代表大家的状态，他说“刚开始做的时候还很有动力和目标，改着改着，已经不知道干啥了，也不想干啥了”。

可想而知，项目范围的不确定，势必造成需求的模糊不清，必然带来产品方案的摇摆不定。

做项目，每一次变化，都是执行人的灾难。

2. 开发优先级排期没发做

项目的范围不明确，产品的需求就不确定，这样带来的结果就是开发工作排期的问题。

在正常的流程下，到了开发工作的阶段，产品的需求基本上都是定稿的，并且应该是经过评审可落地的那部分。有了这样的前提和基础，在分配开发工作的环节才能够有条不紊的进行。

但是如果在一切都还是待定的情况下，仅仅指望开发自己去摸索去领悟项目的内容，这是不现实的，也是不可能做得到的。

在这样什么都不明确的情况下，过早的让开发接入也是比较欠妥的。这样往往会导致什么情况呢，那就是开发所做的架构规划和开发工期，会被不断的来回修改，最终的结果就是啥也干不下去。

说回我们这个项目的例子，最初的方案，1期只做基础的购买流程，2期开始深入优化，3期开始软硬件整体升级。产品需求也是这样安排的，开发优先级也是这样做的。然后在某一次内部会议后，又被改成了1期时间点要上线的内容，包括之前规划的1期 3期的内容。再到一次内测后，又改成1期时间点要上线的内容，包括之前规划的1期 2期 3期的全部。你没看错，就是时间点不变，但是内容是全部。

然后就是无限的恶性循环，最后的结果就是，产品没有主见，开发没有方向，就这样在混沌中继续。

做项目，如果从一开始就想着一步到位，那基本上也就离“做不好”不远了。

3. 项目的交付标准没有

如果上面的需求和开发都没有很好的规划和执行，可想而知，项目的最终交付会是什么样子，那该是有多么的灾难。

所谓项目的交付，在我的理解里，就是按照项目预先规划好的方案，分阶段在规定的时间内高质量完成对应的内容。

一般情况下，项目的范围明确好之后，就会形成相对应的解决方案，在这个解决方案里所涉及的点，就是最终要交付的点，就是最终项目要验收的点。

交付团队一般会做什么事情呢？那就是根据项目的规划，要明确好每一期要交付的内容。而为了最终能够顺利交付，他们还需要进行相应流程的测试、模拟环境的搭建、账号体系的准备、用户培训手册的准备等等相关的配套服务，其实事情还是挺多的。

那如果项目的范围变化了，也就意味着他们的那一些列工作都需要进行相对应的调整。

还是以上面项目的1期、2期、3期内容为例，刚开始的时候，按照1期的交付内容准备相应的内容，并且经过测试，已基本符合相关方的要求。接着就是交付内容的变化，从1期 3期，再到后来的全部。想必那段时间，交付团队的工作一定是十分的忙碌且迷茫吧。

以上，就是一个范围不明确的项目，给产品团队、开发团队、交付团队所带来的影响和挑战。这样的不明确，其实是对团队的极大消耗，无论是时间还是精力，每个人都付出了很多，但最终的结果却是所有人都不满意。

二、如何尽量规避

上面说的那些问题，是不是就无解了呢，其实也未必，经过对项目的复盘，还是有能够解决的办法的。

1. 明确核心干系人的期望

所有的项目，最终都是要为人服务的，那就需要明确项目中的干系人，对这个项目的期望和所希望能够达成的目标是什么，这是很关键的一个点，是决定项目最终是否成功的关键。

当然，在明确每个人的期望之前，是需要识别出项目中的关系人，说白了就是谁对这个项目有话语权，谁的决定能够左右项目的内容。如果有遗漏，那么肯定会在某个时刻，对项目产生不可逆的影响。

上面举例的项目中，我们就是犯了这样的错误。在前期的调研和方案提报的过程中，都没有征询技术负责人的相关意见，项目经理也就理所应当的以为所给的方案就是最合理的。可是就在项目1期的时间点快结束的时候，这个技术负责人提出了他的想法，而他的这些想法，就直接打乱了项目的1、2、3期规划和开发节奏。

当我们识别出了项目中的核心干系人之后，紧接着要判断的，就是这些干系人的权力、职责、和影响力。这是很关键的，也是一个项目经理很核心的能力要求。在掌握了以上基本信息后，就需要和每个干系人进行深度的沟通，深度挖掘他们的需求，洞察他们的真实意图。这是很难的，但是也是必需的，不得不做的事情。

明确了他们的核心诉求之后，如果大家目标都一致，那当然是皆大欢喜。但是，现实情况往往是每个人所关注的点都不一样，而且很多时候还会冲突。这时候，项目经理要做的，就是权衡利弊，有的放矢。

像我们举例的项目中，甲方领导的诉求是在他的任期内，打造一个业内标杆的成功案例；甲方下面具体做事的人要求是，系统平稳过渡，不要一下子就大刀阔斧的切换。我们公司领导的诉求是开拓对方市场，技术经理的诉求是将所有的成熟方案应用落地。

之所以我们后面会进行频繁的变更，也就是从一开始并没有十分的明确他们的诉求点，而在我们的项目中，他们每个人的话语权都挺重，每个人的要求都需要满足。

识别项目干系人，明确他们的期望，了解他们的动机，知晓他们的目标。然后进行汇总、权衡，最后形成让各方都满意的方案。

2. 调整开发节奏

唯一不变的就是变化，为了适应现在的项目节奏，小步快跑快速迭代，敏捷开发及时反馈，才能够适应不断变化的节奏。

以前的项目开发流程，所遵循的基本上都是严格意义上的控制，也就是所谓的结构化开发方法。基本上都是按照项目规划-系统分析-系统设计-系统开发-系统测试-系统交付，这样的流程来操作的。而且每一步之间都有强依赖关系，下一步的内容要严格按照上一步规定好的内容来进行。

这样的方式，好处就是能够比较按照流程推进，但是这对项目经理和团队的要求都比较高。而且这样的方式，很难适应和满足快速变化的项目。

所以，如果项目的范围在前期并不是很明确，可以尝试换一种方式，迭代开发或者敏捷开发，都能够很好的解决前期内容不确定的情况。

将开发的交付按照周为维度来进行划分，大家只考虑这一周要做的内容。有变化要调整就直接记入下一个迭代周期中，快速的响应，及时的处理。

到了项目后期，所有内容都明确和固定之后，再慢慢将快速的迭代和长期的规划相结合起来。

想要做好这点，最关键的还是要从心态上有所转变。不要害怕改变，改变是肯定会有的。不要害怕调整，调整是在所难免的。我们要做的就是根据实际情况，做到灵活机动。

变化，从内部开始，就要升华，从外部推动，就是妥协。

3. 多沟通多确认

有效沟通，是团队保持高效协作的前提。

由于每个人过往的经验、知识的结构、认知的水平等差异，对待不同的事情会有不同的看法，对待相同的事情也会有理解的偏差。

如何才能消除这种团队成员之间的信息差呢，以我目前的经验来看，多次频繁沟通确认是十分有必要的。

很多时候，说的人和听的人，完全是不能够同步的。因为对说的人来说，他所讲的，必定是他自己脑海中有成形的概念的内容，也就是说他自己会在想象中构建一个自己所理解的画面。而且，他也天然的认为听的人能够懂。但是现实情况是，听的人是一头雾水。

这就需要双方进行信息同步确认，说的人，可以引导听的人将听到的内容用自己的方式理解一遍。听的人，在有任何不确定的内容的时候，都需要向说的人确认，避免理想当然和不以为然。

还是以上面的项目来举例，在前期沟通项目方案的过程中，技术负责人说表达出来的是将目前现有的方案进行赋能，而项目经理的理解是将目前正在运行中的模式复制一份到当前项目，然后项目经理和其他所有执行部门所传达的也是项目经理自己所理解的意思。

但是在项目的开发和执行过程中，技术负责人提出了不同的要求和变化，因为在他的概念里，所谓的“现在的方案”内容包括目前正在运行的项目和规划中还未实现的模式，他的脑海中是最后的全面的东西，而且他想趁着新的项目，将他的一些想法进行落地。这样也就导致了项目组所完成的内容，在他眼里都是不值一提的旧东西，他想要的那些突破性的内容没有任何体现。

结果就是项目组进行调整和修改，哪怕临近项目上线的时间点。

前期可以多花点时间，将问题说透，不留任何有异议的地方，方能保证规划和执行的统一。

一些想说的话

很多时候，并不是我们不想做，而是我们不知道怎么做。

很多时候，并不是我们不愿改，而是我们不知道怎么改。

很多时候，并不是我们不进步，而是我们不知道如何变。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！