【2007】浅谈会议中的有效沟通

导语

在很多项目环境中,无可避免的就是开会,可能是跨部门,可能是跨公司。而产品经理通常在会议中都是充当“主持人”和“记录人”的角色,所以“会议纪要”是不可或缺的。

自以为有效的沟通,很多时候并不有效

团队越大,分组越多,KPI越不一样时,无效的沟通的现象越突出。

一方面,正所谓“三人成虎”,每个人的理解都不一样,跟着自己理解的思路走,传着传着就传偏了。另一方面,当老板问起来时,若A和B说法不一致,甚至完全背道而驰,会造成内耗成本加大。为避免此类情况发生,“会议纪要”可以让A和B双方都达成一致共识。

会议纪要的意义

  • 传达会议信息给相关人员
  • 公示会议结论
  • 确认问题
  • 后续计划/跟进

降低阅读门槛,见人说人话

不经过思考或训练的人,一般都在说自己能听懂的话,这是非常正常的现象,所以我们必须学会“见人说人话,见鬼说鬼话”。那要如何做呢?降低对自己沟通能力的自信,让对方复述或解读,或者自己换个阐述方式看对方反应。验证对方是否真的听明白了。

产品经理需要懂多门“语言”

这里说的“语言”并非英语、日语之类的语言,而是职业习惯用的一些术语和逻辑思路。产品经理一般充当跨部门间的翻译角色,降低理解误差,这样能避免无谓的需求变更。

小结

合理的沟通技巧可以有效提升会议中的工作效率,而“会议纪要”更能对本次会议进行一次有效的总结作用。提升自我的“语言”能力,在协同沟通上可以事半功倍,同时也要合理运用于各类文档的编写当中。

 

【4003】建立属于自己的word文档模板 – 样式篇

导语

一般情况下我们写好的需求文档是给别人看的,但别人收到文档时,此文档对于别人来说是陌生的,单凭“目录页”也很难让别人能轻松浏览。这时候文档的样式结构就很重要了,清晰的样式结构,有助于在文档中寻找所需要的内容,并且方便定位。

核心功能

  • 样式:字体,字号,粗/斜/下划线;
  • 格式:多级列表,段落设置;
  • 视觉需要:产品结构图/导航窗格

样式说明

样式.png

一般打开Word肯定能找到,鼠标“右键”->选择“修改”,如下图:

样式1.1.png

在此处调节自己期望的字体,字号,颜色,粗细等。

样式1.2.png

格式说明

我个人比较喜欢的效果是用:

1. 标题

1.1 标题

1.1.1 标题

这个很简单,找到“多级列表”此功能,并选中编辑格式即可

样式1.png

格式_多级列表.png

最终效果

效果.png

在此处记得一个事情,将“格式”并入“样式”。在样式对应项中,鼠标“右键”->“更新 **以匹配所选内容”

更新前

效果1.png

更新后

效果1.2.png

产品结构图

利用产品结构图进行文档阅读,有助于了解文档结构大纲,并能轻松定位到目标页面。

顶部导航栏选择“视图”-> 勾选“导航窗格”,即可成功打开产品结构图。

文档结构图.png

文档结构图2.png

若需要导出PDF文档,也可以让PDF文档带上这些结构参数,在“另存为”操作时选择PDF格式,并在“选项”中勾选“辅助功能文档结构标识”,PDF即可生成对应文章结构。

PDF文章结构.png

PDF文章结构1.png

小结

软件年年都更新,过几年这操作说明可能不适用,此文虽然介绍的是方法,实际推荐的是方案。天下武功出少林,东西都是可以融会贯通的,此方案对阅读有一定的帮助,所以介绍给大家。

【2003】说说周报

导语

相信大部分的公司每周都要写周报,除非特别忙碌,否则周报里总会掺杂一些看似华丽,实际没用的内容信息。就如以下场景:

运营活动发生变更,活动专题页需要调整文字和更换图片,内容琐碎,但存在工作量。产品经理叫技术帮忙调整下页面,虽然是手板眼见功夫,但技术人员想了几秒,还是说了句,提个需求吧。

这里涉及到几个因素:

  • 工作流上应该走需求提交流程
  • 技术人员需要写周报,这是工作证据
  • 有个记录,日后发生问题的时候有依据

今天说的是周报,就不扯远,不去纠结若出了问题这个锅谁背这些办公室问题和职能问题。更多的时候,其实就是工作证明的问题,我做了这个事情,有证据可依。

那么,周报到底要写些什么呢?怎样写周报才让周报真正有意义。

本周做了什么

描述做了什么事情,开了什么会议不重要。关键在于时间节点,进度情况,有什么决定,后续如何跟进等。

