作者:JSON_NULL

很多IT技术人员总是抱怨;说需求频繁变,老板瞎指挥,产品经理瞎指挥,客户经理瞎指挥。一个产品失败了,技术们总是能找到各种各样的理由。总之就是,我是程序员我没错。

难道真的是这样吗?难道真的是老板、产品经理和客户经理都瞎了吗?作为一个IT技术从业者,我必须说句公道话:是的,就是这样,他们真的都瞎了!

稍安稍安,不要拍砖,我只是开个玩笑。哈哈哈哈……

讲真,我在写代码的过程中,也遇到过一群人“站在身后”指指点点;慢时需求三天一变,快时需求一天三变;当时我真的认为他们都是一群傻X。我能预见软件做出来是个什么样子,我知道我再怎么努力我开发的产品也无法“成功上线”。但是我依然在埋头苦干,做着已经失败的项目。

对,最终我开发的产品还是上线了,然后听到了客户漫天的叫骂声。

作为一个程序员,我本能的为自己开脱。我清晰的记得每一次需求变更,并能说明其不合理性;我能列出每次是谁告诉我应该这样做或那样做,而产生了哪些bug。我还记得这个项目中我有多少次加班,每次加了几时几分。

好了,客户的叫骂已经与我无关。

真的就与我无关了吗?

如果是真的无关,那老板们、产品经理们和客户经理们就真的都是傻X了。

是的,老板们不傻,产品经理们也很聪明,客户经理也是牛人。但程序员们也不是二B。项目失败了,问题出在哪儿?

程序员的懦弱,对,就是程序的懦弱导致了项目的失败。当然这并不是全部。

作为程序员,技术经理,如果你在项目进行中看到了问题而不敢说出来,最终导致了项目的失败,那第一责任人应该是你。如果你在项目进行中没有看到问题所在,而在项目出了问题后,找那么一堆理由推脱,做一个事后诸葛亮,聪明的老板也不会留你。

因为我是一名IT技术从业者,所以我知道为什么他们不敢在项目进行中把问题说出来。

当产品经理说:我看xx平台有这样一个功能,咱们能不能也加一个?
程序会说:能是能,但是……。

在上面的对话中,程序想表达的意思是,我有能力做这样一个功能;但是我之前没有做过,需要时间去学习,需要时间去研究,需要时间去了解这个功能中会有哪些坑。总之,要做这个功能,你得给我很多很多时间做前期的准备工作。

但产品经理听到意思是,我们的技术能搞定。然后去给老板汇报了,或是去给客户答复了。但是时间在哪儿?只能程序员加班赶。没有时间学习,没有时间研究,没有时间去了解应该回避哪些坑。最终就只能掉坑里了。

当老板说:我觉得这个功能挺容易的,这周能上线不?
程序员会说:这个……也不太是容易,加加班应该差不多。

其实程序员心里在想,我去、老板都说容易了,我要说这周搞不定,老板会不会认为我能力不行;下次加薪是不是就没我的事了?

而老板听到的是,这个功能这周能上线了。于是给客户答复,或是给投资方吹嘘去了。

不再一一列举了,反正都是类似的场景。如果一个技术人员在公司无法挺直腰杆做事,那结果就应该是这样的。

作为程序员或技术经理,如果你能告诉产品经理这个功能可以加,但需要三个月的时间做前期的准备工作、或者是需要让人力资源部去招一个有相关经验的人来。我想产品经理应该会慎重考虑这个“需求变更”存在的必要性。

如果你能告诉老板,这个功能并没有他想的那么简单;看似简单的一处改动,会对哪些模块有什么样的影响,需要处理什么样的依赖关系,以及会产生哪些副作用。一个聪明的老板,应该不会再要求你本周上线这个功能吧。如果真的遇到了不聪明的老板,那你也没有必要再继续为他工作了!

对,第一步,从技术人员角度解决问题,我们需要先把自己内心最真实的想法讲出来。不要怕产品对你技术能力的质疑,不要怕老板对你技术能力的质疑;时间会证明一切。

当然了,老板们、产品经理们、客户经理们也需要学会如何与技术人员进行交流,只有大家共同努力才能达成项目的成功和客户的满意。

任何单方面的努力都只能暂时平复表面问题。

作为一位IT技术从业者,我不希望程序员和技术经理们是后知后觉者;等到老板、产品经理和客户经理都在努力学着怎么与技术交流并做出改变了,我们还在拖项目的后腿。

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

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