LOFTER for ipad —— 让兴趣,更有趣

点击下载 关闭

LOFTER-网易轻博

项目管理

680浏览    1314参与
榜单数据更新于2018-06-09 02:05
小和

项目管理 - 学习心得

(感谢赵云的精彩分享)


项目目标的根源 

战略目标 → 业务目标 → 项目目标     =  项目

从战略目标出发,制定业务目标,根据业务目标来制定项目目标,这便产生了项目。


项目的制约因素 


举例:

一项目要求于十月一日前完成,以能更大获取国庆期间市场份额,如新型手机。

讨论:如何处理制约因素之间的关系呢?

回答:“进度”因素是不可变的,那么只能调节“范围”、“成本”因素。建议增加...

(感谢赵云的精彩分享)

 

项目目标的根源 

战略目标 → 业务目标 → 项目目标     =  项目

从战略目标出发,制定业务目标,根据业务目标来制定项目目标,这便产生了项目。

 

 

项目的制约因素 


举例:

一项目要求于十月一日前完成,以能更大获取国庆期间市场份额,如新型手机。

讨论:如何处理制约因素之间的关系呢?

回答:“进度”因素是不可变的,那么只能调节“范围”、“成本”因素。建议增加人力财力的成本,争取在十月一日前完成项目。或降低项目的工作范围,减少工作量,保证在十月一日前完成项目。

 

 

项目和运营管理 

运营是通过开展持续的活动来生产同样的产品或提供重复的服务的一种组织职能

项目需要项目管理,而运营需要业务流程管理和运营管理

 

 

项目和运营之间的联系 

可以与产品生命周期中时间交叉

可交付成果由项目交付到运营

资源于两者之间转移

运营为项目提供资源

项目的结果可能会改变运营工作

  

 

项目经理的能力 

沟通能力

协调能力

整合资源能力

领导力

抗压力

技术业务背景

 

 

常规管理技能 

采购

市场和业务

合同以及商法

生产和分配

物流

战略、战术和运营规划

组织架构,组织行为,职业规划等

 

 

项目管理周期 

即项目启动—计划—执行—监控—收尾

 


项目生命周期—范例 



项目生命周期曲线—干系人影响 

在项目初期,项目干系人对“项目”的影响是十分大的,而这个时候变更人员,成本是最低的。

在项目末期,项目干系人对“项目”的影响是比较小的,而这个时候变更人员,成本是最高的。

 

 

项目的边界 



king

解析:APP运营的工作职责和指标



简单来说,从产品上线开始,运营工作也随之开始。运营的核心目的即让一个产品活的更好,活的更久。让产品活的更好是指通过各种推广、渠道让产品的装机量、活跃用户数、市场占有率等数据获得提升。让产品活的更久则是通过数据分析和用户信息反馈收集产品相关优化信息,以供PM进行产品功能的完善,从而获得更长的产品生命周期。
根据运营的目的,运营工作具体有:
1.渠道管理:这点对于移动互联网来说尤为重要,因为移动互联网渠道有限,应将注意力集中在应用市场、论坛或其他下载网页、移动终端的内置三个方面。因此,渠道管理又分为两方面具体工作:
渠道的扩大,即拓展商务合作伙伴;
渠道的监控,即及时了解推广渠道的用户数据与用户质量,以...



简单来说,从产品上线开始,运营工作也随之开始。运营的核心目的即让一个产品活的更好,活的更久。让产品活的更好是指通过各种推广、渠道让产品的装机量、活跃用户数、市场占有率等数据获得提升。让产品活的更久则是通过数据分析和用户信息反馈收集产品相关优化信息,以供PM进行产品功能的完善,从而获得更长的产品生命周期。
根据运营的目的,运营工作具体有:
1.渠道管理:这点对于移动互联网来说尤为重要,因为移动互联网渠道有限,应将注意力集中在应用市场、论坛或其他下载网页、移动终端的内置三个方面。因此,渠道管理又分为两方面具体工作:
渠道的扩大,即拓展商务合作伙伴;
渠道的监控,即及时了解推广渠道的用户数据与用户质量,以及时调整渠道策略。
2.市场监控:监控产品行业的发展动态,分析竞争产品的相关数据,如:装机量与活跃用户数等,并提供相应的策略。
3.活动营销:策划相应产品线上或线下的推广活动方案,以达到提升装机量、活跃用户数等相关数据的目的。
4.产品分析:协助PM进行产品调研,并提供用户反馈,针对用户行为进行细致分析,提同合理的产品改进建议。
需要说明的是,一切产品运营具体工作的基础都是数据,只有准确地跟踪数据,并进行有针对性的分析,才能进行其他运营工作。
运营的核心:效率
笔者理解所谓运营的效率,指的是能够快速的进行产品更新、处理突发事件、顺应用户需求的变化等。
运营的3大要素:用户、产品和渠道
用户和产品不用多说,所谓的渠道,理解下来应该是联系产品和用户间的通道,举个例子,QQ是产品,我们是用户,联系我们和QQ之间渠道便是互联网,试想如果没有互联网的大规模普及,也不会有QQ今天的庞大用户群,所以渠道建设在运营中所占的地位可见一斑。
运营的内容:运营策划、BD、媒介、活动营销、数据分析和市场监控
通过不断的策划确定产品的前进方向和更新,然后通过BD与渠道方建立良好的沟通,通过各种媒介向用户宣传产品,活动营销自然是用来提升活跃用户,数据分析和市场监控是为下一次策划打基础。值得一提的是市场监控中对手产品监控。
运营的3大目标:营收(即赚钱)、增加新用户的数量、提升老用户的活跃度
周鸿祎观点是:好的产品要有2个特性:1、在一点上能够打动用户,比如360的免费。2、不断的改进和更新。用户的需求是不断变化的,任何互联网产品都离不开服务的属性。
数据分析是运营工作中最重要的一环,但是要明确的一点是,数据不是万能的,千万盲目迷信数据。拿到数据的不要先记着进行分析,而是要先确保数据的准确性。根据本人的工作经验,越是复杂的产品数据越是不准确。而数据分析应避免泛泛而谈,应当找到关键一个或几个数据指标,围绕这个指标做产品的规划。任何产品都很难同时兼顾所有的数据提升,我们要做到是抓住重点。
运营的4大意识
1.成本和产出:不是有了数据提升便说明产品的更新成功,关键还是要对比下成本。每次完成产品的上线后,做一次成本和产出的对比,以此衡量迭代的效果,作为下次更新的参考。
2.聚焦和细分:不断成长的产品将面临用户群的扩大,而用户的需求则变得越来越多样性,而为了,往往为了照顾不同用户的需求而对产品进行细分,其结果容易带来就是运营力量的不足和成本的增加。所以,在没有足够运营力量的情况下,做好产品的聚焦的重要性要大于细分产品
3.效率和量级:腾讯的盈利和QQ在线人数成正比关系。在平均用户消费这样的关键指标上,腾讯10年没有进步。说明伴随着量级不断的攀升,产品的运营并没有相应的提升。产品运营的效率已经跟不上了。效率是衡量产品经理的真正价值。想起了我一位执行力超强的前辈。
4.前奏和高潮:产品的运营不要希望一击命中用户的真实需求,一个优秀的产品运营面临着是不断的失败和尝试,最终迎来高潮。
总结
1.互联网产品和运营是驱动;
2.不能把运营与产品混为一谈,再烂的产品也得运营;
3.运营必须目标导向,数据为基础;
4.平衡好各个业务逻辑之间优先和比重;
5.运营也如同产品一样是有品味,有个性的;
6.有些运营是暗藏于产品中,这是运营的高境界;
7.用户是运营中核心协同者;他们行为直接影响运营者的信心;
8.运营逻辑须与产品逻辑一致;
9.产品的愿景定义了运营范围。

king

如何写出好的PRD?

作者:Cherry,2007年进入腾讯公司,一直从事互联网广告产品管理工作,目前在SNG/效果广告平台部从事效果广告的产品运营工作。
PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚。
通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识。如何才能写出好的PRD,让产品研发团队成员,开发、测试、运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题。也...

作者:Cherry,2007年进入腾讯公司,一直从事互联网广告产品管理工作,目前在SNG/效果广告平台部从事效果广告的产品运营工作。
PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚。
通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识。如何才能写出好的PRD,让产品研发团队成员,开发、测试、运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题。也有人可能认为PRD只要中心思想不变,阐明需求就已经足够,交给下游的同学他们理解了就完事了,但是这个文档是否被叫好,是否有用,是否有价值可能从没考虑过。
在此将从PRD的用户侧分析好的PRD应该具备的要素或必要条件。
首先,先了解清楚PRD的阅读对象,使用者。
PRD的模版中一般有如下信息:
PRD预期的读者包括:产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求,以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求,是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后,这份PRD将作为后续开发、测试、需求验证的依据。
其次,一个完整的PRD还应该具备的要素有:

1、文档的命名和编号
文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。文件命名的方法一般是通过版本号定义,比如简单的方法是,XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。稍微详细点可以定义成,XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名,这样更便于阅读和记忆。

2、文档的版本历史
包括,编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序,文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改,一次修改一般为一个版本),章节是具体到修改内容属于的功能模块,以便阅读人及时找到修改后的内容,修改原因说明为什么要修改该需求,让阅读者直观的了解原因。日期是指需求文档修改的时间,修改人是指需求内容的修改者。

3、目录
不需要自己新建,文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的。

4、引言
这部分的内容有:产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明
产品概述:解释说明该产品研发的背景以及核心功能。
产品roadmap:为产品规划的蓝图,每个关键阶段完成的核心任务。产品研发是个不断迭代的过程,需要经过若干个版本的迭代,,对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标,但是对产品未来发展趋势的一种预估,要达到目标,需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌,更好的控制研发过程。
预期读者:文档的使用对象
成功的定义和判断标准:旨在说明产品的目标
参考资料:PRD的参考资料
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。

5、需求概述
需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等
需求概览:分两部分,一是业务流程图,对产品整个业务流程的发生过程做图形化的展示,是对产品整体功能流程的阐释。二是需求清单,对本次要开发的需求任务做分类,给出简明扼要的需求描述并标注优先级。
用户类与特征:产品的最终用户,确定产品的最终使用者,并对使用者的角色和操作行为做出说明。
运行环境:该产品上线后的使用环境,比如支持的浏览器及其版本,操作系统、数据库的要求等等,测试人员在看到环境要求后会在测试时重点测试,而最终上线产品时需要把最佳的运营环境告知给用户。
设计和实现上的限制:比如控件的开发环境、接口的调用方式等等
项目计划:对于prd中要开发的内容,给出关键里程碑,比如需求评审通过的时间、开发的完成时间、上线时间等等
产品风险:描述产品可能存在的风险,比如性能瓶颈,没有解决的问题,用户不当使用的风险等等。

6.功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容:
简要说明:介绍此功能的用途,包括其来源或背景,能够解决哪些问题。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。
业务规则:每上产品在开发时都有相应的业务规则,将这些规则清晰的描述出来,让开发、测试人员能够直观的明白该规则,且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改,建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明,什么时候可见,不可见,灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
界面原型:如前所述,涉及到页面交互的部分,产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是,产品经理可设计一个页面框架,将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。
使用者说明:对产品使用者做出说明,可融入简要说明中。
前置条件:该需求实现依赖的前提条件。比如,上传照片时,需要存有图像文件。
后置条件:操作后引发的后续处理。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明,对每个功能流程走向分点说明(这是非常重要的)。
看过很多的PRD,文档中对既没有前提条件,也没有后置条件,只对主流程做了说明,但是在描述主流程时却没有描写主流程中每个功能流程的各种走向,只有一个主走向,让人感觉prd成了操作手册。事实上,对分支的介绍是非常重要的,开发和测试中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程,同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案(虽然PRD不可能百分之百的覆盖所有的可能,但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则)。另外,在描写功能需求时给出的办法中不能出现“可能”、“或者”等词,一定是明确的,唯一的描述。如果有别的方案,建议写入“可选方案”,在产品构建的早期可选方案可以为功能实现提供更多的选择,当方案确定后可在文档中注明本次使用了哪种方案。
推荐一个方法:“用例”,在面向对象的软件设计模型中,用例是一个被阐述的内容,用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件,主流程介绍,帮助开发、测试等角色快速的了解产品功能。

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

8、效益成本分析
通过这一点上能看出产品经理必须是个全才,不仅要具备行业知识,还需要有财务知识。一个产品的成本衡量一般包括三个方面:效益预测、产品技术成本和其他成本支出。
效益预测是指所提供的功能在未来能产生的效益,可通过对比以往的产品或者竞争对手的产品来做预估,效益预测的指标,如每个功能点的潜在用户数、使用频率,吸引到的新的用户特征及数量。产品技术成本是指研发设计以及上线后的运营需要的资源需求,包括人力,软硬件(带宽、服务器、机房)支出。当有项目经理时可以由项目经理来协调这部分需求,如果没有项目经理,产品经理得挑头了,召集开发经理去找运维等部门落实此事。其他的成本还包括支持成本,比如上线后的运营资源投入、市场推广投入以及客服服务投入等。
此处建议产品经理们都去学习一门课《非财务人员的财务管理》体验下财务的过程管理,如果能亲历沙盘训练,记录财务明细账目,核算资产负债、现金流量、利润率的计算,对成本和利益的核算非常有帮助,而且财务上要求的一丝不苟、精益求精也是每个产品经理需要长期坚持和遵守的。

9、整合需求
产品整合能力是产品经理很重要的一个能力,业务合作通常是不可避免的,将隶属于两个不同来源的业务功能做整合也是常见需求,比如系统登陆使用公司的域用户登陆,或者付款使用财付通、支付宝付款,解决好整合需求也是体现产品经理核心竞争力的一大重要表现。

10、BETA测试需求
很多产品在正式上线前都有BETA版本或者内测版本,或者叫灰度版本,目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的,但如果需要,需要给出在此阶段要实现的目标或测试、衡量标准。
11、非功能性需求
一般情况下非功能性需求包括以下几个部分:产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容,也很好的体现了产品经理的综合素质。

12、运营计划
产品上线后如何运营,目标受众是什么,建议的推广策略、问题反馈途径、风险监控、亮点宣传等等,以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的,让产品用起来、用得好,有口碑更为重要,所以非常建议运营计划的制定上有产品设计人员的参与。
再次,说下需求变更。
需求不是一成不变的,在产品研发过程中需求变更是正常的,产品团队成员需正确的看待需求变更,并要控制好变更。这里的建议是在做需求分析时,尽可能把每个问题都考虑透彻,提前做好需求变更的预估及应对方案,必要的情况下和团队成员提前沟通存在变更的内容。
在与团队沟通变更时,需要以一种开放的心态,从团队成员的角度、产品未来的发展趋势、市场格局的变化正确的提出变更需求,始终保持产品方向的正确和团队成员目标的一致。

总结
PRD的能力映射出的是一个产品经理的产品能力,这种能力分基础和高级两类,毋庸置疑,PRD应该是一种基础能力,产品经理必备的一种技能,PRD的能力反映的就是产品经理对用户需求的理解能力,这种能力其实是建立在对行业的专业知识(表现在对业务的理解力)基础上,再加之良好的沟通能力,一个优秀的产品经理写出的PRD必然是准确度高,开发出来的产品扩展性好,同时受用户欢迎。因此产品经理在日常必须深入学习行业知识,了解用户的操作规则,多与用户沟通,多倾听问题,从而发现问题,解决问题,随着对行业和用户的理解及把控的逐步深刻,PRD阐述的内容将越来越全面,越来越有深度,这份PRD将成为其他人的学习资料,会产生深远的影响。都说产品经理引领着产品的发展方向,是产品的“爸爸”或“妈妈”,衷心的希望每个产品经理都能做个称职的父母亲。
Via:腾讯大讲堂


如果看到这段文字,证明您已经看完这篇文章了,有什么收获有什么感想有什么不赞同,我们期待您的留言评论,并诚挚邀请您加入“互联网er早读课”QQ群,一同交流每天文章的心得并结识同行。官方2群:74447564 ,加群密码“职业信息+城市+姓名”,否则不予通过,入群后请修改群名片。
阅读原文举报

king

优秀产品经理,五大新挑战。

1.平台级产品对战略思维和规划能力的要求

对一些见证着产品从小往大发展的产品经理而言,他们要思考的事情已经远不是产品是否好用这个点,这只是产品后续成长中很小的一部分。更多需要深入考虑地是平台各方利益之间的平衡。

刚刚又出版了《淘宝十年产品事》一书的苏杰以淘宝搜索产品经理的经历为例,如果他们仅仅是从买家需求出发,让那些人气排序、转化率高、销售量高的优质产品靠前,这对整个平台而言产生的问题就是马太效应和产品覆盖率低。

对于平台级的产品而言,产品经理要考虑的是多方利益的平衡,包括买家和卖家利益、大中小卖家之间、淘宝内部部门之间、短期与长期之间、局部和整体等各个角度的平衡。这要求的就是产品经理战略思维和规划

1.平台级产品对战略思维和规划能力的要求