下周要做什么

原理同上,主要描述需要获得的结果成就,不是过程经历。

遇到什么问题

例如:一个可控低的需求,遇到第三方资源还没到位,需要什么人,怎样帮忙。若无法达成,是否存在后补方案。

存在什么风险

例如:一个需求的实现方法上存在多种实现方案,但有各自的优缺点,使用不同的方案分别会引致什么问题发生,这些问题是否存在重大影响。

给谁看

在写作技巧上,尽量少用“继续跟进会员中心功能细节”这种比较虚的描述,应该使用“与开发部的XX同学进行讨论后,达成共识,周4启动XX功能的需求撰写工作”。

根据不同的汇报环境,调解内容的敏感层次。若真的存在敏感内容必须汇报告知的时候,可以将公共内容进行“TO”和“CC”,将敏感内容再单独“盖楼”给对应的人员,完成汇报周报的工作流。

小结

任何工作,不是为了别人,而是为了自己,周报不是应付,而是对自己过去工作的一个小总结,定期对自己过去知识点和碰到的问题进行梳理,让自己能不断的提高。

【3004】SMART原则

 

SMART原则(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound),实施目标管理不仅是为了利于员工更加明确高效地工作,更是为了管理者将来对员工实施绩效考核提供了考核目标和考核标准,使考核更加科学化、规范化,更能保证考核的公正、公开与公平。

原则解释

1. 绩效指标必须是具体的(Specific)

2. 绩效指标必须是可以衡量的(Measurable)

3. 绩效指标必须是可以达到的(Attainable)

4. 绩效指标是要与其他目标具有一定的相关性(Relevant)

5.绩效指标必须具有明确的截止期限(Time-bound)

五大原则

明确性

所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可,或没有将目标有效的传达给相关成员。

示例:

目标——“增强客户意识”。这种对目标的描述就很不明确,因为增强客户意识有许多具体做法,如:减少客户投诉,过去客户投诉率是3%,把它减低到1.5%或者1%。提升服务的速度,使用规范礼貌的用语,采用规范的服务流程,也是客户意识的一个方面。

有这么多增强客户意识的做法,我们所说的“增强客户意识”到底指哪一块?不明确就没有办法评判、衡量。所以建议这样修改,比方说,我们将在月底前把前台收银的速度提升至正常的标准,这个正常的标准可能是两分钟,也可能是一分钟,或分时段来确定标准。

实施要求:

目标设置要有项目、衡量标准、达成措施、完成期限以及资源要求,使考核人能够很清晰的看到部门或科室月计划要做哪些那些事情,计划完成到什么样的程度。

衡量性

衡量性就是指目标应该是明确的,而不是模糊的。应该有一组明确的数据,作为衡量是否达成目标的依据。如果制定的目标没有办法衡量,就无法判断这个目标是否实现。比如领导有一天问“这个目标离实现大概有多远?”团队成员的回答是“我们早实现了”。这就是领导和下属对团队目标所产生的一种分歧。原因就在于没有给他一个定量的可以衡量的分析数据。但并不是所有的目标可以衡量,有时也会有例外,比如说大方向性质的目标就难以衡量。

比方说,“为所有的老员工安排进一步的管理培训”。进一步是一个既不明确也不容易衡量的概念,到底指什么?是不是只要安排了这个培训,不管谁讲,也不管效果好坏都叫“进一步”?

改进一下:

准确地说,在什么时间完成对所有老员工关于某个主题的培训,并且在这个课程结束后,学员的评分在85分以上,低于85分就认为效果不理想,高于85分就是所期待的结果。这样目标变得可以衡量。

实施要求:

目标的衡量标准遵循“能量化的质化,不能量化的感化”。使制定人与考核人有一个统一的、标准的、清晰的可度量的标尺,杜绝在目标设置中使用形容词等概念模糊、无法衡量的描述。对于目标的可衡量性应该首先从数量、质量、成本、时间、上级或客户的满意程度五个方面来进行,如果仍不能进行衡量,其次可考虑将目标细化,细化成分目标后再从以上五个方面衡量,如果仍不能衡量,还可以将完成目标的工作进行流程化,通过流程化使目标可衡量。

可实现性

目标是要能够被执行人所接受的,如果上司利用一些行政手段,利用权力性的影响力一厢情愿地把自己所制定的目标强压给下属,下属典型的反映是一种心理和行为上的抗拒:我可以接受,但是否完成这个目标,有没有最终的把握,这个可不好说。一旦有一天这个目标真完成不了的时候,下属有一百个理由可以推卸责任:你看我早就说了,这个目标肯定完成不了,但你坚持要压给我。

