Chinaunix

标题: 不怕神一样的对手，就怕猪一般的队友，程序员你怎么看？（获奖名单已公布2013-4-7） [打印本页]

作者: send_linux 时间: 2013-03-19 15:57
标题: 不怕神一样的对手，就怕猪一般的队友，程序员你怎么看？（获奖名单已公布2013-4-7）
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4075400-1-1.html

软件开发是一项团队运动，人的因素对结果的影响完全不亚于技术因素。一个项目成功的关键不仅仅是写出漂亮的代码：团队中的所有人朝着同一个目标一起合作也是同样重要的。开发团队是一个整体，稳定的、沟通无碍的团队文化非常重要。好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查，以及能让人放心尝试新事物或者快速失败的环境。

正如xxx语录里的一句：不怕神一样的对手，就怕猪一样的队友！
欢迎各位码农来吐槽，说说您在软件开发中遇到的团队合作经历，以及您的建议！

本期话题：
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
3、说说您遇到的最差的团队合作经验

本期奖品：
最佳积极参与经验分享奖7名，奖励价值29元的《极客与团队》图书一本
参与讨论的其他会员，获得社区积分20分

图书简介：
极客与团队

作者： (美)Brian W. Fitzpatrick Ben Collins-Sussman [作译者介绍]
出版社：人民邮电出版社
ISBN：9787115308443
上架时间：2013-3-5
出版日期：2013 年3月
开本：16开
页码：180

样章阅读：

qy.doc (820.5 KB, 下载次数: 96)

01.doc (3.36 MB, 下载次数: 111)

04.doc (2.05 MB, 下载次数: 83)

作者: duanjigang 时间: 2013-03-19 15:59
ding

作者: platinum 时间: 2013-03-19 15:59
ding2

作者: hellioncu 时间: 2013-03-19 16:03
最怕不懂装懂还不听劝的

作者: zimang 时间: 2013-03-19 16:05
关键是框架模块设计，好沟通，好排错。

作者: jerryjzm 时间: 2013-03-19 16:06
高标准，严要求，顶顶顶

作者: gvim 时间: 2013-03-19 16:23
不知是谁概括的如此精辟的一句话。深有体会啊

1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
小公司靠人情沟通，中等公司靠制度沟通，大型公司靠文化沟通。我们还是小公司。。。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
最理想的    8:30：xx你处理这个，yy你处理这个。 17:30：x总，这个处理完了，17：40：x总，这个有点小问题，不过已经有解决办法，晚上我们加班
比较理想    8:30：xx你处理这个，你可以这样做。  17:30：x总，这个处理完了
稍微理想    8:30：xx你处理这个，你可以这样做。  12：30：x总，这样不行啊，我可能没理解到意思。好吧，你这样这样这样做。 17：30：x总，这个处理完了
不太理想    8:30：xx里处理这个，你这样这样这样做  11:00：x总，还在做，可下一步怎么做？  13：00：还在做，后面不知道怎么做了  15：00：下面该怎么做？ 17：00 x总，总算处理完了
不理想       8:30：xx你处理这个，你这样这样，x总，没问题我会的，不用罗嗦。  12：00，做完了吗？没有    14：00,进度怎样？还在做有点问题    17：00，x总今天问题多，做不完了，我们加班赶赶
十分不理想  8:30：xx你处理这个，你这样这样，x总，没问题我会的，不用罗嗦。 12：00，做完了吗？没有    14：00,进度怎样？还在做没问题  17：00进度怎么样？没问题，17：30下班回家  18：00喂你们处理的结果呢？哦，你看是不是这个。
最糟糕    8:30：xx你处理这个，你这样这样，x总，没问题我会的，不用罗嗦。 12：00 进度怎么样？没问题。 17：30下班回家  18：00喂你处理的结果呢？哦，你要的是什么结果？我还不太明白什么意思。

最理想的团队是能明白你的意思，并且知道怎么做。最不理想的是不能明白要什么，也不知道怎么做，并且还告诉你没问题，一定没问题，出了问题找一大堆理由来说明为什么没做出来。

3、说说您遇到的最差的团队合作经验
2009-2010年一个项目。
客户：把这个改了，我要这样这样。合作方：好，我回去叫合作方（指我方）改。我方：这样子技术上不太好实现，需要用很多代码来实现这个基本不用的功能，可不可以从非技术手段保证？合作方：不行，客户要求的。我方：好吧，你能告诉我为什么要这些参数吗？有什么业务意义？合作方：你就按我说的改嘛。我方：你得告诉我怎么改啊。合作方：这样这样，剩下的你看着改嘛。。。。客户：你们做的什么JB东西，我要的这个功能这样这样，你们怎么做成这个？！我方：合作方告诉我们这么做啊。合作方：他们自己没理解业务，我都是给他们说清楚了的。
操

