从技术转产品已有一段时间了,第一个项目也正常运营了,那么跟大家分享下我这一段时间的转型之路。今年5月公司正好有个新项目启动,作为技术部的唯一女生,我顺利成章的被拉过去做需求,文档出来之后就一直在负责整个产品需求和设计上,只有经历过后,才知道『产品汪』这个称呼不是随便起的,而是有切身体会。 那么谈谈这段时间起早贪黑的到底做了一些什么工作,其实现在回想起来,最多的就是在扯皮,不是在扯皮就是在被扯皮。蓦然回首,人与人的沟通是有多么重要,产品汪的情商要求是有多高。下面就跟大家分享下扯皮的事。 跟技术扯的时候 当测试测出来bug或者验收时发现用户体验不佳的情况下,但技术认为设计如此的时候,那就开始扯了。产品设计原型、效果图、流程图、需求说明书等等都拿出来了,原来发现这种情况,当初设计的时候就没有考虑到。这个时候,我就把针对于这个问题的所有有可能的情况都画出来,立即展开需求变更,放入迭代开发中。不要讲究设计的详细,画个高保真的交互图出来,因为没有这个时间让你去做这个事情;最快的就是画流程图理清楚业务逻辑,把原来的效果截图出来,示意标上需修改的部分。大家都是知道做技术的都是逻辑性很高的一群人,他很快就能明白你想表达什么,并提出他的对问题自己的见解,那么这个淡就扯完了,嘿嘿。 跟其他部门扯的时候 再开上线评审会议的时候,一堆人就开始总结出一大推的问题。总结出来他们说的最多的就是:"我提出来的问题你们还没有给我解决好,又或者什么什么需求你们什么时候弄好…" 被坑多几次后,我总结的教训是:在会议提纲上写明今天的会议内容是什么,而不是在快要安排上线的时候,跟我们扯这些,一句话回拒。这些问题都不是影响系统上线的问题,系统有bug或者需要优化的,已经经过跟各方面沟通,安排好时间。详细见给大家发的邮件,每个问题都有记录,后面都有反馈,那么也算是理清这些淡了,不会影响我们想要达到的目的了。 总结出有效扯淡方法跟大家共享,不要正面跟市场、技术或者其他有关系的有冲突,更不能带情绪工作。是什么问题就什么问题,寻找问题的根源,理清关系,都能找到协调解决问题的方法。不要讲究过多的形式,在做的过程中多沟通,多理解,任何问题都能迎刃而解,就能达到『草木为剑』的境界。产品迭代快,才是我们的目的。 第一次写,跟大家共勉。