次篇作为入坑产品的第二篇，主要记录自己工作中遇到的坑，以及从坑中跳出后的一些学习和反思，避免下次再入同样的坑。
距离上次写东西，大概有半个月了吧，然而在这半个月内爆发的问题是最多的，入的坑是一个接着一个，还坑坑不一样，产品小汪表示好心痛啊，，，，，少说废话，直奔主题，，
一号坑（千万别把自己当个产 品 经 理）
为什么要这么说呢，完全是因为自己明明是产品小助手一枚，非要学什么产品经理改需求，只是运营这边说不行“我们这样用着不习惯”，自己就屁颠屁颠找研发改了，可把自己给高兴坏了，，，
结果，第二周因为改了需求，导致各种事情没能及时处理，老大爆炸了，就像颗💣一样。当然追根溯源，便是我 未 经 老 大 允 许 私 自 改 了 需 求 然 后 让 研 发 同 学 改 了 系 统，然后结局可想而知，就是被批评，通过这件事当时抱怨过老大“你也没说让我事事都请示你，再说这个功能不就是我自己设计的吗，，”但事后反思还是自己的错，自己的锅。
首先，你只是老大的小助理一枚，没有权利去替老大做任何决定。老大让研发同学去做你设计的功能，是老大觉得你的设计可行，里面的细节不管你有没有仔细推敲但肯定是老大仔细考虑过的，相当于每一个细节都是老大替你把关，说白了你只是提出你的想法，最终拍案做决定的还是老大，所以也就不存在你一个人的设计，也便没有了你去任何决定的权利，你只是一个通道，负责筛选运营提出的需求并将筛选过的需求传达给老大，可以提你的想法，但最终做决定的还是你的老大。PS：我们老大确实在沟通上存在一定的问题，我要吐槽，哈哈，，，，
其次，改需求本身就是一件严谨的事，不能因使用的人说这里不好这里就要改，要仔细斟酌为什么这么设计，又为什么要改。这点的话就关系到作为一个产品的专业性了，当然也是我自己得好好学习的地方了，说实话碰到运营说要改需求时自己是有点懵的，感觉运营好象说的很有道理的样子，但其实自己并没有好好研究自己当时为什么要这样设计，只是觉着改了对运营来说很方便，但其实是自己对这个系统的逻辑不是特别熟悉（🌰栗子：一件东西要退货，没有任何凭证，淘宝卖家也没收到货，淘宝在设计退货系统时肿么能给这种场景去退款，，ps:随便举得，只是刚买的东西到了，让我好想退货(┬＿┬)），所以啊，发现了问题就要改啊，快让我再去研究研究这里的逻辑~~
二号坑（解决问题要有 逻 辑 性）
作为产品汪里级别最低的，日常工作少不了解决来自各方面使用公司某个系统的各种问题，比如使用问题、系统BUG、系统功能不全等等问题。当这些问题，单独一类拿出来完全不是事，不能说分分钟解决吧，但也都是能让提问题的人有个满意的答案；但当这些问题扎堆出现时，你感觉你每个问题都处理的很好，但常常是提问题的人得反复跟你确认是这样吗？又或者是你要在次确认我的回答清楚了吗？（只能感慨脑子是个好东西，我却没有~~~~(>_<)~~~~）
后面我反思一下出现这种情况的解决办法：
1，当有多个人提出同一个问题时，说明这一块本身是要好好研究的，如果大家都提出这个模块的功能使用逻辑不明白，那就应该写一份大家都能看懂的用户说明书，直白具体到一个文本框要填什么样的内容（写说明书一定不能和prd一样，因为她们看着费力，尽量说人话，，说多了都是泪啊）；
2，当一个人提了好多问题时要将问题分类，是准确分类，不能模棱两可，如果不能分类那就是考虑这个问题产生的子问题，将问题的调理划分清楚了，只要你足够熟悉该系统，就基本没问题了；
三号坑（需求要反 复 确 认，究 其 根 源）
需求这点相必入坑的同学想必都懂，千万别不好意思反复跟运营确认，千万别磨磨蹭蹭老嫌麻烦别人，因为这就是 你 的 工 作 ，因为我就这么干过，关键还导致工作迟滞不前进，不是被老大批，而是技术会diss你，怀疑你的能力┭┮﹏┭┮，关于这点我自己现在也没有太多的经验，但是磨蹭这点绝对是大忌啊，，，后面经验丰富了会继续补充这一点。