作者: seesea2517 时间: 2013-03-19 16:28
刚刚看的一个文章正好用上了：
Google 极客谈软件开发团队的不良行为

第一条就是不尊重别人的时间
第二条是自负
过分索求是另外一种不良行为。
还有两种行为需要警惕：
* 幼稚或是莫名其妙的交流
* 偏执妄想
最后一条是完美主义

Brian和Ben提出了一些实际的解决办法：
* 写一份明明白白的任务宗旨。这样可以随时保持专注，知道哪些是目标，哪些不是。
* E-mail讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人”。
* 所有历史都要有记录。这不单指代码历史，还有设计决策、重要的bug修复，以及过去犯下的错误。
* 有效地进行协作。利用版本控制，代码改动要尽可能的小，方便进行审查，扩大“公车因子”，避免出现领地感。
* 修复bug，测试，发布软件要有清晰的政策和流程。
* 降低新人加入时的壁垒。
* 依赖基于共识决策，在无法达成共识的时候也要准备好化解矛盾的方法。

对于“不尊重别人的时间”以及“完美主义”深有感触：
比如正在“文思泉涌”的时候有人来找你讨论问题－－建议先邮件预约，也好让人有所准备
比如有版本任务因为某人追求完美导致未能按时完成版本——建议先出功能，后续再优化

作者: qinyiwang 时间: 2013-03-19 16:38
回复 7# gvim
相似啊

作者: craaazy123 时间: 2013-03-19 16:43
我倒觉得不怕神一样的员工，就怕猪一样的领导！

作者: yidou 时间: 2013-03-19 16:44
回复 4# hellioncu

别乱顶贴。你懂么{:3_183:}

作者: hellioncu 时间: 2013-03-19 16:45

yidou 发表于 2013-03-19 16:44
回复 4# hellioncu

你都不会写代码，一边去

作者: patagonia 时间: 2013-03-19 17:11

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

你这是打击报复啊！

作者: txgc_wm 时间: 2013-03-19 17:50
回复 10# craaazy123

投你一票，尤其是对于刚起步的公司来说，这是最让人头疼的。

作者: txgc_wm 时间: 2013-03-19 17:51
回复 12# hellioncu

比较伤人的哦！

作者: txgc_wm 时间: 2013-03-19 18:00
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
=>现在所处的是一个小公司，如果需要各模块的人一起讨论的话，则迅速召集起来开个讨论会，只是个别的话则单独讨论。优势就是迅速、便捷。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
=>面对面或则聊天工具，说出观点1.2.3.4,然后大家有序的论述，最后形成统一观点（由决策者根据讨论结果最终敲定，且要让大部分人信服）。

3、说说您遇到的最差的团队合作经验
=>领导者老是更改需求，而且没有相应的文档，有问题则归咎于下属（很坑爹，这样的话我们找谁出气去）。

作者: action08 时间: 2013-03-19 18:08
本帖最后由 action08 于 2013-03-19 18:08 编辑

不怕神一样的对手，就怕猪一样的队友！

严重同意此条。
如有不服，参考上文。。

作者: craaazy123 时间: 2013-03-19 18:12

patagonia 发表于 2013-03-19 17:11
你这是打击报复啊！

不是打击报复，确有“奇”人

作者: chenyx 时间: 2013-03-19 20:23
支持下,不做开发,看看大家的高论.
楼上说的有一定的道理,外行指挥内行确实很可怕,目前环境如此,也只能忍受了.另外,客户的不合理要求也会造成程序的开发进程冗长.

作者: ddd010 时间: 2013-03-19 21:17
本帖最后由 ddd010 于 2013-03-19 21:18 编辑

1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
沟通？我之前的开发团队8个人，由一个经验丰富的老人带着，除了技术难点有讨论外，其它方面就没有了（如果周会算沟通的话，那就有）。全是领导直接安排就完了。这个团队之后转战另外一个平台，由于大家都对新平台不熟悉，而且也没有相关的技术指导和支持。结果那个项目可想而知，完全是个失败品。
这个优势嘛，我倒是认为在熟悉的平台上做，我这个团队的方式倒是将就。
缺点就显而易见了。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
我认为，沟通的目的是做出决定。那么在一个理想的团队中，任何一个决定都不能由某些人想当然的决定。
这个最最重要。

3、说说您遇到的最差的团队合作经验
一言堂。。。

悲剧啊。

作者: linux_c_py_php 时间: 2013-03-19 21:52
领导一句话就足够了...

猪也是队友, 但如果项目做不出来做不快, 领导眼里大家都是猪.

作者: lsstarboy 时间: 2013-03-19 22:11
不怕神一样的对手，就怕猪一般的队友，更怕猪一样的领导！