对一些见证着产品从小往大发展的产品经理而言,他们要思考的事情已经远不是产品是否好用这个点,这只是产品后续成长中很小的一部分。更多需要深入考虑地是平台各方利益之间的平衡。

刚刚又出版了《淘宝十年产品事》一书的苏杰以淘宝搜索产品经理的经历为例,如果他们仅仅是从买家需求出发,让那些人气排序、转化率高、销售量高的优质产品靠前,这对整个平台而言产生的问题就是马太效应和产品覆盖率低。

对于平台级的产品而言,产品经理要考虑的是多方利益的平衡,包括买家和卖家利益、大中小卖家之间、淘宝内部部门之间、短期与长期之间、局部和整体等各个角度的平衡。这要求的就是产品经理战略思维和规划能力。

2.对提高企业盈利能力有全局思维

一个产品功能的设计要跳出为了设计而设计的思维,需要更多思考是否对企业的盈利有直接的影响。因为越来越多产品已经进入了用户群积累向商业化能力过渡的阶段,这个时候的功能设计就更强调全局眼光。

网易VIP邮箱总监张云以香港商场如何提高购物满意度为案例,一般大家可以想到的作法是设置更多的装修让客户开心,但这对企业的盈利没有直接影响。一个新的作法是,商场在很多位置放了电子屏幕,用户可以在这个屏幕上直接找到自己喜欢的品牌和到达路线。这就让用户在有限的时间内可以提高购物效率。

3.移动端的减法能力

对比移动端和PC端做产品的第一条显著不同即面对更小的屏幕。当没有足够大的空间展示PC端那么多的信息,如何做减法对产品经理提出了更高的要求。

产品思维的变化包括如何针对不同层级的用户提供不同的信息,如何在有限的屏幕上寻找商业化空间,如何利用硬件层面的技术提供一些更有趣的功能等。

淘宝网产品部经理陈镭在介绍淘宝移动端产品一些尝试的功能时介绍,产品人员也在尝试利用硬件的技术支持,比如两个手机碰一下可以交换购物车,或者大家的手机在同一个无线局域网时可以有哪些有意思的功能设计等。

4.不要神话“智能化”标签

追求产品的智能化因素长期以来都是一个热门话题,但并不是所有产品都要花大力气去贴这个标签。

对于智能化方式的神话,忽略用户的实际感受,并不能提高用户使用效率。一些标志着“智能”标签的产品,其实更多也是感受层面的智能,产品背后的原理其实非常简单。

在运用一些创新概念时,产品经理的创新往往是创造新的问题,但创新的根本还是解决问题,它的结果导向决定创新的真实价值。

当越来越多新概念涌入市场时,产品经理需要更强的判别能力,到底哪些新模式是真的可以解决问题,哪些被过度解读。

5.多终端适配能力

用户的产品使用场景不再局限在PC端,而是多终端的使用场景。这对产品的多终端适配能力提出了更高的要求。

一些公司对产品经理的考核中,最新加入的很重要的一条就是多终端思维。在考虑一个新功能时,照顾多个屏幕和终端上的使用场景、功能在各个终端上的延伸等都是产品思维的新角度。

也许,现在大家强调的是PC端和移动端,但未来包括电视屏幕、公交车屏幕、甚者公共场合下出现的各种智能屏幕,都是产品人员需要攻克的难题。

但无论是PC端还是移动端,产品经理的基本素养始终是相通的,这些基本的技能始终包括对需求的把握、对优先级的判断,以及寻找问题、解决问题的能力。

king

如何挖掘互联网产品的真实需求

首先我们来看一段描述,有人问张三现在的需求是什么,张三回答要宝马车,还要原装进口的。那么张三的需求是否真的就是进口宝马车呢?其实不一定,或许进口奥迪车也能满足张三的需求,但我们不能只分析到这里,要挖掘更深层次的东西,要宝马车干嘛呢?或许是为了代步以图方便,节省时间;或许是爱慕虚荣,以方便泡MM。一旦我们找到背后隐藏的需求,我们就可以去设计一个替代品,去满足用户的真实需求,以节省进口宝马车那高昂的成本。我们做互联网产品也一样,不能只关注用户表面的需求,而要挖掘出真实需求,才能设计出正确的产品。

产品设计的过程,需要考虑人的听觉、视觉、味觉、触觉等与人有关的特质,还可以外延至人的心理活动和社会处境。...

首先我们来看一段描述,有人问张三现在的需求是什么,张三回答要宝马车,还要原装进口的。那么张三的需求是否真的就是进口宝马车呢?其实不一定,或许进口奥迪车也能满足张三的需求,但我们不能只分析到这里,要挖掘更深层次的东西,要宝马车干嘛呢?或许是为了代步以图方便,节省时间;或许是爱慕虚荣,以方便泡MM。一旦我们找到背后隐藏的需求,我们就可以去设计一个替代品,去满足用户的真实需求,以节省进口宝马车那高昂的成本。我们做互联网产品也一样,不能只关注用户表面的需求,而要挖掘出真实需求,才能设计出正确的产品。

产品设计的过程,需要考虑人的听觉、视觉、味觉、触觉等与人有关的特质,还可以外延至人的心理活动和社会处境。互联网产品,其实是社会学科的自然学科表达,这里的社会学科包括社会学、心理学等等,因为人本身是感性的、主观的,代码的实现过程则是逻辑的、严谨的。这也需要我们更加关注一些理性的层面,去发掘出人真实的想法,形式追随内容,产品追随人心。

我们可以分析一些社会化产品的例子,比如QQ的隐身功能,SNS社区的真实头像和非真实头像的区别,新浪微博的即时会话功能等,看起来这些功能都不是产品的主要功能,是一些附属的功能,那么为什么要做这些功能,原因就在于人们在群体里面有个体心理表达这样深层次的真实需求在里面,这些功能可以让用户在社交过程当中有存在感又有安全感,也满足了用户倾诉表达的欲望。不过这些功能用户是不会告诉你他真正想要真实头像还是非真实头像的设置的,要靠我们去分析。

什么是需求?

需求是在一定时期内人们的某种需要或者欲望,在经济学上还有购买欲望的含义。我们在收集用户需求的时候,往往会停留在表面层次,用户说什么就是什么,但用户说的往往不是真实需求,产品经理需要尽最大的努力去挖掘用户的真实需求。

1、倾听用户不等于听从用户。很多时候我们去听用户讲解需求,会陷入到用户的思维里面去,认为用户讲的就是他们真实想要的,这是不够客观的。很多用户都不知道自己的真实需求是什么,需要把最终产品或者相似产品的参照物放在用户眼前,才能引发用户对真实需求的思考,因此用户无法表达出他们的真实需求。

2、用户想要什么不等于真实需求。如开头所讲的例子,用户想要什么产品的情况下,我们要去分析有了这个产品之后,能让用户去做什么,达到什么样的结果,再反过来去看,有哪些方式可以达到这个结果。

3、解决方案不等于真实需求。有的用户比较有思路,直接告诉你产品该怎么做,系统该怎么设计,以达到他所想要的结果。有时候碰到这种用户,产品经理也会被绕进去,还会觉得这个用户思路很清晰,沟通起来很顺畅,实际情况确是已经迷失了产品经理自身的职责。

4、可以怎么做不等于应该怎么做。后者限定死了,相对来说是基本不变的,前者确是动态变化的,可以有很多种方法,条条大道都可以通罗马,而不是应该走某条路去罗马。

以上这些方面给我们的启示就是,互联网产品的设计之道可能不在产品本身,而是在产品之外,跟人的因素、心理学、社会学等有很大的关联关系。

满足谁的需求?

知道了什么需求之后,我们还需要分析需求的目标用户。做某个需求到底是满足谁的,是普通用户的需求,还是专家用户的需求?是领导的需求,还是产品所处行业的需求?这需要我们产品经理对已获取到的需求做进一步的分析。为什么银行ATM机不能取1块钱,5块钱,10块钱?是ATM机的容量限制问题么?是 ATM机的设计问题么?其实是ATM只是为了方便那些临时缺钱的用户,而这部分用户一般不会取小面额的钱。

通常情况下我们称这类目标用户为产品的关键涉众,可以从涉众利益的角度去分析,用户需求外加商业目标,也可以反推,这样我们就能找到需求的服务对象。比如宠物商店的关键涉众是宠物的主人,而不是宠物,自然我们做互联网宠物应用APP的时候也要以宠物的主人为分析对象;财务软件的关键涉众是企业老板,而不是企业里面的会计,老板想看到什么样的财务报表,决定了下面的会计要怎么做账;现在互联网产品中很火的理财产品,就有的是面向普通用户的,有的是面向理财规划师的,这都是由产品的用户需求和商业目标来决定的。

需求实现的原则

我们分析好需求之后,在实现的过程当中也会遇到一些问题,是所有的需求都实现呢,还是只实现其中的一部分?因为现在越来越多的成功互联网产品表明,越专注于某一个功能越能体现出产品的价值,也就越容易成功。因此我们在对待需求实现的时候,也要有一个取舍的过程。

1、满足核心用户的核心需求。核心用户就是指产品目标用户中的普通用户,而不是专家型用户或者小众用户,核心需求就是产品的核心竞争力。典型的就是80/20法则,很多时候我们不能为了满足1%的用户需求而影响了99%的用户的使用场景。

2、学会妥协,在不完美中找平衡。做出一个完美的产品,相信这是大多数产品经理的梦想,但现实往往是骨感的,产品经理要学会在有限的资源下,把正确的事情做到极致,这就是成功。

3、面向未来规划产品。产品经理的思维不应该仅停留在当下,而是应该着眼于未来,如果觉得某个方向是正确的,就应该坚持朝着某个方面去设计产品,培养用户的使用习惯。毕竟几年前谁都想不到可以在手机端有微信、陌陌这种社交和通讯方式。

4、需求传递明确且不打折扣。既定的需求不能在实现的过程当中出现差错,因此产品经理要跟进实现的过程,防止出现实现偏差而导致的需求偏离。

通过以上的分析,相信大家对需求分析和实现的过程有了基本的了解,一个真实的需求没有实现出来,谁会最悲痛?用户是不知道的,因为他根本没有意识到自己的需求,产品经理是唯一可以挖掘出真实需求的人,如果你没有把握住分析的机会,或许你就在不经意间错过了很多微信级的重量级互联网产品。

Learning Time

【读书笔记】关于项目管理的一些思考——对《项目百态》的理解(一)

一直以来都很喜欢读Tom DeMarco的书,他的书很少有教条的理论,而是着重于对项目管理的本质进行剖析。前段时间看了《项目百态——深入理解软件项目行为模式》,总体感觉不错,适合想要了解软件项目管理、企业管理、软件工程的人员。本书并没有采用逻辑的结构阐述某个观点,而是将一些经验和理念分散到不同的行为模式中,让读者自己去发掘,这点比较有意思。本书还用大量的篇幅进行了组织文化方面的探讨,令人印象深刻。

本文是对书本的内容做一些回顾,对书中的观点加入了自己的理解,算一篇读书笔记,也算是对最近思考的一些总结。

1.需求是一切的源头

1.1把握真实的需求是一个艰难的互相学习的过程

虽然最终交付物...

一直以来都很喜欢读Tom DeMarco的书,他的书很少有教条的理论,而是着重于对项目管理的本质进行剖析。前段时间看了《项目百态——深入理解软件项目行为模式》,总体感觉不错,适合想要了解软件项目管理、企业管理、软件工程的人员。本书并没有采用逻辑的结构阐述某个观点,而是将一些经验和理念分散到不同的行为模式中,让读者自己去发掘,这点比较有意思。本书还用大量的篇幅进行了组织文化方面的探讨,令人印象深刻。

本文是对书本的内容做一些回顾,对书中的观点加入了自己的理解,算一篇读书笔记,也算是对最近思考的一些总结。

1.需求是一切的源头

1.1把握真实的需求是一个艰难的互相学习的过程

虽然最终交付物的功能或性能指标全部满足,但如果最终用户反映产品“不好用”,那依然是个失败的项目,通常这种失败源自需求分析阶段的工作。

对于软件项目来说,用户交互是非常重要的一环,在范围界定时就应明确的反映出来,并持续给予关注,及时调整。这里的用户交互并非单指UI或UE,交互设计固然重要,但把握到用户“真正的需求”,即,最终产品如何与客户业务相结合,则更为重要。

头痛医头脚痛医脚看起来是最省心省力的,但资源的浪费也是最可怕的,同时,最终用户还不买账。集中精力研究真正的需求,解决真正的问题,结果才能事半功倍,否则,项目最终只会贴满创可贴并被人遗忘在某个角落。

如果希望项目最终产生正确的产品或服务,必须深刻理解消费者的需求和支撑那些需求的特性。这种理解只有当消费者和开发者各自向对方学习的时候才会出现,而最难做到的就是让所有干系人意识到同心协力互相教学的必要性。

我们都知道,在项目开始的时候就指望每个项目干系人能想象出最终产品的样子是不现实的,希望统一这些人的想法就更不可能。因此在搜集需求的时候,往往是一个团队和客户互相了解、互相学习的过程,但是,以下一些障碍会阻碍这个进程:

1.客户太过熟悉自己的工作,因此对某些细节视而不见--因为他们以为开发人员已经知道了。

2.客户也许不具备良好的沟通技能,无法正确或精确的表达自己的意图,也许会对不停的提问变得不耐烦。

3.客户在没看到实物的时候去想象自己到底想要什么东西是极其困难的。

4.事先签署的需求规格书会让客户背负责任,因此,他们不得不强行指定许多内容,以免遗漏了什么东西。最终,需求收集者退化成了抄录员,双方没有了探索性的互动。

5.营销阶段的解决方案很少能解决真实的、更高层次的需求,要知道,它不是真实的东西,它也只不过是想象出来的而已。

6.没有及早开始互相学习,等到干系人脑海中的想法已经定型,改变就变得非常困难,再去学习新的东西也越来越难。于是,项目失去了创新的基石。

1.2想探寻真实的需求,请尽早并尽快向客户提供原型

很少有人愿意从零开始,但大多数人都是不错的改良者,因此,我们应该尽早并尽快的树立一个稻草人让客户进行批判,甚至我们应该故意做出一些错误的东西来测试客户的反应,原型的作用是一种需求钓饵,让我们可判断客户重视的点在哪里,其设计哲学在于尽早犯错,频繁犯错。

原型会带来以下回报:

1.每次评审之后,如果我们都使用新的原型设计来替代掉旧的(重新设计原型),可能会得到更好的主意。

2.对原型不停的改进,最终或许会得到一个完美的设计。

3.原型或者就是客户需要的(别指望它会发生,如果发生了,一定是奇迹,如果是奇迹,就要小心了——你可能在其它地方犯错了。)

1.3小心范围蔓延——需求或特性并不是越多越好

Peter Keen的论文描述过这种现象:那些想要挫败新项目的人没必要冒着风险跳出来反对。恰恰相反,他们可以通过提议数十个能够“帮助项目达成卓越目标”的附加特性和改进措施,给项目以最积极的投票。

实际上,每个人都自然而然的认为自己的需求是最重要的,因此在项目中不断加入新的、无关痛痒的特性,而这些零碎加入的特性并没有考虑到产品的一致性,没有考虑如何去与实际的业务结合,并且这些特性的成本/收益未知。虽然这些建议看上去富有建设性,但这种行为增加了项目的风险和成本,间接增加了项目死亡的可能性:项目的目标开始变得不清晰,产品的定位开始模糊,项目成员对进度、变更做出决定的方式不一致,等到产品发布的时候,已经没有折中或挽回的余地了,最后只能将一锅大杂烩交付给客户。

这种情况的产生从本质上来说,是因为项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观定义,所以额外的需求很容易从不同的来源渗透进来。避免这种情况的发生需要做到以下几点,并且团队的所有人都应该培养这种意识:

1.尽可能早的,干脆利索的定义项目目标和非项目目标。

2.声明项目范围,并以“精确定义输入/输出数据”的形式时刻保持更新。

3.拒绝那些对目标没有积极效应而又明显超出项目范围的需求。

4.遵循变更流程,对新加入的需求进行评估。

另外,采用迭代方式并经常进行特性评估的团队能够在一定程度上避免出现此类情况,因为每次评估会强制重新排定特性的优先级。团队可以选择一些具备高优先级的特性加入到项目中,另外一些会被暂时搁置到下一次评估或直接放弃,一直到列表中只剩下成本高于收益的特性,这个时候项目或许就可以宣告完工了。

1.4最终兵器:找一个关注产品和业务结合的人

很多项目失败是因为缺少一个人专门负责并确保最终的业务流程——从用户的角度来看——尽量顺利地开展。

所以,项目中需要存在这样一个人:他不需要为预算或计划负责,只关注产品如何与目标环境交互,特别是产品与最终用户的交互。他负责用户体验的一致性,并且这种工作贯穿整个项目的始终。这个人关注的是整个项目对于客户而言的最佳的结果,一直到最细微的细节。他可以不是团队内部的成员,也许是客户方的人员,但只要有一个人不断的询问子项目之间的协同状况,就足够了。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


Learning Time

