献给曾经的“黄埔军校”

下午石头在群里说了上家公司的变化,问我是不是应该写篇文章纪念一下曾经的“军校”,一下子还真没领悟过来“军校”是什么意思,后来才领悟回来,曾经的“黄埔军校”。离开“黄埔军校”整整四个月了,选在了2011年情人节那天我离开了它,有些巧合,但是必然,今天再次说起它时,真的觉得时间过的好快,这过去的四个月,曾经的“黄埔军校”已经发生了太多的变化了。

为何曾公司为“黄埔军校”?那有微软、腾讯、迅雷、百度、淘宝、阿里……一系列行业内顶尖的精英聚集,那有60几个产品经理,200多个UED,600多个研发……1600多号人(顶峰时期),在为一个网站拼搏,为了做国内首家“SNS+电子商务”的平台,当群英荟萃的时候会是怎么样呢,于是有了黄埔一期、黄埔二期、黄埔三期……黄埔一期最早是在2010年10月10日前进入“黄埔军校”,二期则是2011年2月2日前进入的,三期是在2月14后进入的……

曾经的“黄埔军校”何等风光,挖了很多大公司的牛人、团队,于是有了PUEC(产品用户体验中心),更曾经行业内有公司曾明文公布说加入他们公司后不能跳槽到“黄埔军校”作为签合同的一个条款。当然也闹出了不少笑话,有人自称淘宝CTO,淘宝何时有这样的职位,当然也不排除有滥竽充数的,比如从淘宝商城的一个普通运营人员一下成为“黄埔军校”的GM,也有来可升职成为VP的,这也为曾经风光的“黄埔军校”留下了败笔。

在那你有宽松的工作环境,在科技园里,有一幢楼都是你可以走动的地方,在那你可以累了就下楼走走,河边坐坐的感觉也不错,在那你可以体验到加班是一件常有的事,但可以坐在玩CS的办公环境里加班通宵或许又有另一番感觉。在那你可以拿到比较丰厚的薪资,因为“黄埔军校”会给出比行业内高20%-50%的薪资来吸引人才,但真正溶入团队的又有多少呢?

“黄埔军校”培训了多少年轻的产品经理,你在别的公司或许只是个产品专员,或刚开始做产品的一员,但你在那给到的title一定会是“产品经理”,在那你或许花不了多少钱,呆个一年半载你可以存一笔钱,因为那已经在很偏的郊区了,在那你可以有爱情,因为“黄埔军校”里有很多美女,但你有时间去恋爱吗?你要陪她在科技园里逛河边?当然也不排除有人从七楼往各楼层跑,就为了去看看哪层美女多。

在那你会有一个从传统行业转来做互联网的BOSS,他最经常的一句话“我在互联网是个外行”,于是有另外一个产品经理这么说“是的,他是个外行,他一直在用自己的行为来证明他是个外行”。他可以下午只有他一个人演讲,当然他也可以彻夜的和你谈产品,从晚上九点开始到凌晨三四点。有这样激情的BOSS到底“黄埔军校”缺什么呢?那就留给下一任去解答吧。

离开“黄埔军校”四个月了,回忆的日子占了很大一部分,我曾多次和朋友说起,如果我还在那,或许我现在很轻松,半夜时分我可以走上街道去吃宵,周末可以很晚睡,可以和朋友一起玩三国杀,可以进厨房做几道可口的饭菜,喝点小酒。那有免费饮料的火锅店,以至于经常想起朋友一群在那狂饮的情景。

对于“黄埔军校”怀着感激的情,怀着怀念的心,同时带着很多美好的回忆,一定回曾经的“黄埔军校”再次走走,吃那美味的火锅,半夜上街吃烧烤……

向曾经的“黄埔军校”致敬……

手机产品设计方向

伴随着手机系统越来越多越来越杂,以及不断的推出新的手机系统,对于手机产品设计来说都将会是新的挑战,是一套多用,还是设计多套?K-JAVA是否将死亡?WindowsPhone7能够带来多少惊艳?Android和iPhone的战争谁是胜者……但有一点可以确定,手机产品设计的方向将迎来新的起点。

