一个中型产品项目该如何落地？作者结合自身工作经验，与大家谈谈做这个项目的思路以及框架，希望对你有所帮助。

7月份的文章还没有发，思来想去准备写之前在《聊聊数据中台》中有提到过的数据建模，但由于它的专业性较强，不够接地气，决定还是写一篇自己是如何做一个中型的项目。招聘系统的内部推荐模块是我去年做的一个真实项目，所以很细节的设计图或数据就没办法给大家展示，主要看一下做这个项目的思路以及框架。

(资料图片仅供参考)

一般一个项目的背景可能会有很多原因，如：

1. 市场环境发生改变，用户的习惯（需求）发生改变。

2. 新技术的出现，打破原有的局限，使得降本增效更加明显。

3. 来自竞争对手的压力，需要提升产品在市场中的竞争力

4. 商业版图拓展，让外部看起来很牛逼，吸引到更多的资源。

问题来源于背景，目标是用来度量问题是否被解决。而价值则是目标完成后赋予的意义。

在早些时候，企业或政府招兵买马，依托的是员工身边的亲戚朋友介绍，给介绍人一点好处，但这种方式受限于一个人的亲朋好友的数量。在如今数字化时代，各种社交工具的诞生，极大地扩宽我们人脉关系，并且提升信息传播的效率，企业需要一个数字化工具来管理和运营内部员工推荐的这一渠道。

（1）定义问题

假设我们做内部推荐这个项目的背景是1和3，你得到的问题一：市场需要，客户有诉求，如何解决客户这一诉求？

问题二：和你切分同一块蛋糕的竞争对手有这一渠道而你没有，导致在客户选择上更倾向于你的竞争对手，如何解决这个问题？

你觉得以上两个问题，是真实的问题吗？就可以开始去做了嘛？不是的，你可能还要去验证问题的真伪。

问题一市场有需求，客户有需要，市场的需求量有多大？80%的企业都需要？客户的诉求有多强烈？没有就不用或不买？

问题二一般是销售或者老板那边反馈过来的，那你就要问有多少客户有这一诉求？是否全部因为这一渠道没有丢了单子？竞争对手做到什么程度？

搞清以上问题才是决定做与不做，在企业不同的阶段的针对上述问题或诉求的处理方式不一样，所以并不是所有的项目或者问题都要立马去做去解决。

（2）目标

假设你已经做了充分的市场调研和竞品分析，以及评估目前公司所处阶段是有余力去做这件事，那么问题一和问题二其实都是指向同一个目标，就是你们得有内部推荐这么一个渠道。

那么目标二应该是做了这个渠道工具之后，会有多少客户愿意使用（付费）或者说能带来多少的新增客户？

目标三：内推这一渠道的增加，可以给招聘提效多少（岗位招聘周期缩短多少）？招聘质量提升多少（简历通过率、面试通过率、员工转正率等）？

（3）价值

问题和目标清晰之后，价值也会变得更加清晰。

从客户侧：帮助客户解决公司的人力资源业务问题，拓展内部推荐渠道，使得招聘的效率和质量都得到很大的提升。

公司侧：降低外部压力，获客增多，营收增加。

核心场景的梳理可通过调研客户的业务场景和流程，将客户业务场景通过泳道图表达出来，使得对整个需求场景有一个更全面的理解。

（1）角色

内部内推涉及的角色有哪些？候选人、员工、HR、HR管理者，首先要分析这个产品会有哪些角色参与？他们的分工是怎样的？上下游的流转是怎么样的？有哪些前置条件？和其他功能模块的关系是怎样的？

（2）核心场景

1. HR在职位发布/管理的时候可以设置哪些职位是属于内推职位以及创建内推项目的时候可选择哪些职位进入这次的内推项目中来。

2. HR可以进行多个内推项目的创建，适用于分公司或不同的时期。不同部门或不同岗位可独立配置职位的奖励规则。

3. 内推活动创建后，可在哪些地方展示？可通过哪些方式分享出去？哪些人可以分享？通过什么方式知道投递的候选人是某个员工分享职位带来的？

4. 内推投递的候选人在哪些地方查看？候选人是否可以查看自己被内推的进度？员工在哪里查看自己内推的人选进度和状态，以及奖励情况？

5. 内推的效果如何？内推职位和非内推职位的招聘周期是否有变化？内推的成本如何？内推奖励如何发放？不同职位和不同部门员工的内推情况如何？

（1）商业模式

B端产品的商业模式主要分为两种：一种是按账号收费的订阅模式；一种是买断制的私有模式；