作者: amarant 时间: 2013-03-19 22:17
码农都有一些优越感，自以为是。非常骄傲自大，花了半天时间实现了一个功能，还挺得意洋洋。一看，原来就是一个库函数。我觉得谦虚是最重要的

作者: LLLinux_c 时间: 2013-03-19 22:57
最怕就是不懂还装懂。{:2_179:}

作者: send_linux 时间: 2013-03-19 23:26
大家不要攻击领导啊.......

作者: yuanzh78 时间: 2013-03-20 09:06
我倒觉得不怕神一样的员工，就怕猪一样的领导！

作者: hanbing789 时间: 2013-03-20 09:18
回复 7# gvim

深有感触！

作者: godymoon 时间: 2013-03-20 11:33
软件开发也有木桶原理，一个人影响项目整体进度

作者: 刺客阿地 时间: 2013-03-20 11:48
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
答：靠吼。。。然后是到处找人谈话。。。没啥优势，一片乱麻。
2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
答：团队沟通，应该是相互协作，尊重团队中每个人提出的观点。
最好的方式就是在开发一个项目的时候，大家分工合作，紧密配合。
团队领导应该起到协调沟通的核心作用。

3、说说您遇到的最差的团队合作经验

答：最差的就是团队成员无组织，无纪律，一片乱麻的，各管各自的开发进度，相互之间交流少，团队项目管理领导缺乏流程控制和管理。

作者: 孙轩 时间: 2013-03-20 12:41
本帖最后由孙轩于 2013-03-20 12:44 编辑

我想说就算是猪也是可以拿来做粮食储备的

所谓不怕神怕猪的说法,我觉得是逃避了自己的责任,如果你找了这样的队友,你不知道该让他做什么不该让他做什么么?就算他一无是处也可以作垫脚石啊,所以怕的不是猪怕的是你不认得谁是猪和你不懂得养猪.

至于项目合作主要就是交流.而交流主要在于互相的了解,如果两个仇人在一起你还指望他们能很好交流么
?所以首要工作是调整项目成员的心理状态和态度.其次就是项目的规划和安排.

作者: Godbach 时间: 2013-03-20 13:28
回复 25# send_linux
茂哥担心歪楼了。领导也是队友。

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

作者: dzminglong 时间: 2013-03-20 13:29
这句话说到心坎里面去了，真怕猪一样的队友

作者: pitonas 时间: 2013-03-20 15:00

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

深有体会啊

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

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

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

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

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

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

作者: 蛇窝里的老鼠 时间: 2013-03-20 15:44
目前还么有遇到此类情况，新手入职，对业务逻辑还不熟，许多都得和经理那边现学呢

作者: yang505982 时间: 2013-03-20 16:57
本帖最后由 yang505982 于 2013-03-20 17:12 编辑

非常赞同
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 时间: 2013-03-20 17:59
今天就因为说了这句话，被同事很批了一顿，犯了众怒

作者: thaldn 时间: 2013-03-20 20:41
怕个个都是神，不怕个个都是猪

作者: send_linux 时间: 2013-03-20 22:01

thaldn 发表于 2013-03-20 20:41
怕个个都是神，不怕个个都是猪

这话精辟，嘿嘿，一般来说，这种情况在团队里比较多，个个都牛逼哄哄的。。。。。。

作者: yang505982 时间: 2013-03-21 00:49
本帖最后由 yang505982 于 2013-03-21 01:59 编辑

其实不是我们有多牛，而是这样的队友太糟糕。
身边真实的例子：
(1)某产品经理，好几次提出，不允许安装第三方软件。研发老大也曾提过。
可是你们有谁听说过，智能机不能安装第三方软件的？
我们当然会反对。我们的机子本身有的就几个软件。真从来没听说过智能机这样做的。
如果一定要这样做，下面的人会去解决。但真要这样做？
对于这样的队友你认同吗？

(2)"短信"想完全自己开发，放在第一位的是界面一定要很漂亮，但基本功能都不全。
"短信"----不能发彩信，不能发附件，不与系统本身的兼容。很多基本功能没有。
更可气的是，连安装第三方短信软件(功能齐全)也用不了(因为系统被修改了与原来系统不兼容)。

(3)官方文档明确说明是这样的，他却另一套做法，所以最后总出问题。测试通不过。

(4)编译中有问题，跟他说这种情况, 先 make clean 再重试。很简单可以验证的呀。结果却是被说"不能这样，这是瞎搞"。真他妈的无语。

(5)确定程序A当调用接口B时，a就退出。(具体是什么程序什么接口就不说了点到为止)
但后面为显示其想象有多么好，所以其竟然建议让上面老大要求下面的人添加一个功能(非必要的)，这个功能中有 a调用B接口。但这样做之后会导致A程序会退出。所以当时就提出不能这样做，却被骂得个狗血淋头。又一个说是总是跟它对着干。
最后A程序负责人向项目组所人包括老大发了邮件,说明情况，请示确定要这样做？最后连邮件都不回。
(很明显的逻辑问题)
。。。。。。。。
框架方向明显有问题了, 难道还看不出来？方法明显不对告诉他却反过来说别人的不是。哈哈，真牛逼。