首先认清手机用户,为手机用户单独设计的产品:必须面对手机用户进行推广和销售,实现自身价值。其推广、下载、注册、使用、消费必须全部在手机端完成。3G让手机网速的提升,iPhone的wifi功能的添加,Andriod加快在山寨机的部署,都将促进手机产品的“一条龙”服务—手机产品整个流程将全部在手机端完成。
其次,手机产品作为PC应用的附属产品:完全为满足PC用户的移动需求服务,获得PC用户的额外附加服务价值,部分使用环节必须在PC上进行,对手机用户无意义。同时,手机作为PC应用的延伸,可以从PC用户中获得大量支持,同时自身也需要针对手机用户推广。
再次,80%的传统手机用户在一定时间内为受限制用户,无法使用PC端。手机产品的应用将在这段时间内取代PC完成相应的操作。特别是iPhone和Android的手机用户,99%是随时在线的,针对他们的产品设计及体验是不同的。

曾经Ben Shneiderman提出的“界面设计8条黄金法则”:
1、力求一致性
2、允许频繁使用使用快捷键
3、提供信息反馈
4、设计对话,提示任务已完成
5、提供错误预防和简单的纠错能力
6、允许“反应撤销”
7、用户应掌握控制权
8、减轻短期记忆负担
而现在产品设计的方向将会有新的变化:口碑传播、少即是多、兼容性、无所不用其极、关注性能和速度、抓住高端用户、大气的设计、满足用户个性化需求、寻求差异……

而随着在无线方面的深入,自己对于手机产品设计规则进行了重新设定:
1、简单快速,减少操作
手机屏幕不大,使用场合特殊,简单快速的操作,争取节省每一毫秒,简捷就是力量,优化流程,减少操作。
2、增强交互
“无交互不设计”这已经成为很多交互设计师的口头禅。做挑剔的用户,增强交互。
3、人性化
人机交互就是别让人觉得面对的是一台机器,人性化设计将是手机产品设计的方向,更贴近人性化的设计让用户的接受程度将更高。
4、魅力、革新
一款产品的第一印象很重要,能给用户带来多少新鲜感,新鲜感可以维持多久这都是这款产品的价值所在。
5、避免输入、给输入法腾出空间
手机不再靠输入进行交互动作,减少输入将是未来手机设计的主流,同随着手机屏幕的增大,别忘记给输入法腾出空间。
6、通用性
K-Java、塞班、WM、Android、iPhone等,通用性对设计者的要求很高,别让换了手机的用户迷失了“回家”的路。做全世界合适的设计。
7、合理的反馈
别让用户久等,别让用户失去耐心,合理的反馈,及时的信息提醒,让用用户得到合理的反馈提示。
8、时刻知道自己的位置
别让用户迷失在产品中。分清前进与后退,所处的版块。懂得退出,懂得进进入。
9、核心功能
产品核心功能是一切设计的基础,设计围绕核心功能将获得更多的认同感。同时会获得用户良好口碑,以及让竞争对手敬畏。
10、口碑设计
高端用户、意见领袖关注的点将是口碑设计的出发点。挑剔的用户才是真正的口碑设计的对象。

移动互联网的战火已经点燃,越来越多的互联网公司已经加大了对移动互联网的投入,不论是炒的火热的百度开发自己的手机系统,腾讯出手机,还是之前的淘宝手机等,都是朝着利于移动互联网方向发展。手机产品将会更加深入人心,不论是对品牌的执着还是对产品创新的追求,都将会是引起新的一番手机产品设计规则的创新。
未来的手机产品设计的方向将更加偏重用户体验和人性化,对于不同系统平台的体验将更加区别化,任何一个人都不想拿着iPhone手机体验的是塞班的效果,但如果拿着塞班的手机体验的是iPhone效果可能就不一样了。产品设计将更加通用性不仅代表着平台的通用性,更是交互体验的通用性。
现在说哪个手机产品做的好还为时过早,包括近期看到的创新工厂的产品以及淘宝的产品等,都无法得到的一种更好的用户体验的手机产品,或者说没达到一定高度让用户觉得可以敬畏,或惊鸿一瞥的感觉。手机产品设计任重而道远,第一印象或许就决定了这款产品的生命周期了。

