做了2年开发，现在找了一份画原型的工作，是的，就是画原型的工作，除了画原型，没有任何分析与统计的工作去做。这是我第一次以产品身份主导一个版本迭代，内容不多，主要是一个小版本的迭代，但是公司只有我一个产品，也没有测试人员，条件有点艰苦，但在这里我想尝试着给自己做一次总结吧。

一. 优化背景

这个产品是一个只针对安卓平台的定制化下载器应用，定制化的意思就是，下载器在打包的时候就会规定好在打开后去下载指定的游戏。不过下载器的界面会和游戏很像，目的是让用户以为这本身就是游戏，只不过是需要进行一些更新包的下载。目前的问题是，应用的下载完成率和安装率都特别的低，所以老板希望我以提高这两个操作的转化率为目的，进行优化。目前的业务流程如下：

尽量让用户愿意等待下载完成并安装，或是增加其他内容吸引用户边下载的同时边在应用内做一些其他事情，不知不觉就下载完成了，只要下载完成了，安装基本也就没什么问题。

二. 需求管理

看过很多资料和文章，目前我认为的工作流程如下：收集反馈–>统计分析现有数据–>挖掘用户需求–>制定产品需求–>梳理需求–>产品原型设计–>产品迭代–>产品运营，也就是回到第一步。由于此次涉及内容不多，而且公司本身除了有一个比较简陋的数据统计平台，没有任何能用得上的资源了，所以我把工作流程分为了如下步骤：统计数据–>体验产品（顺便测试）并记录现象–>结合现有数据分析问题–>针对问题制定需求–>原型设计。以下是我们下载器的一些转化率数据：

先解释下这三个名词：

1. 下载率：下载功能的执行次数 / 应用的启动次数 ，就是说启动应用的人中，有多少人会去进行下载。
2. 下载完成率： 下载完成人数 / 下载功能的执行次数，就是说进行下载的人中，有多少人会等待下载完成。可能很多人不愿意等待而中止了下载。
3. 安装率：安装成功人数 / 下载完成人数，就是说下载完成的人中，又会有多少人进行安装。

可以从统计数据中看出，我们的下载完成的转化率和安装成功的转化率都比较低，那么我接下来就先想到做一件事：确认数据的合法性。我找到了我们的开发人员，向他验证了每一处数据统计的位置，最后确认数据还算合法，可以作为之后工作的依据。接下来我开始进行产品体验（顺便测试），在进行产品体验（顺便测试）的过程中，主要去思考用户的哪些行为可能会对数据造成影响，以及产品本身是不是存在bug影响了数据的统计，举例说明下：

1. 用户只是不小心点错启动了应用，那么用户可能会立即杀进程退出，那么此时就损失了下载率。
2. 用户在没有连接wifi的情况下启动了应用，此时应用不会进行下载，此时也会损失下载率。
3. 用户在等待下载完成的过程中没有其他事可以做，而下载过程又比较漫长，导致用户放弃，此时就损失了下载完成率。
4. 用户在下载时切换到其他应用了，导致我们的应用没有正常运行，这可能是程序本身存在问题，那么此时就可能导致下载完成率和安装率损失。

以上只是思考与实践得出的结果中的其中几项，那么我现在就已经分析出问题了，下面就要针对这些问题来制定需求了。我把需求分为两类，一类是针对发现的问题所制定的解决方案，另一类是扩展一些其他需求吸引用户，侧面提高转化率。例如，用户在等待下载完成的过程中比较漫长枯燥，那么我们可以增加一些新的模块在此，让用户有事可做。以下是最终制定出的需求表

到此，需求就最终确定好了。

产品设计

在需求确定后，我通过绘制业务流程图，思维导图帮助自己梳理逻辑，然后进行原型的设计。新的业务流程如下：

在下载中步骤增加了两条分支，目的降低用户在下载等待过程中的枯燥感，让用户有事可做。

产品开发与跟进

原型设计稿完成并整理好后，先将原型交给开发，UI设计人员让他们先对这次的迭代进行了解（公司没有测试…）。之后聚集他们进行了一次会议，对大家的疑问进行说明，对建议进行收集讨论并调整原型，之后再输出一版最终的原型设计稿交给开发与UI设计人员。

至此，产品进入了开发阶段。因为我是第一次主导产品的迭代，对于进度的跟进还有点生涩，而且我自己之前做过开发，不太喜欢总是被询问进度达到什么程度，所以在跟进的工作上，我是保持一周2次的频率与开发人员碰进度，一版选择在下班之前的半个小时，然后周五一定要碰一次进度，然后进行一周的小结。因为之后会有两天的休息日，为了避免下周上班会遗忘事情，所以我选择了这种做法。

在整个开发周期中，我需要对开发和UI设计提出的各种问题与反馈进行积极的沟通，先跟进UI设计的设计进度，再跟进开发进度，并不断协调各职能人员间的工作，并控制开发能按预期完成。最后我还要充当测试人员，对产品进行测试。

产品收尾

因为我们是定制化的产品，也不通过正常的应用市场发布，我们只需打包一个应用出来提供给领导。这时我需要根据当前下载的游戏，与UI设计沟通，让他设计一些图片素材给到开发，协助开发完成打包。之后领导拿着打包出来的应用用他自己的渠道去验证此次迭代的效果。

总结

这是我第一次作为产品的身份主导一个版本迭代，因为之前有过两年产品研发经验，完整的流程还是比较了解，所以我觉得工作起来还是有一定逻辑。在需求讨论过程中，原型讨论过程中，以及在协调各职能人员的沟通过程中都让我在不断优化自己的做事方式，对整个流程中遇到的问题也能让我及时反思并提升自己的工作能力。

最后，我觉得最关键的还是我需要告诉自己去用一个产品的思维去看待问题，而不再是以一个开发的思维去看待问题，这样我才能在产品的路上走的更远吧。

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

题图来自 Pixabay，基于 CC0 协议