编辑导语：上个月小白刚刚完成了人生中第一个0-1中台产品的搭建，历时4个月。期间也遇到了大大小小、各种各样的问题。那现在就来分享下遇到的问题和对应的解决方案。

需求的来源与处理

作为中台产品经理，经常收到各个部门的需求，那么这些需求都要产品满足吗？满足的形式都要和他们说的一模一样吗？

答案是：都不全是。

产品是否满足用户的需求，一般出现上述问题的原因有两种：

当前产品不能满足用户的使用。

用户有新的想法想要落地到产品中。

对于一个B端中台产品，用户一般是公司的内部人员，一个产品多个部门使用，系统功能复杂。产生第一种情况的原因很有可能是用户不会使用系统产品的某些功能而无法达到他们的预期，而不是产品本身不能满足他们的需求。作为产品经理的我们，需要思考：是不是我们没有写好产品手册？新手引导的功能是不是还不完善？用户对系统产品的工作是不是太过复杂？

这些问题其实相对比较好解决：

分功能模块去绘制产品手册，在用户需要的时候添加冒泡提示或跳转到产品手册的相关内容上，帮助用户及时理解产品的功能和专有名词。

使用真小白的思维去思考，构建新手引导功能。B端的产品大多数是流水线呈瀑布流式操作，新手引导就是帮助用户熟悉这一流程的途径。在新手引导进行时还要注意表明一些功能入口的位置，需要告诉用户某些功能是需要展开、点击、跳转才能使用的。

在完善产品手册和新手引导后，我们可以对系统的功能参照用户习惯进行布局的分析，某些系统流程和功能时用户常用的，可以考虑抽象出一个完成的功能模块，或者对某些功能在直观的页面上就能操作，而无需深层次跳转。

如果确定用户提出的需求时目前系统功能无法满足的，那要解决第二个问题：当用户有新想法时，怎么落地到产品你中。在开始做这个需求之前，首先要考虑这个需求到底要不要做。作为产品我们要有辨别这些需求的能力，区分真伪需求。

伪需求：并不是真实的用户诉求，只是根据心情提出的需求，如颜色、位置等问题。还有可能这个需求本身和使用的系统定位不符合，或者这个需求系统无法实现。

真需求：用户的真实诉求，往往是用户的痛点，这些需求都是需要系统提供的，且这项提供的功能能保证用户长期的使用，而不是不确定的功能，用两天就舍弃了。

在从收集到的需求辨别真伪后，对应某一些完全不招边界的伪需求可直接摒弃，而剩下的伪需求需要产品挖掘出用户真正的需求，从而进行后续的实施流程。

提取出真需求后，做法要按照用户说的做吗？

答案也是：不全是。用户的需求往往只表示了操作系统后想要达到的效果，但是怎么达到，产品的操作流程、页面交互，却是需要产品经理来系统解决方案的，将抽象的需求具体到产品上去落地，也是产品经理额为重要的一项基础技能。在不破坏原有的系统上，用最简单的流程、最舒服的操作模式完成新的需求，这要求我们对产品系统的架构、数据间的关系及结构完全熟悉才可以。一个中后台需求的落地是需要好好思考的。

项目进度与人员调配

当我们确定哪些需求确定要做后，问题就变成了：什么时候做这些需求？那个需求先做？什么时候正式上线?这个是时候我们就要对项目时间周期、需求优先级、人员分配有良好的把控。

首先我们要对我们项目有个大体的时间周期，几周一个大版本发布，几天一个小版本上线，大版本上线功能模块，小版本修复优化功能等等，都要在项目最开始的时候策划好，这样会让我们的产品有更好的调性。非必要时刻周期的步调不要调整（如紧急修复上线），这样既保证了在整个产品的落地过程中的开发节奏，又可以对下一个或多个版本有清晰的规划。

小白用过的免费项目管理工具有：禅道，Trello，Teambition，excel等。实话是各有千秋。对于线性串行工作，推荐使用禅道，项目的各个节点都能通过禅道清晰的看到。对于并行开发且人员调度比较大的项目来说，推荐使用Trello，Teambition。小白个人觉得Trello要好于Teambition。二者提供的任务看板功能，能清晰的开到产品上线各个阶段的任务及人员分配和结束时间。但是这些第三方工具都是针对时间点进行把控的，如果要对任务的过程有清晰的把控，那就用excel做个甘特图吧，用不同色块标识项目延迟，预期，和正式所用时间等。