以上仅代表个人观点,如果有说不对的地方请大家批评指点。

如何写PRD

PRD是每个产品人员最经常看到的文档,还是有很多产品的朋友问我PRD怎么写,如何才能表达清楚意思。其实PRD并没有规定的格式,每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。

PRD(Product Requirement Document,产品需求文档),这对于任何一个产品经理来说都不会陌生的一个文档,一个PRD是衡量一个产品经理整体思维的标准,一个PRD可以看出一个产品经理在某个领域的专业性,同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在:
1、提炼核心需求
2、思考满足核心需求的方式
3、评估方式优劣选定方案
4、思考功能概要
5、思考支撑功能和关联功能
6、细化设计功能
7、子功能(功能间迭代)

PRD其实就是将以上的思维整体走向写出来,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老板……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述。

网上已经有太多互联网公司的PRD文档,淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范,适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例,讲解一下PRD的主要内容。

1、文件命名(编号)
文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页
一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。

3、目录
不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

5、概述
概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险。
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。
产品roadmap:产品分期目标,阶段描述,以及时间点的确定,产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,二期才会继续去完善剩下的30%,同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标,而是更多的通过维护来保持产品的更新和迭代。
产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,不当使用的风险等等。风险级别为高中低。

6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级。
目标客户即为产品的最终用户,确定产品的最终使用者。
需求描述是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。
优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案。你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,永远没有过时的idea,只有最适合时机的idea。所以可以写出几个可选方案,或许是你下期产品改版一个方向。

8、效益成本分析
产品经理是个全才,在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本。
效益预测是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,最好能包含现在和过去的效益数据。如网站的PV值,软件的使用数都是效益预测数据。
产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求,包括人力成本,软硬件支出等。很大时候这份成本需要由项目经理来协助,需要有什么样的人才加入产品中需与人力协助。
非产品技术中心支持成本,产品不是只有产品组完成的,同样需要其它部门的配合与协助。比如:需要客服部投入多少的资源用于该产品的服务,需要运营部投入多少的资源运营该产品。

9、功能需求
功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求。
功能总览一般包括二个部分,一个是流程图,一个是功能表。流程图是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化,同时将列出产品的功能点。
功能详情,这是所有的产品功能的描述和规划。包括以下内容:
简要说明:告诉此功能主要干什么的。
业务规则:每上产品在使用时都有自己的规则,而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则,包括一些细节,如排版形式、日期显示方式全定好,这样方便其它人员的沟通和理解。
界面原型:产品经理在这时做的原型界面只是显示的框架,别细化,这样会给交互和UI造成错觉。只需做一个简单的界面即可,更多的时候只是个框架图。
执行者:产品使用者。
前置条件:具体的操作。
后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,所以对于建议在PRD中的前置条件和后置条件结果合起来。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求
很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求
都说产品经理是全才,在这点上得到彻底的体现。很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分:产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能,还不如说是沟通,如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

13、上、下线需求
上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要。

……

写PRD并不是产品经理的全部工作,但却是不可少的一部分,很大程度上反应了产品经理的思维和产品核心功能把握上,同时对产品经理沟通、协调、规划等都得到了一定的验证,但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

附上一份网上弄来的PRD,可以参考一下。[download id=”8″]

UED设计流程和方法

看惯了淘宝阿里旺旺的UED团队做的图,突然有点冲动,组建一个属于我们自己的UED。没有阿里、百度、腾讯等大型互联网公司有专门的UED团队成员,但我们凭着自己团队合作成立了属于自己的手机客户端UED。

1、需求调研与分析:

任何一款产品都需要对这个市场进行调研,包括会存在的对手分析以及已经存在的对手,包括短时间内会有多少公司会同样开发相同的产品,以及开发这个产品的门槛。而这部分工作需要市场、PM甚至老板的共同努力。如果产品是客户指定需要,则需要对此产品市场上有多少类似的产品做出分析,包括产品核心优势。

产出物:调查报告

2、需求确定、线框图

