<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>潘锦的空间 &#187; 机制建设</title>
	<atom:link href="https://www.phppan.com/tag/%e6%9c%ba%e5%88%b6%e5%bb%ba%e8%ae%be/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.phppan.com</link>
	<description>SaaS SaaS架构 团队管理 技术管理 技术架构 PHP 内核 扩展 项目管理</description>
	<lastBuildDate>Sun, 12 Apr 2026 03:47:23 +0000</lastBuildDate>
	<language>zh-CN</language>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=3.9.40</generator>
	<item>
		<title>技术管理必备之沟通机制</title>
		<link>https://www.phppan.com/2022/07/communication/</link>
		<comments>https://www.phppan.com/2022/07/communication/#comments</comments>
		<pubDate>Sat, 23 Jul 2022 11:49:23 +0000</pubDate>
		<dc:creator><![CDATA[admin]]></dc:creator>
				<category><![CDATA[架构和远方]]></category>
		<category><![CDATA[团队管理]]></category>
		<category><![CDATA[技术管理]]></category>
		<category><![CDATA[机制建设]]></category>
		<category><![CDATA[沟通机制]]></category>

		<guid isPermaLink="false">http://www.phppan.com/?p=2060</guid>
		<description><![CDATA[在《汉语词典》中，沟通有如下定义： 沟通本指开沟以使两水相通。后用以泛指使两方相通连，也指疏通彼此的意见。 沟 [&#8230;]]]></description>
				<content:encoded><![CDATA[<div class="Post-RichTextContainer" style="color: #121212;">
<div class="css-1yuhvjn">
<div class="RichText ztext Post-RichText css-9scqi7">
<p data-first-child="" data-pid="TAgCb4gA">在《汉语词典》中，沟通有如下定义：</p>
<blockquote style="color: #646464;" data-pid="csfQZLZk"><p>沟通本指开沟以使两水相通。后用以泛指使两方相通连，也指疏通彼此的意见。</p></blockquote>
<p data-pid="p3oY4PBS">沟通是通过一定的载体将思想、信息和情感在人与人之间进行传递或交换的过程，群体间的沟通最终也会落到人身上。 著名组织管理学家巴纳德认为「沟通是把一个组织中的成员联系在一起，以实现共同目标的手段」，没有沟通，就没有管理。</p>
<p data-pid="5yBPTWV3">沟通不良几乎是每个企业都存在的问题，企业的机构越是复杂，层级越多，其沟通就越发困难。 一线的许多意见在上传过程中，被层层过滤掉了；高层的决策传达，在落到一线同学时可能表述完全不一样了。 沟通在组织中的主要作用是上传下达，相互协调，以维系组织存在，保持和加强组织纽带，创造和维护组织文化，提高组织效率。</p>
<h2 style="font-style: inherit;">1 沟通的基本组成</h2>
<p data-pid="9deW00Gt">沟通由四个要素组成：沟通目的、沟通对象、沟通内容和沟通方式。这四个要素是相辅相成的关系，缺一不可。这四个要素回答了四个问题，为什么要沟通；和谁沟通；沟通什么；怎么沟通。</p>
<ul>
<li data-pid="kKmulLLk">沟通目的：是指沟通开始前需要弄清楚沟通的目标是什么，任何沟通都需要有一个目标，如果没有目标，也就不需要沟通了。</li>
<li data-pid="ar29Y1UO">沟通对象：明确需要沟通的对象是谁，背景，身份，角色等等，在《官场现形记》第 38 回：“第二要嘴巴会说，见人说人话，见鬼说鬼话，见了官场说官场上的话，见了生意人说生意场中的话。”，这也是明确沟通对象，根据沟通对象确认后续的沟通方式。</li>
<li data-pid="8GNBLQeu">沟通内容：是指在沟通中出现的内容，包括思想、信息和情感，在沟通之前沟通的内容需要做充分的准备，如果沟通内容准备不足，可能会导致沟通的失败。</li>
<li data-pid="Ji5QtEDh">沟通方式：沟通方式是指我们沟通内容的传递方式或者说渠道，常见的有当面聊天、邮件、会议、刊物、报告、演讲等等。</li>
</ul>
<p data-pid="wfots9NS">沟通从种类上来分，可以分为语言沟通或非语言沟通、口头沟通和书面沟通、正式沟通和非正式沟通，向上沟通、向下沟通和平级沟通等。</p>
<ul>
<li data-pid="TTOpM1Gy">语言沟通或非语言沟通是从沟通的载体来区分，语言沟通包括书面沟通和口头沟通，非语言沟通包括面部表情，身体语言等；</li>
<li data-pid="STaxOZ3p">口头沟通和书面沟通是从语言的载体来区分，口头沟通有会议、面谈、演讲、电话等，书面沟通有电子邮件、信函、刊物（电子和非电子）、报表、通讯录等传递书面文字的手段。口头沟通的特点是快速传递和反馈，但是可能传递过程中会失真，书面沟通更偏向于单向沟通、一般会缺少反馈且耗时较多。</li>
<li data-pid="fBjsEwEm">正式沟通和非正式沟通更多的是在组织层面，通过是否具有系统性和结构性来区分。正式沟通是从组织所规定的路线和程序进行信息的传递和交流，如组织间的信函、内部的文件、汇报、会议等等；非正式沟通一般是线下的一些闲聊、喝酒时的吹牛以及一些小道消息等。</li>
<li data-pid="MM-b8QJg">向上沟通、向下沟通和平级沟通，这里主要是以组织层级间沟通的对象为区分，以方向表述对象群体。向上沟通一般是指向你的老板沟通，即所谓的下情上达；向下沟通是指向你的下属沟通，即所谓的上情下达；平级沟通是指横向的沟通，如一些平级的部门负责人之间的沟通，以交接意见，互助互赢为主。</li>
</ul>
<h2 style="font-style: inherit;">2 沟通的步骤</h2>
<h2 style="font-style: inherit;">2.1 沟通准备</h2>
<p data-pid="mhEOGjVr">在管理上执行一个动作或者做某个事情需要有目的，不要做无效的管理。就沟通而言，第一是要明确沟通的目标。 结合团队战略目标，将沟通目标融入战略目标中，基于此开展沟通内容和沟通目标的准备，以减少不必要的沟通事项，降低沟通时间成本和人力成本，毕竟任何动作都会有成本。</p>
<p data-pid="v9WHlr0u">很多时候，沟通的当事人并没有非常清晰的目标，只有一个大概的逻辑，目标很模糊。在这样的情况下进行沟通，比较容易造成混乱和无效沟通。所以，技术管理者作为沟通的主体，就必须先帮助当事人确立清晰的目标</p>
<p data-pid="GgDRb2ml">在确定目标的基础上，我们需要正式就具体的沟通做好准备，一般包括：</p>
<ul>
<li data-pid="TXbKpEZE">沟通对象，了解沟通对象的个人资料，如身份，工种、学历、工作经历、所负责项目，以及一些简单的家庭情况等；</li>
<li data-pid="wRSSDECX">沟通内容，沟通的信息，需要确认这些信息的正确性和充分性，如一些好的问题，一些支撑的数据；</li>
<li data-pid="sc6Rj3Xo">沟通渠道，根据沟通的目的和内容，确定沟通的渠道，比如一些宣导的沟通，可能群发邮件就可以了，或者一些需要及时反馈，需要看到人非语言表述的沟通则需要当面聊天等。</li>
</ul>
<p data-pid="A_7-GOvv">沟通内容和沟通对象强关联，比如一线开发可能准备的沟通内容是具体的工作计划，具体的目标，对老板的沟通可能是技术方向的规划，阶段性成果以及一些管理思路等等。</p>
<p data-pid="t4Z3ZKUo">准备好沟通后下一步是执行沟通。</p>
<h2 style="font-style: inherit;">2.2 沟通过程</h2>
<p data-pid="EtwAk5Hp">沟通过程本质上是一个信息传输的过程，信息传输的模型如下所示：</p>
<figure data-size="normal"><img class="origin_image zh-lightbox-thumb lazy" src="https://pic4.zhimg.com/80/v2-5281093eaeb3af9484b7f4e8537f19c7_1440w.jpg" alt="" width="1000" data-caption="" data-size="normal" data-rawwidth="1000" data-rawheight="408" data-original="https://pic4.zhimg.com/v2-5281093eaeb3af9484b7f4e8537f19c7_r.jpg" data-actualsrc="https://pic4.zhimg.com/v2-5281093eaeb3af9484b7f4e8537f19c7_b.jpg" data-lazy-status="ok" /></figure>
<p data-pid="L2ZC4j5U">沟通过程中主体是发送者、接收者和渠道，主要操作是编码、传输和解码。</p>
<p data-pid="HlF58uRH">发送者：沟通的发起者，本次信息传输的主导者； 编码：整理信息，以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程； 渠道：信息传输的载体，常见的渠道包括：语言、电话、文档、传真、电子邮件、各种 IM 工具等； 解码：接收者对所获取的信息的理解过程； 接收者：信息接收者、信息达到的客体，可能是一个人也可能是一群人，也可能没有人。</p>
<p data-pid="wyX7g0_T">如我们想给比较多人的讲一个事情，一种性价比比较高的方式就是写文档或电子邮件发给这些人看，这个写文档/邮件，发给接收者阅读并理解整个文档的过程就是一次信息传输的过程，也就是一次沟通的过程。</p>
<p data-pid="Me80-T3T">在信息传输过程中，有较多的噪声会影响整个传输的效果，比如我们刚才说的写文档，编码的过程就是我们将想法、思想和逻辑转化成文档的过程，而每个人写文档的能力，对于问题的理解不一样，从而写出来的文档参差不齐，这里的差异就是我们编码中的一种噪声。</p>
<p data-pid="OvaEl36_">在语言沟通过程中，除了讲，还要听，做彼此的倾听者，沟通过程中随时调整沟通的方式和方向，以求达到沟而相通的目的。 从信息传输的模型来看，这里的倾听其实就是为了更好的解码，更好的接收传递过来的信息，而调整沟通的方式和方向是为了优化编码的方式，以适配对方的解码逻辑。 汉字其实很形象地表述了听的逻辑，听的繁体字写法是「聴」，拆开来看，它要求我们听的时候要用耳朵、眼睛和心来聆听，这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」，这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」， 而且是根据对方的「斤」两来决定到底听还是不听。</p>
<p data-pid="IAgxgVVa">特别说一点，技术管理者在与下属沟通过程中，需要不断地增加沟通的可能性，引导下属的想法和目标，以平等的态度，梳理逻辑，让沟通状态从混乱变为清晰，从而达到沟通的目的。</p>
<h2 style="font-style: inherit;">2.3 沟通回顾</h2>
<p data-pid="eRbp9jF9">沟通完成后，需要对沟通做一些回顾，以检验和巩固沟通的效果。沟通回顾包括两部分，沟通中问题和待办的跟进和沟通效果的检验</p>
<p data-pid="dCGB7aWh">在一次沟通过程中，可能会有一些事项需要沟通后再来确认或完成，针对这些事项需要明确具体的执行人和完成时间。 对于一个组织而言，应该要有一个统一的地方或一个系统来跟进这些任务，看是否完成或达到预期。如常见的项目管理工具或者在一些文档系统中以任务列表的方式集中起来，不定时查看。</p>
<p data-pid="1-QV5LUY">沟通回顾在整个沟通中是非常重要的一个环节，无论沟通前的准备有多么的充足，沟通中的交流有多么顺畅和精彩，没有跟进和效果的沟通就等于没有沟通。</p>
<h2 style="font-style: inherit;">2.4 常见问题</h2>
<p data-pid="8Zu_PRVC">在整个沟通过程中有一些问题我们可能会遇到比较多：</p>
<ul>
<li data-pid="sIYYaSus">没有目标，为了沟通而沟通，如一些会议，大家都在开会，但是不知道为什么要开，只是有人叫我开会了，就去了；</li>
<li data-pid="bUz9r-Og">沟通准备不足，前期只是准备了一些模棱两可的资料，这就造成了在沟通的过程中无法正确地运用资料，也无法让资料帮助沟通，比如一次会议中，会议前没有准备好会议相关的资料，会上可能大家就漫无目的的在聊了，最终也没有结论；</li>
<li data-pid="z4j7AztG">没有章法，沟通中的信息过于繁杂，沟通目标确定之后，在沟通过程中对用到的信息进行收集、筛选，与沟通主题无关的信息要尽量屏蔽；</li>
<li data-pid="cPNePG1C">不说人话，没有从接收者的角度来沟通，当沟通的主题涉及专业领域，先注意弄清楚对方的实际水平以及专业情况，不要盲目地运用太多的专业术语，以免造成沟通过程中的歧义；</li>
<li data-pid="j0Uu25oQ">沟通态度消极，沟通是双方的事情，如果有一方的态度不积极，很容易造成沟通不畅，甚至是无效沟通。除此之外，不倾听、不提问，以及一味执着于自己的观念也是另一种消极状态。</li>
</ul>
<h2 style="font-style: inherit;">3 构建正式的内部沟通机制</h2>
<p data-pid="s6iu_Ewp">在一个组织的内部沟通中，沟通双方存在着共同利益，以及一致的目标，所以只要沟通机制没有问题，就很容易达成共识。</p>
<p data-pid="1vNe7HGs">构建正式沟通机制是为了保证内部沟通在正式环境中，能够顺畅而有效地沟通。例如，内部的周会、月会、年会，以及各种内部的正规会议和讨论中，规范内部的目标、工作方案，以及合理化建议的渠道，并且有非常明确的奖罚制度。一个完善的正式沟通机制有如下好处：</p>
<ul>
<li data-pid="i8tAjGkl">建立起很好的下情上达，上情下达的沟通渠道，让内部的每一个人都知道，该如何有效地将自己的合理化建议落地；</li>
<li data-pid="zlV128E5">让每一个人都能够在内部正式的沟通中，发挥出自己的特长和优势，从而提升个人的归属感和工作热情；</li>
<li data-pid="dFOwfuB-">避免管理者无法决策，或者决策失误的产生。</li>
</ul>
<h2 style="font-style: inherit;">3.1 构建会议机制</h2>
<p data-pid="toOWVclq">在企业内，会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。 无论是大会还是小会，开会的目的都是为了通过讨论解决某个问题或做出某项决议。一个高效有序的会议，不仅能够提升工作效率，还能增强员工的参与感和创造力。</p>
<p data-pid="zKqPSMC0">开会的最佳意义在于讨论和互动。只有在你真正需要参会人员之间的互动，需要大家分享彼此的意见和知识，并最终形成一项决议的时候，才有开会的必要。</p>
<p data-pid="FaWB06Fh">以下是我们常见的几种会议类型。</p>
<h2 style="font-style: inherit;">3.1.1 管理例会</h2>
<p data-pid="1lDsP0Bw">所谓例会，都应有相对明确的主题，相对固定的参会人员，相对结构化的会议流程。 管理例会是管理者组织的由管理者及其下一级参加的会议，其主要有如下目的：</p>
<ol>
<li data-pid="XsycSudL"><span style="font-weight: 600;">固化管理正式沟通机制；</span></li>
<li data-pid="uX0Ze_Iz">上情下达，同步公司级或上级最近方向、信息和决策；</li>
<li data-pid="v5zBGHQa">增加组织成员之间的沟通交流，知道大家都在做什么；</li>
<li data-pid="CQ0xxfDr">拉齐大家的认知，确定共同的目标和行动方向，达到团队的一致性；</li>
<li data-pid="qEcB4seF">协调资源，看看有没有什么需要相互支援和相互协作的；</li>
<li data-pid="zMBFuHbu">群策群力，决策当前级别组织的大型事项；</li>
<li data-pid="eKf-7ofj"><span style="font-weight: 600;">增加组织成员的归属感和角色感。</span></li>
</ol>
<p data-pid="mmsY0bXj">管理例会可以在各级组织召开，尽量管理者和其直接下属来开，跨多级可能会出现跨级管理的问题。</p>
<p data-pid="hrBepCpU">明确了会议目的，下一步我们需要明确会议内容。会议内容由于企业的不同，组织层级的不同，团队规模的不同，沟通的内容差异较大，这里我们抽象一下，以问题的形式，列出一些常规的沟通内容。</p>
<ul>
<li data-pid="XAeVBm_-">组织的方向是什么？</li>
<li data-pid="B0hHHtNv">公司有什么消息？</li>
<li data-pid="_JCGZntn">最近都干了些什么？</li>
<li data-pid="l2z-0ekR">组织内有什么问题？有什么需要协调、沟通解决的？</li>
<li data-pid="m_CPO2G2">我们想改变什么？如何改变？</li>
</ul>
<h2 style="font-style: inherit;">3.1.2 项目晨会</h2>
<p data-pid="JZxxn6pp">项目晨会属于进度会议的一种，其主要作用如下：</p>
<ol>
<li data-pid="Nsv2aQgs">同步大的进度；</li>
<li data-pid="ethRVUuN">暴露风险；</li>
<li data-pid="mF6iLfVJ">协调资源；</li>
<li data-pid="NV6wL_B1">团队仪式感，让大家觉得是在一起做事情；</li>
</ol>
<p data-pid="ntQRcadr">项目晨会和管理例会不同，会议中角色除了组织者和参与者，可能还有模块组织者，特别是一些大的项目团队。各自的职责如下：</p>
<ol>
<li data-pid="cxFjXNVK">组织者：组织晨会，记录会议的过程和决议；</li>
<li data-pid="qR-_b7An">模块组织者：准备模块的会议文档，同步进展和风险；</li>
<li data-pid="7JhTH--8">参与者：负责对齐自己所负责模块的进展并暴露风险，有需要协调的在会上提出来。</li>
</ol>
<p data-pid="nt5b5TPT">由于项目中的事情比较多且杂，不可能一个个细项都在晨会上讲和讨论，我们需要有一些原则来控制会议，让整个沟通更高效。会议原则如下：</p>
<ol>
<li data-pid="ih95pEZM">充分的准备；</li>
<li data-pid="lm1oy-4h">沟通进度，快速过，不讨论具体工作；</li>
<li data-pid="SweiEv9i">发现问题，不解决复杂问题。简单的组内协调问题，立即解决；复杂的问题，如果涉及组外协调，给出简单的原则和建议，会后解决并同步进展；</li>
</ol>
<h2 style="font-style: inherit;">3.1.3 需求规划/评审会</h2>
<p data-pid="ZDmZ43H6">需求规划会一般存在于有良好的需求迭代节奏的组织，其组织内有计划的对于需求进行规划，评审，然后进入迭代，开发测试并交付。</p>
<p data-pid="af4aHOvr">这里的需求规划是指需求已经在产品内部评审过，马上要进入迭代，研发同学对于产品需求的技术合理性、业务价值进行评审的过程。</p>
<p data-pid="TcyTR8dp">需求规划会主要的作用说得直白一点就是卡需求，为什么要卡呢？这并不是为了难为产品同学，而是因为需求一旦进入研发阶段，整个事情的投入成本就会急剧增加，如果不合理的需求，或者价值不大的需求占用了较多的资源，可能会导致其它重要或者价值更大的需求的资源变少。技术管理者为了让整个技术团队的 ROI 更高，为了后续研发效能，在需求规划会上评估需求需要看以下一些项：</p>
<ol>
<li data-pid="pr10J1F2">需求文档是否准备好，实际中需求文档没写清楚的大有人在，一个事情没有写清楚，表示还没有想清楚，此时不适合投入资源；</li>
<li data-pid="U_Oh273d">技术上是否具备可行性，需要评估需求在实现层面的难度，对于一些技术难度高，但是业务价值低的需求建议会后再探讨；</li>
<li data-pid="dhZCwai3">依赖项是否准备好，如一些外部依赖，前置依赖等；</li>
<li data-pid="xGgXuM_u">是否有较好的业务价值，需要有数据支撑，或者直接说明这就是一个实验性质的。</li>
</ol>
<p data-pid="9MVU645m">项目管理过程中除了项目晨会、需求规划会还有迭代回顾会，项目总结会，项目问题解决会等等，这些会议的目的都是为了项目过程去发现问题，解决问题，在项目结束后总结问题，提炼问题为下次项目做准备。</p>
<h2 style="font-style: inherit;">3.2 构建定期当面沟通机制</h2>
<p data-pid="vv74fgOr">在会议之外，我们还需要构建定期的当面交流以补充会议机制中缺少的一些内容，如一些人文关怀，一些需要深入了解和聊聊的点。</p>
<h2 style="font-style: inherit;">3.2.1 1v1 沟通</h2>
<p data-pid="sLKz0S1L">每个技术同学都希望得到指导，希望有人告诉他方向在哪里，有哪些可以提升的地方，希望在和上司的探讨中有所受益。</p>
<p data-pid="RIrR1P3a">在 1v1 沟通前我们依据前面的沟通逻辑，要针对沟通目标、沟通对象、沟通内容做好准备，我们可以从 HR 那里拿到关于沟通对象的基本信息，把这个基础上，准备一个沟通记录表，记录表大概结构如下：</p>
<table data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">
<tbody>
<tr>
<td>姓名</td>
<td>岗位</td>
<td>面谈时间</td>
<td>持续时间</td>
<td>面谈目标和记录</td>
<td>下一步计划</td>
</tr>
<tr>
<td>张三</td>
<td>前端</td>
<td>2022/2/10</td>
<td>30 min</td>
<td>1. 关注当前前端技术， 2. 最近正在对跨端架构做深入了解，3. 有一些管理预期</td>
<td>观察，适当给予带小团队机会</td>
</tr>
</tbody>
</table>
<p data-pid="4BGPV6e8">面谈目标和记录将目标和记录放一起是由于两者是一个过程，在面谈开始前管理者先把目标和问题记下来，然后在面谈过程中会有一些输入，基于这些输入确认目标是否达成或问题是否解决。</p>
<p data-pid="m_aObR95">在 1v1 沟通中，管理者更多的站在一个帮助者的角度，平等的沟通，从对方的角度来发现问题，解决问题。关注其日常状态，个人成长，职业发展、家庭状态和身心健康。</p>
<p data-pid="c9MPcMQ3">在 1v1 沟通中有一个简单的 GROW 教练模型，如下：</p>
<ul>
<li data-pid="jQ7L7gAc">Goal: 目标，把时间轴拉长了看，你要达到什么样的目标，主要是从职业发展、个人成长等方向；</li>
<li data-pid="3qfcYBIc">Reality: 现状，基于上面的目标，现况是怎样的；</li>
<li data-pid="jWbEzoxm">Options: 选择，还是基于上面的目标，现在有哪些方法可以达成，别人是怎么做的；</li>
<li data-pid="PtA-qN7F">Will: 意愿，你打算怎么做，有没有计划，或者说想做什么样的计划，长线的，短线的。</li>
</ul>
<p data-pid="aKm4Ohdu">1v1 沟通在管理工作中是常见的一种沟通方式，当一个技术管理者到一个新的团队，需要和这个团队的每个成员聊聊，如果团队太大，可以考虑往下两到三级，至少要两级。初次的 1v1 交流主要是为了认识一下，熟悉一下。在初次 1v1 沟通后，对于下级或核心的同学需要保持固定频率的 1v1 沟通，固定的 1v1 沟通为工作交流，进展同步，计划跟进沟通为主。</p>
<h2 style="font-style: inherit;">3.2.2 定期组织交流</h2>
<p data-pid="s6NsLxRl">在个人沟通的基础上，组织层面的当面沟通也是非常重要的一环节。 组织的当面沟通其实也是会议的一种，这里单独拎出来是为了强调这种沟通方式。 和常规的会议不一样，其主要是为了交流，像茶话会，闭门会议、座谈会之类的，其着重突出交流，可以没有结论。</p>
<h2 style="font-style: inherit;">3.3 构建周报机制</h2>
<p data-pid="uaWNIj4o">从组织的角度来看，周报是组织流程化管理的一部分，是正式沟通地一种手段或方式，其目的是为了更好的向下管理和向上反馈。作为管理者可以通过周报了解一线的情况，如项目的进展，工作的动向；作为普通员工可以通过周报系统性地表述一线的状况。</p>
<p data-pid="ivO7aQRE">从个人成长的角度来看，周报是个人反思成长的载体，是自我管理的一种方式，其核心逻辑是：在过去一周你的时间花在了哪里，解决了什么问题，过程中有什么思考，个人有哪些成长。</p>
<p data-pid="z4lr0JKo">周报在我之前的文章中有细讲，可以看看:</p>
<ul>
<li><a href="http://www.phppan.com/2022/04/weekly/">聊聊周报-团队管理和自我管理的利器</a></li>
</ul>
<p data-pid="NZXK7tdN">这里重点提一下，谁来写周报，每个人都要写，特别是管理者，通过写周报了解组织内发生的事情及进展，发现组织内本周的问题。</p>
<h2 style="font-style: inherit;">3.4 构建内部文档沟通机制</h2>
<p data-pid="OqeljZK0">周报需要有地方承载，其承载的地方可能是某个 IM 平台的附带插件系统，或者某个文档系统，甚至是邮件。其中文档系统是一个相对系统化的地方，除了周报这种过程性的文档，一些结果类，标准类的文档也可以统一起来。</p>
<p data-pid="rxwARCsq">内部文档沟通机制我们经常称之为知识平台，知识库。一般会有两个主要的作用：</p>
<ol>
<li data-pid="TesbRLbr">沉淀知识和历史经验，如标准，流程，规范，业务知识等；</li>
<li data-pid="0WC-IDQQ">通过文档来传递书面的信息，让沉淀的知识、标准，规划通过文档让更多的人知道，或者一些过程性的文档统一起来，让大家更系统性的传输书面的信息。</li>
</ol>
<p data-pid="OwY-4cJD">一个较完善的内部文档沟通机制需要回答以下问题：</p>
<p>1. 文档放哪里？ <br style="color: #000000;" /><br style="color: #000000;" />    文档放哪里主要是指文档的载体是什么？各家公司各有不同，有些是用的类似于飞书之类的云上文档，有些用的是开源 WIKI 系统或者在开源系统上优化后的版本，有些是自主研发的系统，最终是要把所有的文档以系统化的方式全部管理起来。当然，也有直接弄个共享盘，大家一起使用的。</div>
<div class="RichText ztext Post-RichText css-9scqi7"></div>
<div class="RichText ztext Post-RichText css-9scqi7">2. 文档怎么放？ <br style="color: #000000;" /><br style="color: #000000;" />    文档存放的规则是什么？如果是一个 WIKi 系统，或者有类似于文档空间概念的系统，可以有如下规则：</p>
<ul>
<li data-pid="kEJN3Ysn">过程性文档放所在组织结构空间，当组织结构变化时，过程性文档随着变化，以变化应对变化；</li>
<li data-pid="oP8jd_gn">结果性文档或者说沉淀的文档，如标准、规范、历史事故等放各技术通道这种更固化或者说更抽象的表述空间下，以不变就万变。</li>
</ul>
<p>3. 怎么快速找到需要的文档？</p></div>
<div class="RichText ztext Post-RichText css-9scqi7"></div>
<div class="RichText ztext Post-RichText css-9scqi7">     这个问题从技术的角度马上能想到的两个词语是：索引和搜索，也就是当年的雅虎和现在的谷歌。 关于索引，我们可以人工设定规则，比如哪些类型的文档放什么空间下，如刚才所说的过程性的文档放组织结构空间下。这里可能需要更细化一些，如周报放哪些、规划文档放哪里，技术文档放哪里，这些都用规则明确出来，形成索引，在组织内宣导，形成既定的认知。 关于搜索，我们更多的是依赖于所使用的系统，而现在各家公司内部使用的自己搭建的系统，纯大部分的搜索都是属于「又不是不能用」的状态。与此对应的，如飞书，其搜索能力就好很多。</div>
<div class="RichText ztext Post-RichText css-9scqi7">
4. 怎么让有价值的文档让更多的人看到？</div>
<div class="RichText ztext Post-RichText css-9scqi7"></div>
<div class="RichText ztext Post-RichText css-9scqi7">     这是一个很难的问题，现在没有人能很好的解决，属于内容运营的范畴，从技术实现的角度来看，就是如何推荐有价值的文档，那么这里需要先定义什么是有价值，更多是多少？我也没有答案，现在能看到的是还是人工介入，形成类似于周刊，月刊之类的机制，以推荐有价值的文档。</p>
<h2 style="font-style: inherit;">3.5 其它</h2>
<p data-pid="XZ1RhfMk">除了以上的 4 种正式沟通机制以外，我们常见的还有汇报机制、公文机制、备忘录机制等等，这里就不详细展开了。</p>
<p data-pid="g2j5AexS">内部正式沟通机制的建设不是一个一蹴而就的过程，需要不断进步和迭代，需要内部所有人员一起努力和不断摸索前进。 在构建过程中，我们可能会遇到沟通不畅的情况，甚至会遇到各种意想不到的反对或者针对，此时我们不能放弃构建，也不能放弃沟通。作为一个管理者必须正视内部正式沟通不良的现象，积极面对，及时地解决构建过程中可能出现的问题。</p>
<h2 style="font-style: inherit;">4 构建非正式沟通机制</h2>
<p data-pid="E14jzses">在正式沟通机制的基础上，我们还需要一些不那么正式的沟通机制，以补全整个沟通机制。</p>
<h2 style="font-style: inherit;">4.1 IM 群</h2>
<p data-pid="o4kCoXRz">随着信息化的发展，即时通信工具发展迅猛，像微信、企业微信、钉钉等都成了我们工作中沟通交流的主要手段之一。 虽然 IM 有聊天记录等功能，但是作为一个组织的正式沟通机制却是有所欠缺的。</p>
<p data-pid="kXelidEO">但是我们可以基于 IM 做一些非正式的沟通机制，如组建群，不同的群体组不同的群，以达到部分沟通的目的。 而作为一个技术管理者应该如何拉这些群呢？有一些常规逻辑：</p>
<ul>
<li data-pid="5yz-b3se">部门大群，全员大群，主要用于消息通知，周报、请假等信息同步，用作信息同步之用；</li>
<li data-pid="MZRqTyED">管理干部群，主要成员是团队的 Leader，主要是用于管理干部的工作安排和探讨；</li>
<li data-pid="Mzfur-Z_">核心骨干群，主要成员包括管理干部群和各业务模块的负责人，有两个工作，一个是确立核心骨干同学的核心骨干位置感，另一个是骨干同学的工作安排和信息沟通；</li>
<li data-pid="_gcSXgo7">项目群/专项群，具备时效性，某个项目临时拉起的群，项目完结就解散；</li>
<li data-pid="lFkq_46h">问题处理群，更短时效的群，主要是针对一些紧急线上问题等需要快速拉齐信息，快速处理问题的场景；</li>
<li data-pid="uOXLT10I">会议群，短时效的群，主要是针对一些会议的群，包括一些会议的准备，过程中的信息同步，以及会后的沟通等；</li>
</ul>
<p data-pid="XHB0TrCZ">养成事事有交代的习惯，比如请假或休假之类不在公司的情况，可以在大群同步一下，让大家知道你休假了，你手上的工作谁来对接，如何联系到你，大概格式如下：</p>
<blockquote style="color: #646464;" data-pid="-y0Sb1gx"><p>卡神 7.25 ~ 7.27 休假，工作交接给 XXX（或者工作不交接），不定时查看钉钉，急事电联：134XXXXXXXXX</p></blockquote>
<p data-pid="t3nt2xpo">以上这个示例也有同学问了，我可以在钉钉上设置状态，为什么要再在群里发一往遍呢？ 这两个操作本质上不同的，一个是主动反馈，告诉大家你的状态，让大家可以快速知道你的状态；另一个是被动查询，只有当需要的时候才来看一下，或者根本就没注意到，没法提前安排或者需要问一圈才知道找谁 来解决问题。</p>
<h2 style="font-style: inherit;">4.2 别独自用餐</h2>
<p data-pid="0mAjl8Yw">有本书叫《别独自用餐》，这是一本讲经营人际关系的书，但是这里我们并不是要讲人际关系，只是想用这个标题。</p>
<p data-pid="k-wud-iS">在非正式沟通机制中，技术管理者可以经常拉一些同学一起去吃个晚饭，或者喝一顿小酒，都是极好的，据说酒能让人看别人顺眼一点，趁酒意正浓之时，说点掏心窝子的话，互相吐吐槽，倒倒苦水。</p>
<p data-pid="5MrfZrGe">这里就仁者见仁，智者见智，各路神仙，各显神通。</p>
<h2 style="font-style: inherit;">4.3 其它</h2>
<p data-pid="sRq42TJh">非正常沟通机制除了上面的两种，还包括电子邮件、社交活动、小型聚会等等，不仅形式灵活多变，沟通时候的内容和形式也比正式沟通更加自由，更加有利于内部人员分享信息、交流心得、增进感情；也更加有利于达成内部的统一思想和目标，明确共同的利益和方向。</p>
<h2 style="font-style: inherit;">5 写在最后</h2>
<p data-pid="MfQGhZYw">无论沟通模式或工具发展到什么程度，面对面沟通仍然是不可取代的。 良好的沟通，需要知行合一的价值观：尊重他人，请认真对待每次沟通和反馈。</p>
<blockquote style="color: #646464;" data-pid="afBrsXKA"><p>你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： <a class=" external" style="color: inherit;" href="https://link.zhihu.com/?target=http%3A//www.phppan.com" target="_blank" rel="nofollow noreferrer" data-za-detail-view-id="1043"><span class="invisible" style="color: transparent;">http://www.</span><span class="visible">phppan.com</span></a></p></blockquote>
</div>
</div>
</div>
]]></content:encoded>
			<wfw:commentRss>https://www.phppan.com/2022/07/communication/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
