今天来跟大家说说小白实习了快2个月的一些经历和触发的感想，尽量分享给大家接地气且容易消化的“干货”。
看用户评论很无聊？
开始实习的第一个任务是一边看用户评论的数据统计，做用户评论分析熟悉用户，一边熟悉产品，两方面结合起来做用户画像。
实习生刚到的时候先要熟悉用户和产品，而看用户评论是了解和熟悉用户的一个非常有效和成本低的渠道。
不仅如此，从评论中还可以看出来用户留在我们的产品，哪些用户可以归纳为忠实用户，他们注重的是什么功能和什么样的体验等等。而用户注重的功能和特性是我们产经不管在做功能还是做需求的时候需要时刻提醒自己的。
比如小白在公司所负责的产品，由于主要用户是欧美地区用户，在使用产品时他们注重的是产品的简单、简洁、易操作等特点，与中国用户不同，他们对受打扰的容忍度很低，且十分关注个人隐私。
后面小白负责的工作是在功能上提升用户活跃度。要促进活跃，避免不了要去向用户push一些东西，但是小白在筛选功能以及功能设计上为了尽量减少打扰到用户的可能性，在某些功能制定一两个规则，能够在实现目标的情况下又不去打扰用户，避免引起用户反感。
产品小白撰写spec文档这事
需求筛选完成以后，就开始写spec文档了，刚看到其他PM发给我的spec模板时，心里有点苦，因为小白害怕写长篇大论的文档，而且因为第一次亲身经历产品发布周期，从来没写过spec文档，对文档里的一些专有名词和功能逻辑感到很陌生。
20几页的文档，我只能咬着牙去搞清楚整份文档是如何分块的，每个区域是要讲清楚什么，为什么需要在spec文档里面说明这些，一页一页的看，也把不同的功能区域（咦，我好像把这文档也当做产品了）弄清楚，这边是写需求说明，那边是详细设计，为什么是在这边写这个模块，这边写这个对看的人能有什么影响等等。
把spec文档的结构和框架搞明白了以后，就是硬着头皮写文档了。第一天下午写了第一个功能的1/3，到了下班时间，实在写不下去，原本mentor 希望我在今天完成第一个功能的文档，然而任务没有完成，本应加班，但因当时脑子实在很乱，继续纠结着在公司写文档也肯定写不好，效率也很低。于是跟mentor说明了这个状况，就下班回家去了。
第二天上班，我重新看了同事给的spec模板，想着一味根据这份文档写不算回事儿，于是拍着脑袋自己把文档的每个区域需要写的东西规定好，根据自己的理解在模板上做了一些改动，然后根据自己规定的框架和逻辑，一点点把内容填进去，这样效率慢慢提了上来，也感觉轻松很多。
所以啊，照着葫芦画瓢，有好处，就是能让你很快理解一个事物的整体形态，但也有不好的地方，容易让自己陷进别人的思维里面，而没有形成自己的思想和逻辑。
第一份spec文档，mentor表示没有明显不对的地方（不明显的地方是在后面与开发和测试沟通过程中逐步发现和改正的），所以当时直接拿我写的文档给团队成员看了。
接下来写的第2、3个功能的spec文档时，没有像写第一份那么纠结。文档写完第一个版本以后，需要一遍一遍过功能的流程，和每个步骤可能出现的场景以及处理方法，这个过程也就让自己一再地反思和掌握所要做的功能，一方面能弥补写文档时遗漏的场景，另一方面在后期跟团队成员解释功能流程等也提高了说服力，因为你已经在一定程度上足够了解你要做的功能了嘛。
不过spec文档说到这里，还要总结很重要的一点，是在后面开发和测试阶段发现的一个问题，就是我当时写的两个功能的文档，在特殊场景上没有写全，也就是没有把在这个功能上的所有可能出现的场景说明逻辑。
比如说，小白这段时间做的功能中有一个弹框，弹框出现后，用户除了点击YES或者NO，或者忽略，或者退出该页面，还有很多其他的行为，如弹框出现后，用户打开一个新的tab，或者点击返回，或者返回HOME Screen等，这些场景下我们所期望的弹框的状态是什么。
这些不是我们所期望发生的场景，却是可能发生的场景，凡是可能发生的场景都应该做好准备处理。
没有把所有的场景写全的后果是，开发人员和测试人员可能没有去考虑到这些场景，也就在没有完成相应的逻辑，导致功能不完整。或者是开发和测试人员发现了没有这些场景的说明，就需要反反复复地询问PM这些场景的逻辑，加大了团队成员的沟通成本，还可能导致产品上线计划的延迟。
通过小白在公司的实战经历为大家总结出来，spec文档的撰写简单来说需要注意：
1、逻辑清晰
2、语句可相对简短、口语化（能讲明白就好），禁歧义
3、说明所有可能发生的场景逻辑
与团队成员的有效沟通
前期功能进入开发阶段时，刚开始以为沟通上主要是我mentor负责，我只是打个辅助（毕竟实习生），但是mentor几次跟我强调主动找开发和设计沟通，那么就说明，在沟通上我也能狠狠地参一脚了！话说当时还有些小开心。
整个沟通阶段都没有什么特别的问题，但与开发的沟通特别需要把握度，毕竟开发GG有时候思维跟我们业务人员不一样，在某些功能逻辑上他们会以技术层面上的概念去理解和考虑，而产经和测试会以业务的角度去考虑。
比如我们当时针对在浏览器中输入URL算不算一次搜索这个问题，几方人员进行了讨论。
开发角度说输入URL只能算作访问，不是搜索，而我和测试同事认为这算作一次搜索。最终讨论结果以开发的理解完胜，原因是结合业务和技术两方的理解，输入URL进入的结果页是精确的网站，理解起来确实只能当做一次访问，对技术人员来说这是常识。
这类似的事件没有发生多次，虽然有点像“小闹剧”，对我来说却是一个很“长常识”、值得高兴的事情，因为站在不同角度思考的人们碰在一起实在是一件很有趣的事情，在以后的逻辑思考中我也许会试着站在开发GG的角度思考问题了哈哈~
上面讲的是沟通过程发生的一个有趣的事情，第二件事情倒不是很有趣，而是值得反思的错误。
因为在新版本中mentor带我一起负责的有两个功能，两个功能都进入测试阶段的时候，明显能看出来两个测试人员的不同。
其中一个功能的测试人员非常积极地发现和反馈这个功能的问题，也非常主动配合这个功能的进度。另一个功能的测试人员似乎因为手头上有其他功能需要测试，所以在这个功能的测试上没有比较频繁的更新进度，也很少主动找我沟通。
虽然如此，在与第一名测试人员频繁沟通的情况下，小白也不忘时不时去找另一位测试人员询问测试情况，好知晓两个功能的测试进度，确保在beta之前两个功能都能测试完毕。
但到后面第一个功能的bug暴露的越来越多了以后，我将大量注意力放在第一个功能上，也就有点忽略掉另一功能的测试状况。直至第一个功能的bug处理的差不多了以后，我把注意力又平衡起来时，与另一测试人员沟通后才发现功能的某个规则出现错误，原因是前期信息流通上出现偏差，没有及时发现。
发现这个问题后我赶紧确认spec是否有说明这个规则，才发现自己没有在spec上写这个规则（这个规则我记得这么清楚怎么会忘记写上去啊喂），只在口头上与测试明确说明过，那么鉴于这个问题的影响面，我们决定马上修改代码并且重新测试，虽然当天就要进行beta发布，但还是很快解决了，有惊无险。
这个问题反映了信息流通的重要性：
1、 不管是测试还是开发的进度都应第一时间得到反馈
2、进度情况和问题都应明文记录，不管是通过邮件，还是项目管理工具，抑或是文档，都要有信息流通的保证和证据
3、对接的团队成员在多任务同时进行的情况下，自己也千万不能松懈，甚至应该给予激励
团队成员之间需要互相监督，更需要互相帮助
在开发进入后期阶段，功能即将进入测试阶段时，开发GG几次跟我重复一句话：spec文档得删减一些东西啊~否则测试怎么测啊~
我问了他要改哪些，为什么要改。他刚开始说了原因，我想着人家毕竟有好几年的工作经历，自然有这么说的道理，于是老老实实去改了，但自认为必须保留的地方是肯定留着的（ORZ! 难道这个功能的规则就是在这个时候被我不小心删了？恩？？）
但后来开发GG说的次数太多啦，不禁让我猜测他媳妇儿是不是在测试部门（哼哼），而且我也问了测试人员，那边的反映是没有问题的，所以觉得有点烦。
到后面与开发和测试的无数次沟通过程中发现，实际上各个职位之间虽然有明确的职责，但在做项目时，当某个岗位人员掌握某些在项目上可能对其他岗位人员有用的信息时，不管是不是自己岗位的内容都会将信息同步给大家。
比如这次发布的版本中，某个功能的bug需要开发人员在下个版本处理，但是测试人员想起之前在做某个功能时解决过类似问题，于是同步信息给开发，为开发寻找解决方法提供一个已知条件，沿着条件可能找到这个bug的解决办法。
上面的例子明显的受益者是开发人员，而测试是受益提供方，但最终的受益者是整个项目的发展。这是项目成员的默契，也是一种互助的文化。
我想，在公司或者团队中想要与整个团队一起进步，也许就需要每个人为项目、为他人多想一步，这样又能解决问题，又能节省整体成员的劳动力。
【此文章同时发布在微信公众号产品小白的日常——小白的产品经理学习区，精彩原创内容，期待你的关注 】
网友评论