韩军星的博客 » 需求

产品经理和项目经理的矛盾与博弈

hanjunxing — Fri, 06 Aug 2010 10:25:56 +0000

连续、经常性的加班，持续1个多月了吧，今天趁着项目部署与产品体验之间的间隙，聊聊关于产品经理和项目经理的矛盾与博弈。讲一个故事吧，主角是产品经理产同学、项目经理项同学，以及需求小许、技术小记：

经过2个月的奋战，产品计划本周五就要上线了。在周二的体验平台正常测试中，测试发现用户登录系统后，有一个页面前后台状态显示状态不一致，小许急了一头冷汗，马上跟小记了解情况。

原来，做需求时，由于DEMO平台无用户数据而无法显示该页面的登录状态，小许的需求就把这里遗漏了，幸好这个问题很小，提取之前页面的正常状态就可以了。跟产品经理说了一下问题后，许同学马上整理了半页的需求补充，直接提交给了小记。小记也很麻利的10分钟解决了问题。故事本该到此结束，可杯具才刚刚开始…

原来，按照公司的规矩，需求的任何改动，都应该通过产品经理提交，项目经理评估通过后，才可以提交OA流程进行改动，即“留痕”。但这个问题在产同学刚跟项同学沟通时，小许和小记已经把这个问题搞定了。

IM群中，项同学怒了：“你们需求怎么又变更！谁给你们权利直接去跟开发沟通的！”
产同纳闷了：“你这什么态度？我这不在跟你沟通，谁说要需求变更了！产品跟技术沟通还要通过你批准？”

于是，项同学把问题告到了老总哪里……你猜得到结果，老总各打五十大板：“保证项目进度！！”出了老总办公室，项同学拿根烟冲向冒烟室，一脸委屈和愤怒，“这项目没法做了，变变变，这进度怎么保证？你们产品需求的问题，影响了进度和质量，还不是我负责，要我来擦屁股？！”我们的产同学刚在IM跟项同学沟通就遭遇态度恶劣的抵制，又莫名其妙挨了老总的板子，当然起身就追了出去……

后来，听公司同事说，来公司2年了，第一次听到有人在外面吵架，还用100分贝的声音吵了20分钟。当然，这都是后话，但这个梁子，产同学跟项同学是结下了。至于问题的处理结果，让产品和技术都很无语——怎么改的，再怎么改回来，就按错误的内容上线。至于用户体验？项目部署后试用期再汇总问题改吧……

有一点在互联网业内是比较明确了：产品经理对产品负责，对需求负责；项目经理对项目进度和质量负责。但实际的项目过程中，总会出现这样那样的摩擦，特别又是对于公司内部项目而言，项目的需求变动并不能像外部项目那样，甲方能给项目团队加钱，所以项目经理对进度的控制会远大于（产品）质量，人家后面还有N个项目在排队，不是么？本想就着这个杜撰的文章，长篇大论一番产品管理与项目管理，谁知这一等，又是半个月过去了。先贴出来吧，大家对故事有什么想法？

继续浏览相关文章

需求调研与产品设计10条经验

hanjunxing — Fri, 28 May 2010 09:34:43 +0000

1.用80%的时间去研究需求，用20%的时间设计产品；

2.理解用户—>装成用户—>比用户还像用户—>改变你的用户；

3.高效使用产品设计工具会事半功倍；

4.随时跟用户沟通，用户看到并认同了DEMO后需求变更的风险才开始降低；

5.随时跟技术沟通，否则技术一句“不能实现”会否掉你N人/日的成果；

6.产品设计末期，你除了需要忙于修改产品，更重要的是对用户Say NO；

7.经常说：“这部分需求我们计划放在下一个版本中实现”；

8.重视的细节，不只是功能和界面，别忽略数据流转和容错；

9.技术只考虑“如何实现”，而你需要告诉他们“实现什么”；

10.需求评审时要散发出自己的气场，告诉所有人，这份需求文档是无懈可击的。

继续浏览相关文章

关于互联网产品管理与产品设计

hanjunxing — Tue, 09 Mar 2010 02:35:49 +0000

几天前又接到某门户HR的新工作邀请电话，却被自己婉言拒绝了…对我个人而言，在一家行业电子商务门户两年的产品管理和产品设计经验，在金三银四的北京的春天，的确有很多机会，年前我的确也动摇过：为了更好的发展，是不是应该跳槽了？可经过一个假期的思考后，我发现我要学的还有很多，为了跳槽而跳槽是没有任何意义的，自己应该塌下心来继续学习，在现有的互联网产品管理与产品设计领域积累更多的经验。

关于互联网产品管理和产品设计，曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验，但确实也做了很多产品管理的相关工作，并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外，产品管理更是涉及到了软件/互联网企业经营的方方面面：

