会议纪假如将会议内容进行概括提要,条理化、清晰化地整合输出,以记录和传达会议情形及会议结论的文件。
基于会议纪要记录的内容:进行会议信息的通报,让干系职员知悉会议开展情形;统一与会者的共识,确认对会议结论的认知是同等的;

基于会议过程中制订的结论及接下来须要达成的目标,辅导后续事情的开展;后续如果发生问题时,作为可追溯的依据。
02 为什么要用产品思维写会议纪要?
看似一份大略的会议纪要,但是想要把它写好却不随意马虎。
很有可能洋洋洒洒记录了一大堆,一欠妥心就写成没有核心没有重点的流水账。
这样的会议纪要,让看的人不知所云,还须要自己再去记录中抓重点,增加认知包袱;也无法给下一步的实行供应任何参考依据。
对他人来说,收到一份构造清晰、结论及下一步操持明确的会议纪要,能够让干系职员更快、更好、更准确地领会到会议精神,往下推动事情开展。
对自己来说,给出这样一份会议纪要,干系职员会对你的事情能力有所认可,至少输出能力、逻辑思维是清晰而明确的。
身为产品经理的我们,是否可以思考用产品思维来办理这个问题,从而更好地输出会议纪要呢?
而我们也可以从小事不断地磨炼我们的产品思维;演习自己的构造化思维,从用户的角度思考;巩固自己的产品思维,提升自己的事情质量和效率。
产品思维这个观点很宽泛,总的来说,是帮助我们更好地办理问题的思考办法。
在本文中,将结合会议纪要讲一下,产品思维中的用户思维、构造化思维、闭环思维。
03 用户思维:站在用户视角,提升用户体验1. 什么是用户思维?
用户思维,是指站在用户的角度去考虑问题。当我们置身于用户所处的情状中,才能更好地理解他们碰着的问题或者是诉求,再去给出得当的方案。
由于须要站在用户的角度去考虑问题,这就须要我们换位去思考:用户是谁,是什么角色,他在什么场景下,碰着了什么问题或想要达成什么目的。
2. 会议纪要中的用户思维
会议纪要涉及的工具紧张分为两类,分别是发送工具和抄送工具,下面根据这两类吸收工具去剖析他们的场景与诉求。
(1)发送工具:参会职员和目标任务任务人
会议召开后,我们须要将会议纪要发送给与当前事变有直接关系的职员,这个中就包括参与会议的职员,以及会议目标中各任务的任务人。
他们查看会议纪要的场景和诉求为:在会议开完往后,查看记录的内容与参与会议时谈论敲定的是否同等,如果有不一致的地方,须要提出来,以避免在推进事情发展时,涌现方向错了之类的问题。
个中,目标任务任务人,还须要理解会议目标中须要他认领完成的任务,并将事变推动落实下去。这是由于有可能是领导去参会谈论,而实际须要去实行任务的是其下属。
(2)抄送工具:支持部门、领导或业务干系但没能来参会的职员
会议纪要还要抄送给须要对当前事变知情的干系职员,这个中包括支持部门、领导或业务干系但没能来参会的职员。
他们查看会议纪要的场景和诉求为:在会议开完后,收到了同步会议情形的会议纪要,知晓一下事情的进展和发展方向,如有问题可以及时提出,以确保事情顺利推进。
其余,所有角色都还会存在一个查看会议纪要的场景与目的:当后续涌现问题须要追责时,根据会议纪要追溯当时约定的结论,看问题是出在哪里、哪个环节。
由于我们开完会后,会议结论是须要记录并且同步给到干系职员,以传达信息并且推动事情进一步发展;且会议每每都是有多人参与,或者会议后的结论是须要奉告到多个人的。
以是会议纪要每每是通过邮件的办法发送。利用邮件的办法,会显得比较正式,更随意马虎引起重视;并且书面化的办法留底可追溯。
在会议纪要中,以下内容可以结合会议纪要中的用户思维去完成。
(3)标题
结合上述提到的,会议纪要每每是通过邮件发送的。即收件人在收到会议纪要时,也可能会收到浩瀚其他邮件。
因此,收件人须要在看到邮件标题时,就能够一眼看出是讲什么内容的,以决定当下是否要查阅该邮件。
其余,当后续须要翻看邮件时,也可以通过关键词方便地查到。
起邮件标题的格式,可以参考:【会议纪要】+韶光+主题。
个中,主题包括业务主题和环节主题,即同一个业务事变,可能会在不同环节召开会议。为了便于区分不同会议内容,是在什么环节召开的会议也要进行解释。
举例:【会议纪要】7月31日关于XXX业务需求评审
这样,收件人在看到邮件标题时,就可以知道是关于哪个业务的哪个环节召开的会议后记录的会议纪要了。在后续如果有须要查找时,也能够更加快速便捷地根据关键词进行搜索。
(4)会议简介
前面提到,会议纪要的吸收职员包括参会职员、目标任务任务人以及支持部门、领导或业务干系但没能来参会的职员。
他们查看会议纪要的场景除了刚开完会议时,还包括后续涌现问题时,须要翻看之前的记录。
基于查看会议纪要的工具和场景,可以知道查看会议纪要的人未必去参会了,他可能并不清楚事情的背景以及开展情形;或者如果是过了一段韶光翻看会议纪要的,可能也已经记不清楚背景以及当时的情形了。
因此,须要针对会议内容做个简要先容,解释记录一下会议韶光、参会职员、会议内容等,让干系职员能够知道会议开展的背景和开展的情形,知道在什么时候,发生了什么事情,都有哪些职员参与。
如果是事后涌现问题须要追溯时,会议简介也可以帮助回顾当时的情形。
会议韶光的记录格式可以为,XX年XX月XX日 XX点~XX点;例如2020年7月31日 13:00~14:00。记录发生的详细的日期,以及一个大致的韶光区间即可。
参会职员可以先先容外部团队职员,再先容内部团队职员,末了再加上自己。有必要的话,可以在团队顺序中再按照职级顺序去先容,让他人感想熏染到被重视。
会议内容中可以简要先容会议沟通的背景,会议沟通的事变。让没有来参与会议的职员、上级领导等能够理解事情的来龙去脉。知道是基于什么背景发生了什么事情。
04 构造化思维:结论先行,展开阐述1. 什么是构造化思维?
构造化思维是指从多个角度全面而清晰的去思考、去梳理事物的一种思维办法。
先说整体结论,再依次展开论述,给出论据解释前面得出来的结论。
利用构造化思维去进行思考和表达时:结论先行,再去展开阐述,先突出重点,能够让对方更加轻松地理解我们想表达的不雅观点,
而不是吸收信息者先听一堆论据,还要自行去做信息归纳整理,才知道我们到底想表达什么;
在详细阐述时,将零星的点进行组织归类后,信息变得更加有规律和有逻辑,能够提高我们的思考和理解效率,从而更加高效地推进和解决问题。
2. 会议纪要中的构造化思维
(1)会议结论
针对会议谈论的整体情形,先说总体的结论。
这样能够降落阅读者的难度,让他人最快速地节制本次会议纪要的核心思想;再依次展开论述,给出论据解释前面得出来的结论,让想要进一步理解详情的职员,可以再往下看。
如果会议中达成的结论较多且涉及不同类型,可以再做一下分类,比如按照不同的业务环节的会议结论进行分类,例如运营侧的干系会议结论、产品侧的干系会议结论。这样查看的职员可以根据自己的目的去查看其干系的内容。
其余,会议结论是须要同步给干系职员的,如果有必要的话,可以艾特到详细职员。
举例:会议结论:
1)条约管理业务的定位:
条约信息的集中管理和规范化管理,包括发卖条约和采购条约;
个中发卖条约须要记录条约信息及条约干系的开票、收款、收入确认信息。
2)财务事情台、前台产品、商务系统三者之间的协作关系
客户经理成单后,于财务事情台和商务系统分别录入条约与订单(条约与订单之间的关系、订单收款信息、开票信息,由财务事情台供应能力,能够将条约与订单进行关联记录,和便捷的进行数据记录);
商务系统定期完成用度打算与账单结算(通过前台产品供应的操作平台,由用户确认结算;财务事情台供应能力,能够将计费数据与结算数据在财务事情台中进行便捷记录)
05 闭环思维:有始有终,推动问题办理1. 什么是闭环思维?
闭环思维是指我们在做一件事情时,要做到有始有终。不是仅仅把事情做了,而是要担保事情做了往后,是能够办理问题,或者有相应的见效或进展的。
贯彻闭环思维,即当我们在做一件事时,不仅是把当下的事情做完了,还要对结果有促进浸染,形成一个良性循环,从而离目标越来越近。
2. 会议纪要中的闭环思维
发起会议是有会议目的的,是要把事情做推进落地的。
那么在会议过程中,如果有提出一些待确认的问题,或者待实行的事变,就须要跟进并且去落实。
(1)会议目标
会议开展过程中,达成了某些结论,也会达成一些接下来还要做哪些事情的共识,包括待确认的问题或者完成的事变。
会议目标中的这些任务,须要明确任务人跟进和预期完成韶光。
明确任务人是要把事情分配给到某个人,有人跟进,事情才能往下推,不然就没人管了。
明确预期韶光也是同样的,韶光点如果不明确,那么就没有观点说这个事情要什么时候完成,
可能就会一拖再拖,从此搁浅,那么这个待办也是没故意义的了。
其余,在给出待办事项时,同样要记得分类。让看的人可以明确分别有哪些类型的待办,
比如待确认的问题,和待实行的事变;或者可以按事变的类型分类,比如开拓环节须要关注的,比如业务环节须要关注的。
举例:待办事项:
1)请@市场同学 关注并及时确认,请于本周五完成反馈:
关于赠予给用户的流量金额,在给用户进行直充时,须要审核后方可生效。直充订单需流转由谁完成审核?
2)待与@项目组 进一步沟通达成共识,下周三会议谈论:
计费结算干系
预支费业务是否流转至计费系统进行用度打算;明确如约、授权、计费系统的定位问题账户充值干系
直充审核是否须要利用事情流模式;账户体系中,关于赠予金额部分的形式是什么(优惠账户?红包?或其他)小结会议纪假如我们日常事情开展过程中,很常见的须要撰写并与他人协作的内容之一。
用产品思维,做自己手头的每一件事情,从小事动手,能够帮助我们潜移默化地去培养自己的干事习气和提升自己的思维办法。
让我们从这一封封看起来不起眼的会议纪要开始吧~
作者:产品BBQ;"大众年夜众号:产品BBQ,欢迎沟通互换~
本文由 @产品BBQ 原创发布于大家都是产品经理。未经容许,禁止转载
题图来自Unsplash,基于CC0协议