taoCMS-基于php+sqlite最小巧的CMS http://www.taocms.org/ taoCMS是基于php+sqlite/mysql的国内最小(100Kb左右)的功能完善的CMS管理系统 2018-10-20 taoCMS-基于php+sqlite最小巧的CMS 1151 Excel两列求差集和交集 原文地址 https://blog.csdn.net/aldenphy/article/details/6774622

1. excel求两列差集(查找A列中与B列不同的部分)


示例:
  行号   A列       B列       C列结果(A-B)
   1       1          3            1
   2       2          4            2
   3       3
   4       4
   5       5                        5
 
  方法一:
       在c列(结果列)第一行输入:=IF(COUNTIF($B:$B,A2)=0,A2,"")
       【向下复制公式。鼠标放在C1单元格右下角处,变为黑色十字“+”时,右单击鼠标,向下拉动进行填充。】
     
 
  方法二:
       c列输入公式为:=IF(ISERROR(VLOOKUP(A2,$B:$B,1,FALSE)), A2,"") 
 
2.execl求两列交集(查找两列相同)
示例:
   行号   A列       B列       C列结果(A∩B)
  
方法一:
   公式:
          c列输入:=IF(COUNTIF($B:$B,A2)>0,A2,"")
 
    方法二:
    公式:
          c列输入:=VLOOKUP(A2,$B:$B,1,FALSE)
]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-10-06 12:10:52
1150 信贷业务:常用风险指标及分析手法 1、基本名词概念




逾期天数DPD(days past due):已逾契约书约定缴款日的延滞天数,贷放型产品自缴款截止日(通常为次一关帐日)后第一天开始算。


逾期期数bucket:也叫逾期月数,逾期一期为M1,2期M2。缴款截止日与次一关帐日之间称为M0。


逾期阶段stage:分为前期、中期、后期和转呆账。一般将M1(1-29)列为前期,M2~M3(30~89)列为中期、M4(90+)以上列为后期,若已转呆账者则列入转呆账。


即期指标(coincidental):计算延滞率时常用的两种方法之一,以当期各bucket延滞金额÷应收账款(AR)。


递延指标(lagged):计算延滞率时常用的两种方法之一,延滞金额÷上月应收账款。若单纯想了解各月资产质量结构,可使用coindental,但若想精准溯及逾放源头的话,建议采用lagged。


月底结算(month end):month end报表主要在表达各月月底结算数据,适用于消费金融所有产品。


期末结算结算(cycle end):cycle end为信用卡特有的结算方式。账务及催收单位皆以cycle为作业周期。




2、重要风险指标




延滞率(delinquent%):计算可分为coincidental和lagged两种方式,除了各bucket,尚会观察特定bucket以上的延滞率。如M2+lagged%及M4+lagged等指标。如M2+lagged,坟墓为两个月前应收账款,分子为本月M2(含以上)伤胃转呆账的逾期金额。M1落入M2以上可确认为物理交款或蓄意拖欠。


不良率(bad%):bad定义除了逾期户外,可能还饱含各式债务协议及高风险控管户等。转呆账率(WO%):为write-off%的简写,当月转呆账金额÷逾期开始月的应收账款。经过年化之后,月转呆账率转换为年损失率。


转呆账率(WO%):为write-off%的简写,当月转呆账金额÷逾期开始月的应收账款。经过年化之后,月转呆账率转换为年损失率。


净损失率(NCL):为net credit loss的简写,当期转呆账金额减当期呆账回收,亦即为净损概念。


通常NCL%与WO%一并列示。NCL的计算方式为:净损金额÷逾期开始月的应收账款,通常也以年化形态为主。


累计WO%主要目的为观察期满客户的累积损失率,计算样本为已届满总期数后的N期客户,计算公式为:分母案件第1~(K+N)期的转呆账总金额/已满(K+N)期案件的初贷总金额。K表示为总期数,N表示转呆账所需期数。最后1期应缴金额若延滞,经过N个月后才会转为呆账。转换为年化后才较易解读。可精确计算该产品整个生命周期结束后的实际损失率。但在中长期贷放产品中较少使用。


审核金额/件数:检视征审人员的作业绩效及工作压力。


核准金额/件数:检视征审尺度的重要观测值之一,常配合核准率、拨贷率和延滞率等指标一起进行综合判断。


拨贷金额/件数:多寡直接影响应收帐水平。


金额核准率/件数核准率:常见的核准率计算方式有两种,第一种的分母为当月进件量、分子为当月核准量。另一种方式为:当月核准件加拒绝件/当月核准量。


违例核准率(deviation%):计算方式为:(违例核准案件数)÷(核准+拒绝案件数),特例核准一般限定在总审核量的10%~20%。