我们能做什么？挺多能提出自己的意见建议，一个问题最多3次，就沉默了。基本上是有这样的，提出10次，7次被毙。
但是有个问题，eg.有10次(实际上不只10次)这样的明显错误，我们提出来的。那至少是与其不同意见的有10次。

最终结果是被说: 总是反对，总是顶着。

这样的事情发生很多很多。

讨论讨论, 不过大家应该不难发现：一般有事没事对别人指手划脚的，对别吼的，不懂装懂的，闹得最凶的不都是那些最无理取闹的？
而一般真正厉害的不会这样的吧。

我也做过项目老大，但在这个项目里我不是老大。

前面有位仁兄 newbiez 提到：如果发现自己的下属里有不符合这样要求的人，及早放弃。
哈哈，在此也提醒：如果发现自己的团队里有这种那么糟糕的人（包括老大），而自己又不能改变的，那就适应这个糟糕团队吧，要不就及早离开。放弃是双向的。
一个项目最终如果失败，问题最大的一般是在那些不懂装懂的人以及出现决策出错的人那里。
别跟我说老大们见过多少世面，做过多少项目怎么会决策出错? 事实就摆在那里。
不懂没关系，后懂也没关系，不懂装懂以及决策出错才是大问题。
我不是牛人，但cu里牛人还真不少。群众的眼睛是雪亮的。群众会批判。
在此讨论,不是针对哪个人，而是针对“ 不怕神一样的对手，就怕猪一般的队友”进行的讨论。
如此一说只是因为工作十几年经历太多，看得太透，有些事情说出来与大家共勉。当然有说得对与不对的，欢迎批判。

作者: u239 时间: 2013-03-21 09:18
“神”你都不怕，“猪”你却怕。为什么呢？

作者: newbiez 时间: 2013-03-21 09:27
回复 42# yang505982

很明显，这个项目经理把技术决策作为他显示自己权威的一个手段，这也是我常常发现的。。。。。。不少公司喜欢把技术能力强作为项目经理的充要条件，于是项目经理也把技术决策作为自己的责任之一。任何对他技术决策的质疑都是在挑战权威。于是我发现，在这样的项目组里，即便是给他的手下安排更多的技术高手，你还是会发现整个项目的技术走向还是由项目经理说了算，哪怕项目经理的决策是错误。。。所以我强烈的感到，必须解除项目经理的技术决策权力，释放到技术经理、专家小组身上。

作者: 流氓无产者 时间: 2013-03-21 09:27
神虽然难管，但他认为该做的东西，还是会高质量的完成，可猪呢？
你不但要管各种预料不到的困难，还时不时专门留出时间去照看他们
，为他们擦屁股；他们存在的意义就是为你重写争取时间

作者: frogoscar 时间: 2013-03-21 09:28
队员需要好学，负责人，体力好

作者: frogoscar 时间: 2013-03-21 09:29
负责任，有大局观

作者: arkkangfeng 时间: 2013-03-21 13:36
就怕这样的：
1、领导总要加功能
2、领导总说怎么怎么做
3、出现问题队友直接说“不是我的问题！”

作者: wingasun 时间: 2013-03-21 16:55
说的很好，非常赞同你的想法，作为一个团队来说首先是对队友的信任与帮助，如果连自己团队里面的事物都沟通不好的话，团队工作怎么能顺利进行。
所以一个好的的团队需要牺牲个人性格来配合的。
至于影响团队的个人，需要的就是团队领导者的管理来进行调配，这就是考验管理者的大局观。

newbiez 发表于 2013-03-20 15:39
看了前面的留言，想额外说两句，
1）外行领导内行并不可怕，而且大多数专业管理人员都不是技术出身。就像你 ...

作者: 枫影谁用了 时间: 2013-03-21 17:05
优化团队。

作者: xdsnet 时间: 2013-03-21 21:07
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
交流工具进行沟通，部分有据可查。
2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
利用规范的文档进行正式沟通，利用直接交流进行非正式沟通或补充沟通。这样重要沟通有依据可查证，也不失沟通的灵活性。
3、说说您遇到的最差的团队合作经验。
完全是口头命令，一点不落实到文档，出现问题后互相推诿。

作者: 2gua 时间: 2013-03-21 21:18
这本好书，推荐推荐之！

作者: hbsycw 时间: 2013-03-22 13:42
回复 7# gvim

小公司靠人情沟通，中等公司靠制度沟通，大型公司靠文化沟通

