【4008】如何撰写“会议纪要”

导语

前面的文章提及过会议中的沟通,今天我就说说会议相关的文档——“会议纪要”。

会议通过邮件或办公系统发起那一刻起,“会议纪要”就已经开始做相应的记录了,从某个角度联想,一个会议可以理解为一个项目,“会议纪要”就是这个项目的项目文档。

前期准备很重要

会议主题

会议主题很重要,主题太大没意义也肯定没结论,主题太小没必要折腾,直接站立式会议即可快速解决。能在一个会议上解决超过一个重要问题,已经是非常成功的会议了。

提出问题

围绕会议主题,列出几个重要且迫切需要解决的问题,可以从“结构框架”、“技术实现”、“安全风险”和“流程规范”等方面进行思考。一个会议不建议列举太多,五条左右就差不多了,无关痛痒的小问题就没必要写出来。

提供材料

会前材料也是非常重要的,会议应该是在阅读过材料的前提下进行。当然,很多公司习惯开会时才陈述材料,这个没有对错,只是比较浪费时间而已。

材料尽可能提前24小时提供给参会人员,并可根据提出的问题进行思考,会议时就可以针对问题进行解决,或者提出新的问题。

时间地点人物

因为会议非个人可以独立完成的,所以在时间上是不可控的,因此需要有“首选项”,针对首先时间看看是否都能参与,实在无法达成,再启用后备时间选项。

会议室的选择,要根据实际参会人数进行考虑,多预留两到三个空位最为合适,方便应对临时发生的变动。

人员也分为“关键参会人”和“协同参会人”。很好理解,与此会议主题息息相关的部门或人员,为“关键参会人”;只是与此内容有关联,知道发生什么事即可的,为“协同参会人”。

发起会议时,还需要思考后备人选及抄送相关领导,务必让相关人员都对此会议知晓。

主持人与记录人务必在会议中配合做好控场工作。

道不同,不相远谋

开会时不应该直接开始陈述或讨论,应该先确立“宗旨”。本次会议的期望方向及期望结果,若连这个也无法达成一致,后面的讨论都无意义。大家的思路一致,在解决问题时,效率也会相应提高。

解决问题

根据提供的“材料”和“问题”,逐一攻破解决,并进行结论记录。若发生争论不休,一时间无法解决的问题时,可以尝试使用“六顶帽子思考法”或者把问题留到会议最后进行解决。每讨论完一个问题之后,必须二次归纳重复讨论结果,尽可能确保大家思路及信息一致。

回顾会议

会议是个脑力消耗的过程,中间难免会出现走神或分心,尤其对于一些协同部门,在与自己无关的部分容易走神漏听。所以在会议结束前,必须要有一次总结回顾,将刚才会议上的问题及讨论结果重新过一遍,再次确保信息的一致性。

会议纪要

将本次会议的来龙去脉进行整理撰写,并发放给相关部门进行查阅,以此告知天下本次会议的结果,这也起到公示作用。会议中一些没考虑到的问题,也有可能在此时被点明提出,达到补漏的作用。同时避免“三人成虎”,将会议结果错误传达,有人问起,可以直接用“会议纪要”进行传阅。

小结

虽然全文并未举例文档结构样式,但我提供了思路,结构样式只是表现手法,关键是撰写思路。不能写的别人一脸懵逼,前因后果描述清楚,知道个所以然即可。

另外,会议并不是走走形式,而是解决问题。时间很宝贵,我们不能浪费自己的时间,更不能浪费他人的时间,争取每个会议都是有效会议,而不是得过且过的形式流程。

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

导语

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

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

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

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

会议纪要的意义

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

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

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

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

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

小结

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

 

【4006】“修订记录”与“版本管理”

导语

为什么会将“修订记录”和“版本管理”放在一齐?在我理解中,它们是有密切联系的,每个新版本都有对老版本的一些修订内容,否则也不需要发新版本。

