韩军星的博客 » 产品

产品运营的思路

hanjunxing — Tue, 27 Dec 2011 05:05:12 +0000

一直做产品，从未做运营，但这并不妨碍我谈谈对运营的理解。因为在互联网领域，产品和运营都是相通的，产品是要给用户提供价值，运营是让用户认识这种价值，它们相互依存，战略目标是一致的。任何运营都围绕“用户”展开，包括“吸引用户”和“留住用户”，说白了就是：让用户过来，并留下。

1.吸引用户

说道吸引用户，不得不提流量来源。在任何第三方统计软件中，“搜索引擎”、“外部链接”、“直接登录”的流量划分已经标准化—搜索引擎来的通常是受到内容的吸引；外部链接来自于各种推广营销、以及软文和口碑；直接登录的通常都是忠实用户，这样的用户在后面的“留住用户”中再详细说明。补充一点，在SEO中有句座右铭“内容为王、外链为皇”，对于运营中的吸引用户一样适用。

1.1.内容建设

内容是web1.0的精髓，也是互联网的基础。在web2.0时代，UGC类甚至SNS网站的内容依然离不开这个基础，不过运营的方式从“运营商创造内容”逐渐转变为了“运营商引导用户创造内容”。可以分为3个阶段：

在冷启动时，依然需要运营商创造内容，不过他们装成了用户；
运营需要鼓励用户创建符合社区定位的高质量的内容；
运营需要引导用户浏览希望看到的内容，并激励用户参与进来，形成用户与用户的互动；

这三者相辅相成，缺一不可，并且前者是后者的基础。有人说新浪微博也没有装用户啊？t.sina在2009年8月14日内测起，就要求项目组内每人至少邀请20人注册，虽然这没有持续多久，但的确属于装用户的范畴，即便在现阶段，无数的僵尸水军五毛党，背后也站着sina的影子。阶段2是社区进入发展期的标志。微博在推迟公测后的9.10日，赢得了“李开复离职战役”后，才正式进入了公众视野，名人是新浪创造高质量内容的王牌。但对于大多数创业网站而言，这样的资源、机会是很难具备的。如何”鼓励用户“？何为”符合社区定位“？用户怎么才能”创造高质量内容“？这是web2.0产品运营的真功夫。比如白社会的积分体系，比如垂直社区的内容定位本身，再比如各种推荐、各种广场、各种认证…即便只有1个能够产生符合社区定位的内容产生，运营也要及时跟上，告诉作者：我们喜欢你这样的用户；同时告诉社区的其他人：这样的内容在我们这儿是受欢迎的，这就足够了，方式有很多，不再枚举。当第二阶段做好以后，引导推荐与鼓励参与将是水到渠成的事儿，想在加把火，除了产品本身提供的规则和功能外，依然可以动员阶段一中的幕后推手，或者玩玩专题和活动。大势已定时，三阶段的运营没有成败，只有效率的好坏。

本想说内容吸引用户来，谁知道这一说又说开了，不过可以确认的是，网站产品运营内容建设做好以上三点时，无论对吸引用户还是留住用户，都是非常有效的，留住用户在后面还会详细阐述。

1.2.外链建设

外链的种类有很多，对微博而言，门户本身就是最有效外链源；对SNS产品，口碑才是最大的外链；中小2.0网站和垂直社区，广告、软文的分量较重；个站和垃圾站，友情链接、交换链接、联盟等SEO手段带来的外链是不可忽视的。外链是一种结果，依托于渠道的选择，而非过程本身。很多SEOer把外链制造当成了信仰，结果往往成了自己的墓志铭，根本原因还是把内容与外链的关系本末倒置了，这是短期利益的驱使还是浮躁心态的表露不得而知，但稳固的有价值的外链，一定是跟随产品成长步伐的。