不错，赞一个~

作者: Hongqiyaodao 时间: 2013-03-22 13:49
提示: 作者被禁止或删除内容自动屏蔽

作者: patagonia 时间: 2013-03-22 13:55

hbsycw 发表于 2013-03-22 13:42
回复 7# gvim

小公司靠人情沟通，中等公司靠制度沟通，大型公司靠文化沟通

看来我们是小公司，全是靠人情啊
制度形同虚设

作者: hbsycw 时间: 2013-03-22 14:01

send_linux 发表于 2013-03-19 23:26
大家不要攻击领导啊.......

哈哈，这个话题领导绕不过啊，管理员，你怎么看领导的沟通啊？

作者: hbsycw 时间: 2013-03-22 14:03

fengzhanhai 发表于 2013-03-20 15:12
1、外行领导内行；2、不懂装懂，瞎指挥；3、排除异己、带头拉帮结派；4、出现问题需要承担责任时找替死鬼开 ...

深刻，顶你~

作者: hbsycw 时间: 2013-03-22 14:07
回复 40# thaldn

见解独到，精辟~{:2_170:}

作者: emperor9 时间: 2013-03-23 01:11
本帖最后由 emperor9 于 2013-03-23 01:22 编辑

个人观点：

首先，这个标题就自相矛盾。这样的句子是有伤团结的。作为一个团队，第一要做到的就是：相信自己，相信队友。我们应该都看过些电视剧，许三多假如不是队友的帮忙，不是队友的团结，不会成为优秀士兵。再看竞技圈子里，假如打篮球的5个人相互不信任，那么必败无疑。南橘北枳，良好的团队氛围对个人的影响也是很大的。团结是一个团队很重要的气质。“兵熊熊一个，将熊熊一窝”，“判断一个学校的好坏，先看看校长怎样”。一个团队是什么样的气质取决于这个团队的头，而不是某一个兵。

其次，就一个软件项目来说，相对比较重要的是决策者与组织沟通者。我以为，当下最为缺乏的是优秀的架构师，虽然有那么多人顶着这个称呼。一个优秀的架构师的特质：
1）思路清晰
2）有很好的大局观
3）充分理解客户需求
4）对问题的分析和处理专业与简洁
5）有码农背景

再次，当下还缺少优秀沟通者。一个优秀的沟通者要做到：
1）了解客户需求
2）把客户的需求准确无误的带给架构师
3）与架构师讨论可行性与可选方案
4）把结论准确带给客户，讨论后定出需求解决方法
5）和客户，和开发者，保持良好沟通，总是在状况中

事实上，我们最为常见的情况是：
1）架构师陷入代码泥潭
2）架构师对整个市场需求了解不够
3）架构师从代码/机器语言角度达到客户需求，忽视产品使用友好度。
4）沟通者无条件接受客户需求，把需求扔给开发者
5）沟通者无法切入问题，在状况之外

最后，作为程序员，要做的是，尊重自己，爱护队友。无论ta怎样，不要学文人相轻，要学艺人互捧。正如歌中唱的：码农何苦为难码农

。。。

作者: dozol 时间: 2013-03-24 13:41
领导很关键，没有好领导，没法做到各显神通就严重影响团队

作者: yasin635 时间: 2013-03-25 09:03
最恨就是摆架子，好像世界他一个人最nb一样，其它都不屑于顾

作者: fyyizu 时间: 2013-03-25 09:27
核心代码复杂算法所有的能不写注释都不写注释，各种项目，不管怎么设计的需求文档都是一个模式，不管实现成了什么样子，什么设计文档部署文档，一概没有。这很坑爹有木有!!!

作者: 归隐乡村 时间: 2013-03-25 17:45
本帖最后由归隐乡村于 2013-03-26 11:07 编辑

来的有点晚了！顶一下帖子！主题很好！觉得自己拖IT行业的后腿了。严重拖后腿了！

作者: jwnydy 时间: 2013-03-25 17:53
之前就有同样的困惑，更甚者是，不怕猪一样的队友，就怕连猪都不如（根本的就不干活）的队友，该怎么办呢？？？:wink:

作者: xike2002 时间: 2013-03-25 21:40
本帖最后由 xike2002 于 2013-03-25 21:40 编辑

1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
答：涉及到团队共同问题的话，一般都是找个会议室，团队成员都来参加，每个人提出自己遇到的问题，然后共同讨论给出解决方案，如果没有讨论出结果的，下来再讨论。
如果是个人遇到的问题，可以单独找相应的人去讨论，这样可以省去大家的时间，因为时间是宝贵的。最烦的就是每周都要开个例会，不管是否涉及到该人，所有人都得参加，这其实是在浪费大家的时间。因为我们沟通是为了解决问题，但是假如问题根本不涉及到我，我为什么要参加呢。一定要做到高效沟通，效率很重要。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
答：就事论事，随时可以沟通和交流，不要拘于形势，越简单越好。

