在毕业前的最后一个暑假，缘分使然找了几个月暑期实习之后进入了去哪儿，申请提前入职工作至今正好满一个月。

原先有在行业内实习过其他岗位，后来一段时间对产品经理产生了无法克制的热切，一度认为这是世界上最适合自己的职位，但是这只是停留在各大公司对外的招聘需求，以及其他人的分享之上。然而，这一个月的实际经历，颠覆了原有对产品经理工作的臆想，当然热情不减。

文章的初衷只是总结在去哪儿做产品的体验，给那些想求职产品经理的小伙伴一些参照。

一、对产品经理的认识

曾经以为，产品经理是创造出万人使用的产品，要去改变世界的人，以乔老爷子和张小龙为偶像，每天工作就是构想产品概念，然后做出原型，然而当时太天真。实际上，产品创造相对而言并不普遍存在，大部分时间，大部分产品经理的都是在进行产品的优化。

据自己的认识，我将产品经理分为了两类：优化型的产品经理和创造性的产品经理。前者的工作主要是对已有产品功能的完善优化和增加新功能，后者的工作就是从0到1的过程。前者为业界的大多数，后者的要求更高。我所在的部门是去哪儿国内机票，在这一个月内的主要工作就是对系统的功能优化，以及增加新功能来满足业务需求。

二、总结的一些能力

看到很多文章讲产品经理的特质，在这自己通过这段时间工作总结了几点：

1. 沟通能力；
2. 自发驱动与执行能力；
3. 逻辑思维与想象力；
4. 资源协调能力；
5. 数据分析能力与商业头脑；

每一条都非常重要，同等重要，不能有短板。

沟通能力

沟通，好不夸张地说，产品经理的时间有7成以上，都是在沟通，因为这是了解问题最快速直接的方式。日常的工作中，你会和各种角色沟通，运营人员、开发、测试、其他产品、你的老板、用户等等。所有业务相关的角色都会有接触，作为产品只要你愿意，公司的每一个人你都可以打交道。而且大部分时间沟通，你们可能是第一次见面。

沟通的方式按照有效程度由低到高，大致可以分为：邮件、内部IM、电话、当面约谈。去哪儿内部IM用的RTX，可以通过组织架构找到任何人，及时发起群聊。如果需要找人，而不知道具体谁在负责，直接拉人，通过至多三度关系，就能定位所有相关干系人。电话同样，随时查找任何同事电话，打字说不清楚的，电话沟通。当面约谈，最有效的沟通方式，说不清楚直接问工位，哪怕是第一次见面。

去哪儿给每个员工都配备的是笔记本，非常开放，你时常会看到有抱着笔记本走动的，和围着电脑三两讨论的。开放的办公区周围墙壁、走廊、柱子到处都是毛玻璃和记号笔，随手抄起笔开始画流程图十分常见。还有各种放着LED和沙发的角落，讲需求估工时、对case的时候十分好用。

刚开始还不适应这种节奏，磨不开脸，与其他同事第一次见面还需要自我介绍，想想还太嫩。目前已经锻炼地十分厚脸皮，说明来意之后，直奔主题，效率第一，因为你时间总是不够用。

自发驱动和执行能力

所有的工作都没有人在强迫你，动力基本来自自身。个人还是比较认同，必要地去做自己热爱的工作。作为一个产品，你需要负责上游到下游整条流程，从运营或客服发现问题，到与相关产品、开发定位问题，到自己提出解决方案，到相关产品、开发、测试评估影响与实现难度，到功能开发，到与测试提测功能发现bug，到上线后进行后评估和数据分析，都离不开产品，每一环都需要优秀的执行能力。

每个人都会很忙，尤其是技术人员，基本是同时负责多个产品的项目，让开发同事自发性地优先处理你的问题，很难。所以需要催，但是是有技巧性地催，怎么催，目前还不得其法。实际中往往存在推不动的窘境，或者更改方案，或者实在不行而又必须要上那就升级。

另外，对于自发驱动地负责任务有一件事印象非常深刻，前些天上线新功能后需要制作运营数据日报，在我提到这不是数据运营团队的活时，蔡师傅则告诉我，不要想着把托出去，所有的事产品都应该负责，而且是要会。之后，自己也开始利用各种机会问、看、学。

逻辑思维与洞察力

没有强大的逻辑思维的确很难胜任这个岗位。处理问题最怕毫无章法，乱序不仅会导致处理事务不分优先级，严重的甚至会导致沟通不顺畅，双方理解出现偏差。日常的工作中往往接触到的一手消息是已经出现问题之后的现象，这时候需要洞察问题实质来源，将不同问题归类处理。