重点说一下病毒营销。病毒营销是口碑的一种，但在web2.0时代又是最最重要的用户吸引的要素。虽然在第三方数据上，病毒营销的来源相当于”直接输入“或各种邮件链接，但从内部数据依然可以分析出来一部分（邀请注册成功的用户量）。病毒营销对产品本身是无成本的，一旦开始受众数将以几何级增长。但病毒营销的隐性成本是由用户承担的，用户必须有足够充分的理由去传播和邀请，这个理由取决于产品或服务的价值。特别对于web2.0网站，目标受众与核心用户的传播通道一致时，产品能够迅速取占领市场，并能够帮助用户建立稳固的关系，进一步提高网站的粘着度，Gmail是最典型的例子。记住，纯以利益驱使为基础的病毒营销，只能给你带来1秒的快感，然后就会毁了产品的未来。

2.留住用户

能让用户留下是运营的精髓，也是衡量网站的核心指标之一。我们针对”有效用户“、”活跃用户“、”核心用户“详细谈一下留住他们的运营策略：

2.1.有效用户

有效用户区分与垃圾用户和活跃用户，通常产品为这类用户创造了潜在价值，但是价值还不足以吸引其成为活跃用户；或者用户通过各种吸引手段进来又离开的用户。留住这样的用户策略上可以从三个地方着手：刺激他过来；给他好处；展示网站的核心价值。

战术上，刺激有效用户过来其实只需要一个理由。一个理由还找不到么？无论是好友呼唤、活动邀请、问题求助，还是劲爆热点、热门精选RSS订阅，或者各种节日各种庆典各种活动，运营只需要告诉他即可。邮件不错，短信更好，如果有个声音甜美的MM电话唤醒一下最好不过了，当然成本会几何级上升。人家来了能得到什么好处呢？对刺激理由履行承诺是最起码的底线。帮助或引导用户使用刺激他过来的功能或内容，使用户流畅完成操作，舒舒服服的离开，运营的目的就达到了。不要忘了展示网站的核心价值，这直接关系到有效用户是否能够转换为活跃用户，通知、提示、引导广告或者精准推送的内容会放大这个用户创造的价值，甚至给你惊喜。

2.2.活跃用户

活跃用户的运营是留住用户的重中之重。通常活跃用户对网站的认知与网站的定位是匹配的，他们每周甚至每天都来网站，获取内容是他们的主要目的，包括有趣的内容（媒体属性）和关系产生的内容（关系属性）。另外，活跃用户更容易使用产品的附加服务或增值服务，是核心用户的主要来源。留住活跃用户的方法很多，几乎每种运营手段都能派上用场，但不同网站的着重点不一样，不同产品生命周期的运营策略也不一样。虽然这是”正确的废话“，但在KPI的驱动下，能做到为产品”量身定做“并考虑长远的运营真的少之有少。活跃用户的运营目标有两个：提高健康度；提高活跃度。

2.2.1.提高健康度

首先，运营需要贴近用户。相对于有效用户很少来和核心用户都会用，活跃用户在使用产品的过程中会产生大量的问题，遇到各种的困惑，运营需要建立和完善帮助体系，让用户不至于因为”不知道怎么用“这种低级问题而流失。几乎所有的成功网站都有完整的帮助中心、Q&A、问题反馈、客服电话、会员论坛甚至解决问题的邮件和意见采纳感谢信，新版本推出时最好有新旧版本转换，重要功能或易误操作的功能需要加个贴心的小提示……这些不仅能够避免活跃用户的退化，更能体现产品”以用户为中心“的思想。

其次，运营需要指导产品更新。从细节看，产品的使用情况和用户反馈都能够明确产品各个功能的优缺点，需要及时改进升级；从宏观看，运营需要紧盯政策变化、市场发展趋势和竞争性产品，结合产品战略，不断调整方向和节奏。在互联网，特别是中国的互联网，死的不明不白的产品太多了。产品的升级换代和优胜劣汰是产品运营的硬功夫，也决定了产品能达到什么样的高度。学习、创新甚至模仿速度都可能成为成功的决定因素，需要运营与产品紧密配合，最好运营本身就是做产品的，或者做产品的再搞运营，这有助于跳出自己的框框，更有远见的看待自己的产品。