3、说说您遇到的最差的团队合作经验
答：团队中各自为战，最后事情越做越杂，后果难以想象。

作者: mz198424 时间: 2013-03-26 07:50
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
第一，每两三天开一个汇报进度的会议，大家看看其他人都在做什么，这样不会有重复的工作做同一件事。
第二，有一个统治式样和进度的BA，大家所有的问题汇总到他那里，由他形成文档，和整个项目组共享。
第三，大家都坐在一起，有问题，随时可以相互沟通。
我觉得这样的优势是可以随时共享每个人的信息，每个人都知道项目的进度，不做没用的重复工作。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
有问题，能够在第一时间得到反馈和确认，还有别朝三暮四就行。
团队最重要是还是团结啊。。。

3、说说您遇到的最差的团队合作经验
大家都不知道对方在做什么，做了很多重复的工作。
汇报进度的时候有虚报的现象，让项目经理无法掌握正常进度。
有汇报多的，有汇报少的。
项目组内，组员不团结，自己为战。
这是我一次最失败的项目，好在最后还是顺利完成了。

作者: 木头小飞 时间: 2013-03-26 09:05
沟通肯定最重要。

作者: lzzfriend 时间: 2013-03-26 14:09

1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
大家各提一个方案，讨论，选一个最好的方案为框架，在这个方案上优化，文档确定下来
小的事情，随时找大家一起讨论

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
目前人少，目前，个人感觉还行

3、说说您遇到的最差的团队合作经验
不懂装懂，更可怕的是，还是老大

作者: fergon 时间: 2013-03-27 07:53
我不怕神一样的，也不怕猪一样的，就怕事后各种小鞋的！

作者: shan_ghost 时间: 2013-03-27 14:49
先转一个（嗯，我也曾在这样的公司做过……不过没这个严重。所以很快就辞职了。而且决定今后绝不再和任何国营企业打交道。）：
http://www.robinlu.com/blog/arch ... binlu+%28robinlu%29

Asshole Driven Development
by Robin Lu on Jun.21, 2007, about pm
Scott Berkun，The art of Project Management的作者，最新总结出一套开发方法，是那么的似曾相识：
Asshole Driven development (ADD)
团队中重大决定掌握在最操蛋的人手里。所有的智慧、逻辑和流程在Mr. Asshole到来的一刻都灰飞烟灭。也许有规则，也许有process，但被Mr. Asshole全部打破，其他人只有跟随。
Cognitive Dissonance development (CDD)
团队里存在两派，对于产品应该如何完成有着截然不同的观点。两股势力在各种会议和表达个人意见的时候都表现出强烈的冲突(war meeting, there’s a name for such thing)，完全只按照个人意愿来定义项目。
Cover Your Ass Engineering (CYAE)
我们所做的一切只为了不让屎盆不扣在自己头上。
Development By Denial (DBD)
大家都假装自己有办法搞定，事情发展一切良好(The future is so bright….)，而实际上早就乱成一团糟。事情越糟糕，大家越不愿意承认现实，这成了他们能够让自己解脱的唯一方式。
Get Me Promoted Methodology (GMPM)
大家做这做那只为了让自己更醒目，满足老板的奇思怪想，让自己能够快点升职。他们可以为此人为地制造麻烦借此创造英雄，做立竿见影却后患无穷的鲁莽修改，做表面文章胜过创造真正的价值。
当大家都清楚自己在创造垃圾却无法摆脱，当最重要的事情是迎合你的老板，当只有踩倒了别人你才能再上一步，你还能做什么？

作者: shan_ghost 时间: 2013-03-27 15:57
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？

目标，解决方案，开会讨论……
优势是目标相对明确；缺点是常常出现没有方案的空对空讨论（继而导致过于深入细节）；阶段性成果常常说过就忘。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？

目标，方案，子任务与责任划分，接口讨论，周期性反馈

首先，由项目经理/市场提出需求，确认目标

然后，由技术专家（架构师）给出方案，在会议上讨论（由相关方面专家确认方案的可行性）

之后，划分模块（子任务），要给出（原则上）每个模块的输入输出数据（内容及格式，要求完整且最小）

然后，分配子任务给团队中最合适的人（做细化设计）；方案可由技术专家和/或技术专家会议评估可行性

有了大致的细化设计方案后，通过会议反馈，看安排给每个模块的输入输出数据/接口是否合理、在这些数据/接口的支持下，是否每个人都足以完成任务。
——这个步骤可能需要多次反馈。这种反馈甚至可能持续到项目结束。
——但，原则上，每次反馈应该不会有太多修改，尤其不应有可能影响其他模块设计方案的修改（这往往意味着总体方案出现了严重问题

