学校体系模块产品复盘

背景

自己以前的产品历程基本都是被动的接受需求将产品需求可视化，或者是在已有的功能模块上围绕着用户体验或数据指标做优化，并未有过负责某个模块化功能从需求点到落地上线的经历。去年12月底的某一天，老大突然找到我说明年2月底版本即新学期开学前（一款教育产品）要上线一个新模块功能以提高ugc内容量。从需求提出到最终上线时隔两个月的需求终于上线了，作为该功能的主owner以下是我对该功能的复盘，主要从需求分析到产品设计再到项目推动过程中的思考及采坑，试图从第一视角复现并反思这个新功能前世今生。

需求分析阶段

「time：12.22-12.27」

老大通知要做这个需求时只是提出了这个想法，让我自己先思考两天之后一起和运营同事来一场脑暴。脑暴的内容如下图主要是以学校为维度建立一个类似于线下校学生会的体系，会上大家集中讨论了建立这个体系的目的是什么？这个体系里的成员都有哪些？有哪些阶层？每个阶层对应的行为是什么？我们能给予每个阶层的成员什么？其实在这个会上大家讨论的颗粒度很粗，只是大概描绘了我们想要做个什么样的体系。会后大家又在原有基础上去结合具体的业务去聊颗粒度更细的需求点，紧接着便有了第二次脑暴，如下图这一次大家集中讨论大的功能点有哪些？比如体系内对应的等级身份，这些不同身份享有的不同特权，学校这个体系又是如何运转的等等。

第一次脑暴 第二次脑暴

「time：12.28-1.3」

会上大家天马行空的讨论着，提出自己的想法和观点，两次脑暴会后便由我作为这次需求的主owner去拆解需求分配需求点给到对应的人员并确定每个时间点。如下图体系一期主要是以学校为维度将学生会体系的框架搭起来，主要的功能点是宣传导流、学校主页、任务体系、一系列特权等。带着下面这张图我们产品和运营的相关人员利用晚饭后的时间再对了一遍整体的功能点和各自负责的内容并在会上确定各自需求的产出时间。

需求点拆解

产品设计阶段

「time：1.4-1.18」

确定完分工后便在几天内需要给出第一版设计方案并和产品、运营相关同事讨论设计方案。在落到具体的设计方案上并没有着急去画每个页面的原型图是什么样，还是先从平台和用户两方面出发去思考用户想要什么而平台方可以给到用户什么去拆解对应的需求点再落到具体的功能点上。以下便是该功能的用户角色行为&权利：

角色行为&权利 功能点

当把每个角色的拆解后便开始正式的产品设计产出具体的原型图，但在设计过程中发现虽然功能点上图都罗列出来了，理论上按照需求的优先级去设计具体页面就可以了但在实际产出中想象和结果出入很大。当自己拿着第一版原型图去和产品、运营去讨论时别人会问你为什么会这样设计？为什么没有突出这个功能为什么没有突出那个功能？虽然听了别人的意见我又修改了两版，但大家对具体的设计方案仍然不满意。下班后回到自己的住处我没有再立即想着修改方案，而是思考问题点，最后我才意识到自己并没有真正的从用户的使用场景出发也就是站在用户的视角去设计具体的页面。在第一次讨论后我便试着从用户角度出发去思考用户的使用路径是什么，接下来便有了下面这两张图：

核心模型 用户路径

使用该功能的主要是两类用户，一类是对名利特权感兴趣的普通用户，另一类是已经拥有身份的特权用户。根据这两类用户的使用路径我又重新改了一版设计稿，再次拿着新的设计稿和同事们去讨论。这一次的讨论最终通过了设计方案，是因为这一版的方案里明确了都有哪些页面，页面里的功能有哪些，每个功能这样设计的目的是什么都一目了然。

反思：

设计一个全新的功能和日常优化已有的功能有很大的一个区别点在于，优化功能就是在用户已有的使用场景和需求下暴露出来的问题，不管是通过用户反馈还是数据分析上都能直观体现出来，比如上传完成率很低，那通过去看从入口点击到上传完成各环节的转化率便可以有针对性的去做优化。在设计新功能时你很难以这种思维方式去设计功能，应该是站在宏观和微观两个角度去思考如何设计具体的功能。从宏观上抽象出用户类型、用户间的关系模型、用户使用路径等，站在全局的视角去思考，再将这些抽象出来的模型去指导自己的具体功能设计上，而从微观角度上更应该结合用户的使用场景，用户的需求出发，站在用户的视角去设计功能点。只有从全局和用户两个视角去设计功能才能真正让某个功能完整且合理。

项目跟进阶段

「1.23-2.22」