工具只是方便我们进行项目的管理的辅佐，真正的项目排期、人员调度还需我们自己派兵布阵。如何进行项目的排期？这里可以使用四象限法则进行评估。一般情况下可分为3~4个优先级进行，优先级越高，重要紧急程度越高。不建议级别划分太多的原因是：优先级越低的需求，可能排期的时间越往后，且一直都会有其他更紧急的需求穿插上来，导致优先级低的需求极有可能被无限期的搁置。对于中台产品来说，一般汇聚了各个部门的需求，虽然所每个部门提出来的需求可能都是重要紧急的，但出于人员资源考虑，需要提前协调各个部门负责人，让其内部评审得出最紧急的需求，之后联合协调评审，给出时间安排。

作为产品，我们还要有定期清理需求的习惯，需求池的东西不是提上去就不管了，还要定时管理。有些需求已通过其他需求的某些功能可以满足，那就可以直接清理掉这些需求。有些需求由于业务变动，也不需要了，也可以清理掉。在工作不饱和的情况下，就可以把这些需求池中的需求一一实实现，既保证了产品优化，有让人员有事情做。（注：需求池中的内容在于quality，不在于quantity）

在工作过程中，也可能遇到这样的情况：哪个部门leader厉害，就先完成哪个部门的需求，作为中台，一定要杜绝这样的现象，中台产品面前，除非前线产品/运营有非常紧急的需求需要中台支撑，那么其他一律平等。而且，作为中台产品，一定要有动用所有可利用资源的能力，打破常规的上下级边界，进行资源的调配。中台是连接，断了了哪里都不行。

写好文档是保命

一个公司是否规范化工作，取决于它各个部分的文档是否规范。文档在项目前，项目中，项目后都有着不可代替的地位。

项目前期准备：如果有个想法想和老板谈，那就用BDP（商业需求文档Business Requirement Document）。通过文档告诉老板：为什么要做这事（商业价值）、别人做得怎样（竞争情况）、你打算如何做（商业模式、实施策略）、需要多少资源和钱。当然一个要的BDP文档是基于好MRD （市场需求文档：Market Requirement Document），MRD中主要包括了用户调研、市场调研、竞品分析等。

项目开发过程中：产品经理写的最多的就是PRD（产品需求文档：Product Requirements Document）了。PRD是我们和开发、测试沟通的关键。需求不是靠脑子描述的，细节都是靠文档中的规则实现的。好的PRD是在开发不提出疑问下，把产品的所有功能细节、所有约束情况、跳转流程都能完整清晰的表达出来。开发在仅看文档的情况下就能把需求实现，测试也能通过文档来验证开发的产品是否存在问题。在开发过程中，部分需求的实现可能和我们第一版设计的不符合，和各个环节讨论后，产品需要将最终的解决方案在文档中更新出来，不是覆盖之前，而是后续再做标注。有时，需求中的有些小细节开发很有可能忽略，之后再做产品验收的时候，我们就可以拿出之前的文档和开发一条条过。好的PRD，是产品保护自己，减少和开发冲突的利器。

项目上线前期：对于市面上的B端产品而言，大多数都是流程复杂，功能强大，模块之间可能缺乏连贯性。那么，产品使用手册就是帮助用户快速使用产品的重要手段。好的 产品手册也大大提升了B端产品的产品体验，建议B端产品都配备产品手册，并在手册中最好使用图文的方式介绍产品的使用流程。对于C端产品来说一般不需要配备使用手册，而是提供系统新手引导功能，通过引导帮助用户探索产品，完成产品的闭环。

有效的沟通更高效

有人说：产品经理的一天是从开会中度过。不仅要组织自己部门的人员开需求讨论、需求评审、风险评估、问题汇总、战略讨论会等等；还要参加其他部门的需求收集会。

开会，一定要确定主题，控制时间。一般开会都会有明确的主题，但是随着人员增多，讨论声音的增多，会议的主题开始跑偏，明明这个会为了过需求，硬生生的变成了技术方案讨论大会，这样不仅需求没过完，还硬生生把40分钟的会议拖到了两个小时，占用了无关人员正常工作的时间。 作为开会的组织者，一定要把会议的主题明确，如果有会议主题不相关的问题，可以放到会议纪要中，会后私聊或者再找个时间和相关负责人们集中讨论。对于月报、周报这类型的会议，最好规定每个人的发言时间，不超过多少分钟。这种会一般都是一些量化的指标、节点为主，方便各个项目负责人掌握之前、现在、之后要做的事情、项目进度、各种指标等。