拨贷率:核准率×拨贷率。


各类占率:泛指各种维度下的户数、进件、拨款、余额等占有率。常常与核准率及延滞率搭配使用。


负债比(debit burden ratio,DBR):泛测试客户还款压力的常用指标,总无担保债务归户后的总余额(包括信用卡、现金卡及信用贷款)÷月收入,不宜超过22倍。


月负比:另一种衡量还款压力的指标:(推估每月各项贷款月付额+最低生活费)÷月收入


贷后N月的delinquent%:将其中几个重要观测点的数字取出(如贷后6个月及12个月的delinquent%)置于综合分析报表中。在delinquent%的选择上,一般建议采用“M2+lagged%”,若遇延滞反映较慢的产品,则定为“M1+lagged%”


平均额度:主要在观察不同产品及群组间额度的差异


风险等级(risk grade):早期多位rule base,今年由于评分模型普及,越来越多银行采用信用评分来划分客户风险等级score base。


恶意延滞率(non-starter%):原始定义为“贷后从未缴款客户”,主要目的为找出恶性欺诈的案件。


授权核准率(authorization):原信用卡特有的业务,信用卡交易皆须通过授权系统或授权人员的检核才能成立。为维护交易顺畅,授权和准率不宜过低。


命中率(hit%):用于信用卡的中途授信及早期预警报表,所谓命中率意指控管后一定期间内客户发生延滞的几率。命中率过低可能表示浮滥或风险判断方向有误。


可用余额(open to buy,OTB):常与命中率指标一同出现,计算方式为先找出证实控管命中的客户,再会整这些客户遭控管时的信用卡可用余额,此数字可视为银行因控管而减少的损失。


诈欺损失率:计算方式为:诈欺损失金额除以签账金额,功能为观察信用卡签账金额中,发生伪冒诈骗状况并造成损失的比率。


递延率(flow through%):计催收单位最常使用的绩效指标,观察前期逾期金额经过催收之后,仍未缴款而于次期继续落入下一bucket的几率。有四种计算方式:




累计递延率:计算方式为特定区间各bucket的flow through%相乘。


实收金额:催收人员实际收回的金额


呆账回收率:根据计算的时间范围,呆账回收率可分为以下几个类别:





此文由Madwoman Trista编辑整理,转载请注明来源。

]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-07-08 20:07:56
1149 信贷业务:常用风险指标及分析手法
1、基本名词概念




逾期天数DPD(days past due):已逾契约书约定缴款日的延滞天数,贷放型产品自缴款截止日(通常为次一关帐日)后第一天开始算。


逾期期数bucket:也叫逾期月数,逾期一期为M1,2期M2。缴款截止日与次一关帐日之间称为M0。


逾期阶段stage:分为前期、中期、后期和转呆账。一般将M1(1-29)列为前期,M2~M3(30~89)列为中期、M4(90+)以上列为后期,若已转呆账者则列入转呆账。


即期指标(coincidental):计算延滞率时常用的两种方法之一,以当期各bucket延滞金额÷应收账款(AR)。


递延指标(lagged):计算延滞率时常用的两种方法之一,延滞金额÷上月应收账款。若单纯想了解各月资产质量结构,可使用coindental,但若想精准溯及逾放源头的话,建议采用lagged。


月底结算(month end):month end报表主要在表达各月月底结算数据,适用于消费金融所有产品。


期末结算结算(cycle end):cycle end为信用卡特有的结算方式。账务及催收单位皆以cycle为作业周期。




2、重要风险指标




延滞率(delinquent%):计算可分为coincidental和lagged两种方式,除了各bucket,尚会观察特定bucket以上的延滞率。如M2+lagged%及M4+lagged等指标。如M2+lagged,坟墓为两个月前应收账款,分子为本月M2(含以上)伤胃转呆账的逾期金额。M1落入M2以上可确认为物理交款或蓄意拖欠。


不良率(bad%):bad定义除了逾期户外,可能还饱含各式债务协议及高风险控管户等。转呆账率(WO%):为write-off%的简写,当月转呆账金额÷逾期开始月的应收账款。经过年化之后,月转呆账率转换为年损失率。


转呆账率(WO%):为write-off%的简写,当月转呆账金额÷逾期开始月的应收账款。经过年化之后,月转呆账率转换为年损失率。


净损失率(NCL):为net credit loss的简写,当期转呆账金额减当期呆账回收,亦即为净损概念。


通常NCL%与WO%一并列示。NCL的计算方式为:净损金额÷逾期开始月的应收账款,通常也以年化形态为主。


