韩军星的博客

祝福所有的朋友们：

身体健康；合家欢乐；五福临门；牛气冲天！

本来春节回家后不准备写博客了，可今天上 Google 站长工具查看网站内容分析时，发现我的wordpress博客的标题标记有“重复的标题标记 6个”的问题，点击详情后显示“包含重复标题标记的页面”有3个，每个页面下含有一个加了 comment-page-1‎ 的重复页面。如：

http://www.hanjunxing.com/use-case-in-prd

http://www.hanjunxing.com/use-case-in-prd/comment-page-1‎

这是什么问题呢？Google 后发现原来是 wordpress 2.7 中评论分页搞的鬼。

wordpress 2.7的评论分页功能主要作用是在评论过多时，可以分页显示评论，以减少数据库查询次数，从而减少资源占用，同时也会提高页面载入速度。但实际上，对于大多数不知名的博客而言，每篇文章都有好几百个评论是不现实的。也就是说，这个功能对绝大多数博主而言比较鸡肋。

从实现原理而言，评论分页自动生成了原文URL+comment-page-1‎或 comment-page-2…这样的页面，但是这些分页依然采用原文的 Title、原文的 Meta 等信息，这就造成了 Google 工具认为出现了“包含重复标题标记的页面”。我们知道，重复页面对 SEO 不利，严重时可能直接导致网站被K，所以这个问题越早解决越好。

解决办法：进入 wordpress 博客后台，设置-讨论-评论分页关闭（取消选项中的对勾）。

问题就是这么简单。话说回来，评论分页这个功能对我而言的确挺鸡肋的，但如果你是名人，发个文章就无数人抢沙发，那这个功能再合适你不过了。不知道什么时候我才能真正用上这个功能……

我的小黑 ThinkPad T61 前几日花屏了，折腾了一晚上也整不出什么毛病，于是打电话到联想维修中心；谁知道对方说我这个是水货，虽然能够查到全球唯一的序列号，但还是无法提供保修。本应全球联保的 ThinkPad 只有中国特殊……理论了半天，我说我花钱修还不行么，但还是被对方严厉拒绝了。联想逼我去中关村的黑店，我也病急乱投医，在 Google 上搜到家感觉还行的维修公司，北维笔记本数码维修—号称中关村第一家可现场观看的笔记本维修中心，于是17号把本拎了过去。

后面就不用多说了，显卡问题，需要换主板，1350元。工程师还打趣说，“显卡门”事件，我中招了。

网上随便搜一下，叫骂声一片，NVIDIA 的专业笔记本显卡 NVS140m 系列产品部分存在严重质量缺陷。不过 NVIDIA  作为负责任的行业领导者，还是很快拿出了2亿美金给相应电脑厂商作为补偿。可惜我这样的水货客户们是一分钱补偿都没有的，还要为这个缺陷买单。难道 ThinkPad T61 这样的本，偶尔运行下 WOW 都不行么？

过两天就放假了，北维今天打电话来说库存主板出了点小问题，能否年后再拿本。OK，我等着，北维客服态度还是不错的，但我更看重结果。黑不黑，看良心，中关村混迹的维修中心多入牛毛，修的好坏，我都会为这个公司做宣传的。持续更新中……

美国东部时间20日上午12点，北京时间21日凌晨1点，奥巴马在国会山正式成为美国第44任总统。

奥巴马手按林肯当年宣誓时所用得《圣经》宣誓，并在随后发表了激情洋溢得演讲。

我最关注的一点就是他在演讲中提到：

know that America is a friend of each nation and every man, woman, and child who seeks a future of peace and dignity, and that we are ready to lead once more.

美国是所有国家、所有试图寻求和平和尊严的男人、女人、儿童们的朋友，我们已作好了再次担任领导者的准备。

世界的领袖，没错；在其位，谋其职，以目前美国得综合实力，我相信这并非是吹牛皮般无聊的政治说辞。敢于承担，奥巴马，你算个爷们儿！

Google 卫星拍摄的就职现场：

奥巴马就职演讲中英文对照版

随便翻了翻 Google Read 中订阅的文章，在睡到自然醒发现一篇能够查询跟自己共用IP的网站的小工具“You Get Signal”很不错。