订阅模式一般也就是我们常说的“SaaS模式”，可以按照不同功能或同一功能的不同限制包装成一个个套餐进行售卖，也有按照不同模块功能包进行售卖（对于一些企业用不到该功能包可以降低他们的成本），直接买断的客户很少。

回到内部推荐这个项目，如果是你来负责，你会如何思考它的商业模式？商业模式的设计直接关系到最终这个项目能否为公司带来价值，间接关系到你的结果。

（2）运营策略

B端的运营策略和C端大同小异：活动运营、客户（用户）运营、产品运营。

内部推荐这个项目主要是从产品上如何进行运营？

1. 产品设计上

a. 功能上线后在菜单入口增加一个“New”小图标，吸引用户点击，让用户更快发现新功能。

b. 增加指引或新手任务，让用户可以更快上手使用，降低学习成本。

c. 内部推荐是需要员工将职位分享出去的，那么就可以在分享的“海报和链接”页面底部增加“Power by XXX”字样，相当于在给公司打广告。

d. 生成季度或者年度的员工内推报告，如这一年你推荐多少人，有多少人入职，为公司节省多少招聘成本等等，总的就是设计让员工有分享欲的数据。分享的海报带上公司的品牌“Power by XXX”。

2. 渠道运营：公众号、官微、官网、系统公告的关于内部推荐的介绍等等。

（1）产品规划

产品规划一般是在确定要做的情况下，并且已经确定大概的产品方向，分步进行到达目标就需要对产品进行规划，规划每一个版本要做哪些事情。

还是以内部推荐为例，之前有提到内推是企业的一个非常重要的招聘渠道，不仅仅是内部员工的推荐，如果说希望能够更快的招聘到候选人，还需要外部的推荐，那么这个时候社交化招聘就诞生了。所以在进行内部推荐规划的时候，可以根据推荐角色的不同分为：内推+外推，一阶段先满足企业内部员工的推荐，第二阶段再去做外部推荐。因为外部推荐涉及到权限、多重分享、奖金分配计算、提现等等复杂业务场景，也是相对难度更大的一件事。

回到内部推荐，又可以根据业务流程拆分为：配置——分享/推荐——入库——查看/统计——奖励发放，从配置到入库已经是一个最小闭环，也就是我们通常说到的MVP版本。

所以总结下来产品规划要做的事情就是从产品的全局角度，对产品大致方向进行近中长期的规划。关于MVP版本的规划可根据业务流程的最小闭环和满足kano模型中基本型需求，进行校验。

（2）产品架构

产品架构是对现阶段产品上下游关系的解构，包含详细的产品功能，可以帮助我们更好的理解产品之间的关系，了解产品大致的功能内容。

如内部推荐，他上游对接的职位管理、员工组织模块，下游对接的候选人管理、数据分析、招聘官网、薪酬等等。以及内部推荐自身又需要拆分出来几个大的子功能模块，如内推设置、C端展示/分享/查看、数据统计等。

（3）用户故事

用户故事是基于用户真实场景遇到的问题，希望得到的解决方案，目的是一方面帮助产品研发团队更好的理解用户需求和业务，另一方面也可以根据用户故事进行优先级的判断，确定高优先级的需求，从而在最短时间内完成最小可行性产品。

用户故事一般可从4个方面进行撰写：用户角色（ WHO）、遇到了什么问题（WHY）、希望怎么解决（WHAT）、优先级。例如：

（4）原型设计

根据前面的业务流程梳理、产品架构、用户故事，我们脑子里面对这个产品已经越来越清晰了，接下来就是把脑子里面的画面用图进行展示出来。

原型设计需要我们平时对一些优秀的交互、组件有一定的积累，设计起来会非常快。并且B端的页面相对都非常的固定（表单配置、列表展示、按钮弹窗等），重要的是我们对于用户需求的理解，重要和非重要的信息如何放置，这个操作是否高频，我们希望引导用户如何操作、新用户和老用户是否有差异、操作有没有异常情况并如何处理等等。

这里举一个内部推荐的交互设计例子，内推的职位其实是拿的职位管理模块中的职位，职位都是有状态的（招聘中、已暂停、已关闭和已删除等），在选择内推职位的时候是不是只展示“招聘中”的职位，需要对选中职位进行C端展示排序（紧急在前面、技术岗位在前面），这个交互就比较复杂（当时我记得和研发争论点在于：在选择职位弹窗中进行排序还是选择完了之后在职位列表页面进行排序？在选择弹窗中进行排序研发成本会比较大，在选择之后在列表中排序整个流程比较冗余），所以产品经理就需要对用户需求理解较深，是否在选择弹窗中就有对职位排序的需求以及概率是多少，从而进行取舍，决定如何做。

