淘宝商城实习三月记产品经理做什么

　　工作之前
　　角色转变
　　从程序员开始
　　大二起，发现自己在信息技术方向上的兴趣，更多地偏向互联网。说干就干。初中有用FrontPage和Dreamweaver自制网页的小经验，便到图书馆拿HTML和CSS方面的书读起来。一天时间通读，就手工写出了DivCSS的代码，整齐美观，颇为自豪。快速学习的能力是一方面，最重要的地方在于，这份网页不再是通过Dw点来点去、画表格或者使用层东拼西凑，而是纯手工且符合万维网联盟（W3C）标准。这意味着我写的东西不再是玩具；它们进入了可应用的行列；
　　特长和志向不在视觉设计，我也不满足静态网页。选择PHP，因为它使用广泛，入门容易。有了初中Basic和大学C语言的基础，这样的脚本语言很快可以写出来。很自然，MySQL和Javascript列入了我的书单。
　　为了检验学习成果，我立了一个博客项目。衡量其好坏的标准在于，能囊括目前博客网站的多少功能。为了检验应用能力，大胆独立外包了一个电商网站，其中的关系、权限的复杂度与支付功能是从未遇到的。网站勉强顺利开发到一半，老板突然决定改设计成商品展示网站。这下自己减负很多，项目圆满完成。
　　项目经理
　　做外包项目的同时，我已经把自己定位成PHP程序员。空闲之余，在PHPChina网站上捞各种招聘信息。经过多番了解和学习，我发现自己并不适合开发：
　　数学不好，而且对之深恶痛绝
　　缺乏复杂逻辑计算的天赋
　　代码看多了眼睛疼
　　综上所述，恐怕我根本不是开发的料。不过只是借开发之力，完成项目。而且，开发也不是我想要的，因为我：
　　对一个项目（工程、产品）导向感敏锐。不敢称为战略
　　执着于产品设计。包括版式、视觉、文案等
　　要求苛刻，追求完美。对字符、像素级别的单位挑三拣四
　　我想要：
　　改变世界。我们的生活糟糕透顶，需要一个东西彻底颠覆
　　成功。有力量持续改变
　　我以为这样的孩子名头叫项目经理，他来决定程序员写什么。走进项目的流程，进入其涉及的范围，第一步便是搞清什么是项目。这个时候又才了解，相对的，还有产品这个概念。
　　产品经理
　　产品旨在满足需求。产品经理的职责是探索和定义产品：探索价值，定义解决方案。
　　这正合我的胃口。我转个弯，一方面，广泛学习请教产品知识；另一方面，也做项目自察。做产品容易假大空，为了避免如此，我把在博客园上本来准备为技术沉淀的博客，搬迁到了独立博客上。使用独立博客的好处是：
　　显得专业
　　能够炫耀
　　要花钱，所以得坚持
　　本身便是一款产品
　　自此，开始研习产品的学问，所思所得都记于此。
　　应聘淘宝
　　3月8日投递简历
　　淘宝是我应聘的第一份正式工作。
　　去年得知它们有一产品经理特训班。既然专门为咱们这号人打造，自然不能错过。
　　22日参加宣讲会
　　全程很傻很天真地做了笔记。囧。
　　27日现场笔试
　　路痴加上得到了错误的指引，硬是在校园里绕了一个多小时。
　　淘宝笔试的题目分为数学题、逻辑题和论述题，题型为选择题、填空题和问答题。数学考概率、数据结构和指针；逻辑考推算、解除纠纷和推理；论述考写字楼电梯设计和淘宝买家产品设计。刚拿到题目还是觉得挺别扭的，毕竟大学里的考试，你懂的。认真做下去之后，不仅发现难度正好，还觉得挺有意思。最后一题因为时间紧张，只剩下5分钟，答得没有条理，也不够细致。
　　4月14日现场面试
　　准备最多的还是保洁八大问和群面攻防术。我以为会有多复杂，多紧张，结果到了淘宝面试现场也就那样。
　　一面首先自我介绍。根据网上的经验，一句话结束。然后面试官震惊了，要我说个1015分钟，然后我就震惊了。介绍完毕后，主要是询问自己一个做着玩的项目，重点在商业机会。完毕，面试官叫我直接去二面，我本来以为要等个几天的。
　　二面首先自我介绍。根据上一轮经验，我准备开始滔滔不绝。结果，我说的每一句话都被打断这回是盘问而不是询问了我也知道，压力面来了。在交谈的过程中，根据学生会的经验，主要把握三点：线索、成果和收获。线索是跨话题的润滑剂（井井有条就免了，能不生硬已经万幸，又不是演戏），成果是成功的收获，收获是失败的包装。
　　看上去很淡定是么？其实根本就不是这样，哈哈哈。还好也没差哪去。
　　这次面试最大的不足在于，畏惧权威，依据不严谨，导致说服力度没有到预期的档次。另外，我不推崇繁复的自我介绍，因为简历上已经写得明白；我推崇相互尊重。
　　18日收到录用书
　　进入淘宝商城
　　开始
　　纸上谈兵
　　初来乍到，第一反应就是和所阅相比完全不是一回事这些书还都是有关互联网、大产品部门；和学校更是风马牛不相及。具体说来，就是和预期各种不符。根据我的理解：
　　产品经理无授权领导，交换意见后拍板决定
　　产品需求文档保持更新，有据可查
　　项目经理负责掌控项目进度
　　开发不受到打扰，专心进行编码工作
　　运营负责提供数据，供产品经理决策
　　用户体验部门充分独立，为用户体验提供捷径
　　会议有了邀请制、预告和纪要，因此高效
　　经过充分讨论思考，得出问题最佳突破口
　　最终产品功能好用，途径从简
　　事实并非如此。
　　方向、目标、途径
　　当一套知识体系不够用的时候，捷径是获取并切换成另一套，比如公司对员工技能的定义。这一套概念非常有效，因为它努力避免了套话，把具体的能力细化成可以考量的规范；最重要的是，经过证明，它行之有效。好比同样是《小学生守则》，中国讲诚实守信，美国讲考试不许作弊。
　　达成目标最好的技能是主动，但有一股劲使不出也不是个事。这个时候，我发现《启示录：打造用户喜爱的产品》当真是葵花宝典啊啊啊，尤其是第2830章，一条一条地讲碰到什么问题，怎么去做。比如：会议太多，导致产品毫无起色，怎么办？
　　我开始的做法是，抱着本本去开会。如果内容无关紧要，我就可以做自己的事。但这样明显会有几个问题：
　　做事分心
　　会议上的内容没有听好（特别是当别人问起来，自己一无所知时，就悲催了）
　　显得（也确实是）效率低下，做事不专心
　　书里介绍的办法是：直接划去（借口推辞）不重要的会议。比如，有的会是讨论背景，有了结论（做不做，做什么样的需求）后才能和产品经理讨论具体需求。曾经出现这样的状况：讨论了一个上午，把这样的需求删了，或是归并到另一个部门里，自己白白牺牲。
　　在横冲乱撞（很能导致瞎忙活）前，看看有没有好办法；但不论怎样，做，总有收获，错误的路径划去一个是一个，就像爱迪生那样。
　　工作
　　工作环境与同事
　　工作起来比较轻松、开朗、活泼；既很黄很暴力，也很闷骚。好吧，最后两句是我自己加的。大家干起活儿，会碰到各种狗血。比如，教师节，周围会有淘宝大学的同事拿着垃圾桶敲锣打鼓，旁边还挂着牌子：严肃amp；amp；回避。
　　休闲吧的桌上足球不用说，免费的咖啡和奶茶不必说，22点半以后送上门的宵夜自不必说，周六周日来公司可以蹭两餐饭也不必说，最让我觉得有意思的是咱们的卫生间。其间会挂有宣传画，也就是广告，像出什么产品啦，有什么相亲活动啦，做什么折扣啦，用词极为忐忑。比如：二十一世纪最缺什么？老湿！欢迎各位小二来为大家讲解。来就有奖品赠送，至于你信不信，反正我是信了。地球再也无法阻止你湿了，快来报名吧！
　　咳咳，接下来是重点：一次在男生小便池前看到的宣传画是：卫生巾在聚划算打7。5折，于是各种苏菲弹力贴身。男生的大便的隔间里，除了有贴心的卷纸、挂钩和肥皂盒（放手机用）外，还有一块纸板一支笔。我俗称为吐槽板，因为咱们会在上面进行各种吐槽，什么找不到女朋友啊，月光太冷啊，等等。不仅如此，还会整整齐齐地盖楼，各种苦屄你伤不起。
　　办公桌之间的隔板低到相当于没有。我的师兄在我左侧，老大在后面，整个产品技术部的领导就在我对面，囧。同事都很年轻，所以都hold住。好吧，正经一点，总的来说就是：团结紧张，严肃活泼。
　　每天出入大门，保安同学都会亲切地微笑，道声好。一次周末因事赶去公司，15点多才买了泡面当午饭，扫地的阿姨很温馨地和我讲：小伙子，再忙也要吃好饭。
　　认真工作的人，真美。
　　需求文档与原型
　　如果产品需求文档不靠谱，或许有这些解决办法：
　　冗长。像写散文一样，精炼语言；按功能点场景撰写，使用有序列表；重要的废话放在附录里
　　不直观。绘制高保真Axure原型
　　容易过期。任何改动，都更新到文档里，口头除外
　　存在版本控制偏差。严格标明版本（包括文件名和文档内部），每个版本都输出。pdf文档
　　原型也有：
　　非高保真。高保真意味着生成的是。html页面，而不仅仅是截图。菜单是能弹出的，下来列表是可以下拉的。直观，可以简单试用
　　交互复杂。原型是为了演示逼真；复杂交互由于藏得太深，容易忽略。对于复杂的交互，不如拆开成场景。以注释的形式附在交互处旁边，标注其将进入什么场景。注释区域必须一看就知道是注释
　　无法精确还原功能点场景。精确还原需求文档所写是原型的意义。对于一个场景，能对用户的所有行为做出响应。为了避免使用者漏掉某个行为，以注释在形式在空白处穷举
　　重要的是执行。最重要的这一步，我还很欠缺。
　　沟通，还是传话筒？
　　一款产品通常这样经过：需求（来自运营）产品开发用户体验安全测试发布反馈（来自运营）。产品只是传话筒吗？如果去掉产品环节，让他们直接沟通，会不会更好呢？
　　不会。因为：
　　提需求的同学精于运营，缺乏可行的概念。他们知道自己有痛处，但不知道什么可以做（不知道所以想不到点子），什么不能做（想到了点子却做不到）。于是局限了满足需求的方式，更重要的是，隐藏了深层需求
　　开发和用户体验的同学精于实现（可行可用），缺乏对价值的把握。运营和开发同学直接沟通的成本非常大，一是语言不通，二是难以对需求进行有效挖掘
　　产品可以做的事有：
　　掌握现有产品工具技术的实现范围，跟踪其外延。做决策时便有确凿的依据，什么功能能实现，什么不行。不行的话，可以做到怎样的程度，需要多少成本
　　深度挖掘需求。运营同学有了需求后，往往会告诉产品他们想要的，却鲜说（或说不出）真正渴望的东西。如果是这样，一来没有满足真正的需求，导致需求变更频繁，二来，体现不出产品的价值。比如，他们想要一瓶可乐，我们给了，他们又觉得不行，想要一杯橙汁。而他们的实质是口渴了，需要一杯白开
　　在实际沟通中，某些开发和运营同学明显比我考虑得周道；再加上开发更懂技术，运营更谙运筹帷幄之道，作为产品新人，我表示压力很大。
　　说不与责任心
　　对产品负责，就是产品在大产品团队合力的情况下，平稳地向积极的方向迭代，有数据和指标可查。在迭代的路上，总会半路冷不丁杀出来一个坎坷，躲都躲不掉。说说我遇到的情况：
　　更多需求（产品）
　　更多需求（功能）
　　需求变更
　　缺乏开发人手
　　会议太多
　　邮件太多
　　缺乏思考时间
　　对于以上的种种问题，步骤有二：
　　说不。很多情况（麻烦），直接拒绝，会省下很多精力做真正该做的事。做产品要精，但不代表事必躬亲
　　对于非一条产品线（部门）的需求，大部分直接回绝
　　同一条线，则根据其价值、开发人手、关系有选择地考虑。需求的紧急程度永远不在考虑的因素范围内，因为所有的需求都自称最急迫。其重要程度则有明显的区别，比如能带来多少交易额，提高多少转化率、流量等
　　对于一款产品本身功能的多寡，则逐个砍，砍到除非确实不能满足需求或严重影响用户体验。这里存在两点，一是有的需求不可避免，比如为了应对政治、营收和竞争对手需要；二是用户体验的概念泛化，每个人嘴里都在说这四个字，成为各种挡箭牌。产品的好坏，取决于其核心竞争力。做不好核心，边边角角再漂亮都没用
　　不少会议可以推掉，如前所述。推不掉的会议可以参加需要自己参与的部分。会议纪要非常重要，未出席的会议，主要靠它来了解情况
　　绝大多数口水邮件都可以忽略。MSOfficeOutlook2010就有这个功能，单击一下，自动忽略指定话题
　　推动。以前我用的词是跟进，被老大否了；以前我说他们，老大要我说我们。别小看词汇，反映的是态度
　　需求一定是可以变更的，控制好变更频率是王道。我的实例是，每周四提变更需求，周五确认需求，评估可行性和开发周期。在开发周期内，冻结一切需求（1的紧急需求除外）。下周一开工，周三发布上线，拉取运营数据，周四评估是否提新需求还是变更
　　缺乏人手非常普遍。首先，提需求前考虑人手状况；然后，确认需求时确认开发资源（人手、服务器状况）；最后，开发周期内，定期向开发同学询问是否需要帮助，顺便掌握进度和人员情况。如果在立项之初就争取不到人手，办法有：让需求方排优先级；证明需求的价值；向老大请求支持；找朋友帮忙；自己顶上；砍掉该需求
　　利用个人时间思考。我们都笑说产品一天的工作是：白天开会晚上写文档。时间挤一挤，总是有的。有意思的是，做产品不存在工作地点和时间的局限，很多好的点子就来自生活
　　感悟
　　对人尊重。大多数同事都平易近人。养尊处优惯了，遇到不对板的就显得手忙脚乱。一次营销活动，运营的同学非常强势，没有好脸不说，语气还咄咄逼人。经常会说，哦，你把这个给我做了，那个怎么又出问题了，你是怎么搞的。而我又是个暴脾气，一两回还行，次数多就非常受不了。
　　后来师兄问我是不是觉得很委屈，我一个劲点头。他告诉我，要学会看人，这也是尊重人。尊重，意味着考虑其人的性格、办事风格以及当时的环境。那位运营同学平时就是这个样子，办事也比较容易激动。当时她负责的活动别人不大看好，她一揽全局接下来，想做出成绩。更重要的是，她并不是对我一个人这样，而是所有人。将心比心，谁都可能有这样的时候。
　　其次是对尊重二字的理解。尊重体现的是修养，而非交换。好比，横穿马路就像一百人对自己骂娘一样感到耻辱。这是自发的。笑笑，说几句好听的；或是有确凿证据时指出对方的错误，再来一起解决，都有助于合作，最后达到产品预期。