外人眼里，程序员和产品经理是水火不容的，但事实可能并非如此。毕竟产品的需求需要程序员来实现，不搞好关系怎么能行。在和开发沟通的需求会上，开发大多数声音是为什么做这个需求，没必要做这个需求。那么就要求产品在开会前把这做这个需求的目的想好，并在会上用严谨的思维解释清楚，必要时采用数据来做论证。把数据摊开来看，有些问题产品不说开发自己就能提出优化了。产品提出的某些功能，程序员很有可能说该功能太过复杂，或现有的技术不能实现。这也需要产品在前期自己调研下功能点的实现难度，如果该功能需要前沿技术才能实现，就可能需要开发出人力和时间来学习这项技术。如果是该功能过于复杂，在现阶段开发成本是不是可以接受，是不是可把功能拆分，一步步来，最后才是拉上开发进行技术可行性分析。

沟通，更要及时反馈。不是什么事情抛出个问题就可以，终究要解决问题的，若对方没有即使的反馈，产品绝不能坐以待毙，要主动进行沟通。去得到问题的解决方案，如果问题真的无法解决，那就说明原因后再做另一部计划。和上级交流更要有即使的反馈，上级的问题一般会牵扯到多个部门，问题线相对更长，所以更要及时进行跟进。

在沟通的过程中，最棘手的莫过于沟通的不平等。白话是一个人说了一些话，另一个人无法明白或是理解有偏差。这时候需要听着主动把自己理解的程度主动向说着复数一般，看是否达到一致。若对于一个问题来回n次都不一致，那就是双方的思维体系是有冲突的（和人受过的教育方式、知识体系有绝对关系）。这个时候需要其中一位做出及时的改变，转变成对方的思维模式去思考，毕竟目标终究是一致的。若双方都无法妥协，那就再找其他人帮忙，如果都无法妥协，就要思考到底是不是说着根本没有表达清楚。沟通是门艺术，小白认为只能自求多福。

及时做好项目复盘

项目不是一个周期上线了，就大功告成了。一般来说项目在立项或者每个季度都有相应的KPI(Key Performance Indicator：关键绩效指标)或OKR(Objectives and Key Result：目标和关键成果）。当项目结束时，最好在一周的时间内进行复盘，这样能快速的想起我们在这一个项目周期内都做了哪些工作，和之前的KPI和OKR进行对比，看看现实和预期有哪些差异哪些是实现了的，哪些是耽搁或砍掉了的。

通过及时的复盘，还能总结出在做这个项目时哪些功能、逻辑、策略是可取的，可以放到下个版本或者下个产品中。如果有一部分功能或流程做的差强人意，也可通过复盘总结、分析得到问题出现的原因，这样在下一次就能及时止损或者防止问题的发生。

复盘也是自己思考的过程，走过一个项目，给自己带来最多就是成长，在这个项目中，学会了哪项新技能、又精通了哪项技能，自己看问题的角度有没有更开阔，对系统层次的了解有没有更深入，行业知识有没有长进，在脑暴过程中又产生了哪些新的想法。对项目的复盘，更是对自己的复盘。项目中的个人成长不是爆发式的，而是一点一滴的。

勤于思考，善于总结

这是小白导师最开始就传授给小白的话，产品届有个既定的道理：产品思维的高度决定了职业生涯的高度。你的目标在哪里，你的思维高度能不能达到你设想目标，其实并不是我们走到哪想到哪的，在我们踏入产品经理这个岗位前就要进行规划。虽然目标会随着我们自己的高度和实际情况有所改变，但我们自主学习成长的过程是持续不变的。

思考是一个人的。虽然产品经理每天要面临、解决许许多多的问题，但一定要给自己一定量的时间去思考，目标、模式、优化、脑暴、策略等等都可以，但是一定要往正确的方向去思考。如何判定是否正确，可以参照网上或书籍中其他人的历程。比如他人曾经有用到和自己一模一样的方案，在同样的场景下，但是失败了，我们就知道这种方案是有漏洞的。如果其他人用相同的模式取得了成功，我们至少可以验证在一定条件下我们的思考方向是正确的，可以继续朝着这个方向实现。

总结是输出我们思考过程的方法。可以将思考的东西用一些脑图，流程图等形成思维的大纲，赋予文字补充细节，这样才是一个完整的思维闭环。作为产品，要养成时刻记录的习惯，在有大块时间时，可以把碎片的记录进行梳理整理。当完成一个闭环后，会发现这些碎片不仅可以帮我们提高思维模式，增强产品感，更是我们自我突破的入口，让自己达到质的提升。

@小白产品汪，产品壹佰专栏作者。）