累计WO%主要目的为观察期满客户的累积损失率,计算样本为已届满总期数后的N期客户,计算公式为:分母案件第1~(K+N)期的转呆账总金额/已满(K+N)期案件的初贷总金额。K表示为总期数,N表示转呆账所需期数。最后1期应缴金额若延滞,经过N个月后才会转为呆账。转换为年化后才较易解读。可精确计算该产品整个生命周期结束后的实际损失率。但在中长期贷放产品中较少使用。


审核金额/件数:检视征审人员的作业绩效及工作压力。


核准金额/件数:检视征审尺度的重要观测值之一,常配合核准率、拨贷率和延滞率等指标一起进行综合判断。


拨贷金额/件数:多寡直接影响应收帐水平。


金额核准率/件数核准率:常见的核准率计算方式有两种,第一种的分母为当月进件量、分子为当月核准量。另一种方式为:当月核准件加拒绝件/当月核准量。


违例核准率(deviation%):计算方式为:(违例核准案件数)÷(核准+拒绝案件数),特例核准一般限定在总审核量的10%~20%。


拨贷率:核准率×拨贷率。


各类占率:泛指各种维度下的户数、进件、拨款、余额等占有率。常常与核准率及延滞率搭配使用。


负债比(debit burden ratio,DBR):泛测试客户还款压力的常用指标,总无担保债务归户后的总余额(包括信用卡、现金卡及信用贷款)÷月收入,不宜超过22倍。


月负比:另一种衡量还款压力的指标:(推估每月各项贷款月付额+最低生活费)÷月收入


贷后N月的delinquent%:将其中几个重要观测点的数字取出(如贷后6个月及12个月的delinquent%)置于综合分析报表中。在delinquent%的选择上,一般建议采用“M2+lagged%”,若遇延滞反映较慢的产品,则定为“M1+lagged%”


平均额度:主要在观察不同产品及群组间额度的差异


风险等级(risk grade):早期多位rule base,今年由于评分模型普及,越来越多银行采用信用评分来划分客户风险等级score base。


恶意延滞率(non-starter%):原始定义为“贷后从未缴款客户”,主要目的为找出恶性欺诈的案件。


授权核准率(authorization):原信用卡特有的业务,信用卡交易皆须通过授权系统或授权人员的检核才能成立。为维护交易顺畅,授权和准率不宜过低。


命中率(hit%):用于信用卡的中途授信及早期预警报表,所谓命中率意指控管后一定期间内客户发生延滞的几率。命中率过低可能表示浮滥或风险判断方向有误。


可用余额(open to buy,OTB):常与命中率指标一同出现,计算方式为先找出证实控管命中的客户,再会整这些客户遭控管时的信用卡可用余额,此数字可视为银行因控管而减少的损失。


诈欺损失率:计算方式为:诈欺损失金额除以签账金额,功能为观察信用卡签账金额中,发生伪冒诈骗状况并造成损失的比率。


递延率(flow through%):计催收单位最常使用的绩效指标,观察前期逾期金额经过催收之后,仍未缴款而于次期继续落入下一bucket的几率。有四种计算方式:




累计递延率:计算方式为特定区间各bucket的flow through%相乘。


实收金额:催收人员实际收回的金额


呆账回收率:根据计算的时间范围,呆账回收率可分为以下几个类别:





此文由Madwoman Trista编辑整理,转载请注明来源。

]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-07-07 12:07:42
1148 远程桌面报错"CredSSPencryptionoracleremediation"
远程桌面报错 "CredSSP encryption oracle remediation"

由于客户端或服务器端有一方 没打补丁,导致另一方拒绝 和他建立远程桌面连接

可以通过策略或改注册表 来绕过这个报错

C:WINDOWSsystem32>REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
The operation completed successfully.

测试OK

=====转============
https://support.microsoft.com/en-us/help/4295591/credssp-encryption-oracle-remediation-error-when-to-rdp-to-azure-vm

]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-06-10 10:06:04
1147 Windows 10 RDP CredSSP Encryption Oracle Remediation Error Fix

An authentication error has occurred.

The function requested is not supported

 

This could be due to CredSSP encryption oracle remediation.

For more information, see https://go.microsoft.com/fwlink/?linkid=866660

 

解决方案:

 

Win + R,输入gpedit.msc,参考截图进行操作



For those of you who may have recently installed security updates on Windows 10 workstations in the past few days, you may notice that you receive a peculiar error when trying to establish a remote desktop connection to a server that worked prior to installing the updates. The initial March 13, 2018, release updates the CredSSP authentication protocol and the Remote Desktop clients for all affected platforms. The CVE-2018-0886 consists of installing the update on all eligible client and server operating systems and then using Group Policy or registry settings to configure the options on both clients and servers. Let’s take a look at Windows 10 RDP CredSSP encryption oracle remediation error fix.

