如何在公司里舒服的活着

人活着，有时候挺累的。最近在公司遇到了一些问题，引起了我的反思。我该操那份心吗？

说一下现在的情况。最近在一家互联网公司做系统架构师，上级是部门经理。新启动了一个产品线，有专门的产品经理，主要做需求.我和部门经理属于研发部，和产品部是两个不同的部门,分工还是很明确的。

按说我的工作主要是架构设计，主要是各种技术的调研，和系统需求的抽象功能化，以及各种技术规范的制定，还有技术框架的决定，以及核心功能的研发。但是我进这家公司时，已经启动刚进入开发。前期做得并不是特别好，比如各种技术规范不够统一，下面的开发人员风格各一，测试也不规范。基本上每个人的代码都是天马行空。

好吧，我进来了，可能由于以前做team leader的原因，我看着这种情况就不大舒服，想改进。想统一大家的开发风格以及开发的规范，细点说就是各种命名，各层的调用统一等。现在还有着比如spring里应该用xml配置文件还是全注解0配置的争议。还有vo是否应该用等等。当然这些每个人都有自已的道理，各种方式我在以前的项目中都有使用过，当然我也有自已的偏向性。

现在主要让我烦心的是，我把问题提出来了。ok,部门经理说，你来负责把这些问题处理一下吧。好吧，我的工作量来了。本来我就有任务在身，如核心功能开发、WebIM及搜索引擎的研发。恩，我加加班就挺过来了，没什么。但是关于上面这些一规定后，下面N多人的代码要修改，要统一，要花不少工作量，大家肯定会有怨言。有时真的是费力不讨好呀。

大家说我是轻轻松松的，什么都不管，大家爱干嘛爱干嘛，我每天完成我的工作，按时上下班就完事呢。还是发扬主人公精神，管管这闲事？

最新进展：公司内部有一次大的变动，问题也得到了CTO的重视，一些东西也慢慢建立起来。我的工作重心也由原来的一些复杂业务开发，转为专注系统级别的技术研发，如静态化、缓存、搜索引擎、异步消息服务、文件服务管理、redis、负载性能等。在人员配备及在时间压力上，还是很紧。大家只能大干一场才行了。整个团队的氛围现在还算可以，希望一切能够顺顺利利。其实很多事情还是得上面推动才行。
更新进展：公司原来技术副总监离职了，也就是我的直接上级，山雨欲来风满楼呀。下周有新的人空降过来。哥的希望在哪里？

评论

62 楼 Eric.D.Chen 2011-04-25  

peterwei 写道

Eric.D.Chen 写道

ppgunjack 写道

技术非常重要，当然也要看应用类型，只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势，有时意识到也不会做投入，因为不好报表化度量的利益不是自己绩效的砝码，而付出的成本却是真金白银
所以需要转化角度给决策者看，拿出数据效益数据，如果和钱沾上关系更好

同意你的观点。但是偏偏那么多的程序员还用自己的眼光看问题，总觉得事情应该向自己期望的方向发展，也不分析下到底是该改变环境，还是改改变自己。不会变通的都是死脑筋，写出来的代码也是死的。再有，即便是用了很烂的技术，写出来很烂的代码，但是最终完成了项目，真正上线跑起来了，那也比整天强调架构啊规范啥的强，而且是本质的区别。楼上一仁兄说的有道理，第一次上线前谈架构啊设计啥的都是浮云，重构不是第一阶段的事儿。最后说一句，知道为什么“很多”程序员做不了老板么？不光是钱的问题，主要是思维，要是啥问题都非得那么理想才能搞下去的话，公司必倒。

请问你是老板了吗？我把我的工作做好，难道也是错。为什么规范化后，就不能按时上线？这个主要团队努力就行，有人执行就行。烂的技术，写出烂的代码，你认为这样就能顺利上线吗？就算上线了，到时改bug等等，无休无止的加班。你希望看到那样的情况吗？

首先，我不是老板。
其次，“项目做的好不好”在程序员的眼中似乎与“能不能上线”是必然的联系，其实未必。
再次，任何项目都有成本，作为程序员你可以不考虑整个项目的时间成本，但是作为项目经理或者主管领导不可能不考虑。
第四，，作为一个项目团队的管理者，如果带的项目最后还得改无休止的bug、加班，说明这跟架构没多大关系，更大的可能性是管理导致的问题。没有不会打仗的兵，只有不会带的官。
第五，凡事都没有绝对，往往在程序员的眼里只有true或false，但是很多事情并不是这样，比方说一个项目的成功与失败就很难界定，关键是变通看矛盾。