【读书笔记】关于项目管理的一些思考 ——对《项目百态》的理解(七)


7 企业文化如何影响项目

7.1 这事儿很急吗?

好像许多公司里,从管理层到项目成员都非常忙碌,而事实上,很多时候很多事务并没有看上去那么紧急,之所以产生这样的现象,有下面两种原因:

很多组织会错误的将救火行为视为好事

这些组织没有计划性和战略性,任何事务都会立刻转化为“立刻要完成”的工作,这种忙碌会让管理者产生高效率高生产力的错觉,会让组织成员产生“英雄”般的自豪感。这类的组织并不总是会失败,但永远不可能构建那些需要稳定性和计划性的重大产品。事实上,任何公司都会遇到紧迫的事务,但不是所有的事务都是紧迫的,也不是所有人都需要去关心这些事务。有时候,事务的紧迫性会放大它的重...


7 企业文化如何影响项目

7.1 这事儿很急吗?

好像许多公司里,从管理层到项目成员都非常忙碌,而事实上,很多时候很多事务并没有看上去那么紧急,之所以产生这样的现象,有下面两种原因:

很多组织会错误的将救火行为视为好事

这些组织没有计划性和战略性,任何事务都会立刻转化为“立刻要完成”的工作,这种忙碌会让管理者产生高效率高生产力的错觉,会让组织成员产生“英雄”般的自豪感。这类的组织并不总是会失败,但永远不可能构建那些需要稳定性和计划性的重大产品。事实上,任何公司都会遇到紧迫的事务,但不是所有的事务都是紧迫的,也不是所有人都需要去关心这些事务。有时候,事务的紧迫性会放大它的重要性,导致组织做出错误的决策,浪费资源。

从GTD的四象限理论来看,同个人时间管理一样,组织也应该着眼于长期发展,将紧急但不重要的事务迅速处理掉(外包或指定专人处理),舍弃不重要也不紧急的事务,然后集中精力去关注重要但不紧急的事务,否则,这些事务很快将变为“紧急且重要”的事务,于是整个组织便会退化成为消防队。

紧急性是可以伪造的,而且通常都是伪造的

管理层常常宣称一个项目非常紧急,因此必须把时间减少一半,而实际情况是:这只是缩减成本的一种手段而已,他们认为项目的收益并没有看上去那么高。因为如果收益真的很高,则应该投入更多的人力物力去认真的实现它。

伪造的紧急性会引发伪造的风险,项目最终将惨淡收场,这还不是最坏的,最坏的情况是,组织没有抓住真正的商业机会去从事高价值的项目。 

7.2 没人喜欢被安排好的团队建设活动!

无论何时,人们聚在一起,打破职务和阶层的舒服,组织都会变得健康一点。没有人能一天到晚的工作,无论项目的压力有多大,人总是需要休息的。特别是持续面对巨大的工作压力的时候,人的生产率往往会降低,因此,团队需要一个用来释放压力的活动来充当安全阀,或许是共同去看场电影或是K歌,或者是办公室内部的小游戏。私人关系会成为组织工作中的润滑剂。

团队凑在一起进行烹饪或者干脆外出聚餐是个不错的主意,这种活动从某种程度上来说是一起进行的一个小项目。烹饪时有人负责烹调,有人做杂事,有人安排餐桌;外出就餐时,有人排队,有人占座,有人组织。几乎所有人都会自然而然的找到自己合适的角色并毫无怨言的去做该做的事,最终,大家一起坐下来就餐的时候,都会获得一种满足感,这种感觉不仅是食物给予的,还包含一起工作带来的快乐。吃,把所有人联系了起来。一起吃饭并不代表团队会获得成功,就像不一起吃饭也不代表团队就会失败一样。然而,很多成功的团队都喜欢呆在一起吃东西,这一过程提供了丰富的互动机会。

但是,如果是组织刻意安排的活动,效果往往并不好,如果强迫员工参与的所谓“团队建设”,后果只会更糟糕。因为组织往往无法了解成员究竟喜欢什么样的活动,谁会喜欢被命令着参与自己不喜欢的活动呢?只有从团队内部慢慢兴起的一些活动才能获得团队成员的认同。因此,在团队需要释放压力的时候,成员往往会自己想出一些办法,去做一些与工作无关的事,这些活动慢慢将演变成为安全阀。组织在面对这样的情况时,唯一要做的就是,不要去阻止,也无需鼓励,只让团队自己发展,成员自己最清楚该如何利用时间。组织只需要创造条件让人们碰面、玩的开心就足够了,绝对不要去驱迫他们。

7.3 钱能买到人心?别闹了!

组织常常在需要奖励成员的时候选择金钱奖励,但这种方法存在以下问题:

1.难以做到公平。这会降低某部分人的士气,最终影响团队的士气。

2.效果难以持久。会慢慢从“额外的奖励”变为“应得的东西”,从而失去功效,并且这个时候组织还会面临是否取消的两难境地,因为无论如何,这种行为都花费了成本但没有收益。

所以组织需要考虑一下如何奖励团队成员才会看起来不像是“廉价的收买”。

7.4 这该死的文档!

项目当中需要相当多的沟通,这些沟通又有相当一部分使用文档。多数组织会要求团队使用固定的模版进行汇报,甚至使用模版来指导工作的进行。但是这种方式只会阻碍项目的创造性、重复一再出现的错误、浪费开发人员的精力、使成员的关注焦点从项目真正需要产出的东西转向毫无意义的文案工作。

模版并非不好,它为经验的传承提供了良好的载体,但是一味的依靠模版作业遏制了人们对于不同项目选择不同做法的可能性。这里面临这样一种两难境地,如果每个项目都使用不同的模版或是对模版进行变更,则模版就不再是模版,而如果严格按照模版开展工作,则项目只会是简单的重复。不填写模版又会使组织不满。最终团队只能在文档工作上应付了事,文档无法起到本来应有的作用。团队也会纠结于字号、形式、语法,而不是项目的真正内容。

但是,为了避免沟通太多或太少或误解,在某种程度上我们又必须依赖于文档。为了解决这种冲突,我们必须注意2个问题:

1.我们试图沟通的内容是什么?2.  什么是最有效的沟通渠道?

很多时候,我们需要文档,仅仅是因为那是接下来要做的事情,而非它真的对项目的成功有实质的帮助。慢慢的,人们的关注点会从项目目标转到文档上,这导致:

  • 组织慢慢的以项目产出的文档数量来衡量项目的绩效。

  • 由于文档的不可溯,导致组织中充斥着大量的混乱的失效的文档,降低了人们的工作效率,增加了出错的几率。

  • 出于安全感的考虑(从众),人们变成了文档搜集狂,无论是否需要,人们都希望拥有一份副本。

文档使人们停止思考更重要的事情:所从事的工作是否有助于实现项目的目标?

解决文档问题的关键在于认识到每一份文档都应该满足某些明确界定的要求,方法包括:

  • 团队内部不再注重于繁重的文案工作,而是使用各种交付物进行客观的衡量。如用例、约束、特性、模块、功能点、数据元素或者其他适用于项目的东西。

  • 变换沟通的方式,不再依赖文档,而是用过电话、白板、原型作为沟通的媒介。

  • 形成一个资料库,所有需要的人可以自由取得,免得人们一直收集文档。并且,资料库使一些必须的文档变成了可溯源的,也减少了文档的混乱程度。

7.5 来来来,咱们开个会

开会通常是为了做出某些决策,但团队文化的不同决定了会议的最终走向。

有些团队的会议类似脱口秀:要求完美的信息,没有信息就不做任何决定,因为不做就不会错;不断的拖延;不停的离题;变成技术细节的辩论;打屁聊天;最后------“下次开会再讨论吧~”

高效的团队专注于会议主题,有会议记录、回顾和下一步行动,某些事项在会议上已经完成,他们有信心,对时间的紧迫性有清醒的认识并且不会特别担心做错事-只要经常评估并进行修正就可以。

实际上,会议在很多时候并不是做出决策的唯一手段,成熟而专业的组织都具有自己的决策机制,这些规则确保了决策的有效性,而不是不断的举行集体会议,不断的将项目推倒重来。良性的模式是,由权威做出决策,掌权的人负责监督决策的实际执行,因为掌权的人未必是权威,而权威未必掌有权力,所以,对于错误的决策,沉默的专家和无知的经理们都要负上同样的责任。

7.6 和谐是因为人们恐惧

有些组织喜欢营造和谐的氛围,为了让一切都看起来很好,他们用尽了方法并最终达成了目的,但所有这些方法其本质都是在组织内部营造了一种恐惧的文化。组织的成员恐惧被指责、恐惧被公司降罪、恐惧裁员、恐惧个人失败、恐惧项目失败等等,那这种文化是如何毁掉一个项目乃至整个组织的呢?

人们恐惧背黑锅,所以拼命掩盖真相

每次项目的坏消息在最初的时候都包含在各类汇报中,但往往,坏消息在一层层的传递中被美化,人们最终看到的是一派歌舞升平的景象。刻意隐瞒的坏消息最终会使得可解决的问题变成无法解决的问题,最高管理层会惊诧莫名:明明一直进展顺利的项目为何突然之间就失败了?

在这些组织里:

  • 没人愿意听到坏消息,人们在看到报告的时候,优先开始进行互相攻讦,所以传递坏消息的那个人总是会倒霉的。

  • 如果你发现了问题,那你就得负责解决问题。没有人会希望对自己公布的问题负上责任。

  • 如果你发现了问题,但又没有解决方案,那就是发牢骚。发牢骚的员工是不受人待见的,没人愿意当这样的人,所以大家即使发现问题也会闭嘴。

  • 人们在等其他人揭露更大的问题,这样,他们就能趁机掩盖自己的问题。

基于这样的企业文化,迅速的揭晓真相是一条殉难之路。组织不希望听到即时的事实,而希望尽可能长时间的保持其乐融融的和谐局面。即使真相最终被揭露,组织也倾向于等到那一天来临的时候再“着手处理”。因此,所有的人都倾向于将坏消息美化到看起来没那么坏的程度,这导致报告的数据慢慢变的不真实,影响到最终的决策。

人们恐惧被人看扁,所以从不说“我不知道”

有些组织把说“我不知道”的人打上懦弱或无能的标签,因此没有人会在公开场合承认项目存在不可预知的因素,他们要么扯开话题,要么虚假承诺,事情因此拖的更久,直到项目最后变得不可收拾。

如果组织让你觉得说“我不知道”是安全的,那就会有更多的人愿意坦诚,问题会被发现,人们会互相帮助。“我不知道”是信任的宣言,这类组织真正是在各个层面上都鼓励互相写作的,并因此获得相应的好处。

人们恐惧批评,所以从不发出不同的声音

组织不允许有不同声音的存在,这是因为某个高层认为不同的声音就是批评,而批判就是针对个人的指责,而指责某人会伤感情。组织同时还认为,自身的文化还没有强大到能适应批评并从中反省的地步,因此,由于无法确定决策最终的好坏,那么所有人都应该接受决定并闭上嘴巴。他们还给这种刻意营造的氛围起了名字,叫做“和谐”或“礼貌”或“职业素养”,最终,组织里所有的人都是一副假面孔,人们被迫每天背着面具工作。

人们恐惧被指责不努力,所以便只付出“努力”

通常,这类组织有这样一种认知,即:只要“努力”就值得赞许的思想,一个人是否努力并表现出高涨的士气是其个人绩效的评价因素,似乎项目的成功和失败都取决于成员是否努力。(如果这是真的,那为什么还有“管理”这门学科呢?)

高涨的士气永远是组织健康运转的一个象征,但有些组织喜欢把这个逻辑反过来,即:如果士气高涨,那事情就会变好,既然这样,那就让士气“高涨”吧!于是他们开会,搞活动,所有人都要其乐融融的参与进来,如果有人胆敢提出尖锐的意见,那就死定了。其结果是,不管项目存在什么问题,都没有人开口,只管“努力”干活并在公开场合鼓掌欢呼。

有的时候,团队成员早就知道项目会失败,但如果说实话,则会面对管理层的质疑:“你怎么这么肯定你们无法做到?”或“你没有努力去尝试又怎么知道自己无法做到?”而项目的目标是否是合理的、可达的根本不重要。所以,即便所有人都知道项目是不可能完成的(老板可能会心存侥幸),但不会有人说出来,因为那意味着懦弱、逃避责任、不科学的预测或是存心唱反调。在这样的环境里面,“努力了而无法完成”比“站住来指出问题”更安全。

面对被视为懦夫或偷懒者的言论,团队成员会选择沉默,于是他们基于以下的想法,选择在项目初期就开始加班:项目注定失败,如果我加班,经理会认为我一直都很尽力,失败的责任就不会落在我头上。这种现象最终会将团队变得筋疲力尽、雇员背叛、计划延期,甚至会因为对质量妥协而最终损害产品的完整性,直到项目无可避免的走向失败。

人们恐惧承担责任,便让所有人都承担责任

一些项目的运作原则是:每一件事务的责任都有所有人共同承担。看起来很“团结”,但这是政策制定者本身就不愿承担责任的体现,运用这种方式最终只会造成互相推诿以及法不责众。

解决这个问题需要定义项目基本元素的特征,以便能够进行明确的区分,并使每个人都对它有相同的理解。如果能做到这些,就可以给每个人安排独一无二的职责内容,从而促进每个人的责任感,即使项目出现了未能预知的事情,也能游刃有余,因为每个人都习惯了承担责任,而不是畏惧责任。


所有以上这些问题都源于管理层恐惧听到坏消息,所以当他们最后一个知道坏消息的时候,已经完全无法挽回了。

如何解决?很简单:坏消息出现时,首先去解决问题,而不是问责(问责是另外一回事,那不是项目中应该关注的问题),待问题解决之后在查找问题产生的根源,再想个办法去彻底解决问题。

坏消息是可以被解决的,但决不能被美化。

7.7 谁在乎项目成败?

有些组织透出活力,他们目标明确,容光愉悦的四处走动,有些则像被遗忘了一样,人们在办公室里等着下班回家,等着下一次发薪,一边寻找一些有刺激的事情,或者等着退休之日的来到。这是鉴定一个组织的成员是否在乎工作的重要标志。

一个在乎项目成败的人会怎么样?很显然,他会爱或恨某个项目、某件工作、某个流程,因此在工作当中产生争论。这是再正常不过的事情了,争论的目的是为了说服别人,因此首先要说服自己,为了经受住质疑和审查,你必须论证严密,表达清楚,这使得我们的观点变得更好。

争论的重点在于对事不对人,假如每个人都明白,争论并不是对自己有意见,而是为了通过争论的方式改善自己的主张,那么争论在团队中会起到催化剂的作用,将成员的注意力吸引过来,良好的争论气氛也使成员乐意加入这样的讨论,结果是,每个人的思维都被激活了,大家都得到了更多的灵感和注意,最初引起争论的问题由于集思广益也被完美的解决了。

建立这一种良好的氛围并不是一朝一夕的事,而如果有人开始尝试正常的争论(不是争吵),结果是好的,那么这种工作方式将会成为整个组织文化的一部分。

还有一种完全不在乎项目成败的人,这种人是这样的:在项目的最后时刻才对项目提出批评并拒绝提出解决方案,这种人就好像项目中的影评人。很显然,他认为项目成败与自身的成败无关。造成这种现象的原因是:组织认为一个项目存在多种成功的途径,甚至,组织会特意安排这样的角色。但无论如何,影评人即使再努力,他对项目成功的影响也是微乎其微的,甚至是适得其反的。因为挑毛病是最简单的,一旦人们认为组织赞成并奖励这种行为,就没有人会盯着自己手头的事情了。

好的组织则相反,他们强调正确的做事情,而不是“发现别人犯错=正确的做事”。

关心则乱,情绪对工作的干扰程度取决于人们对自己工作的关心程度。不让员工有任何情绪的简单办法就是招聘那些对工作不以为意的人。

对工作富有激情的人才会产生激动的情绪,如果组织不喜欢这类人,当他们意识到情绪和晋升互相排斥的时候,只会产生两种后果:

1.员工离职--组织失去了一个在乎工作的人。

2.员工不再有情绪--组织失去了一个在乎工作的人,得到了一个不在乎工作的人。

哪种对组织更有利呢?

有些公司甚至“禁止员工带着情绪工作”,这是嫌死的不够快么? 

7.8 开放的文化

组织应该乐于接受不成熟的想法

经验表明,一个不成熟的或是无法立即实行的想法最终有可能进化为一个有价值的商业产品。基于这样的认识,组织应当允许并鼓励人们说出不成熟的想法。相对发明新的东西,人类更擅长改善已有的东西,只要坚持下去,一个不成熟的想法经过不断的完善和优化,最终会使组织受益。

而人们不愿意提出想法的原因在于以下这种组织文化:组织习惯于将不是那么可行或直接的想法直接丢弃。这种做法阻碍了人们表达的欲望,遏制了创新。因为想法被丢弃意味人们不得不三思,需要在脑海中不断印证想法,确保它是无懈可击的,否则就有可能会被指责或是嘲笑。并不是所有的人都是发明家,也没有人能够突然的、平白的想出一个完美的点子,因此人们需要一个宽松的环境说出自己的想法,经过团队的讨论甚至争论,想法将变得趋向于完美。虽然最终并不是每个想法都会被接受,但每一个想法都应该获得这样的机会。

