太爽了，搞快点，一起做滴滴PM
前言
在写这一篇文章前，我先问了自己，为什么写？希望获得什么？
是单纯回顾经历，还是希望转发到朋友圈比较酷？
思考后，我发现我希望能够从这一次的复盘中，迭代自己，
并和与我同样心态的同学去分享我的体会。
的确，有了这样的思考，后面的思路逻辑会更清楚了些
或许这就是我第一个收获的产品思维（奸笑
一、不要给自己设限，没人把你当实习生
我是一个非常幸运的人，在入职前就有热心的同事来帮助我租房，入职后同事们也经常带着我一起去吃饭，我的mentor是一个非常温柔的人，交付给我的任务都是循序渐进的增加难度，而且总是用“我们一起商量”、“谢谢你”的词汇，让我感到非常亲切。
怀着这样的情绪，我希望把我分内的事情来做好，再去额外帮助mentor分担，但理想与现实是有差距的。
但前期的工作我是有把握胜任的，比如说修改文案、统计表格（打杂类型）。而后一些对接需求，撰写文档，交付给FE、RD、UE、QA这样正式的工作，我变得有点吃不消。我产生了疑问：在这样敏捷开发，快速迭代的情况下，让我来半主导一个产品，如果失败了，我如何去承担这样的结果？
这样的想法不长，我换了一个角度思考，作为PM实习生，如果不做这些工作，那为什么叫PM呢？不去接触这些，又谈何成长？后面我又和其他的朋友聊了聊，得知互联网公司一般都是把实习生当正职用的，一个公司如果怕用人，是很难发展的，相反一个实习生一直害怕，也很难发挥出更好的水平。
所以，收起玻璃心，除了你自己，没有人把你当实习生。
二、不要怕犯错，不要犯同样的错
当上手做了PM的工作，我发现这是一个非常有趣且有挑战的事情，随之而来的就是不断的踩坑。
每当这次的工作被指出哪些地方不足，我首先做的是修改本次的错误，然后把这次的不足记录下来，用在下次的工作上。但当被交付更有难度的任务时，我会产生一种怀疑自己的心态，如果做的仍然不够好，是不是又会给其他人增添额外的负担？
1个case：当我写完一份需求文档后，中途又发现了哪里不对，这时候告诉研发的同学，会给他们带来很多的麻烦。即便我下一次努力去思考逻辑关系，但难免落下一两个细节，那么久而久之，我会被宰了吧
这个时候我理解到了为什么公司喜欢招“有经验”的实习生，设身处地的想一下，假设你是一个leader，需要招一个实习生来团队里，那么你的目的是培养这个人？还是希望他来分担一部分工作？我想后者成分是据大的，那么尤其是作为PM，这是一个非常注重产出比的角色，培养你的精力如果比自己完成这份工作消耗的精力还要大，这显然是一笔不划算的买卖。
继续说case，这和题目说的并不冲突，因为每次落下逻辑可能并不是同一个坑，而是不同的场景和原因导致的，但结果是导致开发同学泪崩。
我们应该做的是，把每一次的工作都尽可能的往细了想，往多了想（当然，我们也需要简化内容，留下最精简的，那就是需要考虑优先级和理解程度了），如果最后还是丢了一个细节，别人也是能够理解的，如果一直局限于“我怕”，那么也是不会有所成长的，该蹚水的地方躲不过去，那就接受它。
最后强调一下不要犯同样的错是什么意思，假设修改文档忘记跟研发同学说了，导致上线延期，或者功能排期变了之后，下次修改继续忘说，那就要被揍了
三、及时沟通、恰当沟通、会沟通
这个沟通有多层的含义：
如上面说的，文档更改了确定的内容，或者是需求变更、项目风险的情况，需要及时同步给队友，不要藏着掖着
自己遇到了问题，需要和团队成员或者mentor、leader沟通，排出优先级和紧急程度，马上确认的及时说，不着急的先列出list，找一个合适的时机恰当沟通，还是换位思考，你是一个高级PM或者项目经理，可能身兼多个项目和会议，却总被一个实习生打断自己的工作，是不是很不爽
当然了，我们在真实的工作场景里，很难去完全做到以上2点，所以我们需要做到会沟通，如何快速的表达自己的想法，如何在打断别人的情况下还可以让别人高兴？这可能是考验智商和情商的问题了哈哈
四、关于PM工作的一点建议
说到这里，我目前遇到的一些问题就差不多了，但我还想列出一些比较关键的事情分享给大家
作为PM，在任何时候，逻辑一定是要清晰的，不仅要说服自己，也要说服别人，这会给工作提升很大的效率
正是因为逻辑过于清晰，PM辅助测试的时候，可能只会测试逻辑盲点、special case，而忘记了主流程的使用体验，需要兼顾
版本和版本不是独立的，在想功能的时候，要有前瞻后顾的能力，这个成语好像是个贬义词hhh，但是意思到位了，当下这个功能，会不会到前面的功能造成影响，会不会给未来的功能开发增加难度。一套文案格式，是不是能复用于所有的需求，而并非每次都不一样？这些是该考虑的地方
多去考虑“用户怎么想”、“用户理解吗”，而并非“我觉得”、“应该这样”，因为我们自己不一定是用户，所以需要跳出逻辑，去理解用户的思路，必要的时候，应该去问问真的用户
做一个Product Mother哈哈哈，在写需求文档时，先把设计、开发、测试等等一系列同学可能不了解的地方明确出来。把文档作为一款产品，目标用户就是他们，以他们的思路去解释，确保他们能够一眼明确，又不干涉他们自己的想法，这大概是一件很难的事，我也在努力
书本上的东西，记得用在实际上，还记得我上三节课的时候，有一句话：功能要不要做或者确定优先级，可以从“用户量级与频次”、“使用场景”、“开发难度”等等方面考虑，真实情况下我根本没有想，后面被mentor提醒，才发现好记性不如烂笔头，烂笔头不如真的会
及时复盘呀，如果没有复盘，大概也有没有这篇文章了
后续
写完了这篇文章，一共2305字（包括后面的
文笔和审美一直很烂，所以没有比较好的表达和排版哈哈
大概表达出了自己当下的一些想法，我想还是会有很多漏洞
如果你觉得有哪些地方可以优化或补充，欢迎来告诉我，因为我们还都在路上
如果你觉得我写的还不错，可以送我个盲盒，谢谢你