61 楼 peterwei 2011-04-25  

Eric.D.Chen 写道

RCFans 写道

Eric.D.Chen 写道

说了半天，都是从程序员的角度看问题，无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的，想的都只是想把代码写好、架构弄好、所谓的维护省力，你难道不知道哑铃结构么，编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务，说白了，技术就那么回事，没想象的那么重要。

项目型的公司，确实是这样的，一家有长期计划的公司，不会这样，因为项目型的公司，接一个项目是一个活，可能下一个项目又是另外的业务场景甚至领域，技术积累不起来，无法形成自己的核心力量，程序员觉得自己没有完全发挥出价值，所以流动性很大，这样的公司是不会壮大的，壮大也只是靠转包商或央企吃饭。

国外的软件公司，与国内最大的不同就是注重平台开发，所以操作、编译甚至应用商店平台，这些最核心的东西都掌握在他们的手上，国内由于眼光的长短，意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人，因为您完全理解不了新生代的想法，他们要求自我，不服从领导，以实现自身价值为最大目标，想找听话的人，去60后、70后群体里去找吧~

呵呵，你先别激动，我还真就是80后人，你眼光不咋地啊。别动不动就国内国外的，你做过多少项目？成功过多少产品，不要一棍子全打死好不？“他们要求自我，不服从领导，以实现自身价值为最大目标”，如果这样的话你还是自己创业吧，别工作了，你以为公司都是给你开着玩的？任何公司都要有凝聚力才能发展下去，要是都像你说的这样各个都个性，项目怎么做？不要动不动就给自己贴个标签，别拿无知当个性。“RCFans”我不知道你是不是做管理岗位的，但从你说的话里我看不出大局观，你就以你自己为中心写代码吧。

回上面一哥们的话，我不是老板，但我是程序员，从我参与过的项目来看，不用像楼主说的那么悲观，凡事都有解决的办法。想要一下子做到最好本身就不现实，怎么也得有个过程吧？如果你项目组成员都是成手，都能按规范执行的话，还用担心这么多么？

其实吧，又有多少人能做老板呢。我也带过两个项目，很多情况下，也是不管三七二十一，上线就好。但人总要有点追求吧。在保证能顺利上线的基础上，又能做好，有什么不好的呢。当然，底下开发人员可能会心里骂娘。但是我想他们会慢慢理解的。

60 楼 Eric.D.Chen 2011-04-25  

RCFans 写道

Eric.D.Chen 写道

说了半天，都是从程序员的角度看问题，无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的，想的都只是想把代码写好、架构弄好、所谓的维护省力，你难道不知道哑铃结构么，编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务，说白了，技术就那么回事，没想象的那么重要。

项目型的公司，确实是这样的，一家有长期计划的公司，不会这样，因为项目型的公司，接一个项目是一个活，可能下一个项目又是另外的业务场景甚至领域，技术积累不起来，无法形成自己的核心力量，程序员觉得自己没有完全发挥出价值，所以流动性很大，这样的公司是不会壮大的，壮大也只是靠转包商或央企吃饭。

国外的软件公司，与国内最大的不同就是注重平台开发，所以操作、编译甚至应用商店平台，这些最核心的东西都掌握在他们的手上，国内由于眼光的长短，意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人，因为您完全理解不了新生代的想法，他们要求自我，不服从领导，以实现自身价值为最大目标，想找听话的人，去60后、70后群体里去找吧~

呵呵，你先别激动，我还真就是80后人，你眼光不咋地啊。别动不动就国内国外的，你做过多少项目？成功过多少产品，不要一棍子全打死好不？“他们要求自我，不服从领导，以实现自身价值为最大目标”，如果这样的话你还是自己创业吧，别工作了，你以为公司都是给你开着玩的？任何公司都要有凝聚力才能发展下去，要是都像你说的这样各个都个性，项目怎么做？不要动不动就给自己贴个标签，别拿无知当个性。“RCFans”我不知道你是不是做管理岗位的，但从你说的话里我看不出大局观，你就以你自己为中心写代码吧。