想法不应该被约束,组织所要做的只是不加约束,形成一种使人们觉得能够提议不成熟想法的文化。

到底谁是组织的核心?

有些组织里,管理者是核心,他们选择项目、分配任务、制定计划、追踪进度并最终给出一份漂亮的报告。他们认为开发人员只是纯粹的技术工种,如果有人不喜欢,那随时可以离开,他们会和HR一起另外再找一个。

另一个变体是,销售是核心,毕竟,再好的产品也需要有人将它卖出去才行。

以上两种文化都持有这样的意见:开发人员随处可见,因此无需特意照顾。

有些组织对待开发人员的态度完全不同,这些组织的关注点通常在产品的质量和创新性。组织允许开发人员按照自己的想法自由发挥,他们知道不同水平的开发人员之间的天壤之别,他们尽全力希望得到最好的开发人员。不过这种文化的极端也会严重影响到项目,那些天才开发者们不停的在产品上挥洒创意,不断的尝试新的挑战,他们知道有deadline,但他们认为没有问题,所有的工作都会在那之前完成的。但是他们完全没有意识到,组织里的其他人全部都无所事事,因为没有一样已完成的工作可以由这些人跟进的。没有彻底完成的组件,所以无法测试;没有已确定的特性,所以无法宣传;没有明确的计划表,所以无法报告。突然有一天,天才们宣布他们在deadline的前一天完成了一个划时代的产品,但是,项目恶化了。

如果组织决定要专注于产品质量和创新的时候,必须确保组织的文化能够吸引、培养并留住顶级的开发人员,同时也必须确保不走向另一个极端。

尝试团队间透明化的沟通

有些组织奉行最少公开原则,每个人都只知道自己“应该知道的事”,但问题在于,公布信息的人永远不知道其他人到底“应该知道”哪些事。大多数时候,这是造成沟通不畅的元凶。

而过于公开,即那种把所有人都加入邮件列表的形式又只会造成信息过载。完全公开所有信息基于以下几种原因:

1.个人的信息焦虑,认为不了解所有的信息自己就无法完成工作。

2.责任泛化,所有人都了解信息的时候,包含一个隐式的条件,即不反对即同意。如此一来,责任便均摊到了每个人都上,也意味着无需有人为事情负责。

3.组织不知道该让人们做什么,所以就让大家都参与进来,实际上,发布的信息内容并不重要,重要的是,大家都在忙。

信息完全公开的问题在于,过多的信息导致人们在工作中注意力涣散,虽然最封闭的组织会在运转中存在不便,但却要比最公开的组织运转起来好一点点。

因此,我们需要一种介于两者之间的信息公布方式:人们了解一些与自身职责无关的内容,但无需了解所有的事情,这样不仅可以促使个人的成长,也能避免信息过载。

有的组织使用这样的解决方式:每个团队把自己认为可以公布的信息,比如现在的工作状态、进度、计划、甚至心情之类的东西写到一张纸上,然后张贴到公告板上并不断更新,其他团队的成员在路过公告板的时候就能看到这些信息,并且,他们可以选择只查看自己需要的信息。

这种方式传递的不止是信息,还有信任感,团队选择了发布所有信息的方式,没有遮掩(因为马上就会被揭穿),也没有强制的推送,这会使其他团队的成员感觉到坦诚。另外,从某种程度上,这种方式省略了不少项目管理和文档分发的工作。并且在这个过程中,所有团队的目标被统一了起来,因为大家都看的到是否有人的工作和自己想象的有偏差,这会促使组织进行目标的审视,也会让团队之间进行关于目标的沟通。最后,从整体层面上看着工作进度的不断更新,了解自己的工作对于促成组织慢慢达成目标所产生的影响,对于所有人来说,都是一件充满了成就感的事情,因此,团队的士气会随着项目的开展越来越好。

想想这种做法,再看看那种在墙上贴满印着登山运动员、奔跑的白马、老掉牙的成功学激励语的图画的做法,你自己喜欢在哪种环境下工作?


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


king

产品经理必知:沉没成本和机会成本

产品经理们日常的开发中经常需要算计到项目成本,而很多情况下我们都只算计到项目人力成本,而忽略沉没成本和机会成本。明白“沉没成本”,就不会被过去形成的存量绑架。明白“机会成本”,就不会被某种虚妄的构想绑架。而人生苦短,则是一沓越撕越少的支票本。
看到一个故事,一个数学老师带着三个学生去吃饭,有个活动,消费三百返三十,当时已经吃了270了,但是非常难吃。这个时候,学生提议我们再点三个冰淇淋,凑够300好了,反正也一样是270。后来老师说,还是算了,然后就走了,出去以后,买了几个DQ(一种品牌冰淇淋,单价20-30)。理由是,已经吃了这么难吃的饭了,就不要多吃几个难吃的冰淇淋了,虽然不花钱。
这就好像你...

产品经理们日常的开发中经常需要算计到项目成本,而很多情况下我们都只算计到项目人力成本,而忽略沉没成本和机会成本。明白“沉没成本”,就不会被过去形成的存量绑架。明白“机会成本”,就不会被某种虚妄的构想绑架。而人生苦短,则是一沓越撕越少的支票本。
看到一个故事,一个数学老师带着三个学生去吃饭,有个活动,消费三百返三十,当时已经吃了270了,但是非常难吃。这个时候,学生提议我们再点三个冰淇淋,凑够300好了,反正也一样是270。后来老师说,还是算了,然后就走了,出去以后,买了几个DQ(一种品牌冰淇淋,单价20-30)。理由是,已经吃了这么难吃的饭了,就不要多吃几个难吃的冰淇淋了,虽然不花钱。
这就好像你花了五元钱,买了一个烂苹果,为了不浪费,还是吃掉了。这样你不但损失了五元钱,还吃了一个烂苹果。其实这五元钱就是沉没成本,就是你怎么做都无法收回的成本,在沉没成本前,我们最容易犯的错误就是,对“沉没成本”过分眷恋,继续原来的错误,造成更大的亏损。就好像,一些姑娘爱上一些烂人,因为觉得之前付出太多了,甚至怀孕了,就勉强嫁了吧,结果婚后更悲惨,然后……
其实很早之前我虽然不知道这个概念,但我已经有类似的觉悟。上大学的时候,有一种说法是,你的学费大概是多少,然后你要上多少节课,每节课的成本大概是多少(好像一二百吧),如果你不去,你就亏了这一二百。然后我往往会跟他们说,你交学费已经损失了钱,是不是要把时间也搭上呢?然后毅然的就逃课了。我承认这不是什么好事情,但起码还算一个好道理,很多人听完之后都是哑口无言的,当然,实际上看来,多上课的和不上课的在之后的人生中并没有明显的差距。记得当时我接触电脑比较早,比较懂,有同学没有接触过电脑,后来通过刻苦学习,终于算是精通了,能写会编的,然后得意洋洋的说,你看,你刚开学的时候挺牛的,现在我也很牛了吧。后来这个人毕业就去电脑城装电脑去了。
沉没成本基本上是现在电话和短信诈骗的核心支撑理论了,一般这些人一开始都让你交一点小钱,等你交了,就让你慢慢越交越多,很多人觉得,如果后面不交,前面就都拿不回来了,所以就侥幸心理,一再追加投入,最后越陷越深。很多投资公司也这么干的,让你一开始出点小钱做一些评测、资质、标准,很多人就越投越多,想着万一成了,可以拿到上千万投资,就咬牙坚持一路评测下去,最后血本无归。
机会成本则是另一个容易被人忽略的问题。什么叫机会成本呢,也就是选择成本,就是你做出一个选择,就可能损失另一个选项的成本。
举例说,你选择了这顿饭吃麦当劳,就丧失了吃必胜客的机会,而有可能必胜客正好有一个很大的促销,你就错过了。更严苛一点的是,你选择了在宿舍看美剧就丧失了去图书馆看书的机会,而你有可能在哪里遇到一个妹子,最后可能会成你老婆。然后,你看了美剧,就没老婆了。这个老婆,就是你看美剧的机会成本。
这个问题和我之前讨论过的时间成本一样重要,你一定要明白,你做选择是有成本的,千万不要抱着试试看的想法,因为你是冒着损失其他机会的成本来尝试的,一定要努力得到一个值得的结果才好。这个东西在资本运作中就更为明显,比如你当年有一笔钱,你选择投资了房产,可能就笑死;投资了股市,可能就哭死。
这个思想贯彻后,会帮助你分析各种选择,尽可能减少一时冲动的选择,很多人都会有一时冲动导致的一不做二不休的情况。这个时候,你要考虑下你的机会成本,可能就会冷静下来了,适合创业激进分子。
沉没成本的故事告诉我们遇到损失,要及时止损,做不到这一点,就不要碰股票。而机会成本则告诉我们,做选择的时候多思考可能造成的损失,最起码,你会损失时间。比如说你毕业就去创业三年,如果失败了,你不仅仅损失的是金钱,更重要的是,你损失了三年的时间,而这三年,你工作的同学可能已经在某个领域站稳脚跟,甚至有所小成了。这就是你的机会成本,你一定要确保你得到的大于这个机会成本,再去做选择,会比较靠谱。

七滴水

『31』关于任务清单的笔记

本文是关于『任务清单』的笔记。因为任务清单实在是太常用了,但是不知道一些基本原则的话又难以充分发挥其价值,所以整理了我的经验和很多相关资料,形成了本文。


话说,本文的干货相当多啊!


待办事项需要有多详细?


不要指望“足够详细”:


很多时候在实践到足够深度以前是没有办法制定足够详细的规划的。规划的科学性是随着实践的深入而提升的。


一定要有量化指标:


制定计划一定要有明确的量化测评标准,比如做完什么,学好什么,就不如定义学到什么程度...

本文是关于『任务清单』的笔记。因为任务清单实在是太常用了,但是不知道一些基本原则的话又难以充分发挥其价值,所以整理了我的经验和很多相关资料,形成了本文。

 
 

话说,本文的干货相当多啊!

 
 

待办事项需要有多详细?

 

不要指望“足够详细”:

 
 

很多时候在实践到足够深度以前是没有办法制定足够详细的规划的。规划的科学性是随着实践的深入而提升的。

 
 

一定要有量化指标:

 
 

制定计划一定要有明确的量化测评标准,比如做完什么,学好什么,就不如定义学到什么程度,或者抄完什么,看完什么那样量化。

 
 

收集杂事和整理为“行动清单”的区别何在?

 
 

这是“收集”和“整理”的差异。整理以后应该具有关联性,并产生行动指导性。

 
 

怎样算是“整理好了”?

 
 

达到以下要求:①有具体行动;②有达成结果;③有明确内容;④有时间底线。

 
 

任务清单基本原则:重要任务优先

 

重要任务优先原则——来自[The Hard Stuff Often Matters Most@Zenhabits]:

 
 

人们往往倾向于完成任务列表的众多边边角角的任务,而唯独避开一些困难的任务。但是实际上能够带来进步和决定性成就的,偏偏就是那几个最难的任务。所以,作者认为,应该咬牙坚持先完成最难的几个任务,哪怕一天只用三小时左右去完成这些任务,也能看到可观的进步。

 
 

类似地,《哈佛商业评论》也有文章建议给自己定下一条规定:在完成每天最重要的任务之前,不要干别的小事儿。说的是同样的道理。

 
 

注意每天的任务量是有限的:

 

1、每天只能有1件大事、3件中事,5件小事——来自[更好的To-Do List:1-3-5法则@褪墨]:

 
 

在褪墨的原文中被称作『1-3-5原则』。具体是指,每天只能有1件大事、3件中事,5件小事。

 
 

这里要注意的是,需要做完的这些事都有最高的优先级,其差别只在于消耗的时间长短。所以,如果想要更好地使用这个方法,需要有对时间的预估能力,也就是时间统计和数据分析。当然,即使没有预估也可以实践,只是精度降低而已。

 
 

2、每天6件事——来自《整理的艺术》:

 
 

内容:①写出6个任务;②排序。

 
 

被称为“艾维·李(Ivy Lee)的金点子”,是价值25000美元的生存术。

 
 

这是个非常简单的ToDo管理方法。首先是要求员工在下班前写出六件明天必须做的事情,然后按照重要程度,用数字1到6给这六件事标记排序。第二天早会上,对昨天的任务列表进行确认,并按照排好的优先顺序来进行处理。这个ToDo项目不一定非要在当天全部完成。下班前总结的时候,连同没有做完的任务,再写出第二天的六个任务,并按照重要程度标上数字。要做的就这么简单。

 

king

如何挖掘互联网产品的真实需求

首先我们来看一段描述,有人问张三现在的需求是什么,张三回答要宝马车,还要原装进口的。那么张三的需求是否真的就是进口宝马车呢?其实不一定,或许进口奥迪车也能满足张三的需求,但我们不能只分析到这里,要挖掘更深层次的东西,要宝马车干嘛呢?或许是为了代步以图方便,节省时间;或许是爱慕虚荣,以方便泡MM。一旦我们找到背后隐藏的需求,我们就可以去设计一个替代品,去满足用户的真实需求,以节省进口宝马车那高昂的成本。我们做互联网产品也一样,不能只关注用户表面的需求,而要挖掘出真实需求,才能设计出正确的产品。

产品设计的过程,需要考虑人的听觉、视觉、味觉、触觉等与人有关的特质,还可以外延至人的心理活动和社会处境。

首先我们来看一段描述,有人问张三现在的需求是什么,张三回答要宝马车,还要原装进口的。那么张三的需求是否真的就是进口宝马车呢?其实不一定,或许进口奥迪车也能满足张三的需求,但我们不能只分析到这里,要挖掘更深层次的东西,要宝马车干嘛呢?或许是为了代步以图方便,节省时间;或许是爱慕虚荣,以方便泡MM。一旦我们找到背后隐藏的需求,我们就可以去设计一个替代品,去满足用户的真实需求,以节省进口宝马车那高昂的成本。我们做互联网产品也一样,不能只关注用户表面的需求,而要挖掘出真实需求,才能设计出正确的产品。

产品设计的过程,需要考虑人的听觉、视觉、味觉、触觉等与人有关的特质,还可以外延至人的心理活动和社会处境。互联网产品,其实是社会学科的自然学科表达,这里的社会学科包括社会学、心理学等等,因为人本身是感性的、主观的,代码的实现过程则是逻辑的、严谨的。这也需要我们更加关注一些理性的层面,去发掘出人真实的想法,形式追随内容,产品追随人心。

我们可以分析一些社会化产品的例子,比如QQ的隐身功能,SNS社区的真实头像和非真实头像的区别,新浪微博的即时会话功能等,看起来这些功能都不是产品的主要功能,是一些附属的功能,那么为什么要做这些功能,原因就在于人们在群体里面有个体心理表达这样深层次的真实需求在里面,这些功能可以让用户在社交过程当中有存在感又有安全感,也满足了用户倾诉表达的欲望。不过这些功能用户是不会告诉你他真正想要真实头像还是非真实头像的设置的,要靠我们去分析。

什么是需求?

需求是在一定时期内人们的某种需要或者欲望,在经济学上还有购买欲望的含义。我们在收集用户需求的时候,往往会停留在表面层次,用户说什么就是什么,但用户说的往往不是真实需求,产品经理需要尽最大的努力去挖掘用户的真实需求。

1、倾听用户不等于听从用户。很多时候我们去听用户讲解需求,会陷入到用户的思维里面去,认为用户讲的就是他们真实想要的,这是不够客观的。很多用户都不知道自己的真实需求是什么,需要把最终产品或者相似产品的参照物放在用户眼前,才能引发用户对真实需求的思考,因此用户无法表达出他们的真实需求。

2、用户想要什么不等于真实需求。如开头所讲的例子,用户想要什么产品的情况下,我们要去分析有了这个产品之后,能让用户去做什么,达到什么样的结果,再反过来去看,有哪些方式可以达到这个结果。

3、解决方案不等于真实需求。有的用户比较有思路,直接告诉你产品该怎么做,系统该怎么设计,以达到他所想要的结果。有时候碰到这种用户,产品经理也会被绕进去,还会觉得这个用户思路很清晰,沟通起来很顺畅,实际情况确是已经迷失了产品经理自身的职责。

4、可以怎么做不等于应该怎么做。后者限定死了,相对来说是基本不变的,前者确是动态变化的,可以有很多种方法,条条大道都可以通罗马,而不是应该走某条路去罗马。

以上这些方面给我们的启示就是,互联网产品的设计之道可能不在产品本身,而是在产品之外,跟人的因素、心理学、社会学等有很大的关联关系。

满足谁的需求?

知道了什么需求之后,我们还需要分析需求的目标用户。做某个需求到底是满足谁的,是普通用户的需求,还是专家用户的需求?是领导的需求,还是产品所处行业的需求?这需要我们产品经理对已获取到的需求做进一步的分析。为什么银行ATM机不能取1块钱,5块钱,10块钱?是ATM机的容量限制问题么?是 ATM机的设计问题么?其实是ATM只是为了方便那些临时缺钱的用户,而这部分用户一般不会取小面额的钱。