Windows 10 RDP CredSSP Encryption Oracle Remediation Error Fix

Just a couple of days ago, the cumulative updates were released below for Windows 10 and Server 2016, etc.  These cumulative updates include the fix for the CredSSP encryption vulnerability.

May 8, 2018 – KB4103721 (OS Build 1803)
May 8, 2018 – KB4103727 (OS Build 1709)
May 8, 2018 – KB4103731 (OS Build 1703)
May 8, 2018 – KB4103723 (OS Build 1609 & Server 2016)

Once you have installed the patch on a “vulnerable” workstation and attempt to connect to an unpatched server, you will see the following error message that happens after you type in your password to authenticate to the RDP session.

CredSSP-authentication-error-after-installing-May-8-2018-patch-Windows-10 Windows 10 RDP CredSSP Encryption Oracle Remediation Error Fix

CredSSP authentication error after installing May 8 2018 patch Windows 10

There is a local policy setting that is added with the installed security updates.  You can find this at Computer Configuration >> Administrative Templates >> System >> Credentials Delegation >> Encryption Oracle Remediation.  By default this is set to Not configured.

Windows-10-RDP-CredSSP-encryption-oracle-remediation-error-Fix Windows 10 RDP CredSSP Encryption Oracle Remediation Error Fix

Windows 10 RDP CredSSP encryption oracle remediation error Fix

To Fix the issue as a workaround, set the policy to Enabled and set the Protection Level to Vulnerable.  ***Note*** – This is not recommended by Microsoft, as making sure both the client and server is patched is best practice.  However, setting the policy to Vulnerable allows your workstation to now connect to the remote desktop session that was previously blocked by the mitigation.

Settings-contained-in-the-Encryption-Oracle-Remediation-Fix Windows 10 RDP CredSSP Encryption Oracle Remediation Error Fix

Settings contained in the Encryption Oracle Remediation Fix

CredSSP Encryption Oracle Remediation Policy Settings

There are three settings contained in the policy setting that can be enabled.

Force Updated Clients: Client applications which use CredSSP will not be able to fall back to the insecure versions and services using CredSSP will not accept unpatched clients. Note: this setting should not be deployed until all remote hosts support the newest version.

Mitigated: Client applications which use CredSSP will not be able to fall back to the insecure version but services using CredSSP will accept unpatched clients. See the link below for important information about the risk posed by remaining unpatched clients.

Vulnerable: Client applications which use CredSSP will expose the remote servers to attacks by supporting fall back to the insecure versions and services using CredSSP will accept unpatched clients.

]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-06-10 09:06:06
1146 创业公司该不该开会?怎样开? 好的会议是能产出成果且每个人能按计划执行,而糟糕的会议是在浪费每个人的时间。一个典型糟糕的会议特征是,有人在开会期间处理邮件、微信、玩手机。

有人说,创业公司开会是在浪费时间,如果每天的会议都是 CEO 开动员大会,那显然是浪费时间的。这篇文章说的开会,并不是领导一个人在台上「我简单讲三点」的一对多讲话,而是汇集集体智慧的会议,比如头脑风暴,比如讨论执行方案、讨论产品功能、市场推广等。这种会议是一种高效的推进项目手段,但并不是每个公司、每个会议组织者都知道如何把会议的效率最大化。包括上了规模的上市公司。

博客

不久前,我参与到一家上市公司的讨论会,会议一共有 5 方,这家公司的两个部门和 3 个外部合作伙伴,这个会议从中午 1 点半开始,一直开到晚上 11 点,长达 9 个小时。虽然组织方提前发了会议议程,并安排了每 2 个小时 15 分钟休息时间,但我依然认为这是一次效率极低的会议。有几个核心原因:

  1. 会议原计划开到下午 5 点,但光在调试投影仪这件事上,就花了 20 分钟。
  2. 讨论过程往往只涉及两方或三方,其它非直接参与方的时间被浪费。
  3. 会议时间过长,参与者极容易走神,经常一句话要说两遍,浪费参与者时间。一般来说,人们集中精神开会 2 小时已经很疲惫了。
  4. 虎头蛇尾。即使讨论得异常激烈,一直没法争论出结果,但由于会议时间太长消耗了各方的精力,最后往往是双方妥协回到最初的形态,也就是「保持不变」,但这不应该是开会的目的。
  5. 会议主持人没有控制好讨论的节奏和时间。

比较庆幸的是,因为下午 5 点约了其他人,我直接离开了会议室。我没有因此觉得错过了什么,因为接下来几个小时的讨论与我没有直接关系,我的时间不应该被浪费在会议室里。

