程序员的敌人

programmer

今天北京的天气简直好到爆,一整天下来,PM2.5的值就没超过25,俗话说好女不过百,好天不过25,就是这个理儿。吃完晚饭,出去溜了一圈,天高云淡,月朗星稀,空气中弥漫着初冬的寒意,远处的灯光闪闪烁烁,透过清亮的空气,似乎可以看到一丝丝的光线发散出来,感觉真好。北京现在没什么土,也没什么沙,估计很多年前的沙尘暴是难得一见了,所以我希望,这个冬天,让大风来的更猛烈些……

MacTalk 的读者中一定有不少程序员,今天的提问环节是:程序员的敌人是谁?

好吧,举手比较踊跃,看来平时被虐的不轻啊,这位同学: 「Mac 君,我觉得是项目经理,我看丫那个得瑟劲儿就想抽……」 「坐下吧,一会走的时候把怀里的板砖留下。觉得是产品经理的也可以歇歇了」

「Mac 君,我脚着吧,这事和人无关,应该是 bug 搞的鬼,上线时节 bug 纷纷,长使英雄泪满襟!」 「这个答案虽然有了点人文关怀,不过 bug 不都程序员写出来的吗,你不管谁管?」

插播:江湖传言,软件的不幸在于它创造出来的麻烦多过于它解决的麻烦。真实的情况是,软件只解决了一部分它创造出来的麻烦……

现在公布答案,程序员的敌人就是,当当当当,「需求」!

多少英雄汉,在程序世界里纵横四海独孤求败,结果被真实的需求碰球的鼻青脸肿头破血流黯然解甲,转售前的转售前,变甲方的变甲方,最可恨的是这些变成甲方的程序员,成了甲方之后开始用「需求」折麽其他的程序员,比甲方还甲方!原本同根生,相煎何太急!真特么像那只没抢到香蕉的猴子啊。

无数软件工程宝典、创业圣经和成功经验,都告诉我们,要想成功,挥刀自宫!哦,不对,要想成功,一定要满足用户的需求,做客户真正需要的东西。可是,你知道我们程序员想做到这一点有多难么?

首先,需求就分为了用户想要的(Want)和用户需要的(Need),其次,需求又分为企业用户需求和个人用户需求,第三,没有第三了。前两条就够我们程序员忙活一生了。

先说说 Want 和 Need,能够从 Want 直接转化成 Need 的需求简直凤毛麟角,你要遇到了就是你上辈子修来的福分,不当程序员天理不容。大部分情况下,Want 都是用户的谎言,他们不停的重复这些谎言,直到自己信以为真,然后告诉你,「兄弟,这就是哥的 Need,大胆的做吧,哥哥在岸上等着你」。等你费劲扒拉把这个 A 做出来之后,客户拿在手中把玩一番之后,会满脸歉意的告诉你,「不好意思啊,兄弟,我要的是 B,你给我做出个 A 来干什么?」。你呕血三升之后,客户终于把 B 描述出来了,告诉你,做,这次一定不会错!但是你永远不知道后面还有 C、D、E、F、G……在等着……

这是从外部客户角度,还有苦逼的内部角度。比如微软的演讲奇才狮吼功大师鲍尔默,他老先生在Surface发布时宣称 「……但购买这几款平板电脑(iPad、Kindle 等)的用户有可能犯了一个错误,这并不是他们想要的产品。」 「我不认为能有人像我这样意识到用户真正想要的是什么产品。你可以看看周围人们在用的那些平板电脑产品,没有一个是你真正能用的。苹果不行,谷歌不行,亚马逊也不行。没有一件产品可以既可以工作用又可以娱乐用……」 「Surface 才是用户真正需要的产品……」

不知道说这些话的时候老先生在用哪个脚趾头思考,我特么怎么不知道范了那么多错误?Surface的销量给了老鲍一记响亮的耳光,老鲍不干了。可怜那些研发Surface的程序员……

对于企业客户而言,几乎任何时候都存在 Want 和 Need 不对等的情况,我现在唯一能想到的应对之法就是「贴身服务」。再也不要打个包一百万让我们做 ABCDEFG 了,骗鬼呢?!单人单月报价,我们提供人员、技术、平台、工具、项目管理,您说吧,想做锤子还是锤子手机?按月付费,我陪您玩到天荒地老……

对于个人用户而言,如果你真的做对了,满足了用户的真正需求,可能有三种情况: 1、你是自己产品的真正用户 2、你运气不错 3、你是乔布斯

还有一点就是,为个人用户做产品不要让他们有太多选择,这些人不是程序员,不需要知道配置信息可以保存在 xml、注解、properties、json 中,这么多选项会让大家一起疯掉,给一个按钮就好了,就像 iPhone 那样。

Android 系统给了用户无限可能,但也被用户和开发者骂的狗血喷头。iOS 给了用户一堆限制和一个按钮,而且不能用 Flash,结果一个月以后,用户说:哦,原来我真的不需要 Flash!

「需求」如此残酷,值得为之奋斗!希望所有的程序员都能够做出真正满足客户需求的程序,十年后,我们的代码依然奔跑在千万台机器中,无数双手,在代码前挥舞……

4 thoughts on “程序员的敌人

  1. “单人单月报价”,我觉得这个只能是理想情况吧,销售打下单子,貌似就没人管了。
    客户基本都不知道自己要什么,就是让你先做出来看看,再提问题修改,而且是没得商量的。即便是“单人单月”了,我觉得让你加班,也是正常的。

      • “加班不可怕,可怕的是加班做出的东西没人用。”——–这句话不错

        程序员(其实不光是程序员,设计师之类的职位也是如此)很怕反复修改做无用功。虽然用户需求确实很容易变化改变,所以早期在跟客户确认需求时就应该让技术人员介入。

        不懂技术的老板(多半销售出身)觉得技术人员不会沟通,早期搞定客户不让技术人员介入,而销售又不懂技术,为了拿单子,什么要求都答应,什么需求都说很简单,很快能实现,然后程序员就悲催了。

        我有一个兄弟技术出身,后来自己开公司,拿单子的同时就直接确认技术可不可行,实在太难实现的就沟通拒掉。后来人员扩张了,自己不用亲自跑客户了,但他派出去销售的队伍里都会有个技术人员搭配,当场确认什么可行,什么不可行。做下来也不错,客户也都挺满意的。毕竟反复修改,程序员烦,客户就不烦吗?

        对于需求反复改变的局怎么破?我个人是觉得可以让技术人员适当的跨界去接触一些销售工作,毕竟技术人员学销售会容易些,而要销售学技术比较难(两者的门槛明显不一样,从职位要求学历其实也就能看出来,当然学历不是关键)。

        说到底就是通过跨界改变思维模式,只熟悉自己领域的东西,思维模式总会有局限性。需求反复修改,销售人员说技术人员能力不行,怎么这个不行,那个不能做,技术人员觉得销售人员不懂技术,什么要求都答应,做开发苦逼活的又不是你。谁错了,其实谁都没错,可都只站在自己的角度去想问题。当有人对两个领域都有了解(不需求都精通,就像刚才说打技术人员适当了解销售),可能新的解决方法就会出来了----销售搭配技术,如果技术的销售领悟能力高的话可以直接做技术销售人员,那还能省掉一个人力成本了。

回复 多蒙 取消回复

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