比如说，问题现象1出现之后，需要考虑所有导致这个问题的可能，分不同环节逐个排查，判断是原因1还是原因n？是即有问题还是新出现问题？与问题现象n有没有相关联系？另外，在PRD（产品需求文档）中非常重要的一节就是功能流程图，向他人讲述问题配合UML图例能够事半功倍。

入职第一天，天舒就是通过UML向我讲解业务流程，让完全对机票业务陌生的我短时间有了大致的理解，当时折服于其强大的逻辑不能自已。有同学想学习的话，用visio完全可以，日常任何事情都可以通过流程图描绘，尝试去分解对象、动作，如果利用多泳道流程图更加形象。这里建议可以看苏杰老师的《人人都是产品经理》，书中的UML图例很实用。

资源协调能力

资源，资源，资源，重要的事说三遍。要明白的一点是，资源不够，这个问题永远存在，所以提任何需求的时候都需要考虑到实际工作量。这里的资源，主要指技术人员，一般以工作人日来为单位来衡量，有时也包括客服人员或者外包人员。衡量一个需求价值高低，或者说上不上，主要的评判标准是性价比，这从idea产生的初期就得牢记并贯穿始终。

刚入职时，我看待问题比较天真，在写需求的时候动不动就以用户体验、交互设计为出发点，然而当时的项目是内部服务系统已经出现降低运营人员工作效率的情况下新增功能。理所当然，又被教育一顿，如果这是用户端的功能，我们花再多钱也得上，但不是，当务之急是花最少的资源最快时间上线，保证业务线跑通，因为开发资源很宝贵，系统以不影响业务为第一位。

数据分析能力与商业头脑

这个看着较之前面几者能力在实际操作中运用地少一些，但是千万不要忽视了它的重要性。为什么把数据分析能力和商业头脑放在了一起，因为二者缺一不可。只会分析数据而没有商业头脑，会沦为计算工人；只有商业头脑而不会分析数据，那就是大忽悠。

最理想的境界是用数据来佐证你的idea，用数据说话，说服别人。这里的别人包括你沟通的所有人，尤其是，你的老板！开发的老大！测试的老大！因为他们是能够在需求评审当中拍板的人，前期与各方面人员沟通再好，需求自认为多牛，最后也有可能被拍死。战术上的勤奋不能折算战略上的空洞。

前两天，作为新人的我，接手一个特殊情况，这个特殊情况产生的损失公司目前采取承担的策略，但是由于无法准确评估其影响程度和具体的损失量，被拍死。当时老大晓晨哥说了一句，不说清楚不给改，感概良久。这里面插一句，最好最好会用SQL，用来提取数据提高说服力的利器，想做产品的童鞋可以去学习一下，基础够用就好，类似条件提取where之类。

三、一个需求的过程

在去哪儿的时间不多，但是也是很幸运地走过了一个需求的整个过程，在天舒这经历了前半段，在蔡师傅那经历了后半段，对需求有了一些了解。大致来讲，需求的完整过程分为以下几个步骤：idea产生、idea评审、需求产生、需求评审、需求开发、功能测试、功能上线、后评估。

idea阶段

idea阶段真的不只是一个想法，已经是一个可以实行的方案了。不止一次在这里学到，不管是什么任务都要细化，一定要落地，可执行！当然idea最核心的是它的价值，增加营收还是减少损失，提升用户体验还是加快运营效率等等，记得要用数据评估。这时候输出文档，基本就是PRD的前身，idea评审基本就是找产品老大过目。

idea的动机基本是弥补缺陷或者发现不足，很多途径都能产生idea，主要有：

1. 运营人员的沟通；
2. 自身充当客服人员发现；
3. 公司相关部门人员的提出问题

……

为了快速熟悉业务，我临时充当了客服人员三天，收获着实不少。有时候我们做的，和用户感受到的差别会让你吃惊。去哪儿内部还有一个非常有效的机制，产品人员轮流排班接听值班电话，一般都是代理商反应的比较严重的问题，为优化产品提供了不少帮助，甚至许多故障的产品在值班期间发现。

需求阶段

当idea通过了之后，开始进入需求阶段，开始撰写PRD。当然，所有的事务都需要细化，细化到每一步动作，每一个页面，数据的埋点存储，甚至是按钮的形状颜色。在写PRD时，比较重要的一步是通过流程图把整个需求描述出来，各种情况考虑周全，注重逻辑顺序，需要达到第一次接触这个需求的人看你的流程图就大致知道怎么实现的程度。接下来就是需求详述，逐点叙述，一二三四罗列清楚，配上相应原型（Axure是神器）。

在需求产生的过程当中，很重要的一环接是找到相对应的技术干系人讨论需求，一般在去哪儿内部称为技术Review。技术Review形式是不拒于形式，大部分时候都是就近找到有显示屏和沙发的角落，插上电脑就直接开始。拉上DEV（开发）、FE（前端）、QA（测试），大家猛烈抨击你的需求：实现不了，改！涉及面太广，改！华而不实，改！当所有人都认可之后（这中间可能不止一次技术review，而你的PRD会大变样），开始打分估工时。

