初为产品小记

作为一枚入坑不久的产品小汪，有此感想，随手而记；

写在最开始的是初涉职场的一些小记，与产品并无任何关系，初为一个职场人的感想，仅是个人感受，人有差异，入坑较浅，如有补充，欢迎，若不喜欢，勿喷，不胜感激。

刚来第一天，老大：我们现在的产品要出一个第四版，要加这个功能，你去设计一下，画出原型把你的想法输出为一份prd文档，，

我：当时有点蒙，内心os(excuse me ,我特么是新来第一天)，在懵懵的状态里，应了一声，嗯。便走回到工位，不死心的我还以为是自己听错了，发QQ问了老大确认一遍，结果当然是，你！没！听！错！

好吧，兵来将挡，who pa who ，开始了百度，prd文档怎么写？简单思路有了，快用笔&纸记下流程，画出简单原型，那么问题来了几百年前的axure好像想不起怎么用了，凭着印象制作了一份比较草的草图。好吧，进行到这里，只用写文档了，我艹，问题又来了，这怎们自己想的跟写出来的不是一个东西，修啊，改啊，嗯好像是自己的思路了，还要一点没有写完，快要下班了，速速搞完，赶在7点20发邮件，完工，哦耶，下班不忘暗自爽一下，第一天这么重要的活这么快就搞定了，产品也不过如此。晚上回去，仔细看了下相关产品社区的prd（白天一心想着时间没怎么仔细看），顿然心痛了一下，我写的简直就是一坨屎，关键是我把这坨屎还让老大看了，哦买噶扽，我明天要怎么死了。。。。。

第二天，在担忧焦虑中完善了昨天的文档，等到快下班时，邮件回复了，只有四个字 比！较！粗！糙！内心又开心又忧愁，开心的是我的那坨屎老大竟然都看了，关键还都看懂了，忧愁那就是写的那么差劲，会不会被炒鱿鱼啊，内心忐忑又不安，内心顿时联想了一万出被炒鱿鱼的大戏，，，。当然新改的文档也没有勇气去让老大过第二次眼，因为我的思路他都知道了，，

第三天，剧情没有照的我联想的大戏进演，而是收到好多封关于公司另外一个系统的各种相关文档的邮件，而我的任务就是把这个系统的prd文档进行输出，，，

，，，，，，，，，

工作一天天照着不是我所想的轨迹向前走，每天都活的憧憬又紧张，不知道这样的开端会有怎样的路，在这些天算是有了自己的一点小小经验

1，产品需求文档（PRD文档）书写小结

要根据公司以前有的文档生成自己习惯的prd文档，格式无所谓；一定要分清自己的文档是给谁看的，给开发看的就不能将写给运营的东西写进去，因为开发不理解自己要不要去根据这部分写代码，增加沟通成本，这点说起来很简单，但其实自己第一次去做经常会犯这样的错误；

需求文档一定要写的详细，但是要有条理性，有逻辑，可以给出流程图，不要怕麻烦，因为产品本身就是打杂的；

在输出prd文档时一定要让自己所有的思路都清晰的前提下再去开始，这样会节省不少时间。

2，原型设计小记

关于原型，鄙人只用过axure ，想说的是，会用基本功能便是足够（这点跟公司的其他pm讨论过），还有就是作为小白我觉着最好是能将自己的思路想法先用纸&笔大致勾勒出来，在着手原型设计，逐步细化，先构建原型框架，在将自己的想法充分实现。

3，初来乍到的沟通总结

这部分算是自己比较弱的了，在跟运营和开发沟通中，犯的错误比较多，还需好好修炼；

在跟开发确认需求时一定要先跟运营这边的需求确认过没有问题，在去和开发的同学确认开发，除此之外作出的原型或需求文档最好先让运营看看，这样会减少不必要的麻烦；

还有就是最好能懂些研发人员的语言，沟通起来更便捷，这点我也正在学习；

不要跟研发说不确定，应该之类的词汇，他们会嫌弃你，是很嫌弃的那种，ui不确定就去找ui出设计稿，发邮件，需求邮件词汇不能出现不确定的，不要的需求及时从邮件中删除。

以上，算是自己入坑的小小经验，欢迎前辈们指导，学习，共勉。