最后，运营需要紧抓内容建设与社区氛围的营造。在吸引用户—内容建设中有详细的说明，但这在强调一次，内容是一切网站的基础。在web1.0时代，雅虎拿起免费的内容缔造了互联网的规则；在web2.0发展期，从blogger到wiki，从youtube到twitter，创造内容的方式变了，但内容依旧是他们成功的基石；在web2.0的成熟阶段，SNS的崛起也可以理解为关系内容化，内容依托关系进行扩散，这两者相互促进，缔造了今天的facebook。在互联网发展的主旋律中，运营的方式从创造内容逐步向制定规则过度，为用户创造更好的交流平台，通过产品机制和运营定位，让内容淘汰遵循自然法则，使优质内容能够有效传播并鼓励相关用户参与，这种梦幻般的未来，不正是你想要的么？！

但是，提高产品健康度一切都要基于数据说话。在现实中，苦逼的产品调研后无论是用户访谈还是角色建模，无论是装用户还是设计User Story，都建立在一个虚拟的规划中，整个产品都是基于这个想当然的规划通过项目实施做出来的，无论规划看起来多么美好，都需要事实的证明。因此，运营需要搭建一套完整的数据分析办法，无论是Google Analytics还是专业的Adobe Omniture，或者自己开发一套基于数据库的统计分析工具，运营需要使用这些工具监控用户对产品的使用情况，并发现其中的问题或亮点，包括但不限于分析用户行为、分析产品使用情况、分析运营策略是否成功等。让数据说话，也是运营的硬功夫，需要下狠心去抓。

2.2.2.提高活跃度

活跃度是个很让人纠结的指标，有很多维度，什么样的活跃度是让人满意的取决于产品的定位，就像linkedin不指望他的用户跟myspace的用户那样天天泡在上面一样。另外，需要注意的是，促进活跃度需要掌握火候，纯KPI导向的只看活跃度就是在玩火，那样也会毁了你的产品。提高活跃度的办法任何做内容运营的同学都能随口蹦出一大堆，最典型的就是活动。在用户普遍寂寞难耐的情况下，活动能够吸引眼球，让用户参与进来，形成互动，这个活动的目的就达到了。

广义的活动可以切分为内容型、功能型、烧钱型三种。顾名思义，内容型活动就是对话题、争论以及事件、人物等进行包装后的产物，从自动化的热门推荐到人工创造的投票、观点PK以及访谈等等，都是内容型活动的表现方式。内容型活动也是成熟社区产品的主打牌，玩法多，限制少，见效快，也给各种闷骚苦逼宅男腐女排舒缓了压力排解了寂寞。功能型活动，通常是产品功能的伴生品，小到提醒大到引导教程（这已经成了移动端产品的潜规则了-_-），目的都是帮助用户使用，同时为该功能的KPI指标打基础。当然，最常见的功能型活动是能够给用户带来虚拟或实际的利益的，要么能涨积分，要么能让产品更好玩（比如邀请朋友），要么结合烧钱型活动一起Happy一下。烧钱型活动通常有自己的目标，要么带来用户，要么带来流量，最次也要提高一下活跃度冲冲指标，这样老板烧得爽，用户玩的high，其乐融融。

2.3.核心用户

最后，说说留住核心用户。核心用户的运营，一定要围绕产品的核心价值展开。当然，做好核心价值，是产品的硬功夫，对所有用户都适用，但对核心用户，在做好本质产品的基础上需要给他们更多功能或内容的差异和特权。这与产品的定位和运营策略密切相关，也是成长体系的重要组成部分。另外，对待核心用户，需要做好服务和增值。在服务上需要更贴心，更有效率，比如1对1专属客服经理，比如7×24小时在线救援，让用户毫无后顾之忧；在增值上，更多积分、更多优先体验、更多活动抽奖号都是很好的方式，高端点渠道返点，或送高尔夫球卡或者古巴雪茄，人性点邀请来公司参观交流或参加个年会等等，做到极致就是拉拢腐蚀，让核心用户跟你穿一条裤子，做到这份上，神马宣传推广神马病毒营销都是浮云了。

