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

导语

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

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

前期准备很重要

会议主题

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

提出问题

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

提供材料

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

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

时间地点人物

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

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

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

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

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

道不同,不相远谋

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

解决问题

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

回顾会议

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

会议纪要

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

小结

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

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

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

导语

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


用Axure举例

建立原型库

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

如下图:

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

原型库结构

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

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

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

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

优势

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

劣势

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

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

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

优势

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

劣势

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

小结

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

【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,临时补发一个版本。

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

小结

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

 

【4005】产品原型的整理归档心得(上)

导语

日常工作中,我们会碰到各种各样的需求,大部分需求都需要使用原型进行表达,不知道大家是否有将制作过的原型进行整理归档,方便日后修改或迭代更新。

原型工具

[dangerbox title=”常见的原型工具”]

[/dangerbox]

原型工具市面上种类繁多,我人比较古典派,还是习惯使用Axure。很久以前,有段时间直接用Execl结合文字和原型直接解决需求,非常方便快捷。但也只是当时快一下而已,随着时间的推移,产品体积的变大,迭代的东西越来越多,Excel的结构不足以轻松的支撑一系列的需求撰写。会出现各种切换不方便,元件调用不方便,导致信息零散,无法系统化的阅读。

每个人的习惯都不一样,使用什么软件不重要,只要顺手就行,下面介绍一下我的一些原型管理的心得!


用Axure举例

建立原型库

[infobox title=”原型库”]原型库就是一个存放产品原型的容器,并不是单个需求的零散原型,而是一个产品整体的原型。[/infobox]

建立原型库之前,首先要考虑目标产品的体积大小。若是体积较大的产品,可以考虑根据不同的终端建立“原型库”。

如下图:

例如一个体积较大的产品,既有PC端,又有客户端包含iOS和Android,还有Portal后台。先要判断iOS和Android的统一性,是否需要拆分,一般来说移动端都是尽量做成一样,一方面减少工作量和另一方面降低用户的适应成本,所以可以一起建库。PC端和Portal端都是单独出来建库。

如果一个产品体积较小,所有终端放在一齐也没关系,只要文件有办法打开,不卡不慢,查找东西方便,就没问题。

原型库结构

首先我们要合理的利用Axure的“文件”和“页面”的层次关系。其实这个和思维导图Xmind等软件有异曲同工之处。其实我曾经使用过两种完全不同思路的结构方式,今天我介绍其中一种思路给大家。

 

[info]这个是根据迭代开发为思路的产品库目录[/info]

[infobox title=”规划思路”]将“文件”规范化,形成一个一个的小箱子,小箱子可以放进大箱子里面,归类存放。有需要时,可以抽出其中一个箱子新建文件单独抽出展示。[/infobox]

[info]定义[/info]

  • 一个需求存在多个文件;
  • 一个文件为一个功能;
  • 一个功能存在多个页面;
  • 一个页面可能存在多个子页面,因为不同的状态下呈现的效果可能存在较大出入。

操作方法

如上文所述,将原型库划分为以下区域:

  • 简介
  • 思维导图
  • 原型图
  • 参考文档
  • 需求卡片

[info]简介[/info]

全部都是描述类的页面,具体页面内容如何规划就不在原型库结构范围,日后再单独抽出来与大家分享。“简介”的目的是为了日后翻看记录的时候有备注,方便联想当时的情况。

[info]思维导图[/info]

一般此区域我只会维护最新版结构,只有关键版本才做老版本的记录,此版块的目的是为了可以清晰有大局观的查看产品形态。但凡和逻辑思路相关的图表都可以往这放,例如流程图,测试用例,提示语目录等。

[info]原型图[/info]

此区域为占地面积最大,需求确定前,在当前版本文件进行设计规划,终稿封存后归入历史版本内,并把对应页面放入所有页面的“产品结构图”。

所有页面此文件除了可以存档外,还可以记录每个版本页面产生的变化,在哪个版本产生了变化等。

[info]参考文档[/info]

就是字面上的意思,构建方法随个人喜好,可以根据需求版本当时的参考分析,可以是自己收录的一些干货,各种用于参考的图像资料。在此,若参考内容很多,建议额外做一个Excel表格作为参考文件的名称及所在电脑文件夹的路径。不需要存放在原型库文件内。

[info]需求卡片[/info]

此区域也很好理解,就是将需求池搬进来,不一定要在原型库中管理。放在此处的原因是,有时候需求评审,涉及跨部门或者有大领导,有这个版块的存在比较完整,不需要在软件间不断切换,影响观看体验,所以,此处可以只放当前版本的相关内容。

小结

以上是我的一些浅见,也肯定有改进的空间,若你有更好的想法,欢迎留言或直接与我交流。

 

【4004】单项需求卡片

导语

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

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

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

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

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

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

需求编号

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

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

需求类型

  • 功能需求
  • 非功能需求

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

来源

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

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

场景

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

描述

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

原因

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

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

验收标准

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

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

需求的生命周期

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

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

参考材料

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

需求关联

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

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

竞品对比

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

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

需求重要性

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

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

小结

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

【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

小结

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