异常场景的处理：如果说某个内推职位被关闭了，那内推的职位是不是也要跟着关闭，那这些内推职位是否还要展示和在后台内推职位列表中如何展示，以及分享出去的职位和进入流程中的候选人如何处理等等。

这里还想再补充一点，交互设计直接影响到产品的使用体验，尤其在用户被一些优秀的C端产品教育之后，对于B端产品的用户体验也会有一定的要求，用户口碑很多时候就是用户对于产品使用感受的传播，所以B端产品的用户体验同样重要。

（5）权限设计

权限设计是产品设计非常重要的一部分，关系到数据权限和功能权限，特别是一些敏感数据不该一些人看到，一些重要的操作不该所有人都能操作，被泄露和误操作的影响是非常重大的。

权限设计最熟悉的是RBAC模型，即：用户、角色和权限，简单的理解其理念就是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。RBAC其实是一种分析模型，主要分为：基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。感兴趣可以去了解下它们的区别。

内部推荐涉及到的一些权限，无非就是内推配置的「增、删、改、查」，权限跟着角色走，默认管理员可操作，其他角色的权限由管理员分配。

（6）数据埋点

B端数据埋点的目的主要有两点：一是分析产品功能的使用情况，二是分析业务情况。

分析产品功能使用情况有助于我们了解这个功能上线之后，客户对于该功能的需要程度（用的越多说明越重要，后续做更多的迭代优化）。分析业务需要是客户对于自身业务运转情况的了解，针对性解决业务中的问题（如渠道分析，分析不同渠道的贡献度，资源投入也会向贡献度高的渠道倾斜，以及是否要拓展其他渠道）

内部推荐这里的埋点也分为：功能埋点和业务埋点。功能埋点如“内推使用客户数”，业务埋点内容就有很多，更多的是一些统计分析表如“内推职位招聘周期分析、内推渠道分析、内推员工分析等”。

（1）需求评审

需求评审我觉得没什么好写的，只要按照前面的流程把要做的产品想清楚了，基本不会有什么问题，只说三点建议：

1. 需求评审不要让参加评审的人打断你，可以先告知说有问题先记下来，等你快速讲完再提问，否则非常影响你的节奏。

2. 需求评审中不确定的内容，请在评审之前就解决掉，在评审中大家再探讨很浪费时间，有可能你还需要大改产品方案，这是最难受的。

3. 需求评审中需要研发或者测试注意的点，提前标注好或者记好，专门在会上着重提醒一下，节省后续的沟通成本或犯错成本。

验收和培训项目的验收和培训，各个公司的流程有所差异，也没什么可说的。验收的时候重要的功能和流程多测几遍，上线后再验证一次。根据培训的对象不同，培训的内容侧重点也会有所不同，如果是面对销售和市场部门，要讲清楚产品的价值、亮点/友商差异化以及使用场景。

（2）验证和复盘

项目在上线后，进行数据的观测和复盘是非常有必要的，这可能直接关系到你的晋升。项目复盘的方法有很多，比较常用的STAR原则，即“背景、任务、行动、结果”。我在此基础上增加了一个“plan”，下一步的计划。

SITUATION: 情境，即描述背景，你在当时所处的环境或者面临的挑战。比如你当时要做一个从来没有接触过的项目，公司没有成功的先例可以参考；或者在一次团队合作中与同事出现了意见分歧等等…尽量与工作相关，描述的尽可能详细。

TASK: 任务，指描述你当时的任务，或在当时环境下你所承担的职责。比如你是这个项目的组织者、策划者，需要带领团队探索未知。或者你需要解决与同事之间的分歧，试图说服他听取你的意见等；或者是达成销售目标…

ACTION: 行动，即表述你和你的团队做了什么事情，如何克服挑战。

RESULT: 结果，解释所采取的行动产生了什么结果，对比目标是否有实现，从中学到了什么。

PLAN：计划，讲述下一阶段的计划和可能达成的目标。

总结一下：拿到一个项目，不要直接开始就干，首先搞清楚为什么要做，不做会怎么样，做的价值在哪里，如何验证项目是否做的成功；其次再去思考，看看市场上其他人是怎么做的，不同行业客户的诉求是怎么样的，我们做的话别人为什么会选择我们；最后才是动手去做。在做的过程中要时刻思考用户的真实需求是什么，把用户体验做好，要考虑到异常场景以及权限如何设计。

至此整个《如何落地一个中型项目》全部完结，也是我这几年做产品的一些积累和探索，只是为了完成某个项目和认真的去做某个项目，带来的收益（公司/个人）是完全不一样的，不管项目大小，按照我这个框架去思考，一定会让你收获颇多！希望对大家有所帮助～

本文由 @Glee 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。