关于如何高效开会,你在网上可以找到上百篇不同的文章和知乎问答,大多数都是从自身公司出发,讲述自己公司是如何高效开会的。这篇文章,我将结合我参与过的大小会议、我看过的文章和书,以及我和身边的朋友参与过的管理培训,试图讲述一种适合在不同规模公司开会的基本方法论,也就是指南。

使用说明

作为一份指南,这篇文章的长度很长,但我相信阅读这篇文章的人多多少少都组织、主持过团队开会,你只需要细读那些你还未有结构化思路的部分,其它部分速读并不会影响你的吸收。

指南包含的细节关键点很多,但不同的公司、不同的会议,可能有些步骤可以跳过,有些细节可以忽略。请根据自身业务,删减出一份更适合你的操作步骤。

建议你用 OmniFocus 或其它 todolist 工具,比如我之前创业的「轻单」,制作你的操作步骤。

会前准备

开会前,作为会议组织者,需要做一些准备工作。

确定理想结果

开会的目的是什么?我们的产品遇到了什么样的问题,需要通过开会来解决?在开会前,我们需要对会议的结果做合适的预期,以下是一些可以参考的关键点:

  1. 你期待在会议上达成什么样的决策或共识?
  2. 这些决策和共识对公司内外有什么良性影响?
  3. 如果无法形成决策或共识,会出现什么问题?问题有多严重?
  4. 有哪些原因(人或技术难度)可能会导致会议无法达成理想的结果?
  5. 如何定义会议是成功的(比如有执行方案产出,或每个人都达成了共识)?

判断开会的必要性

当我们自我解答上述疑问后,我们紧接着不是召集所有人开会,而是判断开会的必要性。

比如,这次会议的目的是要让所有人清晰了解产品下一版本的功能,这时我们需要思考,是否有必要开会。发邮件能不能达到目的?微信发群公告能不能达到目的?公司内部论坛发置顶帖能不能达到目的?如果能,那就没有开会的必要,因为每个人的时间都很宝贵,我们不应该把时间浪费在「听会」这件事上。

又比如,有些创业公司习惯早上开晨会,让每个人说前一天的工作、今天准备做什么,这样的晨会是否真的有必要?是否可以通过使用 Trello 这样的协作工具完成?对于互联网公司来讲,很多人习惯在家里办公或半夜写代码,晨会是否有必要强制召开?是否有其它工具可以替代晨会?

关于会议的必要性,有以下几个判断原则:

  1. 时间紧迫,必须在极短时间让所有人的信息同步。
  2. 必须集中相关人员,才能解决刻不容缓的问题。
  3. 必须让相关部门(人员)面对面达成共识,事情才能推进。
  4. 邮件、微信沟通效率过低,需要通过面对面的头脑风暴讨论出可行方案。
  5. 必须面对面消除部门之间的分歧,确保项目能顺利开展。

只邀请合适的人参会

每个人的时间都很宝贵,尤其是在创业公司里,时间是按秒计算的。一个更好的做法是在开会前,与有可能「捣乱」的人私下交流。这样的人其实是没有必要被召集到会议室中的。

在大多数情况下,这些人不需要被邀请到会议室:

  1. 他只需要知道会议的结果或执行方案,一封邮件对他来说更有用。
  2. 同一部门已经有其他人参与且其他人可以代表该部门发表意见。
  3. 他的作用是为会议提供必要信息(比如数据),但不需要参与讨论。
  4. 他仅在少数议题上发挥作用,给他单独开个小会即可。

所以,相应地,我们邀请参会的人,应该是能在大多数议题上参与,且能发表意见和讨论的,如果一个人只是聆听,他压根不应该被叫到会议上当中,一方面他会在会议中做自己的事,其他人会觉得尴尬,另一方面,这也是在浪费他的时间。另外,受到会议结果直接影响的人、参与制定执行方案的人也应该被邀请到会议当中。

我的一个朋友,他曾经在一家很喜欢开会的公司工作,他很无奈地告诉我,经常有一些会议,本来没有邀请他,但到了会议召开过程中,负责人突然把他叫到会议室。他为此感到很不爽,一方面他没有做任何会前准备,其次他没有与其他参与者同步信息,他提出的意见可能会很别扭,又或者主持人还需要花很长的时间把其他人晾在一边给他专门做信息同步,第三,他的时间也很宝贵,可能他正在专注做另一个工作,但却被拉到会议室里了。

所以,作为会议主持人,一定要在会议前就 100% 确定参与者名单,并提前通知他们。请尊重每个人的时间,并不是你的项目才是最紧急重要的

会前信息同步与任务分发

一个会议的时间不宜过长,我的体会是,超过 2 小时的会议就变得低效了。低效的原因很多,其中一个很关键的原因是与会者没有做会前准备,导致在开会期间大家还纷纷地打开电脑找资料,主持人还需要花大量时间做信息同步。

