项目企划过程中,工程师要发出自己的声音

工程师的选择
服务器君一共花费了285.359 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

不知道多少人有这样一种经历:明明从技术上看是不对的或者说是不可能的,但还是要按照一种不对的方向做下去。至少我个人是有这种经历的。 

销售的和企划的定好了规格和日期,把他们都作为不可更改的目标发配给程序员。程序员明明知道不应该走捷径去赶进度,但给日程压的没办法,就只能赶啊赶。

在限定场景下,一个人所能完成的工作其实是个确定值,因此这时候能采取的手段其实不多:一个是加班,一个是降低代码质量。最终产品仓促上市,在市场上发现了很多问题---最终很可能仍被归结为程序员的问题。 

不知道大多时候,面对这种场景,工程师(包括开发和测试)会做什么样的选择?

我猜由于在这种多方博弈的时候,工程师的声音总是最弱的一个,所以大多时候,大多的工程师会选择忍受。

大致场景是按title一层层排下来的,最基层的每次都选择说yes。 先不管现实中这么做如何合理,但这样至少是对事业本身是不利的。很多事情往往只有身在现场的工程师才能清楚判断其是否合理,如果在这个环节没有声音,那么就没人知道实现层面是否有问题。

高级别的人也许大局观会好,但在实现层面是否有问题是不清楚的。一旦缺乏工程师的声音,那么商业需求,企业能的政治需求都会有影响力,唯有技术上的考量会被漠视。而技术这东西更像一支橡胶棒,很多人很多时候都可以弯曲它,达成自己想要的形状,但一旦达到某个界限后它就会反弹回来把所有试图弯曲它的东西砸个稀烂。 

所以说回来,我感觉在上面的情形下,工程师要理智的发出自己的声音,要能捍卫技术的尊严,而不能一直说是。 

当然最终的选择很可能和工程师期望的不一样,这也没有关系,责任和权利的比值应该是个常数,只要做选择的人也能负起相应的责任那错了也没什么关系。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1943,欢迎访问原出处。

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1943

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《C程序设计语言(第2版新版)》 克尼汉 (作者), 等 (作者, 译者), 徐宝文 (译者)

《C程序设计语言》(第2版新版)是由C语言的设计者Brian W.Kernighan和Dennis M.Ritchie编写的一部介绍标准C语言及其程序设计方法的权威性经典著作。全面、系统地讲述了C语言的各个特性及程序设计的基本方法,包括基本概念,类型和表达式、控制流、函数与程序结构、指针与数组、结构、输入与输出、UNIX系统接口、标准库等内容。

更多计算机宝库...