在很多场合下，有些人跟我谈起他们的程序员如何的不好沟通，如何的不愿意配合，不愿意公开进度。导致他们项目管理的时候很为难，他们很头疼这些事情。那今天我们就来谈谈如何激励程序员，如何让程序员乐意公开透明的沟通，确保项目朝着正确的方向前进。

       首先我们要知道程序员基本上都是理工科学生，他们的工作也都是基于逻辑，基于算法，基于流程为主的。所以，他们很喜欢讲道理，讲逻辑。那么我们就要用程序员的方式和程序员进行沟通，而不要用别的他们不容易接受的方式来沟通。

       首先，我们来看看为什么程序员不愿意透明化他们的工作进度。我们看看假设程序员公开了他们的极进度他们会获得什么？

下面的图是一种最常见的反馈模式。

可见在这种反馈模式下，程序员没有什么好的选择，最佳选择是按部就班的做出平庸的工作即可。也就不奇怪为什么程序员不愿意公开进度了。所以，如果你想改变程序员的行为模式，你首先要改变自己的行为模式。就是程序员做出的行为，收到的反馈不再是上述模式。那么如何才能够让程序员愿意去改变思路呢？

那我们先得思考的问题是，让程序员变成快乐的程序员。不快乐的程序员是不会愿意跟你敞开心扉沟通的。

那么，程序员如何才能够快乐呢？这里有一些比较直接的能够吸引程序员的选项。

       也就是说一般环境下程序员可能不具备快乐程序员所具备的因素。那么快乐程序员所具备的这些因素都能够很容易的达成吗？很多人会觉得有很多事情办不到。

        比如，公司有工资体系，我无法给员工加工资。我也无法对优秀的程序员做出相应的奖励（这个在软件行业很常见，因为优秀的程序员有的时候表现的价值是较为一般的程序员的几十倍，乃至上百倍，而工资却不可能有这么大的差距）。

       比如，很多公司的文化中，加班是程序员的宿命。不加班是不可能的。早干完只能得到更多的工作。好像事情永远不会结束。

       好像事情并不是容易办到，但是事情并不是这么简单考虑的。这样的考虑方式会比较受到当前的上下文所限制。程序员是社会人，所以，要按照社会属性来思考的话，程序员的选择并不是这么少，还有更多的可能性。

1. 我在这里锻炼更多的本领可以在别的公司那里获得更高的岗位，更好的收入。
    你不愿意支付的价格，你的竞争对手愿意。

2. 作为自由职业者，把自己的创意转化成App，带来额外的收入。

3. 通过自己的努力，锻炼自己的各方面能力，从而转化为更大的价值（比如，创业）。

等等，不一而足。

       不管程序员对未来的设定是什么。如果他有了对未来的设定，那么他做起事情来就会更加容易的朝着那个明确的方向去迈进。比如，未来的那个岗位，需要在技术实力、管理能力和沟通能力上面分别提升才能够达到的话。那么下面这个模型可以说明，程序员可以如何清晰地定义自己的未来所需要的技能和当前技能之间的差距。

       然后，程序员可以通过脑图的方式，对当前需要弥补的差距进行分解。比如，下面是一个技术实力的分解的例子。

当分解了这些需要做的事情之后，程序员就可以把这些需要做的事情排定计划。这也很符合程序员的工作习惯。一个甘特图就可以让事情一目了然。

假设程序员们已经走到这一步了，剩下就是自组织的一个过程了。当利益明显，并且触手可得的时候，不需要你去催促，程序员们自己就会去努力争取了。

而在此之前，你需要构建一种安全的沟通环境才能够得到良性的沟通效果。这样才能够逐步的帮助程序员去构建ta的职业生涯目标，并且同时帮助团队构建一个进度透明的文化。

首先，你要确保程序员如何能够敞开心扉的和你来谈。那就是ta的谈话不会用来被攻击ta自己；不会用来被不匿名的传播；不会...总之不会让ta感受到任何潜在的威胁存在，才能够让ta有沟通的想法。其次，ta的行为应该收获到的反馈应该是基于正向反馈的，而不是基于负反馈的。下面是一种比较理想的反馈模式。

    所以，如果你的职责是跟程序员沟通，并且获得营造这种透明文化的话。上面是整体思路，下面就是一些具体的沟通技巧。

      一个重要的谈话原则是：将“事实”和“感受”分离开来。我们中文的习惯的原因，会将事实和感受混为一谈。比如：“开发团队对产品经理老是不配合这事儿意见很大”就是一个混合式的表达。

     开发团队对于某事的意见很大，这是一个感受。尽管是个客观存在的，但是它是感受。
而产品经理老是不配合这事儿在这个语境下恐怕就不一定是事实。这样的表达会让产品经理觉得很委屈，而开发团队也觉得很憋屈。
      把感受替代事实会造成误解，沟通不畅。所以，需要转化表达，将事实和感受分离开来，才能够更好的解决问题。

例如：
1. 产品经理预计在3月4日提交的新的需求列表没能按时交付 —— 这是事实。产品经理也不会对此进行反驳。
2. 产品经理提交的需求内容经常会在开发团队中产生理解偏差——这是事实。
   换个表达就是感受：
   a. 产品经理提交的需求开发团队无法理解 （这是产品经理觉得无法理解的）
   b. 产品经理提交的需求总是不详尽（这是开发团队觉得的）
    后面两种表达会让矛盾进一步激化，而不是得到调节。

感受不也不是不能提的，而是要有技巧的提。例如：
1. 产品经理提交的需求没有得到正确的理解（这是事实）让我们觉得很为难（开发团队的代表表达出了他的感受），我们希望他能够给我们讲述的更详细些（以及明确的需求）。

2.  开发团队的理解和我想要表达的意思总是不同的（这是事实），这让我感到他们的理解能力不够（这是感受）。我的想法是，能不能安排个经验多的人到团队里面（以及明确的需求）。

上述感受是否正确就不再重要了。重要的是，能够把事实和情绪分离开来，就可以就事实展开更多的健康的对话。对待感受部分，采用“Yes,and”模式会让沟通更有效，更容易打开心扉，畅所欲言。

比如：开发团队代表说，你是一个经验丰富的人，和其他成熟的团队沟通起来可能现在的方式就很奏效。所以你觉得现在这样的资料就足够了。我很理解你很忙，没有那么多时间来做更多的详细阐述。你也知道，这是我们第一次配合，有些我们之间的默契还没有形成，所以，如果你肯花点功夫的话详细讲述一下的话，那么我们反复打扰你的时间就会减少。我们之间的默契也会更快的形成。你看如何呢？

相对来说就更容易获得产品经理的配合。

Tips:

问一下程序员们下列问题，可以引发他们自己的思考。

问题1：你能描述一下30岁（或者35，40）之后的你的理想状态吗？

问题2：现在你在做的事情和达到这个理想状态是同一个方向吗？

问题3：开放，透明的文化是否有助于你达成这样的目标呢？

----------------------