不查不要紧，一查吓一跳。原来跟自己共用 IP 的网站竟然有38个之多……并且其中大部分都是国外企业级的网站。还好 Hostmonster 主机使用的感觉还是很不错的，没有出现过当机和不稳定的情况，速度也比较快。可惜了我的无限空间、无限流量还远远没有充分利用……

话说回来，由于公司封 QQ 的 IP，不知为何顺便把我的博客IP 也给封了，找技术很多次也无法解决，真把我郁闷坏了。查阅了大量的资料，无奈对局域网的了解还处于小白状态，只好这么拖着；网站的问题，只有回家利用休息时间搞了。说不定那天也心血来潮，买个独立 IP 玩儿……

QQ 邮箱在08年5月改版后，市场占有率不断攀升，记得我也是那时开始关注QQ邮箱的。现在的QQ邮箱很多功能非常实用，易用性也不错，但是如果没有一个杀手级的应用，我还是继续会对 Gmail 推崇备至。而这个改变我习惯得杀手级应用就是“QQ邮箱的订阅空间功能”。

虽然现在互联网中 SNS 吵的火热，开心、校内热闹非凡，但个人感觉QQ才是真正的“社会性网络服务”（即 SNS），至少目前在中国，马化腾QQ企鹅帝国在 SNS 领域的造诣是数一数二的。回到正题，QQ的空间有多少人再用我不知道，但我身边用的人至少有80%以上。跟新浪、网易的博客不同，QQ 空间能够借助 QQIM 这个平台，充分地展示博主的个人生活。比起来市面上那些所谓的SNS社区挖空心思拉用户写东西而言，QQ 空间真是占尽了先机。为了更加方便地使用户阅读 QQ 空间，QQ 邮箱将Feed RSS 整合了进去。与 Google Read 不同，QQ 邮箱能够提供现成的好友日志，你再也不用对着 QQ 几百个好友狂点鼠标了……

也正是这个杀手级应用，迫使我每天登陆一次 QQ 邮箱。在享受 QQ 邮箱专享的空间 RSS 之外，也发现了一点小小得缺憾。之前在意见反馈中提出过，但貌似已经被淹没在了很多不痛不痒得言论之间。所以在此对 QQ 邮箱订阅空间的小缺点发一发牢骚：QQ 空间中，一部分用户将自己的空间设置为仅主人可见或者密码访问时，QQ 邮箱订阅空间功能并不能对这样的空间做一个统一的管理。如图： 

这样的空间并不少见，但如果你的订阅中充斥着验证和保密，是大煞风景的。一方面，如果通过IM查看空间，设置隐私的朋友如果你不知道密码或者通过密码也无法查阅时，有过一次失败的经历后，一般是不会二次点击的（除非你对这个人很感兴趣），而QQ邮箱将这样得日志强制放在了你的订阅中；另外，被设置密码访问的日志如果你输入了正确的密码，那么下次需要继续输入，并不能通过cookies记录；最后，不知道密码的日志或者完全隐私的日志并不能通过设置自动屏蔽或者开启，而是需要进入好友管理一一取消订制，这是非常不方便的。

我更希望的是，如果在浏览订阅空间时，发现有设置隐私的空间后，能够直接取消这个空间的订阅，而如果这个空间之后又完全开放了，QQ邮箱能够在我下次登陆后自动提醒我是否继续订阅。

其实，QQ邮箱的用户体验已经做得很不错了，但爱之深，恨之切，希望QQ邮箱订阅空间这个小功能能有更好的改进和更人性化得设置。说实话，这些细节，不是老用户真的很难体会到的……以用户为中心的设计不只是一个口号，落在细节得设计才真正是好用的设计。

产品需求文档（Product Requirement Document,PRD）在 WEB/软件项目中的作用不言而喻，一份好的 PRD  能够使整个项目事半功倍，因此花在 PRD 上的时间成本通常也是非常可观的。我见过几个内部需求项目，PRD 的 word 文档竟然也有几十M之巨，产品需求人员在其中所耗费得精力可见一斑。

chinapm 中汤圆将 PRD 的核心概括为

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。

