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

导语

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

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

前期准备很重要

会议主题

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

提出问题

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

提供材料

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

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

时间地点人物

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

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

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

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

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

道不同,不相远谋

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

解决问题

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

回顾会议

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

会议纪要

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

小结

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

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

【4007】产品原型的整理归档心得(下)

导语

前面介绍过一种基于项目开发进行整理的产品原型归档方法,今天我再说说另外一种将产品原型整理归档的方法。


用Axure举例

建立原型库

如果说上次介绍的方法比较适合用在协同工作上和快速迭代上,这次这个方法就更适合用于个人的归纳总结,像“知识库”一样的存在。

如下图:

此方法建库比较灵活,根目录的结构决定了日后的子目录形式,怎么建立完全按照自己的思路结构决定。

原型库结构

由于此方法比较灵活,不同的思路,出来的效果完全不一样,所以在建立根文件夹的时候,需要考虑清楚自己的阅读习惯。

[infobox title=”规划思路”]此方法的核心在于根据功能体系进行划分,基于不同的功能版块进行填充模块内容,利用不同的维度定位摆放,还是“小箱子”和“大箱子”组合的概念。[/infobox]

[info]按产品建库[/info]

根目录文件夹为一个一个的产品,每个产品文件夹里都有N个功能版块小文件夹。功能版块里有不同日期的页面内容,由于不是基于开发版本,所以使用“时间戳”对同一个功能的迭代修改进行命名区分。

优势

  • 可以清晰看清产品形态
  • 方便进行竞品间的对比
  • 有助于看清产品的发展轨迹

劣势

  • 可能会存在很多重复和类似的功能
  • 容易造成偏科和思维局限

[info]按功能版块建库[/info]

根目录文件夹为一个一个的功能版块,每个功能版块文件夹里都有N个不同类型样式的小文件夹。最终也是用“时间戳”对每个修改版本进行命名区分。

优势

  • 类似记忆宫殿,可以当知识库结构使用
  • 遇到类似功能问题时,可以直接查阅对应版块进行参考
  • 可清晰查阅发展形态

劣势

  • 缺乏产品大局观
  • 不适合工作流,让人无法理解前因后果
  • 时间长后,容易忘记时代背景。(需要用大量备注进行说明)

小结

每个人都有一套自己惯用的思维方式,没有最好的方法,只有最适合自己的方法。就如BAT看似严谨完整的功能上线流程,若放在初创快速迭代的企业,也不一定是好的一个道理。

【4004】单项需求卡片

导语

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

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

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

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

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

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

需求编号

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

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

需求类型

  • 功能需求
  • 非功能需求

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

来源

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

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

场景

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

描述

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

原因

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

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

验收标准

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

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

需求的生命周期

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

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

参考材料

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

需求关联

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

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

竞品对比

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

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

需求重要性

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

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

小结

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

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

导语

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

需求文档是干什么用的?

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

内容够用就好

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

给谁看

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

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

小结

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

【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”,将敏感内容再单独“盖楼”给对应的人员,完成汇报周报的工作流。

小结

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