不怕神一样的对手，就怕猪一般的队友，程序员你怎么看？（获奖名单已公布2013-4-7）

Godbach

回复 25# send_linux
茂哥担心歪楼了。领导也是队友。

哈哈，挺不错的活动，很好的讨论。




   

dzminglong

这句话说到心坎里面去了，真怕猪一样的队友

pitonas

craaazy123 发表于 2013-03-19 09:43
我倒觉得  不怕神一样的员工，就怕猪一样的领导！

深有体会啊

fengzhanhai

1、外行领导内行；2、不懂装懂，瞎指挥；3、排除异己、带头拉帮结派；4、出现问题需要承担责任时找替死鬼开除下属；5、刚愎自用；6、一言堂，必须按照其一人的想法做事情；7、明知下属主管不懂技术，仍安排在相应位置；8、自己存在短板，但固执己见，不懂的领域也要全方位干预，出了问题再让下属回头把工作重来一遍

newbiez

1）我公司的开发团队沟通主要是项目经理分配任务，定期组织讨论会，收集开发中的问题（包括技术难点、不同小组的模块接口），协调不同小组的开发分工。
这种方式依赖于项目经理技术能力，从不同小组的问题反馈中，获取关键点，并且妥善分配到对应的责任人。这是一种垂直的沟通模式，项目经理需要经验丰富、具备足够的威信。优势是，在一个强势的项目经理带领下，开发效率较高。缺点是如果项目经理一时疏忽，可能会未能识别出开发中的问题，或者任务分工出现不平衡。

2）我认为好的沟通模式，除了上面所述的项目经理为中心的沟通模式外，还应该增加技术经理角色，分担项目经理在技术分析上的责任。如果条件合适，还应该增加专家小组。将不同的解决方案交由专家小组评议，选择合适的方案。

3）技术弱势的项目经理、分工模糊，团队成员的工作完全靠自己的经验和自我要求，最终在工作压力逐渐增大时，一个自私、缺乏责任感、遇事推脱的成员几乎毁掉了一个团队的工作。他的工作都很难和其他人衔接，甚至最终在项目上线的半年后，其他成员还在为他的程序打补丁。由此得出的结论是，有责任感、能够顺畅沟通并且接受其他人建议，是一个程序员应有的品质，如果发现自己的下属里有不符合这样要求的人，及早放弃。

newbiez

看了前面的留言，想额外说两句，
1）外行领导内行并不可怕，而且大多数专业管理人员都不是技术出身。就像你的程序设计水平肯定比不少公司老板强，但这不妨碍你要拿他给你发的工资。在一个项目里面，项目经理不一定要是技术最牛的那一个，项目经理这个职位本身就是偏向于商务职能，良好的沟通能力、协调能力、对进度的掌控能力才是项目经理的必要才能，而技术能力不是。当然，在不少公司里，成为项目经理的前提条件是技术能力，但这恰恰是我们IT管理还没有达到较高水平的明证。
2）不怕神一样的对手,就怕猪一样的队友，这句话有些攻击性，而且很不准确。神也有神的缺点，神是唯一的，是孤傲的，是冷眼看世人的，该如何与神沟通？恐怕这是不少管理者的痛苦吧？
在一个工程项目里面，如果有一个神级高手，ok，我有自信来协调他，有两个神级高手，我会说，行，我可以忍受，三个神级高手，我会说，这个项目我带不了，请孙悟空或者玉皇大帝来吧。

而我们凭什么说队友是猪呢？就因为他入行比我们晚一点？因为他反应稍微迟钝一点？因为你心里觉得他的智商稍微比你低一点？拜托，你太高看自己了。
我敢打赌，在三年之后，你曾经认为反应迟钝，思路混乱的这个程序员，就能承担跟你一样的工作，甚至职位与你不相上下——只要他工作稍微勤恳些，这个根本就不是问题。

蛇窝里的老鼠

目前还么有遇到此类情况，新手入职，对业务逻辑还不熟，许多都得和经理那边现学呢

yang505982

非常赞同
seesea2517 小富即安
在上面已经列出了的。

(1)降低新人加入时的壁垒。-----靠的一般就是 规范的文档和注释了。

  关于 代码改动要尽可能的小 ------有好的框架与流程。

  建议先出功能，后续再优化----这个也挺赞同的。
  。。。。。。。。。。。。

(2)制度化规范化, 目标要明确。逻辑一定要清晰。
   在有必要时把 框架图、流程图画 出来。分配好各个模块各个相应人员。
       
(3)平时开会，要有基本的会议记录，防止扯皮。
  开会做出决定后，先按决定的去做。曾有这样的现象，会议明确说明要这样做，但过后却另一套做法。或者是 会议明确说明要这样做，过后却对人大吼特吼“为什么这样做，我是要求那样那样。。。。”

(5)用版本管理来规范 eg. svn 等等
        曾发现有这样的现象：有人不知道怎么用却很能吹，在那里对别人指手划脚上面的人都喜欢听他的。
第一份上传的文件文档，可以上传全部，但后面如果的没有必要全部上传的。曾经的团队，编译一个系统最后，大概有几个GB大的数据文件，哪怕是只修改了一个文件中的几个字母也要上传全部几个GB 大的数据，其实只要上传修改的文件（差异文件）即可。但是，说了没有用。上面只听那些会扯皮的人。因为数据多又大，中间容易中断，最后搞了很久都没有上传OK，挺悲哀的。
　　svn 版本号，记录等等都有了很多东东了，可是现实中让不懂装懂的人给搞。。。。。。
       
(6)修复bug，测试，发布软件要有清晰的政策和流程。、
   在有必要时用　bugzilla, TestDirector  等等来管理。分配好权限，做好培训。
   修改，决定等等都要都历史记录。以防再犯那些低级的错误(同一个错误n多次)。或者出现扯皮现象。修改过的问题要可以通过这些记录或svn记录知道是在哪个版本中修复了哪些问题的。

(7)在查问题时发现，可能涉及多个人的，但暂时还不知道是在哪个人那里出的问题时。很容易出现扯皮现象，一个推给另一个。这时最好能把 流程搞出来。一个一个排查。eg.
硬件层<--->单片机层<--->驱动层<--->系统中间层<--->上层应用。比如上层应用发出指令，但最后没有响应。一个个模块查，这个指令到了哪一层。在哪个收不到，是哪个原因造成的，查出哪个模块出问题让相应模块人员去处理。有可能还得要多个模块的人一起协调处理。

( 跟测试组人员做好沟通培训，有必要时培训测试人员抓log，因为有些问题不是必现的。log 在项目中非常重要。其实不管是集成中，编译中，解决运行的bug中，log 都给了我们很大的帮助。里面很多时候都指出了是哪里问题，在队友中,有问题时他们竟然不看 log ,劝了还不听，不懂装懂。

在项目中真的是 "不怕神一样的对手，就怕猪一般的队友"。

对，外行领导并不可怕，因为他们可能是 不做技术的。也不是因为队友 反应稍微迟钝问题。
最关键最重要的问题是：有些队友很能吹(这不是坏事)，但不懂装懂, 整天在那里对对别人指手划脚，听不进别人的一点反对意见，整天想方设法让别人都听他的，说服上面的人听他的，而最后上面也真的听他的。可是这样一来如果他的方法不对，甚至于框架方向都出了问题，这个项目能做好吗？

“兼听则明，偏信则暗”

kinfinger

今天就因为说了这句话，被同事很批了一顿，犯了众怒

thaldn

怕个个都是神，不怕个个都是猪