今天说的“版本管理”是指产品岗位上的“版本管理”,并非开发团队内部的“版本管理”,开发团队都有自己的一套版本管理方法和思路,并且因为涉及代码层,所以会更严谨和复杂,在此不做延伸。

修订记录

[infobox title=”修订记录”]一般指文档修正更新后,针对文档进行的修改说明。[/infobox]

修订记录无非就是告诉别人改动了什么,所以最关键的是改动项,它的描述要尽可能使用(主语+谓语+宾语)的表达形式,不要加主观修饰语句。尽量一两句话说清楚事情即可。

改动项包含以下类别:

  • 增加(Add)
  • 修改(Modification
  • 删除(delete)

上图的表格也是仅供参考,需要根据所处团队的实际情况进行针对性设计。有人会问版本号,这里的版本号是该文档的版本号,在文章《关于文件名管理》中也提到过同一个文件,修改多几次,就忘记自己看的是哪一天的版本了,若经历多几个人的协同编辑且胡乱起名后,很难保证文件的信息完整性及准确性。

用“日期”+“版本号”都放入修订记录中,有助于校正文件的最新版本和最新内容。

版本管理

[infobox title=”版本管理”]当一个“产品”存在多个版本时,为了更好的区分哪个是哪个,可用版本号进行识别。[/infobox]

[infobox title=”范例”]v A区 . B区 . C区 . D区[/infobox]

区域解释

  • V:版本(versions);
  • A区:重大变动,里程碑级别的调整;
  • B区:功能性调整,操作流程调整等小型改动;
  • C区:小修小补型迭代更新的调整,一般用于普通版本迭代;
  • D区:极小的细节处理,例如修改文字,上线后发现小bug,临时补发一个版本。

版本号使用阿拉伯数字往上叠加即可,内部人员日常沟通时,说到某个功能,带上“版本号”为背景,大家就能清晰的知道对应的是哪些内容。用户发现问题时,提出“版本号”,也方便开发人员进行问题排查。

小结

巧妙的将“修订记录”与“版本管理”相结合运用,版本说明就是可以轻松的归纳总结了。看上去,这个都是比较繁琐且需要维护的没用边角料,实际上在个人成长管理及项目文件管理上,还是非常好用的,大家也可以尝试开发一套适合自己用的“版本管理”方法,让事情事半功倍。

 

【4004】单项需求卡片

导语

不知道大家是否有这样的经历,每天的时间也就24小时,事情也有缓急轻重之分,不可能同时间处理很多事情。但协同部门又有很多需要解决的大需求,小需求,小建议和漏洞bug等,需要跟进解决。一般来说,都会将信息列入需求池的待处理需求中。

需求池的详细程度也决定了需求池的维护成本,在这里,我推荐一种“单项需求卡片”的记录方式,搭配需求池进行使用。可以有效解决同时间解决不过来的需求事物,并能在日后启动需求时,快速的找到相关人员及相关内容等。

当然了,一句话能描述清楚的事情,也没必要动用“单项需求卡片”这么重的东西,灵活变通,切勿浪费大家的时间。

“单项需求卡片”是干什么的?

“单项需求卡片”类似我们去银行办理业务,领个号后,开始填写的业务相关表格。到柜台时,方便柜员进行一系列的资料录入工作。回到工作的场景,就是让需要提需求的同学填写一份表,然后自己根据表上的内容就可大概了解这位同学需要提个什么需求。

“单项需求卡片”需要什么内容?

需求编号

一般需求编号使用大家都懂编写,且看到都能快速转译的方式比较合适。

如:年月日(YYYYMMDD)+姓名。可根据实际需要添加其他大家都懂编写的标签。

需求类型

  • 功能需求
  • 非功能需求

填写的人不一定都非常熟悉产品结构,尽量的易懂即可。

来源

此信息比较重要,方便追溯根源。

产生需求的用户和该用户的相关信息,描述清楚即可。

场景

产生该需求的时间,地点和环境等场景信息。

描述

尽可能使用(主语+谓语+宾语)的表达形式,不要加主观修饰语句。

原因

这也是非常重要的信息,作为产品经理,此时此刻必须保持怀疑的心态,因为有很多的理由是假想出来的。

为什么会有这样的需求?发起者的解释是什么?

验收标准

这个需求要怎样才算是满足了,定义一个标准,好让产品同学和开发同学以及设计同学有个底

  • 尽可能使用可量化的语言;
  • 无法量化的标准要举例解释。

需求的生命周期

这个属于需求的紧迫度和可持续性内容。

  • 需求的紧迫程度;
  • 上线后使用周期和持续性等。

参考材料

对此需求有一定参考价值的材料及有用的相关资料,不一定需要封装压缩,引用说明,能找到即可。

需求关联

与此需求有关联关系的各种

  • 人:与此需求相关联的任何人;
  • 事:与此需求相关的业务、相关功能及事件等;
  • 物:与此需求相关的系统,设备和其他产品等。

竞品对比

  • 竞争对手是如何实现该功能的
  • 竞争对手该功能获得的评价。(大众用户角度,公司内部角度,产品设计角度等层面进行考虑)

给出规范定义“1分”差到“10分”好,有个评分概念。

需求重要性

需求的重要性建议产品经理自己内部团队定义,开放填写此栏目,容易造成所有需求都是紧急需求,重要需求。

除非公司有个提交需求系统,可以针对系统设定一些规则,去制衡乱填需求重要性。

小结

还是那句,一切的模板,套路都是死的,灵活应用即可。在不同的团队,不同的公司,甚至不同的时间周期,可能模板都会纯正各种变异和差异,只要问题能解决,这东西甚至没有存在的意义。在此,希望此单项需求卡片能对大家有帮助。

【2004】需求文档需要详细到什么程度?

导语

相信很多产品经理都有这样的一个经历,需求写的太简单吧,开发同学嫌弃没细节。花大力气写个长需求吧,需求评审的时候又发现,大部分人压根没怎么细读过文档。在这里,要抛出个问题

需求文档是干什么用的?

一般来说也就两个用处:1、用来沟通;2、用来存档。

内容够用就好

很多人可能喜欢在这个时候抛出《用户体验要素》中的五个层次(注:用户体验的五个层面分别是:战略层、范围层、结构层、框架层和表现层。),将一个需求拆分成好几个不同的层面进行说明,写完一副这需求写的完美了,人人都能看懂了,什么信息都包含了。对,这确实没错,但这会消耗大量的时间在编辑文档上啊,若非关键大版本的需求,清楚明白就行了,毕竟实际工作场景中,太多的快速迭代版本,什么都一五一十的写出来,在时间分配上也是一门学问。很多时候,画个原型,加一些辅助的说明,远比文字直观。

给谁看

一个需求的立项,也有调研,分析,评审,排期等不同的阶段,不同的需求也有可能会碰上不同的会议,不同的主题,所以这时候给谁看很重要。最关键的是,TA想知道什么。

  • PPT:一般都是包装华丽,文字精简,突出中心,主要靠的是会议的演讲,并不是文件的本身。针对对象:大老板,发工资给你的那个人;
  • word | excel:一般都是条理清晰,层级清晰,列清楚一二三四五。针对对象:开发同学,一般他们喜欢一是一,二是二,不带歧义的描述;
  • xmind | axure:结构化思维,图形化思维,直观容易理解。针对对象:评审会议上的各路人马,大部分人容易理解这是干什么的,方便看图提问,发现问题;
  • 图片 | 交互流程 | 清单:清楚列出该需求涉及页面数量,交互逻辑是怎样的。针对对象:UI和UE设计师同学,解决设计上的布局问题和体验问题。

小结

软件只是工具,模板只是方法,关键在于随心所欲,灵活变通。

【2003】说说周报

导语

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

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

这里涉及到几个因素:

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

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

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

本周做了什么

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

下周要做什么

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

遇到什么问题

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

存在什么风险

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

给谁看

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

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

小结

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