马上就参加工作一年了。站在今天的我，看到去年刚刚进入职场的我，欣慰的说，这一年里，你成长的很快，远远超过最初的想象。
今天想跟大家分享一下，入职以来是如何进行工作的，以及在去年经历的事业部Top 1的一个项目。
结论写在最前面——一个产品助理，想要成为产品经理，远远不够。
你既要是一个开拓者，又要是一个守业者；
你即能够创造新的道路，还要兼顾现有的城市规划；
你既要是一个规则的维护者，又要是一个规则的打破者；
你既要抬头看天，更要低头看路；
你既要学会与老板沟通，又要学会规避与老板沟通；
你既要学会设计完美，又要学会如何取舍。
1、关于我
一个学了7年计算机却没什么编程能力的普通研究生——学校不是那么夺目，双211，只是刚好够一些公司的基本门槛，在魔都，的确没什么好骄傲的。经历也没有那么精彩，既没有厉害的比赛，也没有BAT的实习经历；既没有产品相关的实习经验，也没有独树一帜的见解——我就是一个硬件刚刚好达标，普通的不能再普通的毕业生。
为什么觉得自己普通呢，因为我是同年进入这家公司，最不起眼的一个毕业生。985甚至海归，BAT或同行业的实习经验，每个人的简历都足以让我心生佩服。
工作4个月后拿到了第三季度的优秀个人，年终绩效拿到了A。
这一年我最大的感受是自己的幸运，这么说起来，似乎这篇文章没什么好读的。但是，今天认真的思考之后，发现每次感觉幸运的背后，都是有可沉淀的内容。
（关于面试的内容，有很多小伙伴都分享过，今天主要想讲一下入职以后的内容，就从选择模块开始吧）
2、如何选择所负责的工作内容
进入公司后，老大非常看重我们的个人选择，让我们自己选择想要做的内容。这一点是非常重要的。产品经理很多工作是非常理性的，但是在个人选择方面，对所负责的模块是否有sense（并非单纯的产品sense），这一点在工作中非常重要。
前端产品经理or后端产品经理
前端产品经理与后端产品经理所负责的工作内容千差万别，个人发展完全是两个方向。当前，互联网行业更所说的内容更多的是前端产品经理。如何观测用户的行为，挖掘用户的需求，提高用户体验，分析用户数据——这是我在进入行业的时候对产品经理的职责最初的认识。然而我的mentor对我说，你有计算机的背景就做后端产品经理吧。我表示接受——这个决定对个人发展非常重要，至今我对如何挖掘用户需求，依然觉得体会不深刻。
选择模块还是选择老大：作为一个初入职场的人，公司分配了一个mentor给你。那么这个mentor会做什么，在最开始的时候，会跟你说，有一个工作需要你去做，是什么什么，如果你不明白怎么做，可以问；不知道怎么发邮件，可以问；不知道接触谁，可以问；遇到了难题，可以问（这一点我是非常赞同我所在公司的工作氛围的，每一个人都非常的nice，非常愿意帮助其他人）。因此选择一个mentor是非常重要的，初入职场，建议大家可以选择一个便于沟通，乐于帮助，有耐心提点你的mentor。
有很多同事，初入职场时遇到的是一个雷厉风行的mentor，他们告诉你应该取做什么。但是不是用你的方法，而是用他的方法，你只是他的一个分身；他无法兼顾这些工作，由你来做，但是你要用他的方法，他的形式，否则，就是没有做好。他们不会告诉你，应该做成什么样子，而是如何去做。在不断的被否定中，职场新人们的心越收越紧，做事情小心翼翼，生怕出错。
你要相信自己是有能力完成这些内容的，不要去问如何做，要去问，做成什么样子算作达标，做成什么样子算作好，仅此，就够了。用你的形式方式去做，不断地反思，如果给你mentor做，他会怎么做。这样的区别在于个人风格，还是真的有优劣，在这个过程中，你会更加清晰的看到自己的不足，同时建立自己的形式风格，而不是成为别人的附属品。
模块如何选择：要选择一个核心的模块。在一个公司，工作多以分配为主，并不是每个人都有选择权的。但是要在这样一个狭窄的范围内，尽量的发挥自己的选择权。什么叫做核心模块——业务的主要流程。一个成熟的业务，主流程并非不会进行更改，互联网永远不变的就是一直在变。涉及业务主要流程的模块，牵一发而动全身，这样的模块最基础，最复杂。无论想要进行什么样的改动，都会涉及到这个模块，那么很多项目，自然而然只能由你来做owner。
3、一个TOP 1的项目
又要提到幸运了，在入职半年内，成为了事业部Top 1项目的owner。这和第二部分中说的模块选择有直接的联系，这个Top 1的项目对整体的业务流程每个阶段都有影响，而我所负责的模块涵盖了整个业务流程（主要流程）。因此自然owner就自然而然的落在了我身上（感谢老大的信任，这是一个非常冒险的决定，失败于我而言是打击，而于老大而言，Top 1项目的失败他将面临更多的责难。）
3.1 迷茫
最开始的时候，我是迷茫的。这个项目涉及到与第三方的合作，当我进入时，已经与第三方达成了一些结论。由老大和mentor告诉我，我们要在现有的产品上，增加一个个性化的内容。我的任务是，设计整体的业务流程，并保障该项目的按时上线（当然是有EP帮忙协调的，这里深深的说感谢）。
主业务流程是我所负责的模块，对该模块的现有逻辑非常熟悉，对自己的模块下刀进行改造没有任何难题。完成设计之后，我开始进入迷茫期。作为owner要做的绝对不止完成自己的模块设计。之后我向我的mentor寻求帮助，她告诉我要从自己模块的owner身份中跳出来，要明白自己的是整个项目的owner。
还要做的事情：
产品设计：对其他模块的改动进行预判与大体设计，通知其他模块有哪些改动，目标是如何，现在设计的主业务流程是怎样的，各模块设计哪些改动点
运营：要向运营询问，在运营中有哪些场景与这个项目有关联，听取用户的声音
法务：是否合乎法务规则
财务：财务要求，成本核算如何
客服：对客服的培训
技术资源：保障在产品设计完成后，可立即投入开发阶段
3.2 解放
在完成产品评审后，可以说我觉得自己被解放了。这个项目一共评审过4次（正式评审），每次面对的都是产品，运营，技术。技术人员会提出各种质疑，这些质疑包括
业务质疑：为什么要这么做，能够达成什么样的业务目标。这要求你对自己的设计非常的自信——这个项目是被合理设计过的。这时候一定要有理有据，不要跟技术人员说，我负责设计，你负责实现就好。要保障自己的设计在评审之前进行了多次打磨，的确符合业务要求，逻辑严密，并且要和他们一起进入业务场景之中，让他们和你站在同一个角度来理解设计原因。
开发成本：很多产品经理都遇到过技术人员说，这样开发成本太大了，破坏了代码的优雅性，为了实现这样一个内容，会出现很恶心的代码等等。面对这样的问题，首先要对代码书写逻辑有一个大致的了解，要知道开发人员会从哪个角度切入，哪个问题是最外围的条件，不要给到技术所有罗列的场景，而是按照一定分类一层一层的下钻。
完成评审就真的解放了吗？NO！
在开发过程中，要时刻准备着开发中出现的问题，前后端是否能够完成对齐，会不会有什么细节之前没有考虑到——要相信程序员哥哥们考虑边界、异常case等能力永远比你强，要耐心听取他们的反馈。
3.3 取舍
不要追求完美。
在设计时，我们会尽可能的从用户体验的角度出发，但是还有如下内容需要兼顾：
现有的业务流程：我们不可能将现有的业务流程都进行更改，因此我们是在一个已有的大楼上，进行改建，因此要保障这个大楼不倒塌，不能将整个大楼拆掉再建。而是借助现有的环境，是做外墙包装，还是延长原有的阳台；是将哪几个房间进行合并，还是重新建新的房间；哪些是能够改的，哪些是不能动的。
老版本的兼容：我们必须保障，在这个版本上线后，没有进行更新的用户，依然可以使用该业务——用户的更新总是滞后的。
成本问题：运营成本，坏账率，用户门槛，风险管控。
时间问题：一个项目必须有deadline，因此必须保障业务在规定的时间内上线，一味的追求完美与完整，无视时间问题，只会让这个项目无限期的拖延下去。
技术实现难度：要尽早的让技术人员介入设计，他们会告诉你，当前技术水平能否实现，技术可行性如何。减少开发中更改需求的情况。
异常问题的兜底与处理方案：由于取舍以及各种可能发生的异常情况，都必须有兜底的方案以及人工干预的准备，以防在运行中出现任何情况可以从容面对。
你要做的，远远多于一个产品经理应该考虑的内容。
3.4 果断
对于初入职场的人而言，果断是很难的，尤其是在高于自己两级及以上的老板面前做决定，在一屋子的老大中要一个结论。
在这个项目中，有三次果断，直接决定了项目的生死：
（1）技术评审后发现第三方合作有问题，与第三方完成沟通后（当时已经是下班时间），立即将产品、运营、技术的老大集中在一起进行了会议（这些都是高于我两级的boss们），并在这个会议上，无论大家有什么样的不同意见，都必须保证达成结论（言语上一定会出现很大声的问题，在这些老板面前，也要保证一定要有结论，会议的讨论能够进行的下去）。注意：无论大家处于怎样的角度和出发点，甚至不同的利益点，必须要求大家达成一致，在下班后的两个小时内，对整体业务流程进行了再一次的更改。如果不能果断的在此时做出决定，这个项目根本无法进行。
（2）在开发过程中，发现一个功能的开发，会导致该项目延期一周。这个时候立刻询问替代方案，甚至是线下的兜底方案，果断的做出取舍，放到第二期完成优化。
（3）面对推脱，要果断的要求现在必须进行，无论你面对的人是谁。
一些感触
千万不要担心这是一个坑：很多进入职场的人，都会担心自己选了一个很坑的模块，会让自己的工作平添很多问题，阻碍太多。而我们往往是没有选择的，如果拿到了一个底层建设不错的模块，那么恭喜你，你可以向前辈学习如何搭建这样的地基。如果拿到了一个像蜂窝煤一样的模块，那么恭喜你，你今年的KPI不用愁了。要充分知道这块蜂窝煤哪里是连接点，哪里是要填充的，孔里有哪些垃圾需要清扫。
