没人把程序员当回事儿

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

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

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

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

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

我也不认为开发人员没有任何责任。如果你看过电视剧Seconds From Disaster,你会明白,灾难的发生是一群人都没有做自己该做的事情导致的。 但是,我可看见程序员们都在做他们自己的工作。而其他人都在干什么呢?

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

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

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

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

[英文原文:LINK ]

分享这篇文章:

5 Responses to 没人把程序员当回事儿

  1. james says:

    说的不错,看来这种事老外也常干,呵呵

  2. jesse says:

    正相反啊,在我待的几个公司里最后做决策的都是程序,因为他们码的代码够神秘——只要你不能从其他同类业务中找到一个例子说明这项功能是完全没有问题的——程序就可以给你白眼说“这个很复杂,这个不能实现。”
    ……然后?你就等着把方案全部按照他的思路再整一遍吧。靠!
    如果这样还是不能在规定时间完成?那就完全是因为市场和设计人员的错误,“这群家伙根本不了解程序,写的文档根本不能用。”至于自己也曾参与甚至主导这个方案的编写,自然被无视了,“我只管编写你们设计好的方案。”
    靠!

  3. Yonghang Jiang says:

    嗯,作为程序员我试过这种情况:客户对市场说需要在两周内完成某个功能,我告诉市场来不及。不过我说,两周内可以完成一部分功能,可以先用上,同时我们在逐渐完善后续功能,在4周后再发布一次。

  4. dongguangming  这篇文章, 并对这篇文章的反应是俺的神呀

发表评论

电子邮件地址不会被公开。 必填项已用*标注