之前在一篇文章中看到说互联网公司给实习生做的是比较不费脑或繁琐的工作，竞品分析和收集用户反馈已经算高级的了。如果这种观点成立的话，那我做的事情应该算是略高级的了，我一般都是进行竞品分析、收集用户反馈，并且给出方案，能被评审通过的方案就采纳执行。
前几天和部门的产品leader一起吃饭，谈论了不少产品相关的话题。他说我对产品的理解是比较到位的，理论知识也比较扎实，但是缺少项目实践经验，说回去让我自己自己考虑一个方案，并且自己负责跟进方案的落实。于是我这个产品新人便有机会自己负责一个小的功能的上线全流程，功能上线后还是很有成就感的，也反思总结了下功能从0到1的全流程，望各位前辈不要见笑。
一.需求调研
需求的来源一般有产品本身、数据分析、竞品、用户反馈、PM自发、来自BOSS这几类，但并不是说所有的需求都要进行满足，首先应该去分析辨别是真的需求还是只是伪需求，是否为刚需，需求频次如何，需求的用户基数有多大。然后也需要结合产品的定位，公司的资源，开发实现的难易程度，优先级，性价比去将合理的需求转化为产品需求。
我们这个产品的需求来源于用户反馈，通过用户反馈的数据发现确实是有此需求，并且根据数据来看需求的人数较多。于是我便又去调研了几个直接竞品(与我们产品的业务模式重叠性较大，目标用户相同)的处理方式，根据分析调研后的数据得出这个需求应该需要满足的结论，于是我针对两种典型的用户采用了两种不同的处理方案，考虑到类型二用户的特殊性，我又将类型二的用户细分为两种方案（暂定为方案a与方案b），方案初步定下来之后我便去找mentor初步评审去了。
二．产品评审
方案评审前一定要自己想清楚方案的细节，以及作出此方案决定的缘由，最好是有数据支撑或者其他支持。切勿拍脑袋下定论，这样评审的时候会死的很难看，别问我怎么知道的。还有在定方案的时候如果牵扯到技术的问题，请提前找技术确认，提前找技术确认，提前找技术确认，不要等方案定下来之后，然后技术说实现不了。Mentor说理论上来讲一般的需求都是能够实现的，只是实现成本大小的问题，当然还有和技术的熟识程度。不停的请吃饭、请吃饭、请吃饭，陪加班、陪加班、陪加班就能快速和技术们打成一片了……
方案一初审就通过了，没有什么问题，Mentor关于方案二的两种情况细致的问了几个问题，便问我为什么不采用另外的一种处理方式，我说考虑到可能需要对接API的问题，然后Mentor说这个不需要对接API，碰到这样的技术问题你应该去找技术确认。我说知道了，便回去重新修改了一下方案二中的两个方案。Mentor确认之后让我就方案二中的a方案和b方案去找技术评审确认下采用哪种方案。
三．技术评审
最开始我是在RTX和技术Leader沟通的，Mentor问我打算什么时候和技术沟通的时候，我说正在沟通啊，然后Mentor告诉我这种复杂的问题应该是提前和技术预约好时间段，进行当面沟通，在评审前做好准备工作，尽可能的将需要问到的问题提前列举出来，提升沟通的效率，在沟通完成之后需要就会议内容进行整理总结。
于是我在整理好方案，并做好准备工作之后便提前和技术Leader预约了个时间点，我把需求和方案拿给他的时候，他说:“方案一没什么问题，方案二需要改动的东西太多，实现不了”。我的内心几乎是崩溃的，于是我就和他说需求已经定下来了，一定需要做。技术Leader确认后问到“已经确定要做了是吧？”我说“是的。”
然后我们就方案a和方案b进行了讨论，技术Leader问了好多边界问题，有的我考虑到了，有的边界问题我根本没有想到。虽然我被虐的惨无人道，还是要说技术的思维严谨程度真是太赞了。最后得出的结论是方案a要优于方案b，但是…还是采用方案b吧。我问技术Leader“以后应该还是要使用方案a的啊”，技术Leader说“方案a是比较合理的，估计以后也会使用方案a的。但是方案a需要改动的东西太多了，就先采用方案b吧。”我说“那以后需要用到方案a的时候怎么办？”技术Leader说“那到时候再改吧。”我……
然后就决定采用方案b了，后来我默默地去问技术的同事“你们是不是通常都是这么处理？”技术说“对啊对啊，都是哪种实现方式最容易，改动最小就使用哪种方式。”我说“那就是不停的改改改么？”得到技术肯定的回答之后，我就问“那以后牵扯到很大的改动的时候岂不是就要整个架构重构了？”他沉默了……
四．产出原型图
对于已经确定的方案，可以在产出原型图的时候把一部分的工作就交由技术开始并发执行，比如需要接口啊，技术需要看一下之前的代码啊，先考虑采用哪种实现方式，出现问题及时沟通，不要等到所有的方案都定下来之后才去找技术人员。
在产出原型的时候需要将边界问题、默认值、极限值这些东西想清楚，确定用户的主要使用流程、支线流程、异常流程，以及异常情况的处理方式，提示语、操作反馈等。同时还应该注意操作的前置条件，是否涉及账号、权限问题，在操作成功之后的情况又是什么样子的，有无进行数据上报的需要，这些都是需要自己想清楚的。这里面有很多坑虽然自己现在并不能够都考虑到，但是也会尽可能的去考虑的全面一点。
五．勾搭UI
Mentor要求功能要在四天之内上线，留两天的时间给技术人员进行开发，所以在进行项目之前，我绘制了一个小型的甘特图，方便自己跟进项目，后来发现那只是理想的状况，事实是遇到了很多问题。方案推倒重来花了半天，技术Leader根本没时间，约个时间评审就等了两个多小时，导致最后视觉稿只能延迟到第三天。然后快下班的时候惊悉UI妹纸明天请假了，所以我就在临近下班的最后去找的UI帮忙产出视觉稿。
在UI妹纸很是嫌弃的目光中，我把线框图交给她了，UI妹纸很是幽怨的说道“哪有你这样的啊，快下班了才来提需求的，啊？”我说“本来是打算明天请你出视觉稿的，不是刚刚才知道你明天不上班么。”还好之前部门聚餐的时候发现UI妹纸是属于典型的吃货，就说回头请她吃饭，UI妹纸立刻两眼放光的回道“好啊好啊”，于是有惊无险的产出了视觉稿。产出视觉稿之后，我又将方案完善了一下，然后去找技术Leader预约资源，技术Leader给我分配了个技术人员，准备第二天开发。
六．研发测试
研发并没有什么问题，整个流程中技术就和我确认了几个具体的问题，其他都正常进行，技术花了接近两天的时间实现了功能。功能研发完成之后，就发到测试环境了，我测试了两个小时之后发现没有什么问题，就让技术把新功能上线了。
虽然说只是上线一个小功能，但也算是自己第一次独立负责的一个功能的全流程，功能上线之后还是感觉略有成就感的，感谢队友们，虽然目前我可能还会有点坑，但是我也会继续努力快速成长的。
回过头来总结一下这个功能上线的全过程，顺便也将自己踩过的坑和经验心得汇总一下，希望能够帮助到像我一样的新人。
心得之一：一定要采用技术和UI常用的方式进行交流，用他们的语言说话；
心得之二：下结论的时候一定要想清楚，有哪些论据可以支撑你的结论；
心得之三：说服别人时用调研得到的数据说话，争取做到有理有据，事实说话，不要掺杂过多的主观因素；
心得之四：自信，做完了相关的准备工作之后，说话一定要有自信，如果说你自己都不能相信你自己的Idea,你怎么能够去把你的Idea推销给别人呢？
心得之五：讨论之前先界定问题的边界，确定你们讨论的是同一个话题，定义的是同一个内容。Mentor关于某一个问题在RTX上和我讨论了近5分钟，他一直捉急我没有get到他要表达的点，我一直捉急我本就就是使用他说的那种方式，没有改动的必要。后来我们面谈的时候，我才发现他错把我们产品正在使用的样式当成了我的Demo。
心得之六：可并行执行的事项就并行执行，由于时间有限，所以需要提前合理的安排好，将能够同时进行的工作同时展开。
心得之七：优先级，做事一定要分优先级，可按照重要程度与紧急程度来进行划分，先做重要紧急的事，最后做不重要不紧急的事情。先做重要的事情，酌情处理紧急的事情，不然很可能会一直疲于奔命于紧急不重要的事情。
心得之八：性价比，做事需要考虑投入产出比，优先做性价比高的事情，减少做性价比不高的事情，甚至根本就不去做性价比低的事情。
以上就是产品新人第一次负责一个新功能上线的全部流程，希望能够对你有哪怕一点点的帮助，也希望广大前辈们不要见笑，人艰不拆啦……