回上面一哥们的话，我不是老板，但我是程序员，从我参与过的项目来看，不用像楼主说的那么悲观，凡事都有解决的办法。想要一下子做到最好本身就不现实，怎么也得有个过程吧？如果你项目组成员都是成手，都能按规范执行的话，还用担心这么多么？

59 楼 peterwei 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.

58 楼 peterwei 2011-04-25  

seeckt 写道

引用

请问你是老板了吗？我把我的工作做好，难道也是错。为什么规范化后，就不能按时上线？这个主要团队努力就行，有人执行就行。烂的技术，写出烂的代码，你认为这样就能顺利上线吗？就算上线了，到时改bug等等，无休无止的加班。你希望看到那样的情况吗？

程序员的思维往往是“把我的工作做好”就不会错，而实际上就是错的，因为这句话再具体点表述，就是把我<认为>的工作做好就是好，而不是把公司或者团队<认为>的工作做好就是好，之间的差异有可能是：
1、优先顺序不分，把对个人重要或者对个人方便的事情优先于团队
2、镀金，过于追求完美，反反复复做“好”一件事情，不考虑实际成本及客户反应

规范的项目不能按时上线是经常的，客户有个内部政治斗争很容易就毁掉个好项目
烂项目顺利上线也不少见，上线直接结项、收钱、换架构，开下一个项目，我就见过1年内同一个系统从A换到B再换到C，你认为上了线马上就下的B需要有多好的技术多少的代码？

现在的问题是要说服别人接受开发管理的改进，总站在自己的角度说事怎么说服别人？

这根本就不是同一个概念。我们在做自已的东西，没有什么拿不拿到钱。至于优先级，我们当然有过评估。不可能说什么都乱干了。做什么事情，我们都经过讨论，然后拍板。既然说我把我的工作做好，当然是boss希望做的。要不然当你提出来的时候，boss就会否掉。

57 楼 seeckt 2011-04-25  

有3个事情需要处理：
1、客户总经理提出的界面风格问题
2、可能阻止关键业务正常完成的BUG
3、正开发到一半的需求

不同角色考虑的优先顺序：
程序员： 3、2、1
开发经理：2、3、1
项目经理：1、2、3

后面就不说了，越接近中高层管理，越可能支持项目经理而不是程序员的优先顺序
这个就是思维方式的区别

56 楼 seeckt 2011-04-25  

引用

请问你是老板了吗？我把我的工作做好，难道也是错。为什么规范化后，就不能按时上线？这个主要团队努力就行，有人执行就行。烂的技术，写出烂的代码，你认为这样就能顺利上线吗？就算上线了，到时改bug等等，无休无止的加班。你希望看到那样的情况吗？

程序员的思维往往是“把我的工作做好”就不会错，而实际上就是错的，因为这句话再具体点表述，就是把我<认为>的工作做好就是好，而不是把公司或者团队<认为>的工作做好就是好，之间的差异有可能是：
1、优先顺序不分，把对个人重要或者对个人方便的事情优先于团队
2、镀金，过于追求完美，反反复复做“好”一件事情，不考虑实际成本及客户反应

规范的项目不能按时上线是经常的，客户有个内部政治斗争很容易就毁掉个好项目
烂项目顺利上线也不少见，上线直接结项、收钱、换架构，开下一个项目，我就见过1年内同一个系统从A换到B再换到C，你认为上了线马上就下的B需要有多好的技术多少的代码？

现在的问题是要说服别人接受开发管理的改进，总站在自己的角度说事怎么说服别人？

55 楼 peterwei 2011-04-25  

RCFans 写道

Eric.D.Chen 写道

说了半天，都是从程序员的角度看问题，无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的，想的都只是想把代码写好、架构弄好、所谓的维护省力，你难道不知道哑铃结构么，编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务，说白了，技术就那么回事，没想象的那么重要。

项目型的公司，确实是这样的，一家有长期计划的公司，不会这样，因为项目型的公司，接一个项目是一个活，可能下一个项目又是另外的业务场景甚至领域，技术积累不起来，无法形成自己的核心力量，程序员觉得自己没有完全发挥出价值，所以流动性很大，这样的公司是不会壮大的，壮大也只是靠转包商或央企吃饭。