这些工作,应该在会议前做好。

在开会前,应该给每个参会者发一封邮件,告诉所有人:

  1. 我们遇到了什么问题,为什么要开会?
  2. 开会的理想结果是什么?
  3. 大家在开会前需要了解哪些基本信息?
  4. 每个人在开会前需要分别准备哪些材料?
  5. 大家有哪些初步想法和需求?

同时,你还应该与核心的参会者在会前私下交谈:

  1. 他是否需要了解额外的信息,而这些信息不方便同步给所有人。
  2. 了解他是否有特殊的需求。
  3. 一对一明确每个人各自需要准备的材料,而不是仅仅群发邮件。

这与项目管理的原则是一样的,除了要让所有人信息同步,还应点对点确保每个人都做好会前准备。

制定议程和传达

当我们已经完成的信息同步和相关需求的收集,结合会议的目标,这时我们就可以制定会议议程了。制定议程除了需要明确每个环节需要讨论的主题、时间和负责人之外,还应考虑议程的顺序,我在考虑议程顺序时,一般遵循 2 个原则:

  1. 循序渐进、逻辑相关。让讨论的问题一步一步深化。
  2. 参与者人数多的议题放在前面,随后递减,让个人不需要参与全程讨论的人可以回去工作。

制定完议程,我们可以给所有与会者发一封邮件,让大家做补充,有时我们一个大脑制定的议程不一定是足够完善的。

私下搞定那些潜在的「捣乱者」

开会过程中可能会出现一些「捣乱者」,他们并不是故意捣蛋,但会延长开会的时间以及让其他参会者感觉进入到垃圾时间。

比如,本次开会的目的是确定下一个版本的产品开发进度,当大家在纷纷讨论进度表的时候,有一个人突然跳起来说,我觉得这个版本的功能不对,不应该这样做,现在讨论进度没有意义,我们应该回到功能讨论。

这时,作为会议主持人你有两个选择,打断他的发言,继续讨论进度,他可能会因此不爽,从而消极参会或离场;让他发言,其他人感到不爽,因为进度已经讨论了一半。

无论是哪种选择,对会议的影响都是消极的,一个更好的做法是在开会前,与有可能「捣乱」的人私下交流,跟他们 100% 明确,产品功能已经锁定,会议是讨论进度的,不会做功能变更;公司已经确认了这个方向,不会做改变,我们应该相信公司的决策。

怎样找到这些可能会「捣乱」的人?一方面看性格,另一方面可以从日程的工作中观察,总能发现一些蛛丝马迹。

提前 10 分钟把会议室的设备准备好

别在开会过程中寻找 VGA 转接口,别在会议开始时发现自己搞不定投影仪。作为会议主持人,应该在开会前就预订好会议室,并在会议室里准备好开会所需要的各种道具、调试好所有的设备。

理由很简单,开会需要高效,别在本来只需要付出一个人 10 分钟时间的事情上,浪费所有人 10 分钟时间

开会技巧

好了,现在我们进入到开会的流程。

沟通基本原则

一个好的会议主持人,需要有良好的沟通技巧,在很多关于如何沟通、如何好好说话的书和文章里,都提到这些基本的沟通互动原则:

  1. 维护自尊,加强自信
  2. 仔细聆听,善意回应
  3. 寻求帮助,鼓励参与
  4. 分享观点,坦诚交流
  5. 给予支持,鼓励承担

这些原则不是我创立的,我也相信,大多数人在开会和沟通过程中,或多或少都用过这些原则。简单说一下这 5 个原则在开会这件事上的作用(假设你是会议主持人)。

维护自尊是指当参会者表现出消极或缺乏信心时,你应当鼓励他们,让他们树立起信心,从而能积极参与到后续的讨论当中。很多时候,称赞是有必要的。比如当一个新人胆颤心惊发表了一个观点后,虽然他的意见可能很一般,但为了鼓励他,你可以说,「这个想法不错,我们先记录下来」。

仔细聆听和善意回应,是让会议能正常进行的基本原则。没有人喜欢自己的发言被其他人忽略,即使他们是带着情绪发言的。作为主持人,当你遇到有人很愤怒的发言时,你可以仔细聆听完后,安抚对方的情绪,并重新用自己的语言,温和地复述,这样,其他人会更容易接受。

寻求帮助是鼓励参与的好方法。有些人开会开着开着可能就不再发言了,但这并不是你想要的结果,你可以通过向对方提问的方式,让他重新参与。比如,当上一个人已经发言完毕后,你可以问他,「刚才 XX 的方案你觉得如何」,事实上,这不是一种好的鼓励参与方式,因为对方可以消极地回答我觉得挺好的。这时,你可以换一种寻求帮助的方式,「刚才 XX 的方案中提到了 YY,YY 是你所负责的项目,你能给 XX 提供怎样的支持」,这样,他就可能没法消极应对了。