当了解完此类产品,对产品整体有个了解时,需要写MRD、线框图、需求确认单,写MRD是给老板看的,同时这也是向老板要资源的根本,一个人的资源是有限的,很多时间需要向老板提出资源,比如人手不够,如果手机遇到证书问题等,包括费用申请都可以写在MRD中。同时这时做为PM应该对产品的大概构成已经有了自己的想法和印象。

产出物:MRD、线框图、需求确认单

3、PRD、高保原型

当需求确定后,PM就可以动手写PRD了,同时这时交互设计师可以开始做高保原型了,一般是先有了PRD后才开始做高保真原型,但公司缺少交互设计师,所以PRD与高保原型都是由PM完成,所以基本上高保原型与PRD有时不分先后,同时PRD中要放入相关的原型说明。写出PRD与原型后需要与评审进行几轮的“轰炸”,而评审的对象有:BOSS、市场、PM、交互设计师、开发人员、UI视觉、测试等,确定是否可行,以及会遇到的问题。

产出物:PRD、高保原型

4、图片、切图、高保图片

当需求确定后,根据高保原型,UI视觉需要进行产品设计。UI视觉在设计产品过程中需要与PM、开发、测试人员保持沟通,因为图片的效果可能在手机界面上产生的效果没有想像中的那么满意,同时测试需对UI设计进行测试,UI的测试工作主要是由测试部来执行,UI设计部门除了视觉输出之外,还要提交一份简单的文档给开发和测试使用,UI的测试应该在研发启动时同步启动,当研发部门有可见输出之后,测试部门可以先对UIt效果进行测试,测试完成后进行归档,并和UI进行确认,如果确定无误则归入BUG管理系统,并且参考UI输出和文档对整个软件的UI进行验收性质的测试。UI确认单是针对于市场与客户,当市场或用户对界面效果没有异议时开始进行相关页面设计,一般UI出图先出三张:登录、九宫格、启动画面。

产出物:UI图片、UI确认单、UI测试报告


5、开发

开发阶段会遇到各类的问题,沟通成为主要的手段 ,开发与PM、UI、测试等的有效沟通显得格外重要,开发周期的控制。这需要PM去协调,同时帮助解决资源需求问题(例手机证书类的申请)。

产出物:DEMO版产品


6、测试

测试从需求确定就已经跟进这个产品了,同时对UI界面的测试,产品DEMO版的测试等,很多公司把测试过程看很不重要,或者把测试的时间缩短的很短,正常的测试应该是开发时间的1-1.5倍时间。测试承担着产品面试前最后的把关工作,显得格外的重要,需要对产品会出现的各类问题进行不断的测试,我们曾经对淘掌柜经过一天一夜不关机的不间断的测试,就是为了让产品在发布前尽可能多测出一些BUG,保证产品在交给用户时尽可能少的出现问题。同时测试需配合开发对操作手册、UC、FAQ等文档的撰写。

产出物:测试报告、UC、FAQ、操作手册

7、Beta版发布

当测试到解决了60%BUG(没有一款产品是100%解决BUG公布的,都是通过版本升级来解决BUG问题),同时没有出现死机类大BUG时,产品的Beta版需要发布给一定用户使用,这期间会出现很多的问题、及时的做好用户反馈工作、系统分析等。运营报告需要很好的对用户的意见进行收集、分析,同时PM需要时时跟进,对产品遇到的问题进行分析,对Beta2、Beta3等版本进行改进,同时挖掘数据,对用户产品需求改进的同时,做好二期产品的规划。

产出物:产品Beta版


8、正式版发布

当产品需要正式面对用户时其实已经对BUG解决80%了,可以很好的满足用户的使用了,可以对将这版本进行了确定,而当产品正式发布时,第二期的产品规划应该已经有了30%的进展了,因为这时手上已经有一定的运营报告做数据支撑,同时对于用户反馈的意见也做出了详细的分析,新的产品功能也将出现了。

产出物:产品正式版


每个公司都有自己的UED,只是很多这种流程形于无形之中,更多的公司需要的是适合自己的UED流程,以确保产品进行的更顺利,更多的用户使用上自己的产品。UED是为用户而存在,也为自己的产品而存在。