如何在公司里舒服的活着

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

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

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

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

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

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

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

评论

82 楼 深夜未眠 2011-04-26  

如果现状满足不了，那就潜移默化的去执行，不必大费周章地全改一通。慢慢地灌输规范思想，总比强硬地采取措施要好得多。这种代码规范势必要进行得，但是需要长期的过程，持久战而已。

81 楼 Eric.D.Chen 2011-04-26  

RCFans 写道

Eric.D.Chen 写道

seeckt 写道

引用

你知道一个一年期项目的成本是多少么？

1、人工成本
这个也就是我们认为项目最主要的成本哈！每个人在财务部那边有人工成本的，包括了工资、绩效奖金、保险、公积金、福利...

呵呵，说的很全了，我这里基本也就这些。

那您说说，“顺着Boss的意思”，这些成本分别对应哪些Boss呀？

此问题是为广大程序员而问，否则马屁拍错了也是引火烧身

仁者见仁智者见智的事儿，基本都是经验之谈。况且他说的确实不错啊，至少代表了很多决策者所关注的方面。
呵呵，你是第二个芮成钢啊，广大程序员都被你代表了啊！还想鼓动广大程序员？ “您”把上面的话往你们BOSS身上套一套，应该有结论吧！

80 楼 dsf007 2011-04-26  

seeckt 写道

引用

否则马屁拍错了也是引火烧身

借楼主的歪溇随便扯扯哈
首先，拍马屁需要有专业上岗执照，就是P(拍)M(马)P(屁)，这个是美国认证，或者你也可以搞个中国拍马屁(CPMP)，国际拍马屁（IPMP）的......以上纯属瞎扯，不喜请无视之......

+1

79 楼 seeckt 2011-04-25  

引用

否则马屁拍错了也是引火烧身

借楼主的歪溇随便扯扯哈

首先，拍马屁需要有专业上岗执照，就是P(拍)M(马)P(屁)，这个是美国认证，或者你也可以搞个中国拍马屁(CPMP)，国际拍马屁（IPMP）的

然后拿到拍马屁资质以后，不要被里面的流程活动什么的搞晕了，认为是一堆官僚不敏捷的东西，因为拍马屁之博大精深，不是一本手册可以写明白的。就拿中国或者美国最被认可的PMP来说，拍马屁官方点的说法是需要管理好“关键干系人”。比如你们公司搞360度考评，如果你老大打的分比例很高，他说你不行，别人都说你行都没用，他就是关键干系人 （Key Stakeholder）。拍马协会（PMI）有个考题就是PM有70%时间用来“沟通”，你当然知道这70%时间都用来拜啥佛了。临时抱佛脚那是没有“识别好关键关系人”，没做好“风险识别”，那是为失败埋下伏笔啊。

还有拍马知识体系（PMBOK）这本书的附录E里面（但愿没记错），写了要关注工作环境中的政治关系，有效利用政治关系能够保证项目成功，所以拍马知识体系不是整天写什么流程什么活动什么知识领域，只是他不方便说拍马的事情。因为他前言就说明了这个拍马知识体系只是指南，不是方法论，总之就是不告诉你具体怎么拍马，但是会告诉你拍马是很重要的！

拿到拍马资质以后，你还需要不断学习怎么拍马来累积积分，比如参加什么拍马沙龙和其他拍马屁们探讨拍马心经什么的。
根据中国2010拍马协会的数据，中国的拍马屁们太不重视积累积分了（就是拿了证以后放弃了在拍马之道上精益求精……），结果大多数人都没有在指定时间段内累积足够的积分，导致他失去了拍马屁专业资质。

以上纯属瞎扯，不喜请无视之

78 楼 ppgunjack 2011-04-25  

RCFans 写道

你知道一个一年期项目的成本是多少么？

这是个应该回答yes，no的问句，说明对需求文档理解产生了偏差

77 楼 RCFans 2011-04-25  

Eric.D.Chen 写道

seeckt 写道

引用

你知道一个一年期项目的成本是多少么？

1、人工成本
这个也就是我们认为项目最主要的成本哈！每个人在财务部那边有人工成本的，包括了工资、绩效奖金、保险、公积金、福利...

呵呵，说的很全了，我这里基本也就这些。

那您说说，“顺着Boss的意思”，这些成本分别对应哪些Boss呀？

此问题是为广大程序员而问，否则马屁拍错了也是引火烧身

76 楼 peterwei 2011-04-25  

你们可真能扯的，都扯到这种地步了。

75 楼 seeckt 2011-04-25  

引用

说得很对。所以出现了很多技术牛的人，就认为自已一定要拿高工资。需不知，只有给老板创造了价值，才能拿到更多钱。你东西做得再好，赚不了钱，没有市场，没有管理，没有做需求的，技术又算什么呢？我刚从技术转需求了。

不知道这个算不算中国教育的悲哀，大学招生就是说教啥啥语言的，
结果出来后有个说法是开发做不了的做QC，QC做不了的做QA
公司想招个实施吧，不好意思，毕业生全没听说有这个岗位