方案通过内部评审后便进入技术评审，评审后进入设计出图环节。在这一环节遇到了我过往所有项目跟进过程中最大的挑战：与UI设计师出现巨大的分歧（注：项目组暂时没有真正的交互设计师而给这个功能出图的UI设计师以前兼任过交互的工作但又并非交互出身，且设计师本人性格过于执拗和强势）。设计师在出图阶段因不了解需求的背景单方面的从她自己所谓的用户角度、运营视角对设计方案提出质疑并给出自己的方案，一开始给她解释为什么要设计这样的功能时她便拿出自己多年大厂工作经验来压我，而且一直说应该这样设计满足用户哪种哪种需求。当我试图再进一步沟通时她完全表示拒绝沟通而且直言不能说服她就不出图，这种情况下最后只能叫上我老大和设计负责人一起再和她沟通，最终才将UI图设计出来给到开发。

反思：

1.在这次项目经历中真的切身感受到产品经理日常工作中分歧最大的不是总和自己撕逼的开发而是设计师。因为于开发而言只要产品经理的需求文档业务逻辑完整就很少有争执，具体的功能只有能实现和不能实现两种，能实现的只要是排期给够都能做，所以日常沟通中更多的是因为产品经理的需求不明确，逻辑混乱不完整导致的。但与设计沟通中他们总是站在自己的角度去认为该是怎样的。或许正是那句人人都是产品经理火了以后就都认为我可以站在用户角度认为某个功能应该怎么设计而完全忽略了站在全局的角度去设计功能。产品经理设计方案其实是在制定规则，而如果像大多数设计师那样说的从某个用户出发去设计或者只在某个局部点上去思考，最终设计出来的产品是个混乱且臃肿的四不像。（有些偏运营驱动的业务产品也会有类似情况，因为很多运营也都是一味的想把所有功能堆在用户面前，生怕用户不知道不清楚，或者只要有用户反馈就认为该上线某个功能）

2.产品经理要强势且自信，切勿让设计师或者运营带节奏影响你的功能设计。接上面说的，因为设计师的强势甚至有些杠精我做了一些退让，某些功能在出图过程中被设计更改。但在最终上线后发现用户使用中存在问题，只能落到下个版本改回来。所以这又再一次提醒我自己虽然性格好但在工作中特别是在设计方案方面只要自己的需求本身没有问题不管是研发还是设计甚至运营提出异议时都要力排众议站在用户立场上坚持自己的方案。

3.伪代码般的需求文档节省你一般的项目跟进时间。因为这次功能比较大且第一次主导去设计，在写需求文档过程中要考虑各个页面的业务逻辑和交叉逻辑，有些地方存在需求不明确或者逻辑细节漏掉的情况。所以导致开发过程中总是要和不同的研发去明确细节，本来应该留给自己思考或者处理其他事情的时间都浪费在了沟通细节上。当产品经理的需求文档写的足够完整清晰，在后期项目跟进环节将有更多充足时间去思考下个版本的需求而且还有利于提高有效地工作时间。相反开发中的需求文档如果存在很多细节问题，也会伴随着大量的沟通时间。

4.沟通要在合适的时间下才是有用的。上面提到的和设计师的沟通分歧其实很难在出图过程中通过自己去说服别人，因为在她心里当前的我可能做得方案都是错的不合理的。最后只能通过我老大和它的老大去说服她，同样一件事不是我不能把原因说清楚，而是在那个情景下她已经听不进我说的内容，去找她愿意去沟通愿意去听的人效果会更好。项目进入尾声后我单独找了一个合适的时间去和她沟通，介绍我们大的项目背景说明每个功能设计背后的目的。最终和我们设计师还是重新回到了很友好的关系，之后的需求出图环节她遇到分歧点时我们也能很心平气和的去沟通去试图说服对方。

效果回归

「time：2.27-3.6」

功能上线一周后便需要针对功能效果做回归分析。分析本质还是要围绕着功能目的出发通过数据去看是否接近或者达到目的，目前存在的问题是什么，接下来的规划是怎样的。

总结

这一次的学校体系项目像是午后的瓢泼大雨，虽然短暂却深刻的洗涤了我。不管是需求分析、产品设计还是项目跟进环节，于我而言都是一场考验。在这场考验中充分暴露了自己这三方面中的不足，也让我自己深刻认识到需求分析环节要从宏观的全局角度去思考去梳理，对需求的把握要更精准；产品设计中还是要站在用户角度去结合场景设计对应的功能点，绝不是我想让用户使用怎样的功能，走怎样的流程，而是按照用户的真实场景和需求出发；项目跟进环节应该更高效处理并推动项目进程。