当方案细化到一定程度，即可制定开发计划并开始编码（事实上，细化方案本身就是较大的框架性编码；且细化时，发现不能确定的问题[如第三方库究竟能否提供某种支持]，都应列入风险和/或试验确认）。

整个流程中间，角色定位必须准确。如：PM要跟踪项目进度、制定计划、确定里程碑；架构师要保证方案对需求变更的弹性；技术专家负责可行性评估论证；每个子项目的负责人/设计者要完全理解分给自己的任务，并给出（或由技术专家给出）实现方案。

总之：
首先必须权责分明；
其次，会议必须以（某个角色的）方案为中心，结论应该是行或者不行（而不能在会议上做设计）；
最后，方案的行与不行，是针对对方给出的接口/数据能否满足自己的需求而谈的；结论应该是增加/修改接口和数据。除非方案本身出现重大漏洞，导致它不可能实现；否则，方案的可行性/好坏，只能在专门召开的、有技术专家参与的、以评估方案可行性/风险本身为目标的会议上，才可以谈论（以避免把接口评估/讨论变成指手画脚）。

3、说说您遇到的最差的团队合作经验

某电信合作伙伴公司里遇到的。

首先，没有设计。
最常见的抱怨：你都不问问我，就自顾自把程序写出来了。
原因是：虽然他给你了详细的接口要求；但实际上，他的方案根本是一团糟。这个接口不过是个幌子。里面猫腻藏太多了，不听他讲，你就不可能知道需求究竟是什么。

其次，以权力代替技术。
很简单点东西，头自己琢磨许久许久……然后，就一个回调函数，他能用A3纸打一幅图出来；然后，你还不能看着这幅图做。因为接下来，他的解释能再画3幅这样的图。
就这样，人家还特自豪：UML是白领用的，太厉害了。以后就是白领做设计，UML生成函数空壳，蓝领往里填代码——而且，代码自动生成技术越来越高，蓝领会被淘汰的！
——不好意思，他这个200多人5000万做两年都没戏的项目，我后来3个人1个月就把核心搞出来了。

至于其他如办公室政治……参考前面的转帖吧。

作者: 瀚海书香 时间: 2013-03-28 13:06
回复 1# send_linux
最烦接手垃圾的代码

现在的项目开发都是团队开发，需要大家能够在同一个知识面上和代码规范上，否则很难进行代码交叉走查和测试。

作者: wonghoifung 时间: 2013-03-28 14:46
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
视频会议，美国程序员和中国程序员，毫无优势，时差太大，不过可以锻炼英语

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
面对面

3、说说您遇到的最差的团队合作经验
经常被要求严重加班

作者: qinyiwang 时间: 2013-03-29 18:19
1、您所在的团队现在是如何沟通的，您认为这样是否有优势？
每周所有成员是有1-2次集合的开大会，讲进度，分配任务等。当项目紧张的时候每天早上主要成员都要小小碰头一下汇报进度。平时工作么就都是干活的一块儿讨论，实在拿不定主意的才会有上报，PM在有事情的情况会单独个人讨论或者要下班了关心一下项目进度。另外PM要求一些邮件的讨论要把他CC上但是不太做的到，一来有些简单问题让他看到了反而复杂化，二来关键问题他反而不给回应。

我认为这样没有什么明显优势，不过对项目进度还是能保证的，PM等领导还是没有管到点子上。

2、您所期待的理想的团队应该是个怎么样的沟通交流方法？
还是PM等领导要多关心项目进度和质量。碰到有难的地方，可以大家讨论或者请其他项目组的“外援”啊。PM最好是技术出身的，不会乱提哪里需要什么花里胡哨或者实现不了的修改。每个任务分配到个人，再安排时间进度表。最重要的事团队成员各司其职，也要能相互帮忙。

3、说说您遇到的最差的团队合作经验
先是乱七八糟听也听不懂的需求出来，没有专职BA是PM听了按自己理解讲的。于是开发各种敷衍作出的产品bug很多，连拿来用作demo都拿不出手。再和客户一确认，人家说根本要做的不是这个，PM跟大家解释说他听着就是那样，但现在应客户想法要求再改，一点道歉的意思也没。大家心里都很凉。leader宁可在那里“嘻嘻哈哈”也不给你指导一下，还把自己的工作分配给别人做完了以后共享出来上面只写她自己的名字。最后PM说感谢她一个人的辛勤劳动。哪里完成得不好或者文档里有个明显错误，那就是为什么我没做好，而leader因为很忙没看你的所以你必须每个都什么什么认真对待。总之就是上梁不正下梁歪，基层员工受欺负。双份工作半份钱，为人作嫁背黑锅。

作者: linuxfellow 时间: 2013-03-31 01:43
能把这样的观点拿到桌面上讨论, 可以说是软件行业的悲哀。