情人之间要坦诚相对,开会时也应该一样。如果你对别人坦诚,别人也极有可能对你坦诚,这样开会才能找到根本问题,从根上解决。如果每一个都遮遮掩掩,说一半不说一半,生怕其它部门的人抢了自己的功劳,对公司来讲没有益处。作为会议主持人,应该先从自己做起,自己先真实地表达看法,坦诚地说出观点和信息,然后鼓励其他人坦诚交流。

给予支持,鼓励承担是指,作为会议主持人,我们可能不是项目的负责人,又或者项目会被拆分为很多小项目,每个小项目都应该有相应的负责人。我们应该鼓励每个人都成为项目的一个小的负责人,这样大家才能更有责任感地参与,但有时有些人可能怕事不敢承担,这时就需要给予适当的鼓励了。比如,你可以说,「XX,这部分的工作你最熟悉,由你来承担,如果在资源上有问题,随时跟我沟通,我来协调给你调派」。

开始开会

熟悉了一些沟通原则后,让我们来正式开会。

开会的第一件事,是召集人也就是主持人,开启本次会议。虽然你已经给大家发过邮件,说了本次会议的目的和理想目标,但在正式进入讨论前,依然需要和所有人强调。你需要强调的包括:

  1. 会议的理想结果。
  2. 达成理想结果的意义:对公司、对团队、对每一个人、对客户、市场的意义和好处。
  3. 如果不能达成理想结果,会有什么坏处和严重后果。
  4. 不在本次开会中讨论的内容。
  5. 会议议程。

第四点尤为重要,大家的时间都很宝贵,不要在会议上讨论超出议程的事项,尤其在大家对超出议程的事项没有做任何准备的时候。

说明问题

接下来,我们按照会议议程一个问题一个问题地讨论,在讨论方案之前,应该把你在会前收集到的信息、问题与所有人同步。

这个过程最好不要自己发言,而是鼓励对应的负责人发言。因为在会前你已经让相应的负责人准备开会所需要的材料了,这时你让他们分别讲述从他们角度看到的数据、事实,以及遇到的问题。

当相应的负责人说明完问题后,鼓励大家参与到讨论当中,讨论应该就问题本身展开,每个人因为立场的不同,会发表不同的看法,又或者其它部门的人能帮助发言人发现问题的根本,这个讨论环节应该是开放和平等的。

当问题被剖析得足够充分,我们将进入到第三步,也就是「形成多个方案」。

形成多个方案

问题被剖析之后,当然要寻找解决问题的办法。

这个时候,你可以询问,是否有人有解决方案,如果有,让其提出,并针对方案进行讨论,让所有人指出方案可能存在的问题以及是否有更好的解决方案。

如果没有,作为会议主持人,你应当自己提出一个方案,你提出的方案不一定是最优的,你的目的是要激发大家的讨论,有时候你甚至可以提出一个你自己都认为不可行的方案,引起大家的讨论

注意在征求参与人员方案时,尽量使用开放式提问,而不是「是或否」。比如,当 XX 提出了一个方案后,你可以点名提问 YY,一种更好的提问方式不是「你对 XX 的方案有没有想法」,而是「你对 XX 的方案有什么顾虑和想法」或者「 XX 的方案有些不能解决的问题,对于这个问题,YY 你觉得应该怎样解决」。

整个讨论结束后,一般来说,会形成多个解决方案。

达成共识

在第四步中,我们需要从第三步的多个方案中,选出最优的方案,并达成执行的具体方案。

最优的方案应该是最接近理想结果的方案,而不是少数人坚持的方案,也不是投票表决的方案。作为主持人,你应当时刻记住会议的理想结果,从结果出发,选择最合适的方案,并让所有人参与到方案的调整过程。

当方案确定下来,接下来就要讨论具体的执行细节了。这些是可能被讨论到的:

  1. 每个事项的负责人与分工
  2. 哪些部门参与,有哪些额外的资源需要公司领导协调
  3. 完成目标的最终时间点
  4. 关键事项的检查点(里程碑)

至此,一个议程就结束了,后续的议程可以按照这 3 个步骤重复进行。

会议总结

当所有议程讨论完毕后,总结和感谢是很有必要的。