说了很多，贴个思路图，期待与做产品运营的同学进一步交流探讨

继续浏览相关文章

供应链式项目管理

hanjunxing — Sun, 18 Dec 2011 16:08:46 +0000

最近我们重新规划和设计敏捷项目总体流程，对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更详细的计划时，发现一个严重的问题：这是一个“梦幻日程计划”。在项目生命周期管理的探索与实践上，我们经历过瀑布式、迭代式、增量式以及混合的Scrum敏捷式，如果只针对项目管理而言，我相信在一个Sprint周期内，做到“一切尽在掌握”是可行的，但放眼至一个季度甚至半年的最终目标上，梦幻计划的完美主义的思想又成为了另一个极端。

为了让计划更加务实，我们需要采用尽可能短的时间盒管理项目，2周是一个理想并充满挑战的周期，但我们相信只要控制好Sprin就t可以实现它。

项目自始至终周期过长，会造成心理放松，对于项目危机感缺失，以至于造成前期浪费时间，后期加班赶时间的窘相。所以我们需要通过不断地迭代，在一次次循环中完成可交付的增量，基于事实的决策远比前端预测型决策更为有效。——Reinhardt

从远期看，我们的产品上线目标和最终运营目标都充满挑战，并且时间只剩半年。为了让不可能的任务更有说服力，我尝试着制定整整6个月的计划，但计划刚刚开始我就结束了这个愚蠢的想法——未来的Idea充满了未知。虽然scrum敏捷能带给我们更强的控制力，但从产品创建的生命周期看，2周时间盒显然给需求的产出带来了极大的困扰：如果需求的定义仅限2周，只有鬼知道这两周的量能否满足下一个项目Sprint的胃口，这还没有考虑不同功能和需求的大小。一个用户体验改进与一个成长体系的需求量，放在两个同样长度的时间盒显然是不公平的，更何况产品经理还需要对页面设计、制作进行协调以及参与Spring周期结束时的部署验收。

在一个复杂又充满挑战的项目中，为了避免这个问题，同时又发挥Scrum敏捷式项目管理的优点，可以采取“供应链管式项目管理”方法。

在传统制造业企业中，为了保证生产的稳定，制造商会有一定的原材料库存。但随着供应链管理思想的深入发展，越来越多的制造商整合供应链资源，与供应商共同管理库存，以确保在生产最经济的情况下满足市场的变化，即“柔性供应链”。

在互联网项目管理中，可以简单的抽象需求、设计、页面制作为供应商，总设、开发、测试为制造商，库存即“待开发需求池”。与传统制造业不同的是，互联网项目团队可以简化为2个供应链中的节点，供应商为制造商提供生产原材料，制造商将其加工测试后交付给市场。

相比Scrum敏捷式项目管理，供应链式项目管理强调了“库存”的价值，产品需要在下一个时间盒开始前保持“待开发需求池”的水量；开发需要确保能够及时消耗掉库存中的Backlog。这使得团队成员的注意力更容易集中在最重要的部分（设计或者开发），而不是无效率的沟通。换句话说，传统的Scrum项目管理的流程更像是一条大河，上游需要确保充足稳定的水量以确保下游的承受能力；下游需要保持足够的消化能力以避免洪水泛滥或者干涸。供应链式的项目管理就是在河道上建起了一座大坝，只要保证水库中的水在安全范围以内，无论洪峰还是大旱（需求暴增或需求锐减），下游生产都可以确保安全与效率。管理的焦点可以集中在“待开发需求池”的安全范围以及优先级。