国外的软件公司，与国内最大的不同就是注重平台开发，所以操作、编译甚至应用商店平台，这些最核心的东西都掌握在他们的手上，国内由于眼光的长短，意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人，因为您完全理解不了新生代的想法，他们要求自我，不服从领导，以实现自身价值为最大目标，想找听话的人，去60后、70后群体里去找吧~

RCFans,言语挺暴力啊。

54 楼 peterwei 2011-04-25  

Eric.D.Chen 写道

ppgunjack 写道

技术非常重要，当然也要看应用类型，只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势，有时意识到也不会做投入，因为不好报表化度量的利益不是自己绩效的砝码，而付出的成本却是真金白银
所以需要转化角度给决策者看，拿出数据效益数据，如果和钱沾上关系更好

同意你的观点。但是偏偏那么多的程序员还用自己的眼光看问题，总觉得事情应该向自己期望的方向发展，也不分析下到底是该改变环境，还是改改变自己。不会变通的都是死脑筋，写出来的代码也是死的。再有，即便是用了很烂的技术，写出来很烂的代码，但是最终完成了项目，真正上线跑起来了，那也比整天强调架构啊规范啥的强，而且是本质的区别。楼上一仁兄说的有道理，第一次上线前谈架构啊设计啥的都是浮云，重构不是第一阶段的事儿。最后说一句，知道为什么“很多”程序员做不了老板么？不光是钱的问题，主要是思维，要是啥问题都非得那么理想才能搞下去的话，公司必倒。

请问你是老板了吗？我把我的工作做好，难道也是错。为什么规范化后，就不能按时上线？这个主要团队努力就行，有人执行就行。烂的技术，写出烂的代码，你认为这样就能顺利上线吗？就算上线了，到时改bug等等，无休无止的加班。你希望看到那样的情况吗？

53 楼 RCFans 2011-04-25  

Eric.D.Chen 写道

说了半天，都是从程序员的角度看问题，无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的，想的都只是想把代码写好、架构弄好、所谓的维护省力，你难道不知道哑铃结构么，编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务，说白了，技术就那么回事，没想象的那么重要。

项目型的公司，确实是这样的，一家有长期计划的公司，不会这样，因为项目型的公司，接一个项目是一个活，可能下一个项目又是另外的业务场景甚至领域，技术积累不起来，无法形成自己的核心力量，程序员觉得自己没有完全发挥出价值，所以流动性很大，这样的公司是不会壮大的，壮大也只是靠转包商或央企吃饭。

国外的软件公司，与国内最大的不同就是注重平台开发，所以操作、编译甚至应用商店平台，这些最核心的东西都掌握在他们的手上，国内由于眼光的长短，意识出现分流是必然的事。另外我从您的发言中觉得您应该不是80后生人，因为您完全理解不了新生代的想法，他们要求自我，不服从领导，以实现自身价值为最大目标，想找听话的人，去60后、70后群体里去找吧~

52 楼 stevendu 2011-04-25  

呵呵，这贴要收藏，楼主跟我目前的状况极为类似，不过我劝你谨慎些，别急于搞社么革新。我找到路线是先把测试做起来，控制开发周期中的每一个里程碑，逐渐培养同事们的好习惯。

51 楼 Eric.D.Chen 2011-04-25  

ppgunjack 写道

技术非常重要，当然也要看应用类型，只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势，有时意识到也不会做投入，因为不好报表化度量的利益不是自己绩效的砝码，而付出的成本却是真金白银
所以需要转化角度给决策者看，拿出数据效益数据，如果和钱沾上关系更好

同意你的观点。但是偏偏那么多的程序员还用自己的眼光看问题，总觉得事情应该向自己期望的方向发展，也不分析下到底是该改变环境，还是改改变自己。不会变通的都是死脑筋，写出来的代码也是死的。再有，即便是用了很烂的技术，写出来很烂的代码，但是最终完成了项目，真正上线跑起来了，那也比整天强调架构啊规范啥的强，而且是本质的区别。楼上一仁兄说的有道理，第一次上线前谈架构啊设计啥的都是浮云，重构不是第一阶段的事儿。最后说一句，知道为什么“很多”程序员做不了老板么？不光是钱的问题，主要是思维，要是啥问题都非得那么理想才能搞下去的话，公司必倒。

