logo
当前位置:首 页 > 杂侃 > 查看文章

发布一个软件,需要多少人?

杂侃 你是第2480个围观者 0条评论 供稿者: 标签:

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

有时候我在工作中嘲笑我们的项目牵扯了太多人。这个项目大约需要三个月,包括我和另一个程序员还有 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,来发布一个只需两个程序员的作品吗?

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

说说梦想,谈谈感悟 ,聊聊技术,有啥要说的来github留言吧 https://github.com/cjx2328

—— 陈 建鑫

陈建鑫
footer logo
未经许可请勿自行使用、转载、修改、复制、发行、出售、发表或以其它方式利用本网站之内容。站长联系:cjx2328#126.com(修改#为@)
Copyright ©ziao Studio All Rights Reserved. E-mail:cjx2328#126.com(#号改成@) 沪ICP备14052271号-3