通常情况下我们称这类目标用户为产品的关键涉众,可以从涉众利益的角度去分析,用户需求外加商业目标,也可以反推,这样我们就能找到需求的服务对象。比如宠物商店的关键涉众是宠物的主人,而不是宠物,自然我们做互联网宠物应用APP的时候也要以宠物的主人为分析对象;财务软件的关键涉众是企业老板,而不是企业里面的会计,老板想看到什么样的财务报表,决定了下面的会计要怎么做账;现在互联网产品中很火的理财产品,就有的是面向普通用户的,有的是面向理财规划师的,这都是由产品的用户需求和商业目标来决定的。

需求实现的原则

我们分析好需求之后,在实现的过程当中也会遇到一些问题,是所有的需求都实现呢,还是只实现其中的一部分?因为现在越来越多的成功互联网产品表明,越专注于某一个功能越能体现出产品的价值,也就越容易成功。因此我们在对待需求实现的时候,也要有一个取舍的过程。

1、满足核心用户的核心需求。核心用户就是指产品目标用户中的普通用户,而不是专家型用户或者小众用户,核心需求就是产品的核心竞争力。典型的就是80/20法则,很多时候我们不能为了满足1%的用户需求而影响了99%的用户的使用场景。

2、学会妥协,在不完美中找平衡。做出一个完美的产品,相信这是大多数产品经理的梦想,但现实往往是骨感的,产品经理要学会在有限的资源下,把正确的事情做到极致,这就是成功。

3、面向未来规划产品。产品经理的思维不应该仅停留在当下,而是应该着眼于未来,如果觉得某个方向是正确的,就应该坚持朝着某个方面去设计产品,培养用户的使用习惯。毕竟几年前谁都想不到可以在手机端有微信、陌陌这种社交和通讯方式。

4、需求传递明确且不打折扣。既定的需求不能在实现的过程当中出现差错,因此产品经理要跟进实现的过程,防止出现实现偏差而导致的需求偏离。

通过以上的分析,相信大家对需求分析和实现的过程有了基本的了解,一个真实的需求没有实现出来,谁会最悲痛?用户是不知道的,因为他根本没有意识到自己的需求,产品经理是唯一可以挖掘出真实需求的人,如果你没有把握住分析的机会,或许你就在不经意间错过了很多微信级的重量级互联网产品。

Madwoman Trista

【经验总结】如何成为一名合格的项目经理

在半年换了工作后,我的lofter就很少更新了…… 这半年里,我从一个产品经理,转变成了一个产品经理+项目经理,带着理论上场后,发现实战中的问题更多,关于项目管理的基本知识,之前有总结过,大家可以参考:http://trista-yan.lofter.com/post/1d4fb20e_9a91b47,这篇更多是实战中的一些问题以及解决方案。

我将根据之前提过的项目管理的定义“通过周密的计划,管理好项目中的人、事、物,达成项目目标。”分别进行阐述。


一、干系人管理

1.干系人分析

干系人是项目管理中的重中之重,在项目启动初期,一定要做好干系人分析。

我撸着袖管子开干...


在半年换了工作后,我的lofter就很少更新了…… 这半年里,我从一个产品经理,转变成了一个产品经理+项目经理,带着理论上场后,发现实战中的问题更多,关于项目管理的基本知识,之前有总结过,大家可以参考:http://trista-yan.lofter.com/post/1d4fb20e_9a91b47,这篇更多是实战中的一些问题以及解决方案。

我将根据之前提过的项目管理的定义“通过周密的计划,管理好项目中的人、事、物,达成项目目标。”分别进行阐述。


一、干系人管理

1.干系人分析

干系人是项目管理中的重中之重,在项目启动初期,一定要做好干系人分析。

我撸着袖管子开干后,发现自己没有分析干系人的直接下场,就是项目中阻碍丛丛,每个被忽略的干系人,都会影响项目的过程,甚至是结果。

发现问题所在后,我列了个干系人登记册,进行了干系人的分析。


干系人分析主要是要分析每个干系人的需求、期望、影响力和利益相关度。

分析完成后,根据干系人矩阵,实行不同的管理策略:

  • 影响力高、利益相关度高的:重点管理

  • 影响力高、利益相关度低的:令其满意

  • 影响力低、利益相关度高的:随时告知

  • 影响力低、利益相关度低的:监督任务


2. 沟通管理

 一个合格的项目经理,至少有90%的时间要花在沟通上,根据最初的项目计划,我定义了一份沟通计划。


沟通的方式多种多样,有正式的沟通和非正式的沟通,根据实际情况可以进行调整和裁切。上述列举的,是正式的沟通。

正式沟通在会后一定要发送会议纪要,或者其他相关文档!所有文档均需要留存,保存在项目文档库!

会议纪要模板:


没会议纪要会出现各种问题,很多人会不承认会上的约定,有矛盾时,只要查阅文档就可以解决80%的矛盾

正式沟通可以包括但不限于:

  •  每日站会:通常跟研发团队进行,每个人挨个发言,讲述昨天做了什么,今天要做什么,尽量控制在10分钟以内。

  • 项目状态报告:我会每周发送一份项目状态报告给全员,告诉大家现在项目的整体进展情况,格式如下:

        包含内容:         

            里程碑

            里程碑拆分的子任务

            计划完成时间

            实际完成时间

            负责人

            状态

            备注

  •  周会:同站会,总结上周任务,和下周计划,输出文档:


  • 项目计划更新:更新项目关键节点的计划后,发送邮件给全员(形式可以是甘特图、表格 等等)

  • 需求及需求变更沟通:PRD更新发送给全员,组织评审会议。

  • 测试用例评审:测试输出测试用例后,由研发团队进行评审。

  • 上线通知:项目上线后,发送邮件告知所有干系人(业务、技术、老板等等)


    另外,重点来了!

    在沟通管理中,需要随时调整沟通策略,了解每个干系人的偏好。

    邮件、微信、当面、电话等等…… 还需要注意是1对1还是1对多,考虑不充分,很容易得罪人!(踩了无数个坑后的惨痛教训)

    比如是任务延误了,是1V1了解情况,还是在周会上说明?

    有bug,是在大群里还是私下说呢?建议根据之前惯例的方式沟通。

    如果不清楚用什么方式,先1V1私下了解,怎么沟通比较合适。


二、事情的管理

这个要说的太多了,列几个常见的吧。事情可以包括:问题、任务、风险等等……

1. 问题

发生问题,首先了解原因,然后分析如何解决,谁来解决(通过干系人的利益,找到可以解决问题的人)一定不要把问题留在手上,要像个烫手山芋一样,赶紧扔出去。

分配了任务后,及时跟进,保证问题得以解决。

如果尝试后,依然无法解决,在项目状态报告中,列举Open Question List,反馈项目当前的问题。周会的时候,一个个过,怎么解决。


2.任务

通过项目管理软件(目前我用的是jira)把任务分配到每个人。

任务需要包含的要素有:任务名称、描述、重要程度、紧急程度、指派人,预计完成的时间。

周会可以根据项目管理软件来过。


3.风险

风险控制主要有几个过程:

  •  事项识别:必须识别影响主体目标实现的内部和外部事项,区分风险和机会。机会被反馈到管理当局的战略或目标制订过程中。

  • 风险评估:通过考虑风险的可能性和影响来对其加以分析,并以此作为决定如何进行管理的依据。风险评估应立足于固有风险和剩余风险。

  • 风险应对选择风险应对——回避、承受、降低或者分担风险——采取一系列行动以便把风险控制在主体的风险容限(risk tolerance)和风险容量以内。

  • 控制活动:制订和执行政策与程序以帮助确保风险应对得以有效实施。

  • 信息与沟通:相关的信息以确保员工履行其职责的方式和时机予以识别、获取和沟通。有效沟通的含义比较广泛,包括信息在主体中的向下、平行和向上流动。

  • 监控:对风险管理进行全面监控,必要时加以修正。监控可以通过持续的管理活动、个别评价或者两者结合来完成。


三、项目管理整体宗旨

全过程围绕PDCA进行展开:

P(Plan)  —— 计划,确定方针、目标和活动计划

D(Do)   —— 执行,实现计划中的内容

C(Check)—— 检查,总结执行计划的结果,找出问题

A(Action)—— 行动,对总结检查的结果进行处理 

可以参考我之前写过的,计划管理能力的文章:http://trista-yan.lofter.com/post/1d4fb20e_c34bac0


以上是我目前想到的…… 还有补充的后续展开讨论。希望能帮到你~



——Trista 原创


沈阳PMP培训机构
项目管理: 成功,并不是什么遥...

项目管理:

成功,并不是什么遥不可及的梦想,把小事做到极致,就有可能会胜利、成为强者,屹立于不败之地。

沈阳PMP培训:024-22722878

项目管理:

成功,并不是什么遥不可及的梦想,把小事做到极致,就有可能会胜利、成为强者,屹立于不败之地。

沈阳PMP培训:024-22722878

king

优秀产品经理指南

很多人都在向往产品经理这个角色,甚至是设计师、程序员、BD,都有做产品经理的想法。我这么多年一直是做技术,虽然头衔都是技术相关的,但基本都是从产品角度去思考技术实施。正好最近我们在考虑计划设计一个社交类产品,从我的角度,把我对产品经理这个职位的认识谈一谈。

对于很多小公司来说,“产品经理”不过是个摆设

我对“出色的产品”这么理解:1、对产品本身,有很好的市场定位、用户,以及前景;2、对产品的用户使用,有很高的用户认可度;3、对产品的市场投放,有高明的手段;

我先讲一个故事。

一个朋友,是产品经理,几个月以前,他们公司开发了一款产品,在青岛试点推广,当时和我谈论这个产品的定义以及市场、用户以及推广,感觉

很多人都在向往产品经理这个角色,甚至是设计师、程序员、BD,都有做产品经理的想法。我这么多年一直是做技术,虽然头衔都是技术相关的,但基本都是从产品角度去思考技术实施。正好最近我们在考虑计划设计一个社交类产品,从我的角度,把我对产品经理这个职位的认识谈一谈。

对于很多小公司来说,“产品经理”不过是个摆设

我对“出色的产品”这么理解:1、对产品本身,有很好的市场定位、用户,以及前景;2、对产品的用户使用,有很高的用户认可度;3、对产品的市场投放,有高明的手段;

我先讲一个故事。

一个朋友,是产品经理,几个月以前,他们公司开发了一款产品,在青岛试点推广,当时和我谈论这个产品的定义以及市场、用户以及推广,感觉他态度是很乐观的,给我的直接信号就是这应该是一个“出色的产品”。而在随后的一个月,他给我打电话,态度很悲观,说这个产品市场反应效果不好,又两个月之后,他去了北京,再给我打电话谈论到这个这个产品,说已经进入融资状态,感觉他又非常乐观,本来我以为他的产品进行了什么大改进,结果聊完才知道,产品没任何改进,只是他们的股东当中有融资的渠道。

通过他对这个产品的态度转变,可以肯定,他并没有权利对这个产品进行把控。

首先,产品在青岛市场反馈不好,那么作为产品经理有完全的责任,这是一点不能推卸的。产品经理需要对产品做出前瞻性的市场判断,市场失利,很可能产品的定位出现问题,或者是没有把握准确的推出时机。出了问题之后应该第一时间纠正产品定位而不是去融资。实际上我了解到,他们的产品定位完全是老板决定的,市场推出时机和策略也是老板决定的。

国内一些小企业,一个普遍的现象,就是责任不清晰,某个环节失败后不深刻认识、吸取教训,而是推卸责任给其他部门和其他人,慢慢就不了了之了。

其次,能有融资的渠道,只能说公司有了潜在的资金来源,这和产品本身没任何关系,产品定位没变、产品本身设计没变,产品一直实实在在的摆在那里,怎么可能有了融资渠道就意味着产品有了希望,这简直就像一群人在起哄一样。
我们聊天中,他也透露了,产品完全由他老板一个人说的算。也就是说产品经理这个职位不过是个摆设。

产品经理的角色

产品经理的角色很复杂,一方面每个公司对产品经理这个职位的定义是不同的,再有一方面也是最根本的原因,就是产品经理这个职位需要跨多个领域,一般来说,产品都涉及:产品的出现 —— 业务部分;用户直接接触的 —— 用户体验部分;产品的开发实施 —— 技术部分;

产品经理不一定是这三个领域的专家,但至少要熟知这三个领域,不然很难驾驭一个出色的产品。打造一款出色的产品并不是容易的事情,这需要产品经理有很好市场判断以及控制力和追求完美的品质。



“产品经理”是“总经理”的摇篮

我的意思是说,产品经理需要很综合的素质,基本上涵盖了整个公司部门,实际上产品经理是“操心的命”:

懂行业、懂这个行业的用户(甚至需要是这个行业的专家)。任何产品都不是凭空想出来的,都深深依托在他所在行业的发展背景中,你对这个领域认知程度,以及前瞻性,都决定了你的产品的命运。

有控制力,控制团队协作,以及与其他部门的沟通。

在有限的时间和资源前提下做产品和市场的权衡(在日企工作的朋友,都听过一个词叫“担当”)。不能推卸责任给其他部门,不要依赖其他环节的成功(这是我见过最多的现象,一旦市场投放失败,公司内部各部门无限循环推卸责任,产品经理把责任推卸给技术和设计,是最常见的)

具体来说,产品经理需要具备以下特质:

第一、产品经理要有很高的洞察力和预见性,不仅仅是一个Idea

我觉得只要是头脑正常的人,都会有各种想法和观点,这并不能说明他有多聪明和头脑灵活,退一步讲,就算这个人的想法被其他人接受,也未必说明这个想法具有市场价值,未必能从想法衍生出好的产品,因为每个人的见识、阅历有限,把想法投放给小部分人得到认可不能说明太多问题。

乔布斯的伟大,很大程度上是他的预见性,能准确的判断出 PC 未来 10 年的发展,能准确预见互联网的未来,这是产品能成功的关键。

比如对移动互联网的预测,2014 年必定是移动移动互联网爆发的一年,移动支付领域、O2O 领域、移动办公领域都会有飞速发展。移动互联网发展迅猛到让人乍舌,一年多前,一些非 IT 人士,不会弄 Android 手机还是很正常现象,现在街上的出租车司机如果不会用打车软件、不会用移动支付,已经被同行嘲笑了。如果产品经理不能预测出未来市场变化,就会错失良机,要么被同行弄死,要么被用户抛弃。

第二、产品经理要懂用户,甚至要置身于客服的位置

我这里再讲一个故事,这个故事我也讲了很多次。

我曾经带领团队开发一个商城平台,他们的用户是大街上维修手机的店铺,后期我们计划为商家提供更多服务,我就设想能否为每个维修店设计一个专门页面,通过 SEO 优化,为他们通过网上带来修手机客户。结果我们事先在他们的论坛上做了一个调查,其中有一个客户的反馈触动了我,他说”会使用互联网搜索的人,不会来修手机“,我就立即意识到我对这些维修店了解不够,实际上他们面对的客户群体往往是民工居多。

我曾经见过做车载导航统计的公司,他们在做产品的时候,要和司机师傅一同作息,就是为了跟进产品,甚至要夜间出去。

在这方面,我觉得产品经理的工作是非常辛苦的,相反那些实实在在存在的产品经理,不屑底层工作、总有高高在上优越感,每天都办公室梦想设计出伟大产品,觉得运筹帷幄中决胜千里外,控制欲是他想成为产品经理的唯一理由,这样的产品经理是没有机会做出好的产品的。

第三、没错,按钮的定义不是设计师决定的,这是产品经理的职责

国内那些专门打造用户体验的团队,一般都称为 UED,最早见于阿里巴巴,在国外公司一般都成为 UX,设计团队与产品的用户体验接触最密切,UI 和 UE 这些范畴以及他们工作中的一些专业方法,产品经理都要懂,不然是没有办法把用户需要转换成设计交互语言的。

如果你不给设计师设定一个场景,那么设计师有一百个理由做出一百个按钮的设计,从设计角度说,这些设计都是合格的。产品经理就是这个设计场景的人,就电影《Inception》中,梦境设计者(Architect)会给造梦者设定梦境,造梦者依据设计造梦,否则,造梦者真的可以随意做美梦了。



如果是一个互联网产品,一个按钮、背景颜色,实际上都是取决于产品使用者的特定的背景的,他的地域背景、互联网文化背景等等,而这些不是设计师职责范围的。

我们在两年前做了一个东南亚移动互联网的平台,当时的设计师是我的朋友,因为这是个 Startup,所以人手有限,我的朋友在做设计的同时,也是做了一部分产品经理的角色的,比如东南亚地区更喜欢色彩靓丽的风格,那么整套产品都会体现这一特点。

所以,如果用户觉得产品外观丑的要命,不要再把责任推卸给设计师。

第四、产品经理把业务实体抽象成模型转换到产品方案上是最困难的

