发布一个软件，需要多少人？

xman

英文：Andrew Wulf
译文： 伯乐在线 - Panblack
链接：http://blog.jobbole.com/102081/

“换一个灯泡需要多少个______？” 类似的笑话有无数个版本。



有时候我在工作中嘲笑我们的项目牵扯了太多人。这个项目大约需要三个月，包括我和另一个程序员还有 20 – 30 个其他人可以算进来。由数不清的副总（VP）经过大约 6 个月的评审之后，所有的需求都定妥了，但变更还是不断出现。 最重要的是，它跟另一个团队的项目没什么区别（但是代码却不能重用），而那个项目已经快要发布了。

为什么要这么多人？为什么大公司要用大团队做出不那么大的东西，这真是个谜。我得出的结论是，你给一个项目投入的人越多，你就需要越多的人来管理这些人，再加上管理这些管理者的人，等等等等。“团队越大，人数就越多；人数越多，团队就越大。”

回顾1988年，我们开发了 Deltagraph，在图表/图形打印细分市场曾处于领先地位。但整个团队只是 4 个程序员，还有一个负责我们项目的 QA，而软件发行商则有一个 QA 和一个产品经理。就这些人，做出的产品在大小和复杂程度上接近1993年前的 Excel。直到我们开发产品的最后一个版本时，发行商才给我们加了几个人。

我之前第三个工作是在一家知名旅游公司（可惜现在是别人的了），全球有1000名左右的员工。我们的移动开发团队有20个人左右，但是截至去年我们就提升销售额 15%，如果我们继续做下去将可以达到到 20% 。我们维护 7 个不同的应用（原生和web端）和一个移动 API。有QA，有产品经理，设计师和程序员，多数时间在一处工作，由一个经理全权管理。我们的 API 和 web 应用是自己在 AWS 上搭建的。公司其他部分在美国和欧洲各有一个主网站。我们每年平均发布 70 -80 次，主网站一年也改不了几次。

我以前讲到过一款app，我们用很少的人、花了两个月开发的，而且app会成为什么样一开始也无从得知（http://thecodist.com/article/the-most-agile-project-i-ever-did）。 (原网址如果无法打开，可参考 bing.com 缓存页（http://cncc.bingj.com/cache.aspx?q=the-most-agile-project-i-ever-did+thecodist&d=4922686905197225&mkt=zh-CN&setlang=zh-CN&w=8WQ-ihwlMl--lFe_hE0ZDV9ovgd25QKE） )

我作技术顾问（不是承包商）的时候，工作内容是帮助客户解决问题，经常是一个人同时当分析师，项目经理，架构师，程序员和 DBA，有时还不得不设计非计算机系统的流程。我记得我们用了近一年时间参与一个大项目，只有两个人，什么都做。

有时我惊讶于小型初创公司没有多少人、仅一点点管理就作出让人叫绝的产品，但由于我也有过类似经历，至少我能想象他们是怎么做到的。我一直认为最小规模的团队能实现卓越的产品，只要能掌控做什么、怎么做。通常大公司的情况是每个人都要控制所有事，大规模的精细分工，仅仅是为了让众多团队都能分一杯羹。

项目里的人越多，你需要的沟通和管理就越多，信息传递和问题报告就越慢。你必须用更多的流程来确保工作得以完成。当然，耗费的时间和金钱也更多，所以你经常要舍弃产品特性，只是为了把东西发布出来。任何需要管理一大堆人的负责人，都会担心难以预料的问题突然冒出来咬他们一口，所以决策就变得保守和谨慎。很自然地，这会让发布产品既困难、又费钱，而且经常拖延很久。再加上以前有着类似问题的项目留下的阴影，工作会更加的小心谨慎、慢慢吞吞。

相比之下，小型创业公司就不会受限于谨慎的作风、繁琐的流程、孤立的管理和忧虑。即使我们那个旅游移动项目组也甘冒风险，使用小团队、尝试 AWS 这样的新事物而不是自行建造一个帝国，尽管我们处于一个庞大笨重的商业实体内。我们是在这样的条件下做到的：在一开始就没有任何管理上的支持，只是希望把移动产品推出来赶个时髦，这使得团队保持精干，同时带来了越来越多的销售额。

看看政府项目，你会禁不住笑话他们，搞那么多人来管所有事情。我记得在咨询公司工作的时候，有两个人为美国国防部的一个项目工作，从主承包商那儿算下来，他们大概是四或五级分包商。经常的情况是，他们不知道发生了什么也不知道该做什么。最近的一个笑话是 TSA（Transportation Security Administration，美国运输安全管理局）花了 $350,000 做的 app，除了两个箭头和一个 random() 调用什么都没有，这个例子也太搞笑了。有个地方，我曾在那儿做架构师，他们有个项目我预估需要 2 个人周的编码。他们花了六个月、经过几十次的会议和一份 120 页的需求文档，得出了同样的结论。我们本可以把这 app 做十次还多，而那些人在会上都干了什么呢？



有些跟我合作的人，他们几乎没空写代码，总是被繁多的会议和电话缠身，根本无法再胜任工程师工作。时间都耗费在协调、解释、计划、争执和筹备那些一成不变的事情上，根本没有多少时间用于产出。

谢天谢地，在我整个 35 年的程序员生涯里参与的唯一一个大型团队项目，是在墨西哥的一次三个月的“死亡之旅”，结果最后什么也没做出来。有时候，你需要更多的人和更详细的计划，比如开发一个 OS，但多数时候更少的人始终是更好的。再强调一次，只要这几个人能掌控做什么、怎么做。你不能使用最小团队然后把流程、标准、报告和会议等一股脑的堆过来还指望他们出活儿。

我现在工作的地方，即使代码写完了，也还是要跟好几个小组见面、评审、填表、协调、得到不同的 VP 签字，才能进行下一步，哪怕发布到测试环境也是如此。搞这么多的流程真是疯了。我猜其他的地方也没什么区别甚至更糟糕吧，这也确实增加了不少就业机会。

我还肯定，很多人认为所有的这些审慎的复杂性是必须的，或至少让高层感觉更稳妥。有时候这些也许是必须的（我从未给核电站写过代码），但是我见过的所有大型团队项目里，多数从未真正让参与的人发挥全部作用。

如果你有一个具有大量自主权的极其精干的团队，你的成就将超出你的想象。但是公司是不愿意冒这个险的，他们更喜欢建立一个帝国，臣民的责任范围越来越窄，这样就能让更多的人参与，并且让领导层自我感觉重要。你真的需要创新/设计、动画、模仿、项目管理、产品管理、发行管理、开发管理、推广管理、运维、DBA、多层的QA还有其他我压根儿不知道的东西，加上好几层 VP，来发布一个只需两个程序员的作品吗？

我打赌你不会的。我怀念那些小团队、大产出的日子。

译者简介
Panblack：挺老的Linux新手