“控制式”的领导喜欢自己定目标,然后交给下属去完成,他们不在乎下属的意见和反映,这种做法越来越没有市场。今天员工的知识层次、学历、自己本身的素质,以及他们主张的个性张扬的程度都远远超出从前。因此,领导者应该更多的吸纳下属来参与目标制定的过程,即便是团队整体的目标。

定目标成长,就先不要想达成的困难,不然热情还没点燃就先被畏惧给打消念头了。

实施要求:

目标设置要坚持员工参与、上下左右沟通,使拟定的工作目标在组织及个人之间达成一致。既要使工作内容饱满,也要具有可达性。可以制定出跳起来“摘桃”的目标,不能制定出跳起来“摘星星”的目标。

相关性

目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标,但对其他的目标完全不相关,或者相关度很低,那这个目标即使被达到了,意义也不是很大。

因为毕竟工作目标的设定,是要和岗位职责相关联的,不能跑题。比如一个前台,你让她学点英语以便接电话的时候用得上,这时候提升英语水平和前台接电话的服务质量有关联,即学英语这一目标与提高前台工作水准这一目标直接相关。若你让她去学习六西格玛,就比较跑题了,因为前台学习六西格玛这一目标与提高前台工作水准这一目标相关度很低。

时限性

目标特性的时限性就是指目标是有时间限制的。例如,我将在2005年5月31日之前完成某事。5月31日就是一个确定的时间限制。没有时间限制的目标没有办法考核,或带来考核的不公。上下级之间对目标轻重缓急的认识程度不同,上司着急,但下面不知道。到头来上司可以暴跳如雷,而下属觉得委屈。这种没有明确的时间限定的方式也会带来考核的不公正,伤害工作关系,伤害下属的工作热情。

实施要求:

目标设置要具有时间限制,根据工作任务的权重、事情的轻重缓急,拟定出完成目标项目的时间要求,定期检查项目的完成进度,及时掌握项目进展的变化情况,以方便对下属进行及时的工作指导,以及根据工作计划的异常情况变化及时地调整工作计划。

总之,无论是制定团队的工作目标,还是员工的绩效目标,都必须符合上述原则,五个原则缺一不可。
制定的过程也是对部门或科室先期的工作掌控能力提升的过程,完成计划的过程也就是对自己现代化管理能力历练和实践的过程。

 

 

 

【4002】需求文档中的“产品结构”和“信息结构”

导语

在日常工作中,需求文档需要给很多不同职能的人查阅,描述一个新增的功能点时,总会容易有些遗漏,很多场景下,都是技术人员给予提问,这个地方是否怎么怎么样,这个地方需不需要什么等等。如果我们每个需求文档中,都将【产品结构】和【信息结构】都描述到位了,就能很大概率的避免这个问题。

产品结构图

如上图,将一个事物分解,用思维导图的方式,将产品的版块,页面,模块,罗列出来,最终形成一个产品结构图。这样可以让设计和程序清晰的了解一共有多少个页面,页面有哪些内容,相互的关系是什么等等。也能方便自己在构思框架和文档复查中找出缺失遗漏项和重复多余项。

信息结构图

如上图,随便抽了一个页面进行举例,这就是信息结构图。带过一些产品新人,普片会出现一个情况,产品结构和信息结构混在一齐描述,混在一起描述不是不行,只是会增加开发同学开发的阅读难度,必须通过一段话进行多次阅读,并进行二次编译,形成他们所需要了解的内容,那些字段,哪些接口等。信息结构图能大大降低开发同学的阅读成本,并不容易遗漏,开发中还可以一点一点对着打勾,否则一段的描述或者混淆的描述,在昏天黑地永无止境的开发过程中,容易因为某些不可抗拒因素就产生遗漏。

小结

产品结构:首页,列表页,详情页,整点秒杀,猜你喜欢,这种版块,页面,模块等就是产品结构的构成部分。

信息结构:主标题,副标题,时间,作者,评论,这些就内容项就是信息结构的构成部分。

根据实际情况,将优化需求文档的描述方式,降低他人的阅读成本,也是一门必修课。

【3002】常用文档类别解释

BRD:Business Requirements Document 商业需求文档

这是产品生命周期中最早的问的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的ppt,所以也就比较短小精炼,没有产品细节。

MRD:Market Requirements Document 市场需求文档

产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,Excel的Feature List等。

PRD:Product Requirements Document 产品需求文档

进步一细化,这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。主要内容有,功能使用的具体描述,Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

FSD:Functional Specifications Document 功能详细说明

有一点像“概要设计”,这步就开始往开发衔接了,产品UI、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多内容,比如表结构设计,要由架构师来编写了。