供应链式项目管理是更宏观的管理，它阐述了产品管理与项目管理的上下游关系。纯粹的Scrum可能更适合老外那种程序员也是产品经理的创业作风，我看过几乎所有被奉为圣经的项目管理书籍都将定义需求作为一个项目的起始，这表面看起来无比正确，却如同鸡肋般既没有说清楚如何定义需求（推荐《用户体验的要素》），又给国内的项目经理和程序员造成了困扰。

产品（供应商）：

产品从“需求池”到“待开发需求池Backlog”，需要经历线框图、需求文档、页面设计、页面制作4个环节，产品设计的迭代由产品经理全权负责，在需求池挑选高优先级的目标，设计并交付最终完整需求至待开发需求池中，需求需要以“情景故事”为单位打包，并区分优先级；需求包的优先级需要满足正态分布曲线，如水库在每个Spring开始前，安全范围为5-15个情景故事，当有10个故事时，2个优先级为1，6个优先级为2，2个优先级为3。

技术（制造商）：

技术在下一个时间盒迭代开始前一周，由项目经理根据团队承受能力与产品共同确认Sprint Backlog，并立即进行需求和用例评审。一旦范围确定，即可立即展开项目（在需求线框图出来后，测试与架构师就可以介入开展前期工作了），并用燃尽图等工具进行监控。后面只需要保持好节奏，相信掌控项目的感觉会让你身心舒畅。

我并不清楚供应链式项目管理思想是否有人进行过类似尝试，它的本质是对敏捷项目时间盒内的需求与开发进行解耦，需要需求提前至少一个时间盒完成并冗余在待开发需求池内，把为了增强项目控制力而压缩的2周Sprint还给项目程序员和测试工程师。它的困难在于，需求为了保证待开发需求池的安全范围而必须承担足够的压力，还好我相信这种压力是我们可以承受的。

这只是一个产品经理对项目管理的思路，实践后会进一步总结，如果你有更好的主意，欢迎与我分享。

继续浏览相关文章

产品出来后

hanjunxing — Wed, 03 Aug 2011 06:25:06 +0000

把产品做精，先有用，后能用，最后好用。有用就是抓住核心价值，核心价值都没有的产品就是浪费生命；能用就是能走通流程，完成既定情景下的操作，另外就是稳定高效。还不能用就不上线，能用就上线再慢慢优化改进；好用就是上线后不断优化用户体验，根据用户需求和运营需要，对功能推陈出新，使产品趋向完美的过程。

运营伴随着产品的生命周期起始。成长期做产品式运营；成熟期做营销式运营，颠倒次序会搞死所有人。产品式运营的目的就是让产品更好用，需要数据的支持和分析。数据是避免主观决策的基础，没有产品式运营，做产品就是自娱自乐；营销式运营的基础是产品好用，也就是用户体验好。残疾的产品不抓紧时间优化，神马KPI神马用户活跃度都是浮云。

拿出20%的时间思考、交流、学习，井底之蛙做不好产品；拿出20%的时间建设团队，21世纪人才最珍贵；拿出20%时间做好规划和计划，并跟进计划及随时调整，及时沟通统一目标；剩下的时间去解决问题、设计方案。对员工，除了给20%的时间去思考，要求80%的时间完成100%的执行力，激励要落到实处。

控制好节奏，把握好需求出口，一步步来；承担责任，不扯蛋，抓紧时间。

继续浏览相关文章

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

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.需求评审时要散发出自己的气场，告诉所有人，这份需求文档是无懈可击的。

继续浏览相关文章

推荐一本书：Thinking in UML

hanjunxing — Fri, 16 Apr 2010 09:39:03 +0000

推荐一本目前正在读的书：咖啡小驻的《Thinking in UML》（09年度行业畅销书）

这本书以UML为载体，将面向对象的分析设计思路融入的建模过程中，从理论到实践，深入浅出，是一本不可多得的好书！

适用于软件设计师、架构师、程序员、产品经理、产品设计师……当然，其中的建模方法对其他行业的童鞋认识和分析事物也有所帮助。