如图，需求端的沟通主要来自于销售和内容，技术段的沟通又涉及到了产品开发的相关方面。我本身是做销售起家转做产品的，因此对用户需求和用户体验非常敏感，但涉及到产品的具体实现上，又暴露出了技术基础不扎实的软肋。产品设计不用深入考虑技术开发，但在明确业务流程并设计产品外，也应该考虑到数据的流转甚至数据表的字段，而不是只设计出产品的骨架外壳，就将剩下的工作一脚踢给技术，否则会加大许多沟通成本，比如我现在连每天的午饭都在跟技术架构师一起吃…

去年拿下年度优秀员工并不是一件容易的事，但即便如此，我依然觉得自己欠缺的还很多。从用户研究到角色建模，从流程设计到产品架构，从交互设计到UI设计，从可用性分析到用户体验，甚至最基本的产品工具比如Axure、Visio都只是“办事儿”的程度，远没有达到精通，更谈不上什么核心竞争力了。低调做人，闷头做事，再给自己一年的时间学习，总结，希望年底时会发现，2010年，我在互联网产品领域又迈出了坚实的一步。

继续浏览相关文章

软件/互联网产品设计流程

hanjunxing — Mon, 18 Jan 2010 09:29:31 +0000

近期站在产品部门的视角整理了公司产品设计流程，一来完成任务，二来对自己一年多项目管理和产品开发经验进行下梳理：

1.产品调研

产品的调研属于市场范畴，由市场部门负责。产品调研是为了提高产品决策质量，解决存在于产品设计及产品上线后销售中的问题而系统、客观的收集、分析市场综合情况的行为。所以与内部产品不同的是，外部产品调研需要撰写市场需求文档即MRD，只有符合公司战略和市场需求的产品，方可进入产品立项阶段。而内部产品调研由于不涉及市场环境，为了产品设计流程的敏捷和高效，不需要提交调研产出物。经过确认必要且可行的产品，可直接进入产品立项阶段。

2.产品立项与评审

产品立项是产品设计项目流程的起点，产出物主要为《产品立项说明书》。产品经理负责产品立项时的文档撰写以及项目时间和人力计划安排。产品立项后，直接进入立项评审流程。立项评审是对产品立项说明书和项目计划的综合评审。立项评审各节点的负责人需要填写《产品立项评审表》，评审通过时评审自动流入下一节点直至归档。立项评审通过后直接进入产品详细需求及设计阶段。

3.产品需求与DEMO设计

产品需求是项目流程的重要组成部分。主要由产品经理负责，对内部业务需求进行详细的调研分析。根据需求，产品经理需要设计业务流程以及构建产品框架，使产品能够满足业务方需求；同时与技术部门协同确保产品方案能够顺利实现。当产品需求明确后，需要设计产品线框图即DEMO展示，确保良好的可用性和用户体验。详细交互情况需要在产品需求说明书中注明。本阶段主要产出物为《产品需求说明书》，以及产品DEMO。应用工具主要为Visio、Axure等。当需求阶段结束后，进入需求评审流程。另外，需求变更一般是在设计阶段，用户的需求发生变化时进行的，当需求评审结束后进入开发阶段时的需求变更应该尽力避免。

4.需求评审

需求评审需要业务需求、产品、技术共同参与，由该项目产品经理对产品的需求说明书以及DEMO做详细汇报，并解答各方面疑问。参与的评审人员需要填写《产品需求评审表》，评审通过后项目自动流入UI设计流程。需求评审的结束是项目的里程碑。

5.UI设计与美术评审

UI设计主要是针对产品表现层的设计，包括框架、元素、界面、文字等等的标准化设计。与DEMO的线框图不同，经过UI设计后，经过确认产出物产品原型需要直接作为前端开发的标准。因此UI设计结束后，需要进行美术评审，征求公司领导和相关产品负责人对产品原型直观印象，直到最终原型确定进入前端开发流程。部分内部产品不涉及UI设计的，可直接进入技术开发。

6.技术开发及前端开发

通常情况下，技术开发在需求评审结束后即可开始介入。即根据产品需求文档和DEMO原型，开始架构产品底层，由架构师负责。随后展开源码撰写的技术段工作，主要由技术部门负责。当产品UI标准及美术交互原型完成后，根据底层开发情况，可以开展产品前端开发。部分网站产品如板块变更，不涉及底层开发部分的，可直接进行前端开发。

7.测试及上线

当开发完成时，由测试部门（测试部门在需求阶段即可参与项目）撰写用例并测试。新产品需要首先发布到测试平台使用测试，网站产品进行大范围改变时，需要上线测试版经过客户熟悉和认可后方可正式上线。

8.产品跟踪

产品上线结项后，产品经理开始对产品持续关注和跟踪。了解业务使用情况，同时针对产品使用过程中出现的问题进行修复；当业务需求变化时，及时对产品进行升级或进行二次开发。产品经理需要在产品的生命周期中持续跟进产品。

继续浏览相关文章

PRD中写用例的注意事项

hanjunxing — Sun, 18 Jan 2009 03:51:10 +0000

产品需求文档（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》。

