这是正式入职做产品工作两周后写的，现在分享出来那些天的经历吧。
第一周其实主要是先了解了公司的产品以及目前上线的情况，这里最大的感受是，比较相当的乱，没有一个比较系统的文档系列，都是比较散乱的存在，甚至有的产品在上线了一个版本都还没有具体的标准化文档——我有点感叹了。当然了，其实当时面试过程中我也大概了解到其中的情况了，所以，在我实际看到的时候，更多的还是比较平静的。第一周后半段时间，就算正式开始接手一两个产品的项目了，主要的工作内容是从文档整理起，虽然其间我制作和构思了不少的措施项目，只不过初来乍道，还是低调为好，仅仅是将这些内容向目前主要合作的一个同事反馈了。当然在和他交流之后，他比较肯定我的一些建议，然后也将我反馈的内容和文档转发给了公司的大老板。总的来说，第一个星期，更多的还是在试图从乱中整理出思路，希望能尽快熟悉整个公司以及产品，做到心中有全局规划。
这其间有几个细节是值得我注意，或者说，比较有意思的。
第一点，其实我做的是产品经理的工作内容，但是被划分到了事业运营部，其他原因我不太了解，但是有一点很明显，因为公司目前还没有专门的产品部门，在我来之前，主要是运营部的总监在兼职负责产品这块。他也就是我目前主要协同合作的伙伴了。
第二点，我虽然被划分到事业运营部，但是办公位却是在技术开发部门，也就是在开发总监旁边。说白了，他们最初的想法就是，希望通过我能更好的与技术这边沟通，毕竟我也听说了之前的沟通障碍。
第三点，公司划分的部门，各部门职责，公司的管理制度等，还算是比较清楚的，或者说是在我看来，比较有制度化的内容的（当然是相比于我之前在上海创业公司的经历）。公司目前是运营方面要相对更强一些。而产品方面相对弱，从目前产品的情况以及做公司内做产品的工作，都可以看出来一些。
第四点，从工作执行层面来看，最大感受是比较乱。特别是运营部门与技术部门之间，经常性的有运营部门的人来直接打断技术开发的工作，而谈论产品修改点。口头说完之后，双方答应好，运营部门的人离开，技术开发人继续做刚才的，而我，在想“这方式好随意，开发人员他真的记得住吗？”
第五点，某天我在工作，突然大老板走过来，说了一句：你就是Mark吧，你的工作日报写得很好！我当时心里想的是，我这两年都这么写的，都习惯了，也没特别感觉到很好。而且这东西更多的是对我自己来说，整理一天的工作和总结，是一种工作方面的“吾日三省”之类的习惯。可能是，当优秀已经成为了一种习惯吧，自己都没太注意了。呵呵，自夸了一下。
第六点，初步了解，可能大老板对我做了一定了解了，从他的态度和其他同事的反馈，我了解到他还是比较认可我的。这样，我后面工作的展开可能会相对顺畅一些。
第二周，也就逐渐在一个一个接手公司的产品了。说的直接一点，目前公司在做的产品，到今天，已经基本上都经过我的手了，一共6个。当然这些产品有的大有的小，而且还有在准备上的。对于这些产品的工作，一方面是尽量按照更合理有序的需求点开发执行方式我来处理，主要是和技术开发这边打交道；另一方面是做需求分析，主要是和运营这边打交道；还有一方面是，从公司层面出发，通过与某些同事的沟通去以公司及合作机构出发来规划。
这其间也有几个要注意的点：
第一点，比较完整的PRD写完了2个，主要是”功能描述和用户界面“这2个部分的，其他部分就暂且没有多花时间。第2个PRD比第1个写得好，这个不用其他人说，我自己就看的出来。我的习惯就是这样，在不断的做工作优化。而且，做产品用到的其他文档，也通过实际工作里的整理，在进行版本迭代，希望从通用和合适此公司这2个层面去优化。需求列表、需求修改列表、需求修改展示文档、工作推进表、原型DEMO、流程图、结构图等都在各产品项目工作里相应做了一些。目前也可以看到对公司的工作有实际的改善效果。而我自己仍然在继续优化这些工作。
第二点，与开发这边的同事打交道，这一个星期基本就算是都熟悉了，也就是都有过实际的工作交流了。一开始肯定会有些障碍，毕竟每个人有每个人的性格，需要去摸着对方的性格处理一些对接。当然，一切的前提是，自己把自己这部分的工作尽可能做到位，然后再去请别人弄。还有就是，勇于并且积极表示抱歉，只要是有一点由自己工作引起的问题，这其实就是在摆明一些态度：我做的我会负责，如果是我的问题我会道歉，而且我是认真在做，尽可能在努力处理好，并且也确实有能力在做好，特别的，我也在改进。除了这些，对于技术这边的工作，多给与鼓励，通用到一般其实也是一样的，对于别人花了功夫去完成的工作，都要给与精神上的肯定和鼓励：辛苦啦！这既是一种策略，更是我自己的一个习惯，我很尊重也真的认为这种人与人之间的鼓励。
第三点，与运营这边的同打交道，他们主要就是需求（修改）的来源了，很多时候他们就直接丢出了“我要怎么怎么样的”，甚至就直接出了解决方案。不过即使出了方案，很多时候都是比较“大”的，并没有能“明确地说清楚细节”。对于他们，首先做的就是需求分析了，对每一个需求点进行推敲，将自己的疑惑说出来，请他们回答。将全部的需求点都这样过清楚了，再整理成一个版本的需求列表，按照优先级做好排序。这个过程中，就存在了某些需求其实是“伪需求”，这个肯定要毙掉。再就是强需求和弱需求，这个还要与技术人员在讨论进一步确定。特别要再强调一点，运营给出的需求，很多时候都比较宽泛，并没有具体的可执行说明，这种东西一旦直接丢给开发人员，那就是由他们随意发挥了，甚至有的比较懒，直接打回来或者搁浅着，因为“他看不懂，不知道具体怎么做”。对于这种，一定要避免，在确认需求列表时，要再检查一遍，确保自己没有遗漏的点。然后一些具体的执行方案，既然是在“做产品”，那么我就直接按照需求，做一个可执行的方案出来，有必要的话与相关人员确认一下，然后再交付开发人员。
第四点，从我这边交付给开发人员的各种文档，除了比较作为正式的PRD之类的，我都用最直白易懂的方式——PPT（PDF）来说明，这样更便于他们一个点一个点，而且是很轻松的理解这个点是什么在哪里该怎么做。当然，作为一种（视觉）设计，我还是要求一定的优秀设计档次滴，不过也是效率为先。不过话也说回来，最近也结合实际内容做了一定数量的文档，也用于不同的产品项目与不同的人交流，还是发现，可以，也是必须有再优化的地方。纵使这些做法是比较“正规的”，但是拿到实际里，还是应该结合实际的情况再做些调整，以达到更符合实际最佳可用性。
第五点，有几天，就一天里要处理5、6个产品的工作，还是有点费力气的。除了是因为本身对几个产品不太熟悉，只能尽可能在想办法处理，再就是与其他人刚开始合作，节奏还没把握好，有点混乱。不过吧，这样也不知道正常不正常，一下子要同时处理这么多，肯定会有先后的，无法一起都搞定。如果参照做需求分析，去做“产品”的分析，区分优先级，也可以改善整个的工作效果。只不过，除了完全从做产品角度来看，还要考虑人事方面，毕竟刚来公司不久，尽可能与其他同事做好合作，不能一开始就在哪块掉链子了，所以，只能“都上”。
第六点，也开过几次会了，也逐渐认识到公司更多的人，也就更了解到各个人的性格和能力了。当然，比较关键是的公司的规划，甚至说是战略导向性的一些东西。这对于我后期做产品是有帮助的。也从几个方面得到肯定，这更加让自己有信心去做好产品工作。
………………………………华丽的分隔线……………………………………
再稍为说一点自己的产品经理之路，自己是知道还有很多关于产品工作要去学习和提高的，目前还是更多的是通过读书来扩大和提升自己在“做产品”这方面的见识和能力，再通过实际的工作去真的转化为自己的一部分。
自己需要一个平台来施展，也必须通过平台更加有效的得到提升。
希望通过此平台里的实际工作，能将自己的产品经理之路，有效地走起来！
继续加油，晚安。