50 楼 ppgunjack 2011-04-24  

技术非常重要，当然也要看应用类型，只是领导者未必能马上意识到技术层面改进带来的那些投资性的潜在优势，有时意识到也不会做投入，因为不好报表化度量的利益不是自己绩效的砝码，而付出的成本却是真金白银
所以需要转化角度给决策者看，拿出数据效益数据，如果和钱沾上关系更好

49 楼 Eric.D.Chen 2011-04-24  

说了半天，都是从程序员的角度看问题，无语了。作为一个典型的程序员根本不知道一个项目是怎么谈下来的，想的都只是想把代码写好、架构弄好、所谓的维护省力，你难道不知道哑铃结构么，编码是整个软件工程中最小的一块。技术的价值就是为需求、为人服务，说白了，技术就那么回事，没想象的那么重要。

48 楼 wolf_awp 2011-04-24  

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

按时上，没有按时下过！

47 楼 Anddy 2011-04-24  

lookdd1 写道

看看  rails老大的那篇圣经。。。。我个人认为网站在早期，第一次上线以前，技术，架构都是浮云。。。。开发越快越好，上线时间越短越好，响应变化的速度也是越快越好。。。  看看为啥play!framework  。rails这些framework为啥没有给你ioc。。。为啥没有神马DTO

越快 ，时间短，成本低。  一开始直接使用开源的代码 来加快开发时间 。
个人觉得， 用户体验、界面美观方面就不能追求时间的快。

46 楼 lookdd1 2011-04-24  

看看  rails老大的那篇圣经。。。。我个人认为网站在早期，第一次上线以前，技术，架构都是浮云。。。。开发越快越好，上线时间越短越好，响应变化的速度也是越快越好。。。  看看为啥play!framework  。rails这些framework为啥没有给你ioc。。。为啥没有神马DTO

45 楼 boboism 2011-04-24  

seeckt 写道

我把问题提出来了。ok,部门经理说，你来负责把这些问题处理一下吧。

这个是不是可以改善一下，现在普遍现象是提个建议，领导说就你来干吧
因为潜意识认为你最了解需要怎么改善
现在经过老一代国企的文化洗礼，只有层级汇报关系，没有谋士参谋的位置
要是诸葛亮提个建议刘备就让他上阵估计一轮就让人给劈了
蒋百里还是中国第一号军事家，带个团正常行军就能把队伍带散了，还不如个土军阀
而且技术出身的比较讲究对错，比较少考虑个人影响力，协调整合能力，容易把双方推到对立面上去

这种情况，最好还是先和team leader沟通，让他们意识到改善是必要的，然后大家一起做这件事情，给下面2年经验的人再洗第二次脑。反之个人直接拿领导的令箭推执行层肯定有阻力：他们为什么要改善，工作量肯定增加了，有什么好处没

我也这样认为，假如lz真的在国企或者领导层有这样的基因，千万要三思而后行。这是不能与外企或者私企可并论的。

44 楼 RCFans 2011-04-23  

Eric.D.Chen 写道

这跟老板没关系，你是个典型的技术男，为了技术而技术。你不是要知道怎么舒服的活着么，那你就得知道你BOSS的想法，而不是什么都想改变，老板关心项目能不能上线，能不能来钱，你架构再好再规范对老板来说没啥意义。所以你要改变的是你的想法，这事没谁对错。楼上的程序员们基本都想用自己的小想法去要求老板，这不可能。而且你们说的什么第一步该怎么怎么，然后和谁沟通怎么怎么的，都是空话，你真正需要做的是，可观的评价自己，做你自己职责内的和你能力范围内的，其他的不是你操心的你去管，结果只有一个，就是你现在的处境！

一个老板确定要做技术产品，没懂行的辅助就是钱打水漂。老板、管理班子、员工，相辅相成，风水也会轮流转。如果老板不能识别那些能够创造价值的好苗子而只用唯唯诺诺的人，那是一种失败。

43 楼 ppgunjack 2011-04-23  

给老板看真金白银的好处，如果没法提供这些佐证，最好放弃建议
越到上面越不会关心技术层次的价值，而会关心是否解决了用户用例，降低软硬件成本，平台效率
老板，老板的老板都是打工的，看不到显著显示收益的冒险对他们而言是没吸引力的