团队合作的神话

作者:陆麟
转载请征得作者同意.
2003.8.18

团队合作是件艺术品.

我是这种傻瓜之一. 给了我一个设备的DATASHEET. 我就努力地看, TRY, 直到写出的代码能让那个设备正常运行. 代码接口自然根据OS不同需要遵循规范. 有另外的MEMBER, 连用都没有用, 竟然就说接口有问题. 经过N次的MAIL来回, 原来这位精英自己设想了一个接口. 说是通用接口. 真是糟糕, 其实根本不通用. 甚至是不能用. 然而在争论中已经有N次不愉快. 精英同志的脸面问题得到了极大的挑战.

另外一个结局是原来这位精英的想法是正确的, 我这个傻瓜与精英争论了N长时间后, 发现原来他的想法虽然不符合OS的接口, 但是确实是更优秀. 经过N次的争论.努力的傻瓜终于被精英认为"无可救药". 日子一天比一天难过.

上面的例子相信多数人都碰到过. 无论哪个结局, 最终会有人面子上很过不去. 怎么长久保持融洽到成了团队合作的大问题. 然而, 我发现有1家公司, 他们的任务分配根本就是以1个人为单位. 对于多数的PROJECT, 只指派1个PROGRAMMER. 然后产出的文档或许由其他人合作, 如果有些调用可以被其他人员使用, 就写成LIB形式, 大家都能使用. 从工作效率和项目完成状况来看, 反而更胜一筹. 至于共享的代码, 用与不用, 取决与接受PROJECT的那位. 不用争论, 出了问题1个人兜. 我倒是觉得这样的模式在多数的中小规模的软件企业中更合适.

那些开口闭口应该怎么怎么管理的经理到多数是中看不中用的人.

小企业就是小企业, 不要学大企业那些条条框框. 团队合作对小企业而言, 障目的成分居多. 小企业能承受80%的时间用于沟通而不是PROGRAMMING上么? 一个人写1件产品, 花费1周. 分割了模块, 找了3个人写不同的部分. 就变成了花费1个月. 而接口的争执会再花费时间. DEBUG时间又要增加. 不要以为3个人中会有人愿意DEBUG其他人代码中的BUG. 这是不现实的.

在大企业中, 多少时间被团队合作所消耗, 一个每天能写100行C代码的人, 一年确只能产5000行代码都不到. 这就是团队的负面. 人越多, 效率折扣越大.