我觉得这一个环节是最难把控的。一般来说,每个公司可能都有自己的一套方法论,更多都是根据产品的性质和公司的习惯来制定的,很难整理出来通用的方法。

比如你要设计一款 iPad 售楼展示系统给售楼处来使用,你可能要兼顾双重使用者,售楼员以及购房者,购房者更关注位置、实际样板间图片展示、价格、交通、优惠,而售楼员更在意便捷性,直接在 iPad 上记录了购房者信息、购房者对这个楼盘的满意程度,是否有必要在一段时间后电话回访。那么综合这些指标,考虑产品的设计要优先体现出来哪部分在显要位置。

第五、产品经理要在团队中打造个人魅力

你既然不是那三个领域的专家,那人家为什么要信服你?这可能就需要你有个人魅力(如果你本身够帅气到也是个优势),要凭借你的实力打造在团队中的影响,就像小说中的张无忌,如果不会九阳神功和乾坤大挪移,是很难服众的,也别指望身边有 4 个女人追随了。

第六、产品经理需要有很强的控制欲,某种程度上说,那些“强迫症”、“偏执狂”更适合做产品经理

如果你为了保住在公司的地位,不敢和你的上级顶嘴,不敢和其他部门说“NO”,不敢为了一个像素和同事争得面红耳赤,是很难打造出色的产品的。

这方面,乔布斯像外界说的那样偏执,我到很认同他的做法,就像《The lost interview》中对他的采访中他说的:伟大的人,不会在意自尊,大家都是把注意力集中到产品上,这毕竟是最有效的工作方式。

同样,在某些企业里,说话要小心、发邮件要注意措辞,不能得罪人、搞明哲保身这一套,在这样的公司,也只能老老实实混点工资了。

实际上,对于产品的把控,我更愿意由工程师来决定,Facebook 是典型的工程师驱动产品,这样好处是因为,避免了很多交接环节(如果通过产品经理把用户反馈传递给工程师,中间会损失很多信息),再有一个就是,毕竟产品的存在和技术太紧密了。如果要工程师驱动你的产品,就需要工程师具备产品经理的素质。

看完这些,你觉得自己是个好的产品经理吗?或者,你还想做产品经理吗?

蓓蓓—PM的修炼

《Scrum敏捷软件开发》精华摘录

成功的变革不是完全的自上而下或者自下而上,团队成员的参与,与管理层的支持同等重要。

ADAPT模型

在很多变革推进的模型中,我们都会看到这个经典的模型。

意识(Awareness),渴望(Desire),能力(Ability),推广(Promotion),传递(Transfer)

意识提升工具:帮助团队意识到问题的存在和变革的必要

  1. 通过沟通,说明问题的存在

  2. 使用度量数据

  3. 接触新的人和经验

  4. 运行一个试点项目

  5. 关注最重要的变革理由

渴望提升工具:帮助团队提升实施变革的渴望

  1. 告诉人们有更好的方法

  2. 创造一种紧迫感

  3. 造势:把时间精力集中于帮助热衷变革...

成功的变革不是完全的自上而下或者自下而上,团队成员的参与,与管理层的支持同等重要。

ADAPT模型

在很多变革推进的模型中,我们都会看到这个经典的模型。

意识(Awareness),渴望(Desire),能力(Ability),推广(Promotion),传递(Transfer)

意识提升工具:帮助团队意识到问题的存在和变革的必要

  1. 通过沟通,说明问题的存在

  2. 使用度量数据

  3. 接触新的人和经验

  4. 运行一个试点项目

  5. 关注最重要的变革理由

渴望提升工具:帮助团队提升实施变革的渴望

  1. 告诉人们有更好的方法

  2. 创造一种紧迫感

  3. 造势:把时间精力集中于帮助热衷变革的人,营造一个不可阻挡的势头

  4. 让团队“试驾” :与其做抽象的争论,不如快速体验

  5. 统一激励机制(至少消除不利因素):比如以团队为导向

  6. 聚焦恐惧的消除:与因为恐惧而放弃变革的人沟通,找出为什么他们会有毫无根据的恐惧

  7. 帮助人们学会放手

  8. 不要诋毁过去:过多诋毁过去的做事方式,会加大转型阻力

  9. 努力让员工参与:尽量多招募同盟者,特别是舆论领袖

能力提升工具:学习新的技能,学会用团队的方式思考和工作,学会在短时间内交付可工作的软件

  1. 提供辅导和培训

  2. 赋予个体责任

  3. 共享信息:传播信息,互相取经

  4. 设置合理的目标

  5. 立即行动

推广提升工具:在直接参与Scrum实施的群体之外创造敏捷的意识和兴趣,对创造新一轮的改善提供一个跳跃性的开始

  1. 讲述成功故事:在企业内广泛宣传早期实施者的成功故事和实际应用,口耳相传的病毒营销是最好的工具

  2. 开一个“敏捷野生动物园”:鼓励自主参与一个敏捷团队,获得几周的真实体验

  3. 吸引注意力和兴趣:举办开放日等专题活动,制作主题海报等宣传展示进展和成就

传递提升工具:让开发组织之外的其他群体了解到如何从变革中受益,确保整个转型不会因为“企业重力”而被拉回远点

  1. 与其他部门沟通:包括人力资源、后勤、市场营销、财务、销售、IT、运营等


试点项目-设定和管理期望

设定和管理期望,降低不切实际的期望,很可能是你在试点项目早期最重要的事情之一。我们可以从4个方面来管理期望:

  1. 关于进度的期望:实施Scrum后团队是否能够取得更好的生产效率,很大程度上取决于该团队之前进展如何。一个已经进展顺利的团队开始可能会慢一点,真正在苦苦挣扎的团队反而可能开始时快一点。大部分团队都会过高估计他们在第一个Sprint能取得的成绩。大部分团队开始做更有价值的工作,很多传统项目会停止尝试去找“最好的”或“完整的”解决方案,而是去找一个足够好的解决方案,尝试它,学习并根据需要作出改变。

  2. 关于可预测性的期望:Scrum团队使用速率来衡量项目进展,速率在刚开始几个Sprint中波动可能会特别大,开始的步调可能不如以前那样可预测,与干系人进行很好的沟通时很重要的。在团队建立一些历史数据后,大部分团队的速率在第3或4个Sprint会稳定下来,形成较为稳定的预期。

  3. 关于对scrum态度的期望:常见的反对和抱怨有,每日站会浪费时间;既然产品不是如此频繁发布,就不该浪费时间每个sprint结束前都经过精心测试等,预期到这一点并提前加以讨论是最好的方法。

  4. 关于参与程度的期望:习惯传统开发方式的干系人会把他们的角色比作把车直接丢给别人保养一样,告诉别人需要做什么,然后在某个约定的时间回来看到工作已经完成。干系人(特别是承担产品负责人角色的干系人)需要理解,这种做法并不正确,在sprint及评审期间,务必需要得到干系人的反馈与期望。

king

网站数据分析的基本流程

网站数据分析没有规范的分析流程容易使最后的结果逻辑混乱或者偏离原来的主题,所以一套规范的流程能够使网站分析更加清晰和有效。

网站数据分析没有规范的分析流程容易使最后的结果逻辑混乱或者偏离原来的主题,所以一套规范的流程能够使网站分析更加清晰和有效。

网站分析其实就是一个发现问题、分析问题的解决问题的过程。问题的发现可以来源于多方面:网站运营中遇到的问题、用户的反馈和抱怨、日常统计数据的表现异常等;分析问题的过程就是根据遇到的问题运用合理的方法对其进行解释,这也是本站重点探讨的方向;而最后的解决问题则是最为关键的一点,也是目前最被忽视的一点,目前的网站分析工作往往在找到问题后无法落实到寻求最优的解决方...

网站数据分析没有规范的分析流程容易使最后的结果逻辑混乱或者偏离原来的主题,所以一套规范的流程能够使网站分析更加清晰和有效。

网站数据分析没有规范的分析流程容易使最后的结果逻辑混乱或者偏离原来的主题,所以一套规范的流程能够使网站分析更加清晰和有效。

网站分析其实就是一个发现问题、分析问题的解决问题的过程。问题的发现可以来源于多方面:网站运营中遇到的问题、用户的反馈和抱怨、日常统计数据的表现异常等;分析问题的过程就是根据遇到的问题运用合理的方法对其进行解释,这也是本站重点探讨的方向;而最后的解决问题则是最为关键的一点,也是目前最被忽视的一点,目前的网站分析工作往往在找到问题后无法落实到寻求最优的解决方案并执行和解决问题这一点上,即使采取了相应的措施也无法进行持续的反馈,并从根本真正地解决问题,很多只是针对一时的举措,而解决问题的过程恰好是最能体现公司执行力的时候,如果没有最终解决问题或者实现优化,那么网站分析就没有丝毫的价值。

随着互联网的不断发展成熟,网站的发展趋势将更加规范化、精细化,更加注重用户体验,今后的网站建设很重要的一点就是网站的质量管理,所以这里就借用质量管理里面的六西格玛中的DMAIC循环来梳理一下网站数据分析的流程,DMAIC是PDCA质量环的改进,这里将其核心设置为“用户体验”,因为不同网站会有不同的目标,而提高“用户体验”可以说是所有网站的共同目标。


正如上图所示,基于DMAIC循环,网站数据分析的流程也可以用这5步来实现:

定义(Define)

原意是识别和确定用户需求,定义任务的目标和意义。对于网站数据分析来说,可以表述为确定这次分析所针对的问题是什么,分析最终需要达到何种目的,对网站有何实际的意义,同时需要确定分析的范围,及规划本次分析工作的进度和质量控制。

测量(Measure)

原意是收集数据,量化分析。对于网站数据分析来说,同样也是一个收集和获取数据的过程,尽量获得完整、真实、准确的数据,做好数据的预处理工作,便于分析工作的开展。

分析(Analyze)

原意是使用数据统计和分析的方法找到问题的本质。分析不只是对数据的简单统计描述,其结果不应该是一张报表和趋势图这么简单,分析的本质应该是从表面的数据中找到问题的本质,最后需要第一步针对的问题进行归纳和总结。同时需要注意的是分析要紧跟“定义”,不能偏离问题的范围和本质。

改进(Improve)

原意是找到最优的解决方案,是问题得到解决或者使问题的负面影响降到最低。个人认为这一步是最为关键的一步,也是目前很多网站分析工作中较为忽视的一步,很多网站分析只是呈现结果,缺少解决问题的方案,这就相当于找到了管道的漏水点却任由其漏水而不作处理,任何不付诸实践的分析结果都是废纸,毫无意义。同时这一步也是最考验网站执行力的一个步骤。

控制(Control)

原意是监控改进的结果,使相同问题不再重现。这一步无疑是目前最被忽略的一步,很多改进方案实施之后根本不会再去关注反馈情况,而有些改进方案治标不治本,就像网站的访问量无法通过一两次的推广活动通过本质上的提升,关键还在于网站本身的质量,推广活动可能让数据在短期内获得提升,但想要保持长期地增长还是需要不断地优化和改进。所以“控制”要的是持续的反馈和监控,并不断寻找能从最根本上解决问题的最优方案。

所以,网站建设是一个循序渐进的过程,很多网站数据分析也是长期的,不断监视、跟踪并改进,而DMAIC循环也正体现了这个概念,通过不断地网站分析来提高网站质量,提高用户体验。

作者: joegh (《网站分析实战》作者)

技术控是百度新闻与钛媒体合作,专门为技术爱好者打造的栏目

PM小舍

产品经理沟通基础方法论

    沟通是产品经理必备的一门技能,网上谈产品经理沟通之事的文章也不少,不过较少有文章将沟通经验整理为结构化的方法论。我做PM时间不长,不过也积累了一定沟通经验,现在尝试总结出一些可追循的规律、流程和方法,来把沟通这个很虚的概念实体化一些。

    顺着沟通的时间流程思考,我将沟通分为沟通前的准备,和沟通中的操作两部分。


    沟通开始前请先做一些准备,想到了什么就冲到别人面前,这样的沟通往往缺乏信息,一无所获。...




    沟通是产品经理必备的一门技能,网上谈产品经理沟通之事的文章也不少,不过较少有文章将沟通经验整理为结构化的方法论。我做PM时间不长,不过也积累了一定沟通经验,现在尝试总结出一些可追循的规律、流程和方法,来把沟通这个很虚的概念实体化一些。

    顺着沟通的时间流程思考,我将沟通分为沟通前的准备,和沟通中的操作两部分。


    沟通开始前请先做一些准备,想到了什么就冲到别人面前,这样的沟通往往缺乏信息,一无所获。

 

    准备一、明确沟通目的

    首先,你需要明确,沟通的意义在于“我希望通过这次对话达成某个目的”,而不是“我希望找人聊一聊”或“我希望搞懂某个问题”。这个目的是具体清晰的,比如“说服设计师同意提供一套新的设计方案”。在之后的沟通中,你的每一句话,都服务于这个目标的达成。具体在后文中详述。

 

    准备二、设计沟通主线,构架沟通引导

    通常,我们在沟通开始前会想想待会要说些什么,而这些想法常常是杂乱无章的。有效的准备方式,是设计一条沟通主线,构架沟通引导。沟通主线就像火车的铁轨,火车不能乱开,而是需要设计好里程碑和节点顺序,然后逐级推进,终点站是你的沟通目标。实例,上文“说服设计师同意提供一套新的设计方案”,我可能会预设的几个节点有:

    一,请设计师说明目前方案的视觉设计思路,并给予设计角度的肯定;

    二,根据目前设计思路,分析在产品端所能达到的转化效果;

    三,表述我期望的产品转化需求;

    四,指出当前设计思路与产品需求无法契合的部分,来说服设计师进行调整。

    在沟通中,我沿着这条主线,分为四段引导沟通的走向,这样,我避免了与设计师直接讨论好不好看、设计品味之类的扯皮问题,而把问题转化到产品需求上,设计师也比较能够接受。没有主线,沟通方向容易失控,有可能会走向“这个button为什么不用圆角”、“红色太鲜艳”乃至“SB你懂设计吗”之类的心理对骂。

 

    准备三:永远给出多种方案,包括可行的和理想化的,然后证明其中一种最好

    举个例子,当你和朋友说“我们去吃杂酱面吧”时,朋友的感觉可能是“不要,我不喜欢吃杂酱面”;但是如果你和朋友说“我们是去公司食堂还是去吃杂酱面?”,朋友一想“靠,我还是去吃杂酱面吧”。两种沟通方式,对方案的接受度截然不同。同样,当你说“我们要使用A方案”时,也要带着这种语境去沟通,为你的方案预设好一个可供对比的planB,比在没有对比的情况下,拼命为唯一方案挡住所有子弹,反驳所有观点要容易的多;很多时候我们选择一个方案不是因为这个方案完美无瑕,而是因为没有其他更好的方案可选,很多人往往是站在方案本身的角度去挑刺的,而你也很容易陷入到“为辩而辩”的漩涡中,如果你能把整个大环境的概念传达给它,或许可以避免很多无谓的争论。

 

    沟通开始后,可以注意的地方:

 

    一、聚焦沟通目的,紧追沟通主线

    在上文中提到明确沟通目的的重要性,实际上,大多数人的问题往往不是没有目的,而是在沟通开始后没有专注于目的,以及里程碑目的,而使沟通走向失控。实例,沟通开始后,如果设计师提到“这个修改起来很麻烦,很重要吗”而你以“我这个项目优先级很高”回应,之后陷入扯皮,那时候你已经早忘了你的目的和主线;专注的做法是切莫急躁,立即把走偏的对话拉回到主线上来,回应“没事,我只是想更好的理解下你的设计思路”,再按照主线往下推进。你的主线就是你的战场,全程每一句话都在推进你的战场,才是沟通效率的体现。

 

    二、不要反驳,而是寻找共同目标

    玩过辩论的人应该比较理解,高级的辩论不是驳倒对方,而是一直同意对方的观点,然后证明对方的观点就是我方的期望。同样,工作中的沟通,也不要试图通过证明对方是错的来证明自己是对的,因为没有人喜欢被打败,而更喜欢获得认同。所以,聪明的方法是把分歧转化为共同目标——从最大目标开始逐级分解,到产生分歧的前一级转向。

    具体如何操作?

    举例,设计师坚持一个button用灰色,询问原因后设计师回答“这里颜色太多,需要保持一致性”,那么你们可能能达成共识的最小上级问题是“这个区域的需要保持视觉一致性”;接着我会从这次设计的更高目标开始问起,如“这次设计你也希望能增强购买的转化率吗”→“这个区块你觉得是核心区域吗”→“这里的视觉一致性的确很重要”→“你的方案可以达到目标,不过我有另一个建议,这里做成半透明的,咱尝试效果会不会更好?”注意这个沟通过程,一是不停的给予对方肯定和认同,二是完全没有反驳对方任何观点,这样给对方的感觉是“你有一个与他一致的目标想尝试”,比“这里用红色不好看,请你改成半透明”带来的挫败感要好的多。

 

    三、分析对方的真实意愿

    任何沟通里,大部分人都有一个误区:认为别人说的话的语义代表了他们的想法。实际上,沟通的字面表述,和沟通者的真实想法经常是两回事。我指的不是那种故意为之的虚伪,而是人类由于内心价值观、道德观的束缚,很多人都处在不自知的潜意识自欺状态,导致他们自然而然的把潜意识思想包装后再表达出来。晦涩难懂的话,说点大白话的,技术和你说“这个我觉得没必要做,有人用吗”时,他真正想说的可能是“这个功能实现性价比太低”、“这个太难,我不想做”、“我TM想下班了,今晚还要开黑”;如果你读不到这些潜在语言,而和他争论“这个绝对有必要,…”那就是白费功夫。至于潜在意愿的挖掘,不说太多人性、心理学方面的理论,从小到大,生活中你一定见过很多撒谎、逃避的案例,以这些为基础经验,认真观察对方的言谈和表情,不纠结于字面,找出对方真正想说的话,再给予对方真正需求的反馈,才是突破沟通障碍的关键。

 

    以上是我做PM的一点沟通经验。当然,沟通不是PM的职业专向能力,而是人类的一门大学问,拓展开来还有太多东西需要学,例如一些我感兴趣的关键词:影响力、个人魅力、情感绑架、姿态、气场等,鉴于篇幅和见识就不班门弄斧了,学习,进步,共勉。


