一个项目带你走进产品经理的世界（6）：设计确认

上一篇我们围绕「产品的第一个版本」展开分析，接下来，我们继续来看下设计确认的过程。

设计确认

首先我们来看下「设计确认」的含义。

「设计确认」包括原型确认和 UI 确认两大步，这是研发和测试可以开始工作的前提。也就是说，原型和 UI 确认了，研发团队才能干活。

那产品经理和 UI 确认图的时候，研发在干什么呢？划水吗？

一般来说，「设计确认」提前一两个开发周期完成，以确保研发工作不会出现断档。也就是说，研发在做上一个开发周期的功能时，产品经理和 UI 就要开始下一个周期的「设计确认」。

曾经年少的我认为研发出现断档，让大家在一段忙碌期后休息休息也是好事。直到有一天 Leader 和我核算了一下我们部门的成本，研发断档一天的成本是 5k+ （10 个人平均一人一天 500 块），我才开始认真对待这件事情。关注成本可以说是产品经理的必备技能之一，而这也让我对一些事情的看法和之前相比有了明显的不同。

原型确认

「原型确认」就是需要确认原型啦。嗯，这是一句正确的废话。不过，需要说明的是，这里的「原型确认」是产品经理确认的、并经过评审的下一个开发周期的原型。

为什么需要评审？一方面避免产品经理自嗨，另一方面多方评审可以保证整个团队在做最重要的事情。谁来参加评审呢？这个每个公司的要求不一样，一般会有技术、产品、UI 等多方角色参与。

1. 功能打包

对于我们的产品「简报生成器」来说，由于简报的信息源因为实现而导致无法让用户自定义，导致产品的核心和我们之前所理解的有所不同。所以，我们在做下一期的功能列表的时候，需要重新评估，也就是所谓的「功能打包」。

每个开发周期都是需要重新评估功能列表，重新审视之前的「产品规划」，以保证下一个开发周期做最正确的事情。因为在产品开发过程中，我们总会遇到一些问题，从而导致周期调整或者功能调整，甚至在上线后也很难保证所有已知的 Bug 都被解决。而这些遗留问题都需要记录在案，进入功能列表中，以待下个开发周期被选择或被解决。

由于简报信息源的问题，导致「简报生成器」的功能更偏向于简报的信息展示，信息源的添加需要产品经理提需求，程序去实现，才能保证对应信息可以展示。

因此，「简报生成器」下一个阶段最重要的两个功能点是：信息源的添加和信息的展示。而不是我们之前规划的「简报设置」，甚至说「简报设置」这一大类都不复存在了。

这么看起来，「简报生成器」这个产品名字似乎不太合适呢，更准确地叫法应该是「简报」。相应地，产品的定位也会相应随之改变，一个提供简报信息集合的产品。按理说，产品的定位修改后，要重新进行竞品分析什么的，这里我们就暂且略过，可能和之前的文章分析内容不太一样，但是分析的思路和方法是一致的。感兴趣的朋友可以翻看之前的文章。

接下来，我们继续分析：信息源的添加和信息的展示这两部分。

（1）信息源的添加

首先，信息源的添加是不需要画原型图的，只需要产品经理提供信息获取的规则。那对于「简报」来说，首先需要提供如下几类信息：

互联网产品
开发者资讯
创投 | 融资 | IPO
热门问答

我们以「互联网产品」为例，给出具体的信息提取规则。从信息源上来讲，「互联网产品」包括以下几个类型：小程序、产品文章、iOS 应用、Android 应用、Mac OS 应用、Windows 应用。小程序从「知晓程序」获取，需要获取每日最新的小程序名称及说明。如果你是这么写规则的，那么你一定会被挑战。

开发同学：「知晓程序」是个网站吧？我需要全网爬吗？这个工作量有点大哦…

产品经理：当然不是啦，只需要爬取首页的「最新」，谁让你全网爬了。

开发同学：那你不说清楚。另外，我怎么知道什么是「每日最新」？

产品经理：点小程序进去，不是有个「发布时间」吗？它等于「昨天」就是最新的。

开发同学：还要点进去，好吧好吧……那什么是「小程序说明」？

产品经理：就是点进去那个「产品介绍」啊……

开发同学：

上一篇：干货分享：如何更好地使用栅格系统

下一篇：折叠屏设计第二弹：商家移动端体验升级