随便翻了翻 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之巨，产品需求人员在其中所耗费得精力可见一斑。
该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。
而 PRD 中这个“详细”和“量化”究竟到什么程度，是产品管理者经常遇到的问题。一方面，如果 PRD 中的需求描述或用例说明没有具体到具体细节操作，一旦开发人员理解有误或不完整，则会对出现不断的变更或返工（通常，开发人员喜欢闷头开发）；另一方面，如果将 PRD 内容描述得过分细致，则又会出现很高的成本，何况百密一疏的情况也是非常多见的。如何解决这个问题呢？
《编写有效用例》一书中提到了描述事件流程的基本方法，不论具体的用例是由需求人员做，还是技术人员做，都是需要了解的。对于用例中的 include 部分一定要细致入微，而 refine 部分则可以分清优先级考虑。
include，表示你要在一个用例当中包含另一个用例，并且被包含的用例是必须的，如果缺少被包含用例，则主用例就不能完成。比方，在用户管理场景中，要删除一个用户，你必须先查询到该用户，然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine，是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容，只是更加细致。比方，取钱是一个用例，在描述用例场景时，你会用核对帐号，效验密码等活动来描述取钱的场景。在概念分析时，你可以把核对帐号，效验密码等定义为用例来描述取钱的过程，这时核对帐号，效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程，但是取钱在概念阶段被精化成了核对帐号，效验密码等粒度更小的用例，这此用例仍然需要描述用例场景，例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要，向下则要更进一步能接近系统分析所需要的粒度。
同样的道理，如果需要，核对帐号，效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字，所描述的内容也从业务描述精化到了系统交互，但描述的仍然是取钱这一个业务。
当然，最重要得依旧是团队合作。在项目运行中，可能发生任何事情，但只要大家做好沟通，没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典，我就不班门弄斧了。临近春节，快递都放假了，不然也想尽快拜读一下他的大作《大象–Thinking in UML》。
需求变更在项目管理中是经常遇到的问题，特别是当项目进展到尾声时，一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微，在开发阶段滴水不漏，在流程管理上规规矩矩，但无奈的是，我们的客户总是希望拿到更完美的产品。于是乎，变更就成了结项后的潮水，一波一波，无休无止。不是你的产品坏，是这个世道变化快……
如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。
首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；
其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；
最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。
需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。
通常，一个产品项目完整的周期包括前期调研、立项、需求文档、开发、测试、部署等。其中，用户、销售、市场可能需要参与前期的调研和需求；开发到部署主要由技术部门负责；而产品经理负责整个产品项目的周期。虽然结项是这个周期的结束，但实际上项目的结项也是产品另一个周期的起点。
1、试用期-完善产品
试用期对绝大多数新产品来说都是必须的。产品本身是为需求而设计开发，最终还要回归到用户中去检验这种需求是否被满足。特别是对于技术主导的网络、软件等IT产品而言，试用期可以很好的检验这种新技术的价值；而没有试用期的产品是危险的产品，就像新研发的药物没用经过活体实验及持续不断的跟踪观察一样。
通常，试用期阶段的产品能反馈给产品经理绝大多数的 BUG 或需要再次完善的地方，如果持续关注和改进，产品本身也会不断完善，直到被用户认可。一般这个周期是三个月。
2、应用期-改进产品
在应用期前，产品应该已经能够满足用户的基本需求。其中，除了对产品正常的维护外，最需要关注的就是用户体验。在产品开发周期中，如果在用户体验方面已经足够关注，这里应该能节省绝大多数的时间，但这并不意味着你不需要对用户体验在做关注了，因为产品团队并非用户本身，真理也需要实践的检验，何况是你的产品？当然，如果这个产品在开发周期中从未关注过用户体验，那么相信这个产品已经被抱怨淹没了。你的产品是以用户为中心的吗？能用-有用-易用-好用……改进有很长的路要走。
3、升级-让用户知道你在进步
你的产品不是真金白银这种硬通货，在竞争如此激烈的今天，一成不变的产品再完美，也会转眼成为昨日黄花，时刻保持危机感，定时或不定时升级你的产品，哪怕仅仅像新款牙膏只是将牙膏口开得大了点这样的升级，也会使你的用户感到，你非常重视他们，这很可能意味着忠诚度的提高。
以上是最近做的两个项目下来的切身感受，一点浅见，适用于互联网产品以及软件产品多些，有不完善的地方，还望大家指教。
“产品（product）”对我们每个人来说都不陌生，日常生活中我们也总是与形形色色的产品名词打交道：免检产品、IT 产品、产品设计、产品管理、产品忠诚度……可以说，只要有需求，就会有相关的产品满足你，我们的生活也离不开产品；而由产品衍生出的相关管理思想也在不断的推动着市场营销理论甚至企业管理本身的发展。
那么，究竟什么是产品呢？早前我的博客中，有部分提到过对产品简单的认识，实际上，不同的行业中有不同的定义，但我们还是可以简单得概括一下：
产品的狭义概念：被生产出的物品；
这是产品的原始概念，即人们通过劳动生产制造出来的物品。
产品的广义概念：可以满足人们需求的载体；
产品的概念随着经济和市场的发展而被扩大了，首先产品本身可能并非是由生产制造而来的，比如天然宝石、原煤等（未被开发的自然资源并不能算是产品，虽然这些资源本身能够满足人们的需求，但也要等它们真正被发现和挖掘出后才有交换价值）；其次，产品不一定是物品，也可能是某种服务，甚至包含物质实体在内的一体化解决方案；最后，产品必须能够满足人们的某种或多种需求，比如“我们需要人体工学的键盘系统”；
有人把产品理解为商品，其实是不确切的。产品和商品的区别在于，商品是用来交换的产品，商品的生产是为了交换，而当一种产品经过交换后进入使用过程后，就不能再称之为商品了；当然，如果产品又产生了二次交换，那么在这段时间能，它又能被称之为商品了。
需要注意的是：所有的产品都是具有使用价值的，这是产品的自然属性；一旦产品失去了使用价值，就成为了废品。这一点非常重要，因为产品的使用价值越高，则越能够满足人们的需求，那么就会给你带来巨大的商机。换句话说：如果你的产品能够很好的满足市场需求，那么你的产品就是成功的产品，它可能会为你带来滚滚利润！
到这里，相信你不会再为繁琐的概念解释而无精打采了，可惜，如何通过合理的产品策略赚钱是以后要讨论的问题；本篇主要讨论什么是产品，以及产品的相关注意事项，希望这篇“什么是产品”能满足需要她的读者。
最近，公司封掉了QQ，这也意味着我无法通过QQ上的签名来提高博客流量了。
对于一个新开的博客来说，朋友的支持是尤为重要的；而目前，我的博客日均IP中的一半以上来自直接输入；虽然总流量只有十几，但我已经很知足了。
公司的这个决策的对错我先不予置评，抱怨并不能解决问题。穷则思变，变则通。看来我不得不思考下一步的发展了。
首先，对于我这个新生的网站而言，我并不能过分去追求流量，因为流量是随着网站的发展慢慢才能形成规模的。而我最需要做的，就是持续不断的更新，争取能够积累下来一些好的博文。我要写什么，读者要看什么，这个度在目前而言我并不清晰，也不能够做到有针对性得写东西。虽然我不希望这个博客成为个人日记本，但实际上，文章或多或少都会涉及一些身边的事务。毕竟我非砖家，非叫兽，更非名人。我希望分享自己在工作中所学到的和感悟的东西，这些东西作为资料也好，作为评论也好，不知对我，也对一部分读者有价值。这就够了。
其次，我相信之后的大多数流量都会来自搜索引擎，值得庆祝的是，昨天时，我的博客也已经开始被百度收录了。在随后的文章中，我会更珍惜搜索引擎带来的流量，同时也会做好SEO。
最后，必须更加重视用户体验。亏我还是做产品需求的…就自身的观察而言，这个博客的用户体验很一般。该没有的没有，该有的也没有，很是惭愧。但是这也是需要时间的，毕竟对于 wordpress 程序来说，我依旧是个菜鸟。不过，我会尽力做好的。
针对博客中的问题，在这里也提出几点改进，如有遗漏，还望大伙不吝赐教：
1、标题尽可能简明扼要
之前的标题有点凑数的感觉，很不美观，也降低了标题在SEO中的权重分布；
2、取消分割线
文章添加分割线有很多好处，但最致命的缺点就是给读者造成了麻烦。可以想象你看到一篇很感兴趣的东西时，发现这个页面能呈现给你的只有一半的内容！你不得不点击一下“read more”才能继续查看；或许点一下那个可恨的链接后还会弹出来“对不起，您的权限不够，请注册”的提示，相信这种挫败感对每个人的打击都是巨大的。在我留有最后一丝犹豫的时候，打开UCD领域最佩服的牛人白鸦的博客，干净的首页中，你不需要点击任何东西就可以看完所有的文章（除了看到底后的下一页），于是我决定之后所有文章取消分割线；
3、留言功能修改
准备添加一些有趣的留言插件，包括表情、符号等应该都能够使用才行；另外，争取对每个留言都进行回复，在留言量小的现在，还是很容易做到的；
4、增加对图像等多媒体的应用
虽然这样可能会带来服务器负担加重，但不可否认的是，人们对图像、表格的领悟能力要远大于纯文字的内容；
5、英文博客的精品化
英文博客自从写了一篇后，就没有再更新过。当然这有时间和精力等客观原因存在，但主要原因是我希望英文博客能够专精于某一方面的内容；这就要求中文版也应出现一些精品的、简短的、值得作为参考资料或能够更好跟人共鸣的东西出来……是不是有点不务正业了……我平时工作还是很忙的……尽力而为吧！
以上是一些对于博客发展的简单思考，随着时间的累积，这样的东西可能会越来越多，下次写时，应该对这篇提到的改进有所回应了。计划和总结是刀刃和刀背，没有刀背的分量，再锋利的刃砍出去也是轻飘飘的。
鼠标和键盘作为人机交互的信息输入端，是我们使用频率最高的电脑外设。现在市场上为电脑族设计的人体工学键盘和鼠标款式繁多，效果如何，却因人而异。究其根本，问题在于我们是否正确地使用这些工具——它们是否被摆放在正确的位置？我们是否使用正确的姿势？
作为铺垫，之前我写了篇上班族在电脑前正确的坐姿，这是很细节的问题，但也是最关键的问题。不过，在纠正姿势前，首先应该考虑：我们的键盘鼠标以及显示器是否被摆放在正确的位置？毕竟我们就需要一年近300天，一天七八个小时地去使用它们。俗话说，路远无轻重，电脑外设的摆放错误直接导致了姿势的错误。长年累月下来，电脑病就不可避免了：背痛、肩膀痛、脖子痛、腕管综合症…这些小病小痛会慢慢折磨我们。
从人体工学的角度讲，键盘鼠标应该与肘关节同高，也就是说，当你使用它们时，小臂与地面是平行的。
但是，我们的办公桌或其他桌子的普遍设计是高于肘关节的。因为设计桌子时不止要考虑键盘鼠标的摆放，还要考虑显示器以及其他物品的摆放。所以，目前绝大多数电脑桌和办公桌都设计有键盘架（也称键盘托、键盘柜），这些真的有效么？ Read More…
正确的坐姿：
√ 视线与地面平行；
√ 上臂与小臂垂直，上臂与地面垂直，小臂和手与地面平行；
√ 后背与大腿垂直，后背与地面垂直，大腿与地面平行；
√ 大腿与小腿垂直或自然弯曲，脚得到地面或脚托的支撑；
其中需要说明的是，这是一个相对完美的坐姿，但不是一个普通人能够保持的。有研究表明，人在背部后倾时（背部与大腿保持135度钝角）最舒服且不易疲劳；但这仅限于休息，没有公司会给员工准备个沙发吧；更何况，对着电脑的工作效率与保持舒适是鱼与熊掌的关系…当然，关于上面的标准的姿势，也是因人而异的，参考一下即可。但是下面的错误是尤其值得注意的： Read More…