在会议结束前,有 7 点是需要做的:

  1. 回顾会议上做出的所有决策和共识。
  2. 回顾所有确定的执行方案。
  3. 让方案的事项负责人复述他负责的事项和执行时间点。
  4. 定义项目紧接下来的沟通方式,比如每天晨会、使用 Trello、微信沟通等。
  5. 建议不同部门和个人之间,私下自行讨论执行的细节。
  6. 再次回顾项目的目标,鼓励所有参会者。
  7. 感谢所有人付出时间来参会,并表达对项目的信心。

至此,线下开会过程已经结束了,但整个开会的过程还未结束,有两件事,依然需要去做。

会后事项

会议室的讨论结束,并不意味着开会的结束,往往,这只是项目的开始。为了更好地推进项目,也确保每个人明确自己的职责,有两件事是必须做的。

会议记录

会议上应当安排一个人做会议记录,并在会后将记录发给所有人。记录人最好不是主持人,因为主持人需要做的是沟通和推进工作,做记录会分散注意力。

一个好的会议记录是这样的:

  1. 开会前,用熟练的办公软件建立了会议记录的基本格式,开会时,直接录入,而不用去理会排版、格式、错别字的问题。
  2. 文字记录的同时,开启录音记录。我一般使用 Evernote ,这样我的录音可以和会议记录存在同一个文件里。
  3. 会议结束后,记录者重新整理出一份结构化的记录,发给所有人。所谓结构化,就是每个人都能清晰且快速地回顾会议、明确责任。

除了作为备忘录,会议记录的必要性还在于,它可以用来追究责任、避免路线走偏。

后续跟进

因为会议主持人往往是项目负责人,会议结束后,你还需要时刻跟进进度,尤其是会议结束后的第一天,你需要确保每个人都按照前一天定下的计划在开展工作,这个时候,一个项目管理软件对你来说可能是必要的。

同时,你还需要对下一次开会做出计划,在达成什么里程碑的时候,或遇到什么样问题的时候,召开下一次会议。

特殊情况的处理

如果会议按照前面的流程推进,当然是最好不过了,但往往开会时会遇到一些困难情况,比如:

  1. 参会人员之间由讨论变成冲突,甚至有可能演变成肢体冲突
  2. 无论如何讨论,个别人员一直坚持己见,并尝试主导会议
  3. 有些人的个人习惯可能会降低会议的质量,比如一直在玩手机
  4. 有人中途在会议室电话,导致会议不得不被中断,等待他结束通话
  5. 当方案达成时,一些人表现出异常消极,甚至起了辞职的念头
  6. 有人的发言过长,其他人已经显得不耐烦
  7. 在某些问题上,多方一直僵持,无法讨论出结果

对于这些问题,有几个干预建议:

强调会议议程和理想结果

当与会人员由讨论变成冲突,我们可以再次强调会议的理想结果,把他们从两个人的冲突中抽回来,回到讨论当中。

鼓励轮流发言

轮流发言是打断独占发言的好方法,当一个人喋喋不休,其他人已经不耐烦时,可以用一种合适的沟通方式打断他的发言。比如,你可以说,「不好意思我打断一下,我们今天会议的时间只有 1 个小时,我们必须完成整个议程的讨论,我们先听听 XX 的意见,完了有时间你再继续说你的想法」。

用总结的方式打断独占发言

用总结的方式打断独占发言是一种更好的方法,比如,还是前面的情况,你可以说,「我听懂了,你的想法是 XXXXX,其他人有什么意见么?」

强调开会规则

当发现有人一直打断其他人发言,或在过程中玩手机、接电话时,你可以强调会议规则,要求每个人发言过程中不允许其他人中断,要求大家把手机盖起来,如果要接电话请离开会议室等。

休息时间

休息时间可以用来解决两个问题,如果个别人员一直坚持己见阻碍会议正常进行,你可以在休息时间与他私下交谈,交谈方式可以参考前面提到的沟通技巧,以确保会议能够继续顺利进行。

另一个可以被解决的问题是个别人员的消极回应,我们可以私下站在对方的角度,讲述方案看起来对他的影响是负面的,但如果方案做成了,其实对他有哪些好处,从而建立他的信心。

推后解决问题

如果有些问题实在无法在会议上解决,不妨考虑推后解决。往往在大家冷静之后,事情会有所进展,要么,双方找到更好的解决办法,要么,其中一方消气之后,稍作妥协。

没有必要就无法解决的问题,在会议上浪费所有人的时间。

总结

开会不一定会浪费时间,做好充分准备,并善用沟通技巧的会,能快速让参与成员达成共识、形成方案。

以上,是我开过那么多会,以及我在 Evernote 里所有关于高效开会和沟通的内容整理,希望对大家有用。如果你是创业公司的一员,除了这篇文章,这篇《创业公司的员工都有哪些特点?》的文章可能也适合你。

]]>
taoCMS-基于php+sqlite最小巧的CMS 2018-05-26 21:05:01