需求评审阶段

需求评审（FR，Final Review），是一场血战，因为你的需求可能就此戛然而止，之前所做的所有工作就此付之东流。每个礼拜的某一天都会集中安排FR，所有需求的干系人都会到场，评审委员会由各个部门老大组成。回想第一次参加FR的情景，心有余悸，因为用毫不留情形容并不夸张。从项目评估开始，需求就会被挑战，每一个细节都会被盘问，技术的工时也会被进一步控制。最终，能够顺利通过评审的需求，并不多。

功能开发阶段

功能开发阶段，主要由DEV和FE同学负责，但是产品必须与其保持密切的沟通，已确保功能不走歪变形。同时，这短时间QA频繁地与DEV和PM沟通，编写checklist，全方位保证功能质量。之后，开始编写case（测试用例），一般由PM和QA一起操作，当然免不了增、该、删，因为PM对自己的需求最为熟悉，需要帮助QA同学考虑一些最有可能出现bug的环节。

编写case真的是一个虐心的过程，细化到每个操作动作描述以及对于出现的结果，一个下午40多个测试case，使我对需求又有了一次新的认识。

功能上线与后评估阶段

功能测试与上线，这个阶段是检验功能的成效与质量的环节，借助已编写case。测试的过程会出现各种状况，PM与QA及时沟通十分有必要。在提测的那两天，我就是带着笔记本搬个小凳在QA同学旁边，虽然坐在一群QA中间，但是的确我只是个PM。那时才弄懂了如何修改host、各种beta环境等等对我一个管理出生的学生而言十分神奇的东西。更多地了解所有的业务功能在上线前，都经历过怎么的内部迭代和一次又一次的质量敲打。

项目后评估。一般在PRD文档中会注明项目目标以及后评估的时间，如何检验公司花这么多资源上线的功能有没有用，就看这时候了。当然，还是得用数据，最好自己SQL，有时候还要设计运营数据日报。问技术同学，问数据运营的同学弄清楚各个表字段的含义，取你所需，为你所用。

四、感受

立志从事互联网工作的时间不短，但对产品经理这个岗位了解并不多，一个月前的认识就是停留在观察过以前同事，看过一些产品类书籍和自己在学校鼓捣过的地步，和自己真正去从事这项工作真的两码事。想象的都太过肤浅，诸多人对这个岗位有别样的热情，甚至非它不可，我觉得的确有些过了。如果有童鞋真的特别想从事，建议动用一切资源机会找一份实习去感受下。在去哪儿的这一个月感受挺多，自我感觉无形中成长不少，在这里总结了一下：

1. 沟通很重要。弄不明白就去问，找最熟悉的人去问，这个成本比你自己蒙头发现原因低很多，同时也能避免再次发明轮子的尴尬。不要磨不开脸，同事都很乐意解答，因为同时他们也在完善自己的工作；
2. 硬技能容易学，但是软实力不好培养。如果说你觉得自己不会Axure、SQL等等技能而放弃，完全没必要，这些只要有心都可以学会。真正要重视的是自己的软实力，比如阐述能力、逻辑思维、商业感觉、与人相处能力等等；
3. 细节，注重细节，任务要细化，思考要全面。任何时候提出方案都是需要可以直接执行，说通俗的一点，就是要落地。夸夸奇谈并没有任何成效；
4. 结果比过程重要。在以结果为导向的互联网行业内，没人在乎你当中多么艰辛，付出了多少，所有的评判都是结果怎样。企图通过任何过程的理由来解释结果，都是耍流氓；
5. 定位很必要，给自己制定计划。不能懒惰，逼着自己忙起来。学校生活很安逸，但迟早都得出象牙塔，早早规划好到毕业要走的路。与其找工作是抓瞎，不如笨鸟先折腾。找实习，抛开24h都自由支配的学校生活，像一个正式的职场人士去忙碌，公司没有实习生，只有员工；
6. 还有几点不断提醒自己可以使自己更强大：不要玻璃心、不要薄脸皮、不要牛角尖、不要愤青。

最后，欢迎大家对去哪儿提出任何意见。APP也好，主站也行，意见欢迎，投诉处理。

最后的最后，感谢领我入司的HR璐姐，老大晓晨哥、晗哥，不厌其烦解答我各种问题的天舒、丁晨哥、蔡师傅、老乡赞姐、京晶姐，以及一众包容我这个新人的同事们。

本文由 @郭佳冰 原创授权发表，并经人人都是产品经理编辑。转载此文章须经作者同意，并请附上出处(人人都是产品经理)及本页链接。