king

产品经理必读的九步法

本文描述的产品设计“九步法”,主要框架来源于几个从无到有设计了亿级用户产品的闪闪发光的人,我曾经在一个10亿级PV的产品中做过长时间的实践和不断修订,一转眼,已落网16年,有幸和多个中国公认最顶级的PM共事多年,现在在自己的理解下进行阐述。“九步法”是为泛互联网产品而写的,适用于大型产品,也适用于产品中的新功能。使用方法是PM在产品设计时,对以下九个问题自己逐条进行书面回答,并和团队逐条分析和讨论。


第一步: 足用 的哪一个核心需求?

产品设计的关键在于搞清楚产品的核心价值是哪一个,满足用户什么核心需求。实践中,70%的PM经常忘记了这一点,因为“满足用户需求”几乎成了每一个PM都...

本文描述的产品设计“九步法”,主要框架来源于几个从无到有设计了亿级用户产品的闪闪发光的人,我曾经在一个10亿级PV的产品中做过长时间的实践和不断修订,一转眼,已落网16年,有幸和多个中国公认最顶级的PM共事多年,现在在自己的理解下进行阐述。“九步法”是为泛互联网产品而写的,适用于大型产品,也适用于产品中的新功能。使用方法是PM在产品设计时,对以下九个问题自己逐条进行书面回答,并和团队逐条分析和讨论。

 

第一步:足用的哪一个核心需求?

产品设计的关键在于搞清楚产品的核心价值是哪一个,满足用户什么核心需求。实践中,70%的PM经常忘记了这一点,因为“满足用户需求”几乎成了每一个PM都能张口就来的口诀,所以就常常忘记了。我们经常听到的“微博要加强SNS属性”、“微信要打通O2O”、“社区信息要流动得更快”,就是最典型的忘记了用户需求的例子。所有这些提法都是想当然,没有站在用户角度的思考,没有搞清楚用户需求,就一定会注定失败。

实际上,即使PM使用了这一条,也常常于事无补。因为仔细分析“满足用户需求”,会发现其实是无字天书。第一,“用户”是一个虚拟群体概念,PM找不到一个具体的人代表用户;第二,“用户”实际上根本不知道自己需要什么。所以实践中用户总是被三种人代表:PM自己,假想的典型用户,PM的行政领导。而今天iphone,微博,微信不离手的人几年前又哪知道自己需要这个。

用户需求永远是被天才捕捉到和创造出来的,就像后年时尚界流行什么,那些奢侈品消费者、时尚评论家是不知道的,只有天才的设计师才能引领未来。IT历史上那些big thing,要么是被天才创造出来的,要么是被超级幸运小子撞上的。网游“巨人”曾经很用心的去实践“满足用户需求”这个真理,非常认真的调研用户,用户要什么给什么,结果到最后发现“用户”根本不存在,那些标签为“用户”的人,其实内心不知道自己需要什么,于是产品彻底失败了。

很幸运抑或是很不幸,我们大部分人,不需要像乔帮主那样天降大任去发明一个iphone,也没机会初出茅庐就和金正恩一样创造并引领时代潮流。所以,假如你只是去做一个即有产品的新功能,或者想设计一个新玩意,那有两个比参悟“用户需求”更切实的做法:

1、 疯狂的热爱你的产品

2、 尝试去解决你遇到的最大痛点

一个PM最基本的特质就是要热爱自己的产品。如果你不热爱自己的产品,此处的建议是立即换到你喜欢的产品门下,那怕少拿一半薪水。为自己热爱的产品燃烧,那人生会变得多么有趣啊。10年前,我的好友为求得这样一份工作,不计较地域(无论天南海北,刀山火海),不计较职位(无论高低贵贱一线二线),不计较薪水(可维持个人当地衣食住行即是底线),结果做出了世界最伟大的中文产品。三年前,我有一位下属,一个普普通通的小男孩,在大公司被职称评定为级别最低的PM,但却胸怀同样的豪情,以一颗年青的心,做出了几乎和微信匹敌的,影响一时的产品。

按照此“九步法”的第一步,如果你是微博的深度用户,那请思考一下新浪微博最近的三栏式结构改版,满足了用户的什么核心需求?

作为新浪微博的深度用户,我却经常在电脑前用手机上微博,因为PC没有给我更好的浏览体验。但不幸的是,“PC用户浏览体验差”这个核心需求不但没有得到解决,反而在三栏式改版后更差了。不从用户需求出发,就会导致南辕北辙,请每一个PM在你改版时,首先考虑你解决了一个用户的什么核心需求,你可能改变世界,也可能谋杀千万用户的时间。

第一步的要点是“一个核心需求”,特别注意是“一个”。对于微博这样的产品,让浏览体验更好,就是核心需求。系统如何加载更快,用户如何生产优质信息,如何摒除spam,如何提升视觉体验都是亟待解决的问题。PM永远不要妄想一下子去发明,颠覆现有的产品,或者增加一些自己觉得挺时髦的新功能,只有抓住“最核心需求”一点一滴的去改进,一个百分点一个百分点去提高,才能从量变引发质变。

 

第二步:与同类产品相比你的独特性什么?

如果步骤一解决的是产品“有什么用”的问题,那步骤二解决的就是“别人凭什么用”。这个问题看起来简单,其实相比70%的PM经常忘记了“用户需求”,大型公司甚至有高达90%的PM不会考虑“别人凭什么用我”。

为什么这么多PM不会考虑“别人凭什么用我”?大型公司最大的优势就是有钱,有人,有技术,有用户,能够把一个市场上证明了有需求的产品迅速推到用户面前,同时还带给用户不算差的体验。正因为大公司的产品与生俱来有这样的优势,成为了PM习以为常的制胜法宝,所以他们不需要考虑产品定位,所以最大的优势往往最后变成了劣势。

2011年底的一个晚上,我在广东佛山,饭后去捏脚。我照例问技师小姑娘平常上什么网站,生活中有什么爱好,最近打算干嘛。年轻的姑娘回答我说最近的梦想就是买一部小米手机。当时我吃惊得手中的茶杯都差点掉在地上。2011年底,我也只是在网上看到小米的新闻,市场上连一部真机都没有。但在千里之外的广东,一个小城路边的洗脚妹都把小米手机当作人生梦想了。我连忙问她为什么,她说“小米手机一千多块钱,但用起来和苹果一样,多划算呀”。

这就是定位,这就是产品的独特性。

中国互联网很常见的例子:从新闻、门户、电商、视频网站,到现在的团购、安全软件、浏览器、微博、手机,99%都是无差异化的竞争,很少有人考虑“与同类产品相比你的独特性什么”。显而易见,那些后发而胜出者,都对这个问题有深刻的理解和超凡的控制技巧。

按照此“九步法”的第二步,如果你是微信的深度用户,请你考虑“朋友圈”这个产品的 “独特性”是什么。

当微信在设计“朋友圈”这个功能时,一定考虑了他和微博,Qzone,校内相比较的独特性。在SNS产品同质化这么严重的情况下,微信的一个二级功能如何胜出,他的独特性在哪,这就是PM团队要解决的首要的问题。

我个人觉得这个独特性就是“私密”。

其实社交的本质就是“隐私的分享”,人与人相识,到朋友,密友,甚至情侣,最后夫妻,关系深化的过程,也就是隐私一步步不断彼此分享的过程。微博为什么做不了SNS,因为微博这类的广播平台,天生不具有私密性的特质。而微信朋友圈在私密性的定位上,用一种简单的手段,解决了Facebook复杂的隐私设置问题。无论是微信PM天才的洞察到了这一点,还是碰运气碰上,不得不让人佩服。如果微信朋友圈能在“隐私的分享”上做得更好,那这个产品前途无量,未来可以有机会和Facebook对决。

 

第三步:分解用。根据品的核心价,将用分解成不同角色。

步骤一解决的是 “有什么用”,步骤二解决的是“别人凭什么用”,步骤三到步骤七解决的是“如何更好用”。如何更好用的关键就是变成用户,站在用户的角度进行思考。

也许天才能够洞察到用户需求,但天才在洞察用户需求上也有一个成长过程,我们看到乔帮主也是从一个个失败里一下下爬出来的。对用户需求的把握就好像佛陀的证悟:削一个苹果,削到最后,发现是空,于是悟道了。用户需求原来是一本无字天书,要领悟,需要有一个削苹果的过程。

分解用户,变成用户的过程就是一个削苹果的过程,一个PM的必经修炼。不同产品,不同维度,有不同的分解方法。初期不用太复杂,但也决不能脑子里只有一种用户,那就不是削苹果,而是削石头了。PM至少要按产品的核心价值,用最粗的线条把用户进行分类。

如:

UGC产品:看的用户,写的用户;

论坛:浏览用户,发贴用户,版主;

B2C:浏览用户,交易用户;

电子商务:卖家,买家;

新产品:种子用户,成长用户;

老产品:初期用户,成长用户,衰退用户,流失用户;

等等。这个过程的核心就是抓住那些最重要的角色。

需要特别指出的是,角色的划分,和产品的运营程度有关,运营成熟的产品,进入精细化阶段,就需要更细的分解角色。

简单用微博举例:如按使用方式、生命周期把角色分为X轴Y轴两维,那微博的使用方式可以是浏览信息用户,发布信息用户,还可以分得更细,比如发布信息用户还可以分为个人、认证个人、企业、媒体、大V等,微博生命周期可列出种子用户,初期用户,成长用户,衰退用户,流失用户等。

当我们把X轴Y轴一相交,就得到了很多的角色,上面列举的微博角色,就能得到30种,当然,其中有一些角色是无意义的。很少有产品和有PM需要去分解几十种角色,大部分情况下,我们把最重要的几种角色拿出来就可以了。

 

第四步:变成用户。每类角色回答以下两个问题:

问题一:该角色为什么会使用这个产品?

问题二:该角色怎样知晓和到达这个产品?

在分解完角色后,PM就需要把自己代入角色了,进行cosplay,充满想象力的角色扮演游戏。

回答“该角色为什么用这个产品”时,我们会发现用户的核心需求开始分解。用户的核心需求就是一级需求,一个产品只会有一个一级需求,此外其它都是二级需求,二级之下还有三级四级。比如微博用户看微博,就是一级需求(浏览),发微博就是二级需求(表达),发微博插入各种功能就是三级需求。

当我们分析微博用户的核心需求“浏览自己关注的信息”时,第一个被分解出来的角色是“浏览用户”,回答“浏览用户为什么会使用这个产品”时,我们发现,这是因为有“发布信息用户”,那用户为什么会布信息呢?

当对微博角色和该角色为什么使用这个产品进行层层分解后,我们会发现,微博用户是有多层需求的:

1、 获取信息的需求

2、 表达的需求

3、 社交的需求

4、 自我实现的需求

这些需求呈金字塔型,用户数量逐层递减,最顶端的是“自我实现的需求”,这些角色就是微博的大V用户。他们在这个平台上的目的是实现自我价值,于是他们制造了最优质的信息,决定了整个微博的生态环境,这就是新浪微博和其它产品所不同的独特性。最底端的是“获取信息需求”,这些角色就是微博的全体用户,他们真正代表了微博的全部,包括商业化的梦想与未来。

要回答的问题二“该角色怎样知晓和到达这个产品”是一个产品运营方面的问题。好的产品离不开运营,很多产品甚至以运营取胜。新浪微博在初期,为了请一个潜在的大V,可以派专人去香港两周,就为了送给这个名人一只iphone,教会他用手机上微博。能够准确的洞察自己最核心的用户如何知晓和到达这个产品,并实施高执行力的操作,这就是新浪微博成功的关键。

新浪微博的例子告诉我们,在差异化竞争中,你只要在产品或者运营上,拥有一个与众不同的特点,并能把这个特点发挥到极致,让竞争对手追而不能及,那也能在市场上成功。

 

第五步:确定角色成就。确定品如何足不同角色的成就感。

每一类角色如何在使用产品过程中不断成长,不断得到满足,这就是产品持续成长的关键。关于这一点,90%的PM都陷入了一个误区。

1996年我沉迷BBS时,网上很流行一首改编的歌词《同网的你》,我记得有一句歌词是这样的:“那时候天总是很短,一晃就到了十点半,你只考虑何时才能升级,哪怕视力再降个0.1”。我曾经为了在一个bbs上挂到经验值全站第一,而荒废了四年大学时光,所以虚拟成就害人呀。

一晃16年过去,简单直接的积分激励被国内的PM们熟练掌握,是屡试不爽,发扬光大的一个手段。其中的创新层出不穷,简直可以写一部中国互联网创新史。

经典如的QQ的升级制度、点亮各种图标,Discuz的各种头衔、积分体系,网游的各种称号、徽章、道具,微博的粉丝,工具类产品的积分、扩容、世界排名等等。目前没有用户积分类激励的产品,反而成了另类,比如微信。

正是这种特别适合东方人心理特点的短平快手段,让很多PM忽视了产品的核心。90%PM陷入的误区就是产品的过度游戏化。

一个产品最重要成就是:用户核心需求被满足时获得的成就感,当无关的激励干扰到他的核心需求时,他真正的成就感降低了。

免费网游、淘宝、搜索引擎因为核心用户的成就直接与最敏感的指标收入强相关,所以是世界上把核心用户成就做得最优秀的产品。百度最近的搜索提示suggestion上了一个新功能,当用户第二次搜索同一关键词时,这个词的搜索提示会变蓝,这就是搜索用户所获得的成就:查询信息更方便,搜索引擎更懂你。相反,如果搜索引擎推出一个功能,用户搜索时,弹出一个浮层:恭喜你,你的经验值又上升了10点,那最直接的结果就是收入马上下降,因为这干扰了用户的核心需求。

商业模式不清晰的产品没有敏感的量化指标,PM又忽略了用户的核心需求,过度游戏化时,次要的角色的成就立即喧宾夺主了,比如新浪微博对浏览用户的一些干扰式激励。所以,这一步的关键是关注你的核心用户的核心需求,让核心用户在核心需求上获得核心成就。

在角色分解上,新浪微博的二级需求角色,即“发布信息用户”的角色成就一些点是做得非常优异的,特别是评论模式和粉丝概念的创新,远远胜过Twitter,从产品上奠定了后发制胜的根基。对于微博这种可以分解出几十种角色的产品而言,在梳理各种角色成就时,把握整体与局部之间的关系,对PM是一个巨大的挑战。

 

第六步:确定用需求程中的关点。

将每类角色从“获知产品,使用产品,需求得到满足,离开,回来”的整个过程进行分解,描绘出关键步骤和关键页面。

这一步,就是考验PM的执行功力的关键步骤,PM能不能把这一步做好,和天份无关,只和是否努力、是否用心有关。

对整个用户需求满足的过程控制得最好的是电商企业。原因很简单,因为每一步都是钱。优秀的电商企业,如天猫,淘宝,京东,PM一定会对用户从哪来的,怎么用的,如何走了,如何再回来,有清晰的认识的明确的量化指标。因为PM很明白,一个关键点搞好了,收入就上升,一个关键点没搞好,收入就下降,这直接和奖金有关,可是乱来不得的。

这就是有清晰商业模式的产品的优势,商业价值的高低,和用户需求成正比。搜索和电子商务都有最好的商业模式,就是在满足用户的一级需求时,把商业价值实现了。商业价值和用户需求都能找到“收入”这一敏感的衡量指标。你的用户体验做得好,收入就上升,用户体验做得差,收入就下降。世界上没有比这更有效的提升用户体验的手段了。

这一步是痛苦的cosplay。我们假设一个最简单的B2C新产品,至少有四种最简单的角色:

1、 浏览用户

2、 交易用户

3、 种子用户

4、 初期用户

对这最简单的四种角色描绘“获知产品,使用产品,需求得到满足,离开,回来”的过程,可能就有20个关键点,十多个关键页面。所以戏演多了就入戏了,按照佛陀的哲学,产品经理削苹果,削到最后发现苹果没了,自己就变成用户了。

 