继续浏览相关文章

需求变更-要效率还是要规矩？

hanjunxing — Fri, 16 Jan 2009 15:02:29 +0000

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

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

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

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

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

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

继续浏览相关文章

什么是产品

hanjunxing — Tue, 13 Jan 2009 14:34:12 +0000

“产品（product）”对我们每个人来说都不陌生，日常生活中我们也总是与形形色色的产品名词打交道：免检产品、IT 产品、产品设计、产品管理、产品忠诚度……可以说，只要有需求，就会有相关的产品满足你，我们的生活也离不开产品；而由产品衍生出的相关管理思想也在不断的推动着市场营销理论甚至企业管理本身的发展。

那么，究竟什么是产品呢？早前我的博客中，有部分提到过对产品简单的认识，实际上，不同的行业中有不同的定义，但我们还是可以简单得概括一下：

产品的狭义概念：被生产出的物品；

这是产品的原始概念，即人们通过劳动生产制造出来的物品。

产品的广义概念：可以满足人们需求的载体；

产品的概念随着经济和市场的发展而被扩大了，首先产品本身可能并非是由生产制造而来的，比如天然宝石、原煤等（未被开发的自然资源并不能算是产品，虽然这些资源本身能够满足人们的需求，但也要等它们真正被发现和挖掘出后才有交换价值）；其次，产品不一定是物品，也可能是某种服务，甚至包含物质实体在内的一体化解决方案；最后，产品必须能够满足人们的某种或多种需求，比如“我们需要人体工学的键盘系统”；

有人把产品理解为商品，其实是不确切的。产品和商品的区别在于，商品是用来交换的产品，商品的生产是为了交换，而当一种产品经过交换后进入使用过程后，就不能再称之为商品了；当然，如果产品又产生了二次交换，那么在这段时间能，它又能被称之为商品了。

需要注意的是：所有的产品都是具有使用价值的，这是产品的自然属性；一旦产品失去了使用价值，就成为了废品。这一点非常重要，因为产品的使用价值越高，则越能够满足人们的需求，那么就会给你带来巨大的商机。换句话说：如果你的产品能够很好的满足市场需求，那么你的产品就是成功的产品，它可能会为你带来滚滚利润！

到这里，相信你不会再为繁琐的概念解释而无精打采了，可惜，如何通过合理的产品策略赚钱是以后要讨论的问题；本篇主要讨论什么是产品，以及产品的相关注意事项，希望这篇“什么是产品”能满足需要她的读者。

继续浏览相关文章

环保万年历，一点也不环保

hanjunxing — Mon, 05 Jan 2009 09:28:52 +0000

前些天，部门发了点小礼物给同事们，其中之一便是这可爱的环保万年历。（如图）

初见这个新鲜玩意时，的确觉得环保，正如说明书所写：
※ 环保型的DIY台历设计,代替纸张的浪费,只要每月调整一次就可以重复使用一万年;
※万年历有3种不同风格系列，日历上配有各种图标，如图；
※ 日历使用简单、有趣，桌面摆设或送礼都一样怡人；
※ 可以提醒你当月的安排，使忙于工作的您不会忘记一些重要的日子；

刚发下来时，的确如此。大伙都找回了童真，一个个拆了它开始拼积木，结果还被经理严肃批评到：禁止在上班时间做这些跟工作不相关的事情！但第二天，每个人的桌子上都拼好了当月的日历。
转眼09年也过了一个礼拜了，再看看大家的万年历，依旧是去年最后一个月的。自己万年历一样停留在08年的回忆中。本来是想拼拼的，可太忙了。于是乎，环保万年历成了摆设，成了不算那么好看的鸡肋小玩意儿。
至此不得不说，这是一款失败的产品。虽然不是网络产品，但天天摆在我的桌子上，还是想写写的：
首先，每个人都对日历有自己的需求；但是不可否认的是，对于天天对着电脑的人而言，电脑就是满足需求最好的产品。虽然电脑的日历查看需要用鼠标双击时间，但是这点劳动量绝大多数人还是可以忍受的。当然，那些无法忍受，或者对日历使用频率很高的人，或许也会考虑在电脑上装个桌面日历；
其次，即便跟电脑打交道很少的人，大多数对日历时间本身的关注要多于日历款式很多。日历要的就是准确，而自己手动拼起来的日历，会不会出现什么纰漏？谁也说不好，尤其冒着风险拼积木，不如弄个传统印刷的挂历省心吧；
最后，就是拼凑这个积木花的时间了，反正我第一次用了十几分钟，并且还需要有辅助日历对照。也就是说，这个万年历是寄生的，离开了别的日历是没有使用价值的。
所以，不得不说，这个产品是失败的产品。没有抓住用户的根本需求，没有贴近细分用户，也没有一个明确的市场定位。或许爱玩积木的小孩子会拿来拼个变形金刚？
可谁又能拼他个一万年呢？
环保万年历，只是一堆塑料垃圾的笑话而已。