前言：就如之前一篇《如何让研发跟着你temp走》所说，本人作为一个刚入门的产品，参加了某个项目的封闭式开发；在整个过程也“有幸”接到了运营后台和web两条产品线。虽然也是天天加班，但是收获不少、激情不减。就在今天的3月1日，封闭式开发结束了，借着新版本的顺利发布激动的心情写些感受吧。PS：终于结束加班了，想想还真有点不舍
对于一个产品新人来说，能自己亲手将一个产品从0到1发展起来是多么难得和幸运的事情。这种锻炼的机会会使人在短时间内迅速成长，学到很多技巧和能力，并且会碰到大量的困难并需要你硬着头皮，扛着压力去解决他（想着自己就是张小龙、乔布斯，想着做出来的产品会让用户爽到爆的时候就不会觉得累了）。
废话不多说，就拿我负责的“App运营后台"这条产品线来和大家分享一下这几个月来的感悟。
需求收集：
1.首先需要明确的用户定位，考虑好你的产品是为谁服务。对于运营平台来说，运营部的同事是我的用户，我的目的就是为了做出来让他们爽的产品。
2.其次对于不同角色来说，其需求的点都是不一样的。例如内容运营、平台运营、推广运营、活动运营、商家运营等等等等角色需要你一一收集需求。
3.在收集需求的过程中，最重要的是不要让其跑偏，引导他们提出他们运营过程中的需求（在此之前你必须要站在用户的角度，了解并且梳理不同角色运营中的流程，并且能够通过此流程来引导他们）。如果你也跟着天马行空，那么 你就输了！
4.再通过自身对于运营用户的了解，同业产品数据、之前相关产品的数据分析，站在运营用户的角色角度将一些需求补充起来。
需求分析：
1.拿到那么多散乱的需求，首先我们要理出相关的功能点。不管真伪，先全部理出来，并且将每个需求整理放入到各个流程中，将不在流程中的需求标示出来（并不是这个需求没有必要，而是相对优先级较低）。
2.再用你理顺的功能点与用户进行二次沟通，确保你的功能点是他们需要的，那时候用户也会跟着你的节奏，求真去伪。在这个过程中，本人不仅仅沟通了两次，多次的沟通会让他们能更清晰自己的需求，很多时候用户都不知道自己需要什么，这时候需要我们来引导他们。
3.理清功能点，排出优先级，顺利脑图输出。你以为这个阶段就完事了嘛？错，还有一个关键就是需求的分析不是阶段性的，在实际过程中你需要不断的分析这些需求，是贯穿全场的打野型选手。
原型设计：
这个部分就是考验各位产品人将各个需求，流程图转化为具象化的直观的原型图，是与研发沟通的利器。我认为在此过程中应该注意以下几点：
1.原型图为线框图，并将整个流程展示出来这样最好。为什么这么说呢，首先线框图已经可以清晰的展现出你所想就够了，不许要太多精力在高保真原型上，原型展示的是你的思路而不是你的技术（比你技术高的人太多了！）。其次高保真会对UI设计带来一种先入为主的感觉，无法全力发挥自身的艺术美感。
2.若时间赶得紧，我建议将用例图，流程图和业务规则在原型图上进行标注。不仅减少写文档的时间，并且让开发人员一目了然（当然PRD是必须的，若时间宽裕，PRD文档是很有必要性的，尤其是平台类产品）。
3.用原型与开发沟通：这是个关键而且很重要的过程（本人在此过程吃了太多的亏，痛定思痛地分析一下几点）！
首先原型、PRD是要不断和模型、服务、前端进行不断沟通。需要沟通的优先级从高到低为 服务>模型>前端；其次原型、PRD中的规则要写全，模型字段要对上，方便开发进行理解；当然在此过程中要有自己的立场，不要完全妥协，但必须有理有据。
其中有个小技巧：如果这个需求的优先级没那么高，倒是可以用这个来缓减和研发的纠纷，让他们知道，我们也是会考虑他们滴；
跟踪开发，保证产品顺利上线：
1.不断进行的沟通，解答他们在开发过程中遇到的逻辑问题。在此过程中，千千万万需要自己清晰的思路来进行沟通，不然他们会觉得你都没想清楚，还要我们来做。
2.不定时进行产品验证，有的时候，程序员是需要鞭策的。
3.大家都是为了同一个目标奋斗，有分歧时正常的，说明产品正在往好的方向进行。坚决杜绝任何为了自己偷懒而撕逼的程序员；
上线跟踪：
现阶段只能拿之前老产品来说分享了：
1.数据是很重要的，对数据的敏感度是很重要的。例如：通过一天某个数据（不好透露），之后尽然是发现风险控制体系漏洞的一个起点（真实经历过）
2.不断对用户进行访谈，调研。你会得到很多你意想不到的东西，并且在之后的产品设计分析过程中很有帮助。
我作为一个刚入门的产品汪，说的东西可能正确可能不对，在之后成长过程中回头看看可能自己都觉得可笑，但谁都要经历的呢，所以尽情的拍吧，让我看到更多的想法和更多的理解，那么写这篇文章的我，就赢了！
这两个月也这么快就过去了，感觉获得的还远远不够，说明自己在产品路上还有很久很久啊，图样图森破啊！
网友评论