一个项目的从0到1

对于一个产品新人来说，能独立负责一个项目，是一件可遇而不可求的事情，平常我们做产品基本都是对某一个功能点的优化，涉及到的业务、运营、ued以及开发相对较少，产品功能也比较简单，而做一个项目则不同，今天结合我所做的一个项目和大家分享下。

1.思考产品价值和商业价值

和平时我们对产品模块优化相同的是，做一个项目之初，也要去了解产品价值和商业价值，这个项目能满足用户什么样的需求？用户是否真有这样的需求？对公司能带来什么价值？对产品能带来什么价值？

以我最近做的延保补购项目为例子，这个项目大概意思就是在购买完成商品(3c和电器类)后，用户仍然可以购买保险。满足了用户对商品后续保障的需求（有可能买的时候没注意到，或者没想到），3c和家电类电器一般都要用好多年，但是目前自带的保修时间可能为一到两年，这个一个服务确实满足了用户的需求。从产品角度考虑，完善了产品的功能性，形成了一个从购买到售后再到保险的闭环。一份延保的利润是相当可观的，可以给公司带来直接的经济效益。

2.理清业务逻辑

想明白了以上这些，这个项目就可以确定做了，并且会申报立项；在项目审批期间，最重要的事情就是理清具体的业务逻辑，这个需求随时和业务人员沟通交流，继续以刚才说的延保补购项目为例，需要考虑了解购买完是下订单后，还是商品妥投后，延保可不可以退，如果可以，多久可以退；延保一般有多少种，只是普通的延长保修还是要加上手机类型碎屏保等；这些每一个细节都要了解清楚。

3.产品框架的梳理

接下来就是要考虑做牵扯哪些页面，入口是再哪里，项目中的页面是全新的页面还是有些可以调取现有主站的一些页面；

4.页面原型绘制

确定了哪些页面后，要针对每一个页面去思考每一个字段的逻辑，是否显示，什么时候显示，什么时候不显示，当然这些都是依据产品目标去考量的，这里我的原则是在开发成本较小和满足业务需求的情况下，越简单越好，举个栗子，延保补购涉及到填写订单页面，从业务逻辑来说，其实买延保就是买一张发票，从公司业务角度考虑，可以选择纸质发票和电子发票，那么在填写订单页配送时间、发票信息和支付方式可以去掉很多信息。

支付方式只支持在线支付

配送时间不可选，商品信息一切从简

5.需求讨论&评审

在需求评审前，可以和涉及到的开发，接口等去沟通，产品的想法是否可行，这一个目的是把粗糙的原型做的更细致化，所谓细致化不是指高保真，而是更具有可行性，确保每一个字段都可以时间，包括具体的时间逻辑，展示方式等；在评审的时候更多的是一种告知的方式，叫上涉及到的业务、运营、ued、开发、测试同学一起过一下这个项目，同时告知项目的上线时间，完事后再次需要了解ue、ui、开发和测试的工期。

排期这块如果只是做一个小的模块优化还好说，如果是做一个项目的话，就要考虑到哪些可以先做，哪些必须到了一定阶段才能做，哪些可以同时做，等等。这个只有产品心中必须明白后，才能更好的规划排期，按时间推进项目上线。

---

这次暂且说到这，因为目前刚刚进入开发阶段，后面还得跟进开发、测试、项目验收等，相信还有一系列的坑等着我去跳，等项目上线后，再来填坑。