1.用80%的时间去研究需求，用20%的时间设计产品； 点击查看全文…
分类：设计 发布日期：五月 28th, 2010. 2 Comments.3,585 views
几天前又接到某门户HR的新工作邀请电话，却被自己婉言拒绝了…对我个人而言，在一家行业电子商务门户两年的产品管理和产品设计经验，在金三银四的北京的春天，的确有很多机会，年前我的确也动摇过：为了更好的发展，是不是应该跳槽了？可经过一个假期的思考后，我发现我要学的还有很多，为了跳槽而跳槽是没有任何意义的，自己应该塌下心来继续学习，在现有的互联网产品管理与产品设计领域积累更多的经验。
关于互联网产品管理和产品设计，曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验，但确实也做了很多产品管理的相关工作，并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外，产品管理更是涉及到了软件/互联网企业经营的方方面面：
分类：设计 发布日期：三月 9th, 2010. 9 Comments.5,094 views
分类：设计 发布日期：一月 18th, 2010. 23 Comments.7,982 views
分类：设计 发布日期：十二月 28th, 2009. 9 Comments.3,174 views
昨天网易首页改版了。对于我这种喜欢网易并且上门户80%会上网易的用户而言，不得不说两句：
网易改版后的优点：
1.字号变大了。从12号变成14号，这对我而言是非常必要的。公司电脑目前的分辨率是1280×1024，家里笔记本分辨率是1280×800，对比下搜狐，你会发现明显的区别。字号变大也直接导致我这样有点近视的人能够远离屏幕一公分；
2.新增了如qq.com一样的文字链接导航。我对QQ首页的导航模块用的最多的就是直接去QQ软件，我想对于一部分人而言，网易这个导航模块的最热点击应该是加红的魔兽世界；
3.可以直接登录进邮箱了。之前输入帐号密码后进入网易的通行证，随后才能进入163邮箱，现在你可以直接进入它；
网易改版后的缺点：
1.最郁闷的就是网易不再简洁了。改版前，网易是门户中最简洁干净的网站，现在打开它第一眼我还以为打开了新浪；
2.新闻图片很小。相对广告图片而言，新闻图片的重要程度被降低了。并且更像广告，这很容易叫我无视它；
3.对颜色的使用不太和谐。除去花花绿绿的广告，我发现只字体的颜色就使用了5种以上，还不算字号、粗体、背景色，实际上5种并不多，问题是，红色和蓝色太多，干扰了视线。对比下腾讯你会发现明显的区别；
其它的变化还有很多，比如板块位置、登录状态、换肤等等，但并无太大新意，用户体验跟之前也没有太大区别。至于整体风格的感觉，就智者见智了。话说回来，最近看新闻，越来越依赖谷歌资讯了……
分类：设计 发布日期：十月 13th, 2009. 4 Comments.1,691 views
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》。
分类：设计 发布日期：一月 18th, 2009. 4 Comments.4,184 views
需求变更在项目管理中是经常遇到的问题，特别是当项目进展到尾声时，一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微，在开发阶段滴水不漏，在流程管理上规规矩矩，但无奈的是，我们的客户总是希望拿到更完美的产品。于是乎，变更就成了结项后的潮水，一波一波，无休无止。不是你的产品坏，是这个世道变化快……
如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。
首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；
其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；
最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。
需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。
