管理与沟通四个步骤

 

四个步骤：

 

1、确定问题，与工程师就问题的定义达成一致。

2、确定这一问题的责任属于工程师自己；

3、就解决方案的大致范围进行交流，让工程师主导；

4、直截了当，并且在需要完成什么，包括在范围、优先级和期限上面达成一致。

 

 

 

 

有时候为了节省时间，你的进行的更慢些。（不能跳过前面的步骤直接进行步骤三步骤四，讨论解决方案）

 

 

工程师们不喜欢做日后要被抛弃的工作。他们宁愿花时间自己创造出一种可靠的解决方案，以后不需要额外的返工。有时候他们确实有些苛求智力成果的纯洁度而不进行仔细的工程学上取舍的分析。比如某个有资深技术知识的经理与工程师们争论这些技术亮点。这就是为什么最好不要与其讨论方案本身而要让工程师给你建义的原因。

 

注意不要让软件工程师们同时做太多的工作。

 

目地是增进交流。如果你与之对话的对象觉得你是在施恩或者在利用他，你的交流就会彻底失败。

 

跟工程师们交谈是一个过程而不是一个事件。对话需要不断推进。不要以为你与这名工程师一次就要谈完事情。一次性的交谈很容易让他对交谈的内容走样。

 

 

 

 

通过若干年的观察，我发现工程师们还有另外一个偏好，这这值得我们注意。当你向他们提出问题的时候，他们倾向于最全面的分析问题。也就是说，他们自然而然的希望“整个问题”都得到解决。

这会带来两个问题。首先，要让问题在整个参数范围内得到解决，要比限定于参数的某些区域内解决问题难的多。事实上，在某些时候，即使在被限定到某个范围是易于解决的，但是几乎不可能找到一种普遍的解决方案。因此你得详细说明，实际上你只需要在某种限定范围内使问题得到解决，否则工程师会感到相当棘手。

第二个问题是他认为可以解决，尝试之后才发现他错了，这个发现的过程成本都是相当昂贵的。

最后，也许问题可以完美的解决，工程师也能胜任，并且他找到了完美的解决方案。但不幸的是代价昂贵，你所需要的仅仅是其成就的一部分而已。

 唯一避免这一窘境的方法是在步骤一和步骤三的讨论是要相当仔细地告诉他问题到底是什么，在步骤四的时候告诉他你为解决方案负担得起什么样的代价。