介绍一款可以记录鼠标运动轨迹和点击的小软件：IOGraph。IOGraph是由莫斯科的设计师Anatoly Zenkov和Andrey Shipilov合作开发的一个小程序，主要用于记录他们在设计作品时鼠标在Photoshop的工作轨迹。当然，我们可以用IOGraph记录更多有意思的东西。
分类：工具 发布日期：六月 11th, 2010. 2 Comments.476 views
推荐一本目前正在读的书：咖啡小驻的《Thinking in UML》（09年度行业畅销书）
这本书以UML为载体，将面向对象的分析设计思路融入的建模过程中，从理论到实践，深入浅出，是一本不可多得的好书！
适用于软件设计师、架构师、程序员、产品经理、产品设计师……当然，其中的建模方法对其他行业的童鞋认识和分析事物也有所帮助。
站在产品经理的角度讲，这本书提出了需求分析的一种标准化方法，并介绍了建模工具Rational Rose的使用。用Visio画流程图，用Rational Rose建模做用例，用Axure设计交互原型，很好很强大的产品设计组合。
点击以上购买链接可以直接购买《Thinking in UML》，相信我，绝对值这个价！
最近太忙了，让博客休了个长假。在这期间付出了很多，也收获了很多，生活也有了新的憧憬，下周开始继续更新博客吧。
分类：读书 发布日期：四月 16th, 2010. 3 Comments.608 views
几天前又接到某门户HR的新工作邀请电话，却被自己婉言拒绝了…对我个人而言，在一家行业电子商务门户两年的产品管理和产品设计经验，在金三银四的北京的春天，的确有很多机会，年前我的确也动摇过：为了更好的发展，是不是应该跳槽了？可经过一个假期的思考后，我发现我要学的还有很多，为了跳槽而跳槽是没有任何意义的，自己应该塌下心来继续学习，在现有的互联网产品管理与产品设计领域积累更多的经验。
关于互联网产品管理和产品设计，曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验，但确实也做了很多产品管理的相关工作，并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外，产品管理更是涉及到了软件/互联网企业经营的方方面面：
产品需求文档（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. 3 Comments.1,937 views
需求变更在项目管理中是经常遇到的问题，特别是当项目进展到尾声时，一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微，在开发阶段滴水不漏，在流程管理上规规矩矩，但无奈的是，我们的客户总是希望拿到更完美的产品。于是乎，变更就成了结项后的潮水，一波一波，无休无止。不是你的产品坏，是这个世道变化快……
如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。
首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；
其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；
最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。
需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。
通常，一个产品项目完整的周期包括前期调研、立项、需求文档、开发、测试、部署等。其中，用户、销售、市场可能需要参与前期的调研和需求；开发到部署主要由技术部门负责；而产品经理负责整个产品项目的周期。虽然结项是这个周期的结束，但实际上项目的结项也是产品另一个周期的起点。
1、试用期-完善产品
试用期对绝大多数新产品来说都是必须的。产品本身是为需求而设计开发，最终还要回归到用户中去检验这种需求是否被满足。特别是对于技术主导的网络、软件等IT产品而言，试用期可以很好的检验这种新技术的价值；而没有试用期的产品是危险的产品，就像新研发的药物没用经过活体实验及持续不断的跟踪观察一样。
通常，试用期阶段的产品能反馈给产品经理绝大多数的 BUG 或需要再次完善的地方，如果持续关注和改进，产品本身也会不断完善，直到被用户认可。一般这个周期是三个月。
2、应用期-改进产品
在应用期前，产品应该已经能够满足用户的基本需求。其中，除了对产品正常的维护外，最需要关注的就是用户体验。在产品开发周期中，如果在用户体验方面已经足够关注，这里应该能节省绝大多数的时间，但这并不意味着你不需要对用户体验在做关注了，因为产品团队并非用户本身，真理也需要实践的检验，何况是你的产品？当然，如果这个产品在开发周期中从未关注过用户体验，那么相信这个产品已经被抱怨淹没了。你的产品是以用户为中心的吗？能用-有用-易用-好用……改进有很长的路要走。
3、升级-让用户知道你在进步
你的产品不是真金白银这种硬通货，在竞争如此激烈的今天，一成不变的产品再完美，也会转眼成为昨日黄花，时刻保持危机感，定时或不定时升级你的产品，哪怕仅仅像新款牙膏只是将牙膏口开得大了点这样的升级，也会使你的用户感到，你非常重视他们，这很可能意味着忠诚度的提高。
以上是最近做的两个项目下来的切身感受，一点浅见，适用于互联网产品以及软件产品多些，有不完善的地方，还望大家指教。
分类：产品 发布日期：一月 15th, 2009. No Comment.1,307 views
“产品（product）”对我们每个人来说都不陌生，日常生活中我们也总是与形形色色的产品名词打交道：免检产品、IT 产品、产品设计、产品管理、产品忠诚度……可以说，只要有需求，就会有相关的产品满足你，我们的生活也离不开产品；而由产品衍生出的相关管理思想也在不断的推动着市场营销理论甚至企业管理本身的发展。
那么，究竟什么是产品呢？早前我的博客中，有部分提到过对产品简单的认识，实际上，不同的行业中有不同的定义，但我们还是可以简单得概括一下：
产品的狭义概念：被生产出的物品；
这是产品的原始概念，即人们通过劳动生产制造出来的物品。
产品的广义概念：可以满足人们需求的载体；
产品的概念随着经济和市场的发展而被扩大了，首先产品本身可能并非是由生产制造而来的，比如天然宝石、原煤等（未被开发的自然资源并不能算是产品，虽然这些资源本身能够满足人们的需求，但也要等它们真正被发现和挖掘出后才有交换价值）；其次，产品不一定是物品，也可能是某种服务，甚至包含物质实体在内的一体化解决方案；最后，产品必须能够满足人们的某种或多种需求，比如“我们需要人体工学的键盘系统”；
有人把产品理解为商品，其实是不确切的。产品和商品的区别在于，商品是用来交换的产品，商品的生产是为了交换，而当一种产品经过交换后进入使用过程后，就不能再称之为商品了；当然，如果产品又产生了二次交换，那么在这段时间能，它又能被称之为商品了。
需要注意的是：所有的产品都是具有使用价值的，这是产品的自然属性；一旦产品失去了使用价值，就成为了废品。这一点非常重要，因为产品的使用价值越高，则越能够满足人们的需求，那么就会给你带来巨大的商机。换句话说：如果你的产品能够很好的满足市场需求，那么你的产品就是成功的产品，它可能会为你带来滚滚利润！
到这里，相信你不会再为繁琐的概念解释而无精打采了，可惜，如何通过合理的产品策略赚钱是以后要讨论的问题；本篇主要讨论什么是产品，以及产品的相关注意事项，希望这篇“什么是产品”能满足需要她的读者。
分类：产品 发布日期：一月 13th, 2009. 2 Comments.1,816 views
