Liu 的个人资料唯有仰望是真实的照片日志列表更多  |  工具 帮助 |
|
2009/4/22 百度阿拉丁上线 http://alading.baidu.com/ 百度开放平台。这个太让人惊恐了。他们的一位内部人士说过，入口已经比源更重要。用户只记住了入口忘记了源。这个，如何权衡呢？ (via @qichangxing) 在twitter上面看到这个消息，琢磨着还真是，大家赶紧来抢坑吧，酷讯赶紧做一个机票/火车票的时刻表查询吧，希望带来的流量能够撑起足够的收入. 如果大家感兴趣，欢迎在twitter上follow我@ayuer. Google Analytics API发布今天，一个很振奋的消息来自于Google Analytics API team, Attention Developers: Google Analytics API Launched! 在Stanford ETL的ecorner的podcast中听了Brett Crosby讲述他们创建Urchin的故事，如何起步，如何面对.COM泡沫的破灭，如何被google收购。在其中他们提到在Urchin的时候如何使用web analytics来给客户提供价值，同样的商业模式现在仍然在被像Omniture, Webtrends等公司所继续。这种模式也许就是同客户达成“深发展”的模式，将analytics融入都客户的商业价值中去。 Google收购了Urchin之后，作为开放的服务为所有的网站免费开放使用，从一个别的web analytics公司想都不敢想的角度给这个行业带来了革命性的冲击，方便了很多的网站，将web analytics的概念和应用价值推广和普及到更多的站点负责人。 那么从一个皇家专属大厨变成一个麦当劳肯德基，这里面给客户提供的价值的创新有了变化，GA的使命是从一个很高层很普遍的角度来提供解决方案，虽然提供了很好的定制功能，促使产业链上咨询师和咨询公司的健康发展。在拥有了Google的品牌，推广渠道和技术的基础设施之上，他们作为一个web analytics工具比别家多了很多竞争优势，但是同时也限制了他们创新的方向。 这次API的发布是google的方式来带动这个不能说沉寂但是需要更多创新的行业活跃起来的创新举动，在这么一个春季，给这个行业带来了春的气息。 这之前，如果你的业务数据需要和站点访问数据进行整合，你只能选用GA然后收工整合，或者自己实现访问数据分析（这个是多么痛苦和艰难我想有经验的人都有体会），或者选择专业的Omniture等公司的服务。 API的利用远不止于此，有了它，你可以利用iPhone应用来查看你的站点访问情况，或者其他更创新的方式。 相关阅读：Google Analytics开放API (果然是媒体出身，文字写的比我好太多，多学习多学习:-) 2009/4/16 页面停留时间与站点停留时间(time on site & time on page) 很少的人知道他们如何计算，更少的人知道他们的价值和如何来利用。 相对与ROI，大家还是比较清楚其价值所在的，但是很少有人 能够看清楚其如何计算和得来的，只能看到一个黑箱，却不知道中间 的一步一步如何来的。 感谢Avinash至少让我们明白了停留时间这一点如何计算，清楚的给我们讲解了 其中的难点，关于跳离页的时间的计算方法与IE7和FF等在标签页浏览(Tab browsing)时的情况， 详情请参照。 http://www.kaushik.net/avinash/2008/01/standard-metrics-revisited-time-on-page-and-time-on-site.html 另外一篇来自2007年9月，google analytics调整计算站点停留时间受用户抗议回退的blog文章。 http://analytics.blogspot.com/2007/09/reverting-back-to-original-average-time.html 2009/4/15 关于问题的哲学朋友从福州网龙带回来的一个书签，关于问题的分类的哲学，很有意思，与大家分享。 新问题: 往往是老问题披着新外衣，解决的关键是不要着急去解决问题，先看清问题的本质再着手解决，不要头痛医头脚痛医脚。 老问题: 即重复发生的问题，老问题的根本是人的态度问题，解决之道在于人要改变的是自己，要丢弃的是借口。 解决不了的问题： 往往是思路问题，是角度问题，需要换个角度看问题，需要自我反思，需要借助旁观者，需要借助外力。 没有问题： 没有问题是最大的问题，说明你从来就没有对自身的问题进行检讨和反思，从来就没有看到隐患，没有感觉到外界的变化。 2009/4/10 产品经理眼中的7中工程师which one are your? and which one you want to be? 转载自http://www.renqijian.cn/?p=555 7种工程师类型在crankypm.com看到关于介绍不同工程师类型的文章，很有意思。工程师是产品经理打交道最多的对象，总得来说他们真诚、直率、聪明、执着，当然也有些小毛病。 我们来看看产品经理经常接触到的几种工程师类型。 第一种工程师类型属于工作狂型的工程师。 这类工程师非常热爱工作，并且非常有责任感，永远不用担心交给他的开发工作，他甚至会反过来催产品经理的工作进度，还会给产品经理一些好的用户体验和产品功能方面的建议。这类工程师绝对是产品经理最愿意合作的对象。
第二种工程师类型是经验丰富的工程师。 这类工程师可能已经在公司工作好多年了，他参与过很多产品线的开发，他对已有业务和产品的了解甚至比产品经理还要清楚。产品经理应该多和这些工程师沟通，从他那里经常能得到这样的有用讯息“这个事情几年前就有产品经理提出来想做过了，后来因为商业利益点不够明确，同时需要占用大量工程师资源，所以项目被搁浅了”。
第三种工程师类型属于技术牛人型的工程师。 这类工程师技术很牛，热爱开发工作，并且性格平易近人，他们也是产品经理喜欢合作的对象。这类工程师会自告奋勇的去啃技术开发中那些最难啃的骨头。当大家都觉得产品经理的提案太fancy已至于怀疑技术可行性和技术压力时，往往能从这类工程师嘴里听到这样的声音“如果真要这样做的话也是可以的，就是麻烦一点，可以这样这样…”
第四种工程师类型属于代码快枪手的工程师。 这类工程师一般很聪明，写程序很快，但是比较粗心，交给他的开发工作，本来以为他3天才能搞定的，他半天就搞定的，但结果测试花了5天。
第五种工程师类型属于标新立异型的工程师。 这类工程师一般也技术很牛，但是没有第三种工程师好沟通，他们看问题一般以技术为导向，不太喜欢听产品经理讲用户体验
第六种工程师类型属于吹毛求疵型的工程师。 这类工程师总是对产品经理写的文档吹毛求疵，包括对他不喜欢的产品经理也是吹毛求疵。总是认为产品经理的文档这里没写清楚，哪里没讲明白。要和这类工程师合作顺利，得要先和他搞好个人关系。
第七种工程师类型属于不善沟通型的工程师。 这类工程师要么比较内向，要么不善沟通，他总是说着工程师自己的语言“这个可以通过队列实现”，在技术部门和业务部门一起讨论时，需要产品经理要实时帮他翻译给业务部门听。
Randy Shoup eBays Architectural Principles据说是QCon上eBay的ppt, 在QCon@Beijing和QCon@SF等似乎是一样的，不过从eBay的经验中学到不少东西，很实在的经验。可惜不能看到更详细和具体的东东，也还没有找到视频，不过据说现场一般。
据说hongqiangning@Douban讲的session很赞，希望能够看到更多的资料。他们在scale的路上也走了三年多了，一定有很多经验。 还有Youku和网易的session。 Randy Shoup eBays Architectural Principles View more presentations from deimos. 如何写好MRD--something i wish i knew when i was 20从淘宝的一个产品经理的blog上看到几篇好的文章，觉得有必要分享出来给大家看。两外欢迎大家订阅我的google reader share, 地址在http://www.google.com/reader/shared/04136959170458108738。 这篇取名叫something i wish i knew when i was 20, 因为在这几年的工作中对如何产品，技术，设计各种角色的沟通遇到了很多的问题，也思考过很多关于其中的原因和如何改进的方法。虽然这篇文章讲的 1，是具体如何写MRD或者PRD的具体技巧， 2，甚至可能只在大公司会有如此八股文的正式的MRD，在小的团队中大家顾虑流于形式和附加成本太高的缘故几乎不存在MRD和其他一些方面的文档， 但是，文中体现出来的沟通的重要性和对沟通内容，方式和方法，途径的思考确激起了我的思考。 我经历的都是小的公司小的团队，对于大的团队没有概念。 在小团队中，沟通也是非常重要的，因为小，所以不能承担有队员往不同的方向努力带来的负面影响。 而有不少的研究表明，小团队中沟通程度与绩效相关性很强。找到此论据的source再贴出来:P 那么如何来做呢？ 你需要多学习，多思考，多尝试，多总结。有不少方式能够来改善沟通，你应该多了解别人成功的案例，对自己的情况进行分析，把好的方法根据自身实际的引入近来，一步步磨练你的团队。 下面是淘宝的一个PM翻译的关于如何写好MRD的十种技巧的文章，其中从用途和读者受众以及目的出发，讨论了写MRD的角度，写的方式，方法，内容和功能等各个方面。 产品经理写好MRD的十种技巧 http://www.renqijian.cn/?p=634 by admin MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。 在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。 在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。 写好MRD的10种技巧 1、从用户角度的编写 从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas）”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA（sales force automation）软件的“Login”的功能性。 方法A： 用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。 方法B： Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。 哪个方法更加容易阅读和理解?就我的看法,毫无疑问，”方法B”。还有，它同时减少了令人烦恼的阅读！ 2、使用Screen Shots 使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字！ 举个例子,看看下面这个screen shot，你需要多少字来描述？我想可能不只一千个字。  3、用简单的语言编写 在我超过11年的行业中，我通常注意到的（更多是令我懊恼）一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。 相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦（有时他们会把MRD撕碎然后再碎片喂给碎纸机）的用做作的语言的陷阱。 还有： a)保持简短的语句，把长的语句分解成多个小的语句。 b)避免大篇幅的连续文本，把他们分解成多个小的章节。 c)把大块文本内容分解成，screen shots，表格、重点列表等等。 4、小心的使用模板 我发现MRD模板非常有用。他们的几个好处包括： a) 模板提供了一个标准的格式，使那些不得不阅读大量MRD的读者更加容易阅读。 b) 模板让新的产品经理快速的写MRD变得容易，因为公司与公司之间的MRD内容是不同的。 c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分； 然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用： a) 产品经理害怕但又不得不写MRD - 就像不得不和Dick Cheney去南德克萨斯打猎一样（译者按：美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴）。 b) 工程师团队害怕但又不得不阅读MRD。 c) 写MRD和读MRD都需要花大量的时间。 我推荐你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。 5、区分需求的优先级 在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素！ 这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办法帮助让他们决定那些特性要实现那些可以推迟。 区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3…这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。 最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。 我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。 6、说明”是什么”和”为什么”，但不要”如何” 产品经理为理解客户的需求负责，然后基于这些理解，定义是什么和为什么需要开发. 一个只详细描述怎样实现每一个需求细节的MRD是工程师不想看到的。 考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。 推荐-描述“是什么” Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。 不推荐-描述“怎么样” Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。 好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。 我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。 附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。 7、覆盖非功能性需求 尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如： a)性能 b)可伸缩性 c)可用性 d)国际化 e)等等… 我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。 要点：当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。 8、评审&修正 我有一个朋友-我们叫他Matt（他的真名叫Steve）。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。 他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。 他是罪犯？他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们！ 不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你（或者至少少恨你一些），你的团队也将创造更好的产品。 9、定义市场目标和定位 大部分我看到过MRD在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做的很好。 我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些？拿到定义了什么是需要的还不够吗？” 这些问题（谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的）的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。 这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的（在MRD中）包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。 10、包含一个术语表 如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。 当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者（有些可能不是技术人员）理解你的意思是什么。 2009/4/8 “框框”里的突破性思考 -- 如何组织一个好的头脑风暴“框框”里的突破性思考 如何组织一个好的头脑风暴 Kevin P. Coyne, Patricia Gorman Clifford, Renée Dye (HBR 商业评论 2009年3月） 如果请你20分钟内拿出一份创业计划，你可能觉得这个任务又大又模糊，因此没法完成。很多人碰到这样的难题，都是浅尝辄止。 如果问题更具体一些，问你”Rollerblade， Häagen-Dazs和Spider-Man Movie有什么共同点？“，那么答案可能会比较容易找到－提供这些产品的公司，都是抓住人们在孩提时期的一个梦想，然而用一种发展到极致的，更加昂贵的方式呈现给成年人。鼓励你也想一想，能否找到类似的例子？ 使用这种方式的用意在于建立一个新的思维框架，这个框架既不是天马行空没有边界，又不同于已有的思维框架，限制突破性的想法。这正是三位作者作为McKinsey资深的咨询顾问，帮助很多客户公司解决问题的实际头脑风暴中总结出来，并在各种场合成功运用的方法。 头脑风暴缘何低效惯用的错误组织手段：1，鼓励大家跳出思维框架，漫无边际。 2，用新手法在老框架内进行剖析 1的问题在于大多数人不擅长无结构的，抽象的头脑风暴。 2的问题在于很难产生价值比较大的创见。 恰如其分的提问作者们10年前在McKinsey带领的团队进行研究时，了解到芝加哥大学心理学教授Mihaly Csikszentmihalyi的一项研究中描述了一些诺贝尔奖获得者和其他一些富有创造力的人是如何取得突破性成果的。其中有趣的一点时这些人只要头脑里形成了正确的问题，就会变的思如泉涌。无论什么业务，一个能够激发创见的问题是：“人们在使用或者购买我们的产品和服务时，不知不觉中遭遇的不必要的最大麻烦是什么？”或者我们常说的，“What’s their itch?”。很多创业者就是努力思考如何解决这些麻烦，举例有了Jiffy Lube(提供即使快速更换机油服务)，CarMax(以合理的固定价格，在怡人的环境里销售带有保修服务的二手车)，即买即用的预付费手机（省去20分钟的配置过程，而且不用冒付出高额话费的风险）等。 作者列出了“开发新产品的21个好问题”作为副刊，随后做个XMind脑图贴上来。  并且鼓励对好的构想和创意，反向推理最初是什么问题促使发现这样的机会的？ 使用逻辑树的方式来一步步细化和具体化思考，拓宽思路。  更好的组织头脑风暴1，给构想划定一个分为，然后据此选择和修改问题2，挑选能够提出新颖构想的人与会 3，确保所有的人都全心投入 4，合理组织会议，让社会规范帮助你，而不是妨碍你（如何协调少数爱出风头，喜欢左右讨论的人与选择缄默不语的有想法的人） 5，用预设的问题防止讨论过于发散（加一些限制更有利于发挥，可以采用分组分派主题限时的方式） 6，不要依靠一次头脑风暴会议解决所有问题（前期准备和后面的跟进） 7，在会上旧选出你将要深入研究的那些构想（不要担心会让构想落选的人失意，大多数人更希望当面决策，这样能从你的思考过程中学习，以便下次提出更好的想法） 2009/4/7 我们都是和自己赛跑的人by - 李宗盛 亲爱的蓝迪我的弟弟 |
|
|