还有大家都知道需求不清的苦，急着招需求分析师，结果呢，无价也无市
能搞明白业务的都搞市场营销或者经理去了，搞不明白的也不想往这个方向跑。从个人利益角度说，懂业务又怎么样呢，一种是跳业内的企业，大家一个小圈子，谁混的也不会太舒服，一种是跨行跳，那业务知识基本就全扔了

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

seeckt 写道

引用

你知道一个一年期项目的成本是多少么？

1、人工成本
这个也就是我们认为项目最主要的成本哈！每个人在财务部那边有人工成本的，包括了工资、绩效奖金、保险、公积金、福利...

呵呵，说的很全了，我这里基本也就这些。

73 楼 seeckt 2011-04-25  

引用

你知道一个一年期项目的成本是多少么？

1、人工成本
这个也就是我们认为项目最主要的成本哈！每个人在财务部那边有人工成本的，包括了工资、绩效奖金、保险、公积金、福利
如果为了做预算方便，每个职位不同LEVEL的人都可以有一个大概的人工成本，做预算的时候根据你项目的情况乘就可以了
另外1年的项目你必须考虑到薪酬增幅

2、教育培训成本
看情况是不是要瘫到项目中去，针对项目的培训一般要摊进去

3、低值易耗品
笔纸开会用的，胶水贴发票的，这个不好少，名片，给客户的项目资料，光盘

4、差旅、安家费
出差用的旅费，外面租房以及水电煤，出租车

5、业务招待
销售们的最爱，有酒肉吃了

6、广告宣传
看一般项目估计用不上

7、修理费
修电脑？也许有房屋维修，有钱人要修公车什么的

8、通讯费
手机报销，特别是外地项目长途电话报销厉害

9、招聘费
离职率30%左右吧，做一年项目总有人跑路的

10、劳务外包
人不够了要买

11、董事会费
老大们要你交什么报告的，要伺候好了，这个术语叫赢得关键干系人支持

12、代理代办费
要找人跑腿的钱

13、产品研发费
如果产品开发部和项目组不是一个部门的，可能需要内部交易

14、党团活动费、反恐费什么的
领导我们翻身做主人的亲儿子们专用

15、市场培育费
看公司习惯这块是不是要摊到项目里

16、综合管理费
同上

成本差不多是这些
然后就是风险储备，核心技术人员抽筋、客户方换领导、倒闭的不说，利比亚或者伊拉克那边搞项目遇到政<和谐>变什么的最讨厌了

最后一个，给PARTY的保护费，每个项目25%

72 楼 RCFans 2011-04-25  

ctoeye 写道

RCFans 写道

Eric Chen的经验能够理解，如果视野能再开阔一些，多和客户的高层接触或不同类型的软件公司接触的话，你会有更多的视角。作为项目承包商，十有八九是处于被动，因为是价值链的下游。

另：你知道一个一年期项目的成本是多少么？

你这话问的，一个项目的成本要看行业，要看大小，要看团队积累等因素。你这样问，他无论如何回答不了你的问题。

一般我提的问题，没有绝对的答案。

71 楼 ctoeye 2011-04-25  

lym6520 写道

jamesji 写道

首先，你说的这些是架构师工作范围以内的事情，是必须要做的。
但是，怎么做，是需要技巧的。
通常来说，相对于现行的技术体系，超过15%的变化，被团队否决的可螚性是很大的。

我的建议，
1. 将现有程序模块化，采用 maven 进行统一管理。模块分两大类，功能性的和技术性的。功能性的是说有用户界面的或者需要根据客户需求进行调整的。技术性的是没有界面的，比如安全校验。每一个模块都要有一个统一的对外的接口。这个过程中，尽可能的只是 refactoring, 保证程序可靠运行是唯一标准。模块越多越小越好。
2. 建立 core team。选择技术好的核心工程师加入，每周开一个会沟通。三到五人为佳。也看具体项目和团队大小。
3. 建立你说的标准，做好详细的文档和例子。也可以你开个头，让一个核心团队中的一个 senior 去做。然后，在核心团队中先征求大家的建议。这样，加上细化的那个 senior， 应该容易通过。
4. 将标准加到 TWIKI 上，这样确保每个人都可以看到。
5. 在团队全体会议上宣布并讲解。要用鼓励性的话讲，比如，“我们已经干出来一个好的产品(good)，但是我们要把这个项目成为一个最好的产品(great)。”等等。讲解的时候，一定要有例子。一定要说明，这个规定只对新的模块有要求，这样大家的心里容易接受。
6. 通过后，找人一个一个模块的改。因为接口的存在，影响应该是可控的。
7. 如果是 java 项目，可以用 check style 在 Eclipse 或者 build 阶段帮助程序员follow 你定的标准。

关于 TDD， 技术性模块一定要加 TDD。功能性的看项目进度。

My 2 cents.

不知能否指点下maven在实际开发中是如何应用的？

这种技术细节，你去看一下maven入门就完事了，还好意思问。