第七步:提升关点的化率。

当PM把约20个关键点找到,那每一个关键点,关键页面如何提升转化率,就是阶段性的目标。我任贴吧总经理时,为了了解新用户是怎么进来的,自己线上注册了80多个帐号,看注册流程有什么可以提升的点。所以,一个普通的PM,至少在每一个关键点上,都要尝试数十遍,这样才可能找到感觉,找到提升转化率的有效方式。

很多人都听过“多点击一次用户损失一半”原则,虽然不同的产品实际损失率不一样,但基本都是一个可观的数字。在“普通角色使用产品”这一天底下所有形式的产品最核心的关键点上,多少年来,门户、搜索、IM都用了至少两个页面:门户的首页和内容页,搜索的首页和结果页,IM的好友列表页和对话框。电子商务的用户需求链比较长,用的页面更多。但Facebook 、Twitter只用一个页面就满足了用户核心需求,把转化率提升到了最大。李兴平发明的hao123,比Facebook、Twitter早七八年实践了这个交互革命。

必需提一下的是,Facebook、Twitter之后,交互史上影响最大的创新是搜索开放平台(阿拉丁),在搜索结果当前页就满足了用户需求,免去了用户跳转到新网站,再次查询甄别的时间。这是中国最成功最富有的PM的发明。

所以,永远不要以为转化率已经做到最高了,也许换一种方式,你就能带来一场革命。百度的阿拉丁,Twitter的左右分栏式改版,都是针对用户核心需求厚积薄发的创新。在这个移动时代,更多的前人没有涉及的领域等待PM去开拓。

 

第八步:形成闭环让产品能自我成

上一步PM的阶段性目标已完成了,第八步要静下心来考虑的是闭环问题。闭环就是产品自我成长的循环。

淘宝的信用评价体系,就是一个闭环。买家购买产品,商户提供好的服务获得好评,得到好评就会得到更多新买家,新买家又购买产品,商户又有机会得到更多好评,形成一个循环。PM的工作就是发现,设计,确保这个闭环的顺利运转。比如差评师,就是这个闭环的杀手。

UGC产品也常常是一个闭环。用户发布优质信息,优质信息吸引新用户,新用户也发布优质信息,更多新用户被吸引来形成一个闭环。垃圾信息发布者、Spam、低质信息等,都是这个闭环的杀手。对于很多UGC产品,PM花费心血使它运转正常,但信息质量的降低,却会像病毒一样,蔓延到整个循环中,让产品枯萎,最后死亡。

更多的产品就不是闭环,比如支付宝、词典APP,IE浏览器、Flash小游戏、微软办公软件等等。用户量的增加,并没有带来产品的自我成长。不同的是,现在很多工具类产品也找到了自己的环,如云输入法,用户越多,输入法越好用,输入法越好用,用户越多,形成一个循环。

移动、云、大数据时代,将为更多产品形成闭环提供可能。只有形成闭环,这个产品才能自我成长,进化成一个有机体。很多小闭环,最后会组成一个大闭环,很多个大闭环最后有可能进化成一个生态系统,比如阿里、百度、腾讯,其实都是一个生态系统。多个生态系统有可能进化成一个超级生态系统,比如阿里系正在干的事。当然,生态系统这个词是战略家或评论家喜欢的用词,产品经理只需要关心那些小闭环,拔动、调理那些击中你痛点的环。

2012即使人类末日来临,从物理学的概念来看,与一块冰融化成水,并没有什么本质的区别,都只是一种形态的环,又组成了另一种形态的环。PM要做的,就是成为拔动琴弦的歌者,无数闭环的振动,整个宇宙都会为你奏响乐章。

 

第九步:大干快上,迅速迭代。

Google、百度面试PM时,都不约而同出过一道相同的试题:产品到了预定发布日期,却发现还有功能不完善,你是选择上线呢,还是继续打磨,直到令人满意再上线?

曾经有大BOSS答错了这道试题,但在数百道题目中,只错了这一道,于是还是做了谷歌、百度最大的技术BOSS。你的答案呢?PM脑子里总会想到太多东西,但用户想得很少,甚至不想,全世界最牛的PM Facebook CEO扎克伯格干脆就直接把用户叫做“白痴”,中国有个天才级的PM把变成用户形容为变成白痴,他希望PM和白痴之间的距离只有0.01公分。

如果你有幸聆听过中国互联网最成功和最富有的两个PM的教诲,你会注意到,这两个千里之外的人都会强调两个相同的原则,其中一个就是:大干快上,迅速迭代。也许,这就是成为首富的秘密,因为他们深知机会错过了,就没有了。如果你两个原则都注意到了,而且又在30岁以下,那很有机会像他们一样,在改变世界的同时,顺带手挣个盆满钵满。

但现在移动领域迅速迭代有个误区,很多无关要紧的APP升级,频繁的提示用户安装新版本,这绝不是迅速迭代。迅速迭代只是一个手段,目的是更好的满足用户体验,所以产品升级要给用户一个超出预期的体验,要让用户盼望和等待你的升级。没事发布一个小改动,强迫用户升级,浪费公司带宽,浪费用户流量,这样的PM应该自己为手机费买单。APP的迅速迭代请向微信,向新浪微博学习,他们是生于移动时代的娇子。

没有什么是恒定不变的,世界变化的速度又太快,要削多少个苹果才能证悟用户需求?所以我说的总是错的。

 

结语

产品设计“九步法”

第一步:产品满足用户的哪一个核心需求?

第二步:与同类产品相比你的独特性什么?

第三步:分解用户。根据产品的核心价值,将用户分解成不同角色。

第四步:变成用户。每类角色回答以下两个问题:

问题一:该角色为什么会使用这个产品?

问题二:该角色怎样知晓和到达这个产品?

第五步:确定角色成就。确定产品如何满足不同角色的成就感。

第六步:确定用户需求满足过程中的关键点。

第七步:提升关键点的转化率。

第八步:形成闭环。让产品能够自我成长。

第九步:大干快上,迅速迭代。

以上就是产品经理必读的产品设计九步法,我已帮你又单独整理出来,现在请你打开电脑的记事本,针对你正在设计的产品,逐条回答以上九个问题,之后再与你的团队逐条分析讨论。如果你做了,你会相信,你想的都是错的,因为一个月后,你还需要一模一样再来一遍。这个过程是痛苦而寂寞的,改变世界的人,是世界上最孤独的人。

但我相信,只要你这样做,你的手就会把这个世界变得更美好起来。请你顺手将这篇文章分享给其它梦想改变世界的产品经理,只有更多的闭环才能承担无数的闭环。


沈阳PMP培训机构
国际PMP认证,培养高级项目管...

国际PMP认证,培养高级项目管理师,恭候您的光临!

咨询电话:024-22722878

国际PMP认证,培养高级项目管理师,恭候您的光临!

咨询电话:024-22722878

king

提高产品发布成功率的思维方式

思维1:具备进行致命缺陷搜查的本能动力。

思维2:启动组织内部竞争。

思维3:充分理解“以模仿而实现独特性”的价值。

思维4:永远铭记对产品进行情感化处理的重要必。

思维5:拥有独特的组织方程式。

思维6:在信心与畏惧之间保持精妙的平衡。

思维7:在现实世界中,成功的发布不会是一天、甚至一个月的工夫。修订--不断重复的修订。、

若想检验你的组织是否已准备好进行需求创造的发布活动,还有一种更加简单的方法。

领导者是否足够强势?

团队是否足够强韧?

资源来源是否足够强健?

恐惧感是否足够强悍?

答案越肯定,你成功的概率就越大?


思维1:具备进行致命缺陷搜查的本能动力。

思维2:启动组织内部竞争。

思维3:充分理解“以模仿而实现独特性”的价值。

思维4:永远铭记对产品进行情感化处理的重要必。

思维5:拥有独特的组织方程式。

思维6:在信心与畏惧之间保持精妙的平衡。

思维7:在现实世界中,成功的发布不会是一天、甚至一个月的工夫。修订--不断重复的修订。、

若想检验你的组织是否已准备好进行需求创造的发布活动,还有一种更加简单的方法。

领导者是否足够强势?

团队是否足够强韧?

资源来源是否足够强健?

恐惧感是否足够强悍?

答案越肯定,你成功的概率就越大?

 

赵洵-产品经理

产品经理技能——项目管理

公司最近一个项目出现大面积加班,原因是上线时间比原计划晚了1个月,然后就开始大量赶工,经过个人分析应该是项目管理上出了问题。

今天就和大家分享自己对项目管理的认识。

-------------------------------------------------------------------

在我们生活当中,很多东西都可以把它当做一个产品,当作一个项目来看待。产品的实现是需要以项目的形式来运作的,确切地说狭义的产品只解决了项目需求那块,广义的产品却是将整个项目管理包含进来的,因此一个广义的产品生命周期是长于项目的生命周期。

PMI定义的项目管理包含5个过程组、9大管理体系和42

公司最近一个项目出现大面积加班,原因是上线时间比原计划晚了1个月,然后就开始大量赶工,经过个人分析应该是项目管理上出了问题。

今天就和大家分享自己对项目管理的认识。

-------------------------------------------------------------------

在我们生活当中,很多东西都可以把它当做一个产品,当作一个项目来看待。产品的实现是需要以项目的形式来运作的,确切地说狭义的产品只解决了项目需求那块,广义的产品却是将整个项目管理包含进来的,因此一个广义的产品生命周期是长于项目的生命周期。

PMI定义的项目管理包含5个过程组、9大管理体系和42个子过程。



当然,我们做产品的是不需要用到每一个子过程(所谓子过程,就像上表中的 4.1制定项目章程一样,是一个可执行的指令),我着重说一下我们需要掌握的技能。

产品经理需要对整个产品的整合,进度,质量,范围以及沟通有很好的管理技能,而人力资源,成本,风险以及采购我们可以适度了解。

A、整合管理

整合管理是对一个项目的全局把控,里面包含最重要的东西是项目管理计划,这里项目管理计划不只是一个单一的计划,它里面包含了范围管理计划,进度管理计划,成本管理计划,质量管理计划,风险管理计划,人力资源管理,沟通管理计划和采购管理计划。它是所有计划的一个集合,它最大的用处就是,理想情况下不管发生了任何问题,都可以通过查找上面事先设定的方案来解决问题,因为它是最全的。 比如,当项目临时发生了变更,那么就可以通过查找项目管理计划中包含的范围管理或进度管理来响应对应的处理措施,这样整个项目就处于可控状态。整合管理包含制定项目章程、制定项目管理计划、指导与管理项目执行、监控项目工作、实施整体变更控制、结束项目或阶段等6个子过程。

这里着重讲一下制定项目章程,因为这是我们需求的最原始来源,因为不管你最初做产品的原因是为了满足市场需求,还是满足上级需求或是公司战略定位等,但最终立项后都会有个概要说明,说明这次我们要做一件啥事,达到啥目的,这个东西就是写到项目章程里面,最后,我们基于项目章程来做需求分析与范围管理,如下是每个子过程的输入与输出以及分析工具与技术,其他子过程大家简单了解就行。



B、项目范围管理

这个管理与我们产品经理息息相关,因为,我们最核心的事情就是确定好范围,那么,这里就会涉及到收集需求、定义范围、创建工作项分解(WBS)、核实范围和控制范围。

收集需求是我们产品人最常干的事,这里做好需求收集应该从几个方面入手,第一、项目整合管理产出的项目章程,那里包含了我们最原始的想法与需求,第二、从项目整个涉及到的干系人(与项目有直接利益相关的人)那里获得需求,如果你产品是对内,那么找准你的业务方,如果你的项目是对外的,找准你的客户群,当然除了这些人可能还涉及到其他的相关核心人员也要考虑其中。当需求整理好了后,就应该划定项目范围,这里我们产品人常用的两个工具是Axure画高保真原型以及直接写出需求规格说明书。当项目很大时候,我们还需要进行工作项分解,其实,在我们画原型的时候就已经做了工作项分解,通常,我习惯于用脑图的形式将产品做细分,颗粒度详细到Button。但范围划分清楚,工作项整理完成后,也就有了一份完整的高保真原型,最终交给领导核实范围就可以了。项目从头到尾,产品经理都得需要保证项目不能出现范围蔓延的情况,如果发生范围蔓延,最终会导致项目延期,因此必须做好项目范围控制。如下是子过程图:



C、时间(进度)管理

时间管理,作为产品经理不需要同项目经理那样细颗粒度的控制项目时间节点,产品经理需要控制几个大的时间节点,类似里程牌一样的时间卡位,然后保证每个里程牌节点按时交付,就可以保证整个产品按时交付。时间管理包含定义活动,排列活动顺序,估算活动资源,估算活动持续时间,制定进度计划以及控制进度。这些子过程中,很多都是项目经理重点关心的,而产品经理需要做好排列活动顺序,确定每个活动的时间先后顺序,要高度和业务需求吻合,然后把这个需求告知项目经理,让他基于此做资源与时间评估,最终形成进度管理计划。




D、成本管理

成本管理产品经理不需要过多考虑,更多交给项目经理完成。因为项目经理更加清楚项目耗掉了多少资源,耗掉了多少人力,他评估的数据更加准确。

成本管理包含:估算成本,制定预算,控制成本。



E、质量管理

质量管理对于产品经理来说也很重要,因为,我们自己需要知道最终交付出来的产品是否满足了我们最初提的需求,是否存在Bug,因此,产品经理必须要做产品的功能性测试,而不应该把这部分工作推给测试团队来完成。质量管理包含规划质量,实施质量保证,实施质量控制3个子过程。这里的过程对软件产品来说不完全适用,可参考。



F、人力资源管理

产品经理这里需要涉及的比较少,当然如果你手下人比较多,那么这块就应该当作重点来处理,因为一个好的团队才可能打造一个好的产品,当你作为一个领导时,需要合理分配员工工作,合理调节工作节奏,注意人际关系培养,矛盾冲突处理等。如果你是项目经理时,请注重人力资源管理。人力资源管理包含:制定人力资源管理计划,组建团队,建设团队,管理项目团队。



G、项目沟通管理

这也是产品经理的重点,一个优秀的产品经理要很会沟通,需要学会和程序员沟通,将你的需求无失真的传达给他。需要和UI沟通,将你的理念与设计逻辑告诉给他,让他为你锦上添花。需要和领导沟通,需要随时传达你的最新进度,以防止走偏。需要和运营沟通,知道产品最终的推广方式与玩法,以便提前做好产品设计。需要和其他产品经理沟通,找到一个更加友好,更好完美的逻辑业务设计。甚至有的时候,还需要和用户沟通,以便定位你的产品走向。总之,产品经理需要和相关干系人沟通,而且务必注意沟通的手段,因为产品经理是没有实权的,但是你却一直要求别人在做事,别人通常会反感,因此沟通技巧在此很重要。我给大家一个小方法,产品经理务必不要和这些相关人混得太分离,你要知道各方的期望所在,要管理好干系人期望,务必要在做项目时,不要分你我,而要形成一个集体感,形成我们 的感觉。当他们都认为你和他们是一队的时候,很多问题其实就好解决了,但是融入进去,并将你我并为我们是需要大家去努力的。项目沟通管理包含:识别干系人,规划沟通,发布信息,管理干系人期望,报告绩效等5个子过程。



H、风险管理

项目风险管理与产品经理关系不是很大。但是,产品经理也应该了解整个产品容易受到哪些风险的影响,而导致产品市场占有率下降或用户使用率降低。因此,能做一个风险评估分析,形成一个风险管理计划,适当情况下可讲部分东西固化到产品中去,保证产品安全性。比如:涉及到资金类交易的产品,那么在安全环节涉及就应该更加谨慎,以防止资金出错。当项目万一处于风险当中时,如果事先有风险管理计划,并制定了详细的风险应对措施,或者,产品设计中有类似的预防机制,那么就可以减少项目损失,降低风险的影响程度。风险管理包含:规划风险管理,识别风险,实施定性风险分析,实施定量风险分析,规划风险应对,监控风险。




I、采购管理

产品经理几乎不用考虑采购管理,在此就不展开了。采购管理包含:规划采购,实施采购,管理采购和结束采购。



 总结:大家应该从上文对项目管理有个初步的了解,其实大多数产品经理只做了其中的一部分工作,如果你是产品总监,而且,直接管理开发团队,那么上面的事情你应该全部负责。因此,产品经理要想做一个好的产品出来,真心不是你一个人努力就好了,需要整个团队的力量共同推进,才可以诞生一个伟大的产品。


写在最后的话:

通过一篇文章也很难将整个项目管理说清楚,这里以产品为线对项目管理做了简要介绍。如果大家有想详细了解项目管理的,请在评论处留下你的邮箱,我会发一部分干货资料(我曾经考过PMP,因此有很多电子档的项目管理资料)给你,相信能帮助你更好的理解项目管理。



LOFTER

让兴趣,更有趣

简单随性的记录
丰富多彩的内容
让生活更加充实

下载移动端
关注最新消息