正在加载...

下文译自美国一位资深的Flash/前端工程师John Nance的博客“Never Trust a Programmer”,其中讨论了许多开发人员面临的最大挑战之一:如何与客户或者公司内的销售部门协商项目估算。全文如下:

编程对很多人来说有点神秘。这就造成了在公司内部,人们对编程的事情产生了很多怀疑和疑惑。 通常,当你不了解一个东西是怎样做成的时,你只能说:可能是这样吧。 如果你从没见过工地,你也许会认为几个星期就能建出一栋大楼。 事实上,在这样的时间内是可以完成这栋建筑的,只是能不能用就不知道了。 如果你看过房子如何建造,跟踪它的建造过程,你能从物理实物看到地基如何浇灌,钢架结构如何搭成,等等。 但给电脑编写程序,或建设一个网站却是不可见的。

除了程序员外,程序代码对其他人来说是接触不到的。程序的运行好像是大幕后发生的魔术戏法。 只有开发团队的成员才能知道程序是什么,怎么工作的,不能干什么。 从程序员的角度看问题,你就能得到最好的开发结果、项目评估数据和进度更新。 很多的A型性格的人对此不以为然,但事情并没有那么简单。

当客户提出他们想要什么东西,而且要在什么时候完成时,问题就开始出现了。 销售人员希望做成这笔交易。拜托,请告诉客户,他们的想法不现实,这个生意做不了。 这样做下去只能导致一场灾难。 我曾看见过销售部门把估算的工期消减一半,四处花钱去达成他们的销售,完成他们的任务。 直到最后有一天,事情的发展看起来都是程序员的错造成的。他们这样做结论是因为程序员是最容易责备的。

程序员们在学校里没有学过办公室政治学。他们应该学,当然这是另外一个话题了。 作为一个程序员,他需要集中精力,沉着的思考,去开发出清晰好用的程序。这是个困难的事,需要用去你全部精力。 程序员们没有时间去理会是谁背后给了自己一刀。可销售部门玩的这些把戏却有严重的后果。

我的前一个公司,一个百万美元的项目,热热闹闹的,像烟火一样,短暂的光华后就落地地上了。 什么原因?是这个公司指使程序员们每周工作70小时以上去完成客户专横的进度表导致的?还是销售部门对客户言听计从导致的?

我也不认为开发人员没有任何责任。如果你看过电视剧Seconds From Disaster(注:美国国家地理频道的一个系列节目,讲述了各种人为和自然灾害),你会明白,灾难的发生是一群人都没有做自己该做的事情导致的。 但是,我可看见程序员们都在做他们自己的工作。而其他人都在干什么呢?

那么,公司是怎么认为的?他们解雇或开除了所有的程序员。然而整个销售部却没事。 这次惨败的死亡之旅后,也没人愿意留在那里了。

程序员被打入地狱的过程都是有一个个的“遵命”铺就的。 为了对得起自己,对得起自己的职业,程序员应该警惕那些危险的事情。 评估分析,评估工作通常会花掉很多的精力。据我所知,这个比任何事情都要费神,它需要你从多个层面去考虑整个事情。 不幸的是,我曾亲身经历优秀的评估报告被驳回或修改。 评估的越符合实际,招惹的众议越多。

把符合实际的预期报告告诉用户是个困难的事情。这会使生意的成交增加困难。 程序员在承担其他人冒险的后果。程序员的工作从来不轻松。 事实上,程序员是一个公司里对这个事情看的最清楚的人。他们懂编码,知道需求业务。他们也许不善于和客户打交道,但他们却真正知道项目应该怎么做。

重视你们的程序员。他们不仅仅是个技工,他们也是懂业务的。 他们能凭借自己的经验判断出,是谁在为了留住客户而胡乱夸下海口。

这篇文章的英文原文曾经在Reddit等开发人员网站引发很多争议

得到回应最多的评论是:“企业IT项目真不是人干的。” 有人用企业IT=“IT+governance+audit+project+management+estimates+requirements+ J2E+cobol+xml+corba+the+microsoft+stack+sharepoint+biztalk+the+ ibm+oracle+bea+sap+stack+eai+esb+soa+bpm+6sigma+thedailywtf”的公式表示认同。

有人评论,合同是程序员和软件开发公司最好的武器。马上有人回应:开发人员往往不是签合同的人,很多项目合同协商过程中都没有开发人员参与。有人则表示,自己的很多客户都是公司内部的部门,这招不灵。

的确,我们都知道,软件需求变化叵测、难以捉摸,预先的项目估算往往很难准确,完全依赖合同,并不现实。

怎么解决这个问题呢?有人提议让公司的高层了解更多软件开发原理和流程,让销售人员以质量为由尽量争取宽松的预算。有同学很快尖锐指出,“很多情况下,都是钱的问题。这是没法解决的。”

你的看法呢?你日常工作中是怎样处理这一问题的?

: http://www.ha97.com/2611.html

本文相关评论 - 1条评论都没有呢

No comments yet.