站在产品经理的角度讲，这本书提出了需求分析的一种标准化方法，并介绍了建模工具Rational Rose的使用。用Visio画流程图，用Rational Rose建模做用例，用Axure设计交互原型，很好很强大的产品设计组合。

点击以上购买链接可以直接购买《Thinking in UML》，相信我，绝对值这个价！

最近太忙了，让博客休了个长假。在这期间付出了很多，也收获了很多，生活也有了新的憧憬，下周开始继续更新博客吧。

继续浏览相关文章

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

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.产品跟踪

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

继续浏览相关文章

市场需求文档MRD的必要性

hanjunxing — Mon, 28 Dec 2009 09:03:14 +0000

临近年关，公司战略调整以及部门整合如火如荼，我受命整理产品部门标准文档和各类流程规范，着实头痛。先说说产品调研以及MRD。

通常一个新产品创意的诞生有两种情况：

首先是领导拍着脑袋想出来的。老板是公司战略的制定者；而高级管理层为了实现公司战略，需要给出未来新产品的开发方向；随后产品经理根据产品方向针对具体产品做出相应的规划。这个过程通常在中小互联网及软件公司中非常常见，碍于时间成本和人工成本，创业型公司甚至就是光杆司令既是战略的制定者也是产品的设计者。优点是敏捷高效，能够第一时间插入目标市场；缺点是风险高，可控性低。

其次是市场部门经过数据的研究和科学论证得出的。市场部门以公司战略为基础，通过对SWOT分析及对公司目标用户的研究，结合当前互联网行业发展，为公司产品提供方向。通常由销售人员、产品人员以及用户数据提供支持。这个过程在中等以上规模公司比较常见，虽然高层管理也需要参与决断，但并不对研究方向起主导作用。这种方式优点是科学、准确、可行性强；缺点为反应缓慢笨拙。

当然，老板为了证明拍着脑袋想出来的是正确的，有时候也需要市场提供相应的决策支持数据，而后产品人员进行需求调研和产品设计，两者相互纠结的情况是最多的。MRD（Market Requirements Document）文档就是市场部门经过调研后针对市场需求撰写的“市场需求文档”。

也就是说，市场需求文档MRD解决了“为什么做”的问题（因为市场认可，能赚钱！），而接下去的产品需求文档PRD解决了“怎么做”的问题（用户研究，需求整理，线框图，DEMO…）。虽然通常一份MRD对应一份PRD，但也可能一个产品无法满足市场的所有需求，根据一份MRD产出多份PRD也是有可能的。当然，关于文档范围，可以根据实际情况灵活掌握，毕竟MRD和PRD只是工具。没有最好的，只有最适合的。

在模式成熟的技术导向型互联网公司中，MRD并非为产品生命周期里的必须产出物。更多的是产品总监、产品经理与高层领导共同研究后直接决定开发产品的。“为什么做”的问题已经在沟通和协调中解决了，跳过了MRD文档而直接由产品部门产出PRD文档。特别是内部需求产品，是可以完全无视MRD的；而直接面向用户的产品，也可以通过需求调研或者用户角色模型等方式，对产品可行性进行分析，并表现在PRD中。

目前，有的公司将MRD交予UED（user experience design）部门做，意义在于可以更好的满足用户体验，实际上我并不赞同这种方式。UED的精髓在于更好的满足用户，使产品流程更加通畅，设计更加人性化，用户体验的思想可以贯穿产品设计的结构层、框架层、表现层，但是，MRD是需要从战略层就开始介入的（没有市场分析的战略没有任何意义），解决了产品范围层“为什么做这个而不作那个”的问题，而MRD的着力点在于市场能否认可和产品能否赚钱，而非如何使产品更加人性化这样的用户体验。所以由市场资深人士或老板牵头，UED或者产品经理参与的MRD才能更好把握市场需求，为产品的成功奠定基石。

最后，给大家提供一个MRD文档的模板：》》点击这里直接下载PFD格式的MRD文档模板！！《《