无人售货智能机网站管理平台建设产品经理工作常见问题，关于产品经理的成长模型在构建电商平台的过程中会遇到林林总总的问题，有些问题属于产品需求范畴，有些问题已经超出了产品范畴。不过从落地的角度考量，产品经理对这些问题需要有一定程度的了解和思考，这也能从侧面推动问题的快速解决。此外，产品经理在整体发展方向上也需要有一个自我认识，这样才能不断地成长。下面聊一下这些有关于产品经理的日常“生活”。
关于需求变更在需求研发过程中，由于业务形态、时间进度等因素的变化，产品需求也会出现需求调整修改的情况。而需求的变更势必会影响当前系统的架构、进度甚至逻辑，由此产生的一连串反应总是会让人头疼不已。产品经理日常最常见的场景就是：在上线前一天业务人员询问是否可以增加一个简单的功能，描述完后还说希望尽量不要延期。面对这样的需求变更，我们应该如何去看待呢？在开发过程中我们应该如何去预防、监控和处理可能发生的需求变更呢？下面我们来聊一聊这个话题。首先我们来看一看需求变更这个事情到底产生了什么样的变化。我们知道，每一个需求的开发、上线过程都要经历若干个环节，无论是瀑布式开发还是敏捷开发，在过程中都会有一些核心结构是需要稳定的。有几个要素决定了系统的上线周期和质量，即需求范围、逻辑点和资源等，它们的关系是互相依存而又互相制约，
如图8-1所示。
●需求范围：指的是当前项目或者迭代中需求的边界，需求范围决定了当前项目或者迭代的体量。
●逻辑点：这里说的逻辑点不是单纯的需求个数，而是将需求分解完毕后本次项项目或者迭代需要变更的逻辑内容；由于需求的逻辑复杂度不同，因此不同难度的逻辑点最终都会转化成资源占有情况，作为一般等价物进行衡量，也就是我们俗称的“人天数”。
●资源：这里指的不仅仅是人力资源，还包括流量资源、硬件资源和跨部门配合度等，一切项目需要的外部支撑都属于资源的范畴。因此我们可以看到，需求开发的过程本质就是将当前需求范围内的需求逻辑点按照一定比例转化为资源占有情况，并根据当前的资源情况确定可以匹配的数量，这也就是我们常说的项目排期或者迭代排期。说完了需求开发的本质，接下来我们看看需求变更到底动了哪块奶酪。需求变更通常有几个来源：业务方、产品自身和开发等。业务方的变更是最为常见的，这源于瞬息万变的业务情况以及业务人员不同的处理流程。业务方的需求变更往往是由于前期思考时间过短或者过长。当然由于业务变化出现临时增加需求的情况也是有的。我们知道，所有的研发周期原则上都会落后于业务的发展速度，在业务项目周期内，需求开始时间点的统计口径，产研方与业务方是完全不同的。
假设一个项目业务方开始立项，按照以往经验来看预计需要15天。但由于业务前期构想较为简单，在详细沟通细节后发现需要明确的逻辑点较多，真正需求确认后开始研发的时间可能已经到第7天了。这样，从产研的角度来看，项目真正开始的时间是第7天，而这一天距离业务领导立项已经过去了一半时间。这种时间偏差往往造成排期后无法按时完成全部逻辑点，需要根据情况进行删减，删减的同时也可能对需求产生影响进而调整需求逻辑。这种情况就是资源不变的前提下对需求范围和逻辑点进行调整。而临时增加需求也属于这种情况，不同的是需求范围和逻辑点是增加而不是减少。另外一种情况是在业务立项后，经过简短的沟通，立刻准备需求研发，虽然在时间上偏差不多，但由于前期沟通不够，导致过程中出现逻辑质量差、问题多的情况，这同样会造成排期变更。这时候只能通过简化逻辑或者增加资源的方式来保证按时交付。这种情况是在需求范围不变的情况下调整逻辑点和资源。产品的自身情况和业务方的情况相反，由于在前期沟通的过程中对需求的理解不够透彻，导致产品设计上出现逻辑问题，继而产生需求的调整和变化，它也属于资源不变的前提下对需求范围和逻辑点进行调整。
网站建设公司在开发发起的需求变更更多来自于技术需求，比如一些技术架构的调整等。由于技术结构不支持，需要对结构进行调整来满足需求实现。综上所述，需求变更的特征就是三要素最少会出现两种以上的变化，继而影响到第3种要素。而造成需求变更的原因主要是信息理解不一致和思考不全。针对这些，我们需要分两步处理：预防和解决。预防主要从两个节点入手，之前大概讲过项目管理的流程节点。在需求确定前需要和业务方确定需求内容，PRD与业务方完成逻辑点的核对。在这个节点检验的是产品经理将业务语言转化成逻辑语言的质量，而PRD完成后与开发进行需求评审检验的是产品经理将逻辑语言传递给开发以便他们完成代码的表达能力。这两个节点都会导致信息丢失或异常，我们需要在这两个环节明确一些规则或者概念。
首先业务流程必须要有清晰明确的流程流转，即流程图和数据流转图，明确流程后才能确保相关功能是依附于正确流程的产物。如果流程不正确，功能逻辑就无法完成闭环。其次双方一定要对流程中的概念定义达成共识且对其有详细明确的文字说明，比如商品上架的概念是实物仓库上架还是线上系统上架，下单完成是指支付完成还是履约完成。这些看似非常容易理解的概念其实正是容易出现想当然的“意见统一”。很多情况就是大家都以为对方想的跟自己一样而没有明确文字定义，以致产生了后续不必要的麻烦。对于需求的延伸性一定要进行构思和设计，即使本次需求不做。产品经理需要对结构完成构建，使其完整，而这点对于业务来说可能短期内都不一定是关注点。这里说的结构不是指单个的功能，还是如何使业务描述的流程形成完整的闭环。比如在平台搭建初期，可能各个系统都不完善，早期上线的功能中只有订单之前的系统，由于时间原因履约环节不能同时上线，前期的数据传输只能通过线下Excel传递（不要怀疑这种情况的发生，很多时候会比这样还简陋一些）。当我们在设计订单、商品以及用户端的时候，就需要考虑履约环节在实际业务场景下是如何操作的，把相关的信息考虑进去，这样才不会出现上线后因数据缺失而无法导出Excel的情况。所有的产品设计都需要在明确业务流程以后考虑如何完成业务闭环，而不是仅仅思考业务提出的某一个功能点，这样才能有效地预防需求变更的情况。当然，我们不能保证所有的变更都能被遏制在萌芽阶段，当我们遇到变更情况应该如何去处理呢？这里就会涉及一些项目管理的知识。上面讲到变更影响的三要素：需求范围、逻辑点和资源，我们需要做的是把变更影响尽可能控制在最小范围。比如前面提到的第7天开始进行开发，项目周期无法保证所有需求的完成，那么我们原则上尽量只影响一个要素。我们可以按照需求优先级排序，砍掉需求优先级较低的内容，这样就能保证在逻辑点和资源不变的情况下缩小需求范围。通常需求范围的变化是通过优先级来解决，逻辑点的变化是通过简化产品方案来解决，资源的变化是通过协调增加资源来解决。不过具体的执行就需要大家结合实际过程来判断了。好了，
深圳网站建设公司本文关于"关于智能售货机管理PRD与业务方完成逻辑点的核对与实施方案"知识就分享到这里，谢谢关注，博纳网络编辑整理。
