软件主管要不要和工程部门以外的人沟通

我看到很多年轻人毕业后就进入知网郑州软件公司，看着他们成长，成为部门主管，看着他们遇到各种问题，看着他们解决这些问题。然而我还是忍不住想把下面这些话说给他们来听。  

        你所在的产业，并不会有刚毕业的清华北大MBA像坐火箭似地突然冒出来，接任前线的工程管理职位。为什么？因为任何够聪明的工程团队都会生吞了这位名校毕业生：

        清华高材生，你可以来跟我一起走查这个堆栈跟踪吗？

        对管理人员来自于一线员工的产业而言，好处是我们拥有了解我们的行话和问题的主管，而这也是诅咒的开端。

    
        故事如下：一个有才华的毕业生，刚毕业就加入了一家创业公司。他的主管给也搭配了一个聪明的高级工程师。在两年的过程中，我们这位大学毕 毕业生以实际动手和耳濡目染的方式学习了软件开发：要有效率，需要时可以天马行空地地发挥才智，对权威讲事实，按时完成，不要交付垃圾。

         一次又一次地，我们这位工程师交付着他的产品。犯过错误，学到了教训，突然间5年就过去了。我们这位大学毕业生已经成长为高级工程师。他

所学到的教训，变成他所教的经验。他拥有了保证所有产品的交付品质的好名声。他已经是可靠的了，还希望成长，想承担更多的责任。因此，有人决

定把他提拔为主管。

   
        他主持的第一次跨部门会议，产品经理、销售和技术支持都出席了。他们在问为何开发团队不能完成某个特性，而我们这位刚刚上任的主管突然

意识到自己完全没有办法描述这个要求所涉及的技术和性能影响，因此他只能弱弱地说：“嗯，这很难。’

   
        多道冷冷的目光跨过会议桌射到身上，我们这位主管疑惑了：“他们讨厌我？”

        是的。

        每个人都讨厌工程部门

       
        在工程部门以外，没有人真正喜欢工程部门。以下是原因。

       
        没有人知道我们实际上是怎样开发软件的，所以他们假设那是轻松的

       
        在其他所有人的脑海里，把那个核选框添加到页面上真的只是很简单：“只是插入分支语句……使用If/Then或者类似的语句o"

        说得很好，但这样说真的很讨厌。

        被要求更改的，已经是世界上最糟糕的规格书。但真正的问题是要求的那个人假设他已经描述了所有相关的工作。他们以为自己对开发产品的工作

有一定的了解。

         更糟的是，这种误解是双方面的．．

         我们把工作当成自己的，其他人一定做不到

         
         我们极端认真地承担自己作为代码所有者的角色。我们一直盯着这些代码有好几个月了。我们熬到凌晨3点来保证它们的正确性。我们已经成功地

让这些代码通过我们用心良苦的质量保障部门的审查，并交付出来了。不好意思，你在问什么？

   
         嗯，这还不是完美的。你可不可以把这个区域移到那边，让这个按钮提上来，因为…

   
        这样的反馈，如果在什么时候提出会非常好？在4个月前的凌晨3点，在我放弃了5个周末的休假来赶上那个疯狂的限期的时候。那附要求新功能会

是个不错的时机。

        我们的代码就是我们的世界。我们确实听过产品营销、技术支持和销售等，但我们错误地、执着地相信代码就是一切。知道吗…．．

        我们只和代码打交道

        在计算机科学的职业生涯中，一个很鲜明的特色就是几乎没有原始财富积累是来自干跟人面对面的成功互动的。实际上，我们的职业生涯开始阶段，社交上的笨拙反而可能会是好处。

        回顾前面列举过的事项。

        #要有效率：编写优质的代码。

        #发挥才智：编写大量的优质代码。

        #对权威讲事实：跟那些很懂行的人来辩护你的优质代码。

        #按时完成：在你答应的时间内交付你的优质代码，但……

        #不要交付垃圾：要确保代码是优质的。

 
        在实现以上目标的历程中，合理限度的远离人群会大有好处。让大脑无心人类行为的复杂性，可以节省你的宝贵时间来专注地编码，而我们的

生涯正是基于代码的。我们的激励也是基于代码的。年终的时候，当主述我们的绩效时，他们会基于代码的成功来描述。

        我们要成为成功的工程师，几乎不需要跟工程部门以外的人进行沟通，而这一点使我们要面对诅咒。

        关注成功，关注未来，关注知网郑州软件公司。