锁定老帖子 主题:如何在公司里舒服的活着
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2011-04-24
技术非常重要,当然也要看应用类型,只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势,有时意识到也不会做投入,因为不好报表化度量的利益不是自己绩效的砝码,而付出的成本却是真金白银
所以需要转化角度给决策者看,拿出数据效益数据,如果和钱沾上关系更好 |
|
返回顶楼 | |
发表时间:2011-04-25
ppgunjack 写道 技术非常重要,当然也要看应用类型,只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势,有时意识到也不会做投入,因为不好报表化度量的利益不是自己绩效的砝码,而付出的成本却是真金白银
所以需要转化角度给决策者看,拿出数据效益数据,如果和钱沾上关系更好 同意你的观点。但是偏偏那么多的程序员还用自己的眼光看问题,总觉得事情应该向自己期望的方向发展,也不分析下到底是该改变环境,还是改改变自己。不会变通的都是死脑筋,写出来的代码也是死的。再有,即便是用了很烂的技术,写出来很烂的代码,但是最终完成了项目,真正上线跑起来了,那也比整天强调架构啊规范啥的强,而且是本质的区别。楼上一仁兄说的有道理,第一次上线前谈架构啊设计啥的都是浮云,重构不是第一阶段的事儿。最后说一句,知道为什么“很多”程序员做不了老板么?不光是钱的问题,主要是思维,要是啥问题都非得那么理想才能搞下去的话,公司必倒。 |
|
返回顶楼 | |
发表时间:2011-04-25
呵呵,这贴要收藏,楼主跟我目前的状况极为类似,不过我劝你谨慎些,别急于搞社么革新。我找到路线是先把测试做起来,控制开发周期中的每一个里程碑,逐渐培养同事们的好习惯。
|
|
返回顶楼 | |
发表时间:2011-04-25
Eric.D.Chen 写道 说了半天,都是从程序员的角度看问题,无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的,想的都只是想把代码写好、架构弄好、所谓的维护省力,你难道不知道哑铃结构么,编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务,说白了,技术就那么回事,没想象的那么重要。
项目型的公司,确实是这样的,一家有长期计划的公司,不会这样,因为项目型的公司,接一个项目是一个活,可能下一个项目又是另外的业务场景甚至领域,技术积累不起来,无法形成自己的核心力量,程序员觉得自己没有完全发挥出价值,所以流动性很大,这样的公司是不会壮大的,壮大也只是靠转包商或央企吃饭。 国外的软件公司,与国内最大的不同就是注重平台开发,所以操作、编译甚至应用商店平台,这些最核心的东西都掌握在他们的手上,国内由于眼光的长短,意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人,因为您完全理解不了新生代的想法,他们要求自我,不服从领导,以实现自身价值为最大目标,想找听话的人,去60后、70后群体里去找吧~ |
|
返回顶楼 | |
发表时间:2011-04-25
Eric.D.Chen 写道 ppgunjack 写道 技术非常重要,当然也要看应用类型,只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势,有时意识到也不会做投入,因为不好报表化度量的利益不是自己绩效的砝码,而付出的成本却是真金白银
所以需要转化角度给决策者看,拿出数据效益数据,如果和钱沾上关系更好 同意你的观点。但是偏偏那么多的程序员还用自己的眼光看问题,总觉得事情应该向自己期望的方向发展,也不分析下到底是该改变环境,还是改改变自己。不会变通的都是死脑筋,写出来的代码也是死的。再有,即便是用了很烂的技术,写出来很烂的代码,但是最终完成了项目,真正上线跑起来了,那也比整天强调架构啊规范啥的强,而且是本质的区别。楼上一仁兄说的有道理,第一次上线前谈架构啊设计啥的都是浮云,重构不是第一阶段的事儿。最后说一句,知道为什么“很多”程序员做不了老板么?不光是钱的问题,主要是思维,要是啥问题都非得那么理想才能搞下去的话,公司必倒。 请问你是老板了吗?我把我的工作做好,难道也是错。为什么规范化后,就不能按时上线?这个主要团队努力就行,有人执行就行。烂的技术,写出烂的代码,你认为这样就能顺利上线吗?就算上线了,到时改bug等等,无休无止的加班。你希望看到那样的情况吗? |
|
返回顶楼 | |
发表时间:2011-04-25
RCFans 写道 Eric.D.Chen 写道 说了半天,都是从程序员的角度看问题,无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的,想的都只是想把代码写好、架构弄好、所谓的维护省力,你难道不知道哑铃结构么,编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务,说白了,技术就那么回事,没想象的那么重要。
项目型的公司,确实是这样的,一家有长期计划的公司,不会这样,因为项目型的公司,接一个项目是一个活,可能下一个项目又是另外的业务场景甚至领域,技术积累不起来,无法形成自己的核心力量,程序员觉得自己没有完全发挥出价值,所以流动性很大,这样的公司是不会壮大的,壮大也只是靠转包商或央企吃饭。 国外的软件公司,与国内最大的不同就是注重平台开发,所以操作、编译甚至应用商店平台,这些最核心的东西都掌握在他们的手上,国内由于眼光的长短,意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人,因为您完全理解不了新生代的想法,他们要求自我,不服从领导,以实现自身价值为最大目标,想找听话的人,去60后、70后群体里去找吧~ RCFans,言语挺暴力啊。 |
|
返回顶楼 | |
发表时间:2011-04-25
引用 请问你是老板了吗?我把我的工作做好,难道也是错。为什么规范化后,就不能按时上线?这个主要团队努力就行,有人执行就行。烂的技术,写出烂的代码,你认为这样就能顺利上线吗?就算上线了,到时改bug等等,无休无止的加班。你希望看到那样的情况吗?
程序员的思维往往是“把我的工作做好”就不会错,而实际上就是错的,因为这句话再具体点表述,就是把我<认为>的工作做好就是好,而不是把公司或者团队<认为>的工作做好就是好,之间的差异有可能是: 1、优先顺序不分,把对个人重要或者对个人方便的事情优先于团队 2、镀金,过于追求完美,反反复复做“好”一件事情,不考虑实际成本及客户反应 规范的项目不能按时上线是经常的,客户有个内部政治斗争很容易就毁掉个好项目 烂项目顺利上线也不少见,上线直接结项、收钱、换架构,开下一个项目,我就见过1年内同一个系统从A换到B再换到C,你认为上了线马上就下的B需要有多好的技术多少的代码? 现在的问题是要说服别人接受开发管理的改进,总站在自己的角度说事怎么说服别人? |
|
返回顶楼 | |
发表时间:2011-04-25
有3个事情需要处理:
1、客户总经理提出的界面风格问题 2、可能阻止关键业务正常完成的BUG 3、正开发到一半的需求 不同角色考虑的优先顺序: 程序员: 3、2、1 开发经理:2、3、1 项目经理:1、2、3 后面就不说了,越接近中高层管理,越可能支持项目经理而不是程序员的优先顺序 这个就是思维方式的区别 |
|
返回顶楼 | |
发表时间:2011-04-25
最后修改:2011-04-25
seeckt 写道 引用 请问你是老板了吗?我把我的工作做好,难道也是错。为什么规范化后,就不能按时上线?这个主要团队努力就行,有人执行就行。烂的技术,写出烂的代码,你认为这样就能顺利上线吗?就算上线了,到时改bug等等,无休无止的加班。你希望看到那样的情况吗?
程序员的思维往往是“把我的工作做好”就不会错,而实际上就是错的,因为这句话再具体点表述,就是把我<认为>的工作做好就是好,而不是把公司或者团队<认为>的工作做好就是好,之间的差异有可能是: 1、优先顺序不分,把对个人重要或者对个人方便的事情优先于团队 2、镀金,过于追求完美,反反复复做“好”一件事情,不考虑实际成本及客户反应 规范的项目不能按时上线是经常的,客户有个内部政治斗争很容易就毁掉个好项目 烂项目顺利上线也不少见,上线直接结项、收钱、换架构,开下一个项目,我就见过1年内同一个系统从A换到B再换到C,你认为上了线马上就下的B需要有多好的技术多少的代码? 现在的问题是要说服别人接受开发管理的改进,总站在自己的角度说事怎么说服别人? 这根本就不是同一个概念。我们在做自已的东西,没有什么拿不拿到钱。至于优先级,我们当然有过评估。不可能说什么都乱干了。做什么事情,我们都经过讨论,然后拍板。既然说我把我的工作做好,当然是boss希望做的。要不然当你提出来的时候,boss就会否掉。 |
|
返回顶楼 | |
发表时间:2011-04-25
最后修改:2011-04-25
seeckt 写道 有3个事情需要处理:
1、客户总经理提出的界面风格问题 2、可能阻止关键业务正常完成的BUG 3、正开发到一半的需求 不同角色考虑的优先顺序: 程序员: 3、2、1 开发经理:2、3、1 项目经理:1、2、3 后面就不说了,越接近中高层管理,越可能支持项目经理而不是程序员的优先顺序 这个就是思维方式的区别 这个我先来回复你一下。我的选择是1,2,3.如果是在线系统,那么是2,1,3.至于为什么,没有会愿意去得罪客户经理,并且1也是最快能出成果的。但如果是在线系统,关键业务完成不了就有问题了,所以优先级是第1. |
|
返回顶楼 | |