70 楼 lym6520 2011-04-25  

jamesji 写道

首先，你说的这些是架构师工作范围以内的事情，是必须要做的。
但是，怎么做，是需要技巧的。
通常来说，相对于现行的技术体系，超过15%的变化，被团队否决的可螚性是很大的。

我的建议，
1. 将现有程序模块化，采用 maven 进行统一管理。模块分两大类，功能性的和技术性的。功能性的是说有用户界面的或者需要根据客户需求进行调整的。技术性的是没有界面的，比如安全校验。每一个模块都要有一个统一的对外的接口。这个过程中，尽可能的只是 refactoring, 保证程序可靠运行是唯一标准。模块越多越小越好。
2. 建立 core team。选择技术好的核心工程师加入，每周开一个会沟通。三到五人为佳。也看具体项目和团队大小。
3. 建立你说的标准，做好详细的文档和例子。也可以你开个头，让一个核心团队中的一个 senior 去做。然后，在核心团队中先征求大家的建议。这样，加上细化的那个 senior， 应该容易通过。
4. 将标准加到 TWIKI 上，这样确保每个人都可以看到。
5. 在团队全体会议上宣布并讲解。要用鼓励性的话讲，比如，“我们已经干出来一个好的产品(good)，但是我们要把这个项目成为一个最好的产品(great)。”等等。讲解的时候，一定要有例子。一定要说明，这个规定只对新的模块有要求，这样大家的心里容易接受。
6. 通过后，找人一个一个模块的改。因为接口的存在，影响应该是可控的。
7. 如果是 java 项目，可以用 check style 在 Eclipse 或者 build 阶段帮助程序员follow 你定的标准。

关于 TDD， 技术性模块一定要加 TDD。功能性的看项目进度。

My 2 cents.

不知能否指点下maven在实际开发中是如何应用的？

69 楼 ctoeye 2011-04-25  

RCFans 写道

Eric Chen的经验能够理解，如果视野能再开阔一些，多和客户的高层接触或不同类型的软件公司接触的话，你会有更多的视角。作为项目承包商，十有八九是处于被动，因为是价值链的下游。

另：你知道一个一年期项目的成本是多少么？

你这话问的，一个项目的成本要看行业，要看大小，要看团队积累等因素。你这样问，他无论如何回答不了你的问题。

68 楼 ctoeye 2011-04-25  

Eric.D.Chen 写道

seeckt 写道

Eric.D.Chen 虽然不是老板，但明显和老板或者至少中层混的比较多
跳出程序员的角度看项目就是这回事
ITEYE主要还是面向程序员的

  我曾经是个程序员，至少现在也在写代码，是个完美主义者，以前凡事极力要求完美，包括我带的团队，曾经我给了成员很大的压力，后来随着项目越带越多就发现，自己原来的一些观点是不完全准确的。我认为不管是不是程序员，思维方式应该开阔一些才好，对咱们没啥坏处。力求完美，开发精品是大家共同的追求，但也应该多角度考虑下，从决策层的角度考虑没什么不好。我从没说过不注重软件品质而只关心完工，我的意思是变通地看问题，形势不允许花太多时间的情况下就该以进度为主。

说得很对。所以出现了很多技术牛的人，就认为自已一定要拿高工资。需不知，只有给老板创造了价值，才能拿到更多钱。你东西做得再好，赚不了钱，没有市场，没有管理，没有做需求的，技术又算什么呢？我刚从技术转需求了。

67 楼 RCFans 2011-04-25  

Eric Chen的经验能够理解，如果视野能再开阔一些，多和客户的高层接触或不同类型的软件公司接触的话，你会有更多的视角。作为项目承包商，十有八九是处于被动，因为是价值链的下游。

另：你知道一个一年期项目的成本是多少么？

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

seeckt 写道

Eric.D.Chen 虽然不是老板，但明显和老板或者至少中层混的比较多
跳出程序员的角度看项目就是这回事
ITEYE主要还是面向程序员的

  我曾经是个程序员，至少现在也在写代码，是个完美主义者，以前凡事极力要求完美，包括我带的团队，曾经我给了成员很大的压力，后来随着项目越带越多就发现，自己原来的一些观点是不完全准确的。我认为不管是不是程序员，思维方式应该开阔一些才好，对咱们没啥坏处。力求完美，开发精品是大家共同的追求，但也应该多角度考虑下，从决策层的角度考虑没什么不好。我从没说过不注重软件品质而只关心完工，我的意思是变通地看问题，形势不允许花太多时间的情况下就该以进度为主。

65 楼 seeckt 2011-04-25  

Eric.D.Chen 虽然不是老板，但明显和老板或者至少中层混的比较多
跳出程序员的角度看项目就是这回事
ITEYE主要还是面向程序员的

64 楼 RCFans 2011-04-25  

Eric.D.Chen 写道

RCFans 写道

Eric.D.Chen 写道

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

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

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

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

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

我是管理岗位的。

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

peterwei 写道

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