作者: hello_ketty 时间: 2013-03-31 12:42
各楼说的都非常好，鄙人非常赞同也深有同感，但就目前我的处境来讲，我更希望的是部门之间的沟通能够达到一种无缝连接的程度，
在一家公司里面各个部门之间应该是相互扶持，而不是自命清高、不可一世，只有各部门之间能够团结一致，才能够创造更大的效益。

作者: howge 时间: 2013-04-02 16:57
回复 23# amarant

你这是一竿子打翻一船人啊

作者: chinaunixspring 时间: 2013-04-07 11:16
不论公司大小，讨论时的一些礼节都是不能废的。

作者: 耗资喜欢猫 时间: 2013-04-15 09:34

chenyx 发表于 2013-03-19 20:23
支持下,不做开发,看看大家的高论.
楼上说的有一定的道理,外行指挥内行确实很可怕,目前环境如此,也只能忍受 ...

刚起步的公司，这种奇人很多

作者: dell-sz 时间: 2013-05-21 10:42
提示: 作者被禁止或删除内容自动屏蔽

作者: kdkgod 时间: 2013-10-08 10:45
ding2

作者: kook20464811 时间: 2014-01-24 14:39
兄弟，你是在国企吧？

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

作者: zhj1011 时间: 2014-01-27 10:02
更怕猪一样的领导

作者: send_linux 时间: 2014-01-27 14:38

zhj1011 发表于 2014-01-27 10:02
更怕猪一样的领导

兄弟这是没有领到年终奖的节奏么？

作者: zhj1011 时间: 2014-01-27 16:45
回复 84# send_linux

哈哈这是我在以前单位的深切经历啊

作者: bskay 时间: 2014-05-13 16:30

gvim 发表于 2013-03-19 16:23
不知是谁概括的如此精辟的一句话。深有体会啊

1、您所在的团队现在是如何沟通的，您认为这样是否有 ...

你这个X总和让小狗做银行行长也能赚钱是一样的了...................

作者: zhendehaoren 时间: 2014-05-13 19:48
水平再高，开始也像猪一样，中国人喜欢鄙视同类，鉴定完毕，本人是工作了6年啥也不是的研究生，写c写吐了，敢说我水平次？

作者: zhj1011 时间: 2014-05-15 13:51

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

深有同感，切身体会啊！

作者: bandaotidejia 时间: 2014-09-17 14:33
中国人就喜欢窝里斗，来个老外就傻逼了，把人家膜拜的当上帝，当然来个印度人和美国人，对待是不一样的，骨子里的势利眼

队友再笨也不能叫猪，懂不？

作者: smalloc 时间: 2014-10-03 21:10
3、说说您遇到的最差的团队合作经验
那都不叫合作了，叫相互坑，相互压榨。。。

作者: chuwuwang 时间: 2014-10-08 22:24
顶10楼啊，说的对啊.....

作者: chenhengjin 时间: 2015-03-06 12:15
老总:今天写一个软件设计报告出来
程序猿:好的
。。。两天后

程序猿:报告写完了，您看看
老总:这里，这里，还有这里要改，要写清楚
程序猿:好的
。。。N小时之后

程序猿:改好了
老总:我想了想，应该还要改
程序猿:好的

...N小时之后

程序猿:改好了
老总:这个还是有点问题，我有新的想法，改一下
程序猿:好的

。。。N次之后

程序猿:改好了

老总:等我跟其他评审团的商量之后再改，先放在那里。。。。。

作者: send_linux 时间: 2015-03-06 22:51

chenhengjin 发表于 2015-03-06 12:15
老总:今天写一个软件设计报告出来
程序猿:好的
。。。两天后

这么惨，估计砍人的心都有了，哈哈

作者: jd808 时间: 2015-03-10 12:05
懂得如何尊重别人比什么都重要,项目经理,策划,不管你如何牛,你不懂得如何尊重技术人员,吃苦的可是你自己,技术人员不懂得尊重策划和项目经理,照样很憋屈,放开心态,相互尊重,在工作中寻找共同点,一起开心工作最重要,压迫对方工作迟早出问题.

作者: jd808 时间: 2015-03-10 12:08

流氓无产者发表于 2013-03-21 09:27
神虽然难管，但他认为该做的东西，还是会高质量的完成，可猪呢？
你不但要管各种预料不到的困难，还时不时 ...

一个项目有项目经理,小组组长(分策划,美术,技术),如果技术出现猪,技术组长就应该安排他做些非常简单的工作,甚至就安排他写文档,做辅助,再不行开除,这样安排就不会有猪了,有猪存在是因为管理不善,小组组长的责任应该要背起来,除非你在项目里没有发言权,那这个项目就必死无疑.这是我的经验.

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)