而 PRD 中这个“详细”和“量化”究竟到什么程度，是产品管理者经常遇到的问题。一方面，如果 PRD 中的需求描述或用例说明没有具体到具体细节操作，一旦开发人员理解有误或不完整，则会对出现不断的变更或返工（通常，开发人员喜欢闷头开发）；另一方面，如果将 PRD 内容描述得过分细致，则又会出现很高的成本，何况百密一疏的情况也是非常多见的。如何解决这个问题呢？

《编写有效用例》一书中提到了描述事件流程的基本方法，不论具体的用例是由需求人员做，还是技术人员做，都是需要了解的。对于用例中的 include 部分一定要细致入微，而 refine 部分则可以分清优先级考虑。

include，表示你要在一个用例当中包含另一个用例，并且被包含的用例是必须的，如果缺少被包含用例，则主用例就不能完成。比方，在用户管理场景中，要删除一个用户，你必须先查询到该用户，然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine，是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容，只是更加细致。比方，取钱是一个用例，在描述用例场景时，你会用核对帐号，效验密码等活动来描述取钱的场景。在概念分析时，你可以把核对帐号，效验密码等定义为用例来描述取钱的过程，这时核对帐号，效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程，但是取钱在概念阶段被精化成了核对帐号，效验密码等粒度更小的用例，这此用例仍然需要描述用例场景，例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要，向下则要更进一步能接近系统分析所需要的粒度。
同样的道理，如果需要，核对帐号，效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字，所描述的内容也从业务描述精化到了系统交互，但描述的仍然是取钱这一个业务。

当然，最重要得依旧是团队合作。在项目运行中，可能发生任何事情，但只要大家做好沟通，没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典，我就不班门弄斧了。临近春节，快递都放假了，不然也想尽快拜读一下他的大作《大象–Thinking in UML》。

需求变更在项目管理中是经常遇到的问题，特别是当项目进展到尾声时，一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微，在开发阶段滴水不漏，在流程管理上规规矩矩，但无奈的是，我们的客户总是希望拿到更完美的产品。于是乎，变更就成了结项后的潮水，一波一波，无休无止。不是你的产品坏，是这个世道变化快……

如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。

首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；

其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；

最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。

需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。

通常，一个产品项目完整的周期包括前期调研、立项、需求文档、开发、测试、部署等。其中，用户、销售、市场可能需要参与前期的调研和需求；开发到部署主要由技术部门负责；而产品经理负责整个产品项目的周期。虽然结项是这个周期的结束，但实际上项目的结项也是产品另一个周期的起点。

1、试用期-完善产品
试用期对绝大多数新产品来说都是必须的。产品本身是为需求而设计开发，最终还要回归到用户中去检验这种需求是否被满足。特别是对于技术主导的网络、软件等IT产品而言，试用期可以很好的检验这种新技术的价值；而没有试用期的产品是危险的产品，就像新研发的药物没用经过活体实验及持续不断的跟踪观察一样。
通常，试用期阶段的产品能反馈给产品经理绝大多数的 BUG 或需要再次完善的地方，如果持续关注和改进，产品本身也会不断完善，直到被用户认可。一般这个周期是三个月。

2、应用期-改进产品
在应用期前，产品应该已经能够满足用户的基本需求。其中，除了对产品正常的维护外，最需要关注的就是用户体验。在产品开发周期中，如果在用户体验方面已经足够关注，这里应该能节省绝大多数的时间，但这并不意味着你不需要对用户体验在做关注了，因为产品团队并非用户本身，真理也需要实践的检验，何况是你的产品？当然，如果这个产品在开发周期中从未关注过用户体验，那么相信这个产品已经被抱怨淹没了。你的产品是以用户为中心的吗？能用-有用-易用-好用……改进有很长的路要走。

3、升级-让用户知道你在进步
你的产品不是真金白银这种硬通货，在竞争如此激烈的今天，一成不变的产品再完美，也会转眼成为昨日黄花，时刻保持危机感，定时或不定时升级你的产品，哪怕仅仅像新款牙膏只是将牙膏口开得大了点这样的升级，也会使你的用户感到，你非常重视他们，这很可能意味着忠诚度的提高。

以上是最近做的两个项目下来的切身感受，一点浅见，适用于互联网产品以及软件产品多些，有不完善的地方，还望大家指教。