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

shan_ghost

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

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

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

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


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

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

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

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

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


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


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

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


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

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

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

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


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

瀚海书香

回复 1# send_linux
最烦接手垃圾的代码

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

   

wonghoifung

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

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

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

qinyiwang

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

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


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

linuxfellow

能把这样的观点拿到桌面上讨论, 可以说是软件行业的悲哀。

hello_ketty

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

howge

回复 23# amarant


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

chinaunixspring

不论公司大小，讨论时的一些礼节都是不能废的。

耗资喜欢猫

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

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