我们整个公司ODC的业务占了很大的比例，我们分公司做过的大部分的项目都是ODC. 那么是不是我们所有人对ODC项目都有一个正确/恰当的认识呢？我觉得不尽然，所以我想写写我对ODC的认识。一个是让我们公司的工程师知道ODC是什么，另外让客户知道真正的ODC服务是什么(除了销售的介绍，不妨听听正真服务人的想法)，他的优势是什么，如果处理不好，ODC的问题又是什么？

ODC的片面理解？

在公司经常听到以下一些对解释：

ODC就是按月付费

我觉得按月付费只是ODC服务的一种付费形式，他根本不是一种服务。

ODC就是按时间付费

这个也是片面的，1个小时也是时间，一个月也是，一年还是时间。几天的服务算是ODC吗？我认为不是。

ODC是Offshore development center

这个解释也太过“干瘪”，离岸开发中心？ 离岸研发中心？如果这样理解，他就是离岸的一个办公地点而已嘛！

ODC到底是什么？

对我们公司来说，我觉得ODC是一种合作方式，他的产出是一种服务，这个服务可以是如下一些交付物：

• 软件——-交付高质量的软件
• 咨询服务—-企业信息化(软件项目的立项，软件项目的规划, 开发商的评估等等)

而ODC服务要做好的几个主要的部分，我觉得是：

• O (Open): 双方都必须开放，必须透明，只有这样，才能做好互信，才能更好的信息共享。

• D (Development): 这个部分是开发，或者咨询服务的实施过程

• C (Coperation): 合作，我们知道客户合作胜过合同谈判。

ODC的模式好处有哪些?

我认为ODC有几个很主要的优势：

1. 软件开发，需求很难固定，尤其是现在这个变化极快的时代，一旦需求固定，将失去竞争力，拿现在手机开发来说，如果一开始定义了一个手机，而且严格按照计划来，一年以后等你上市时，发现大部分手机都有了指纹功能，而你的没有，那么你的手机就毫无竞争力，让之前的付出瞬间付之东流。

2. ODC的合同一般更倾向于长期客户，这样可以让团队成员能够更稳定，让熟悉的人能够长期服务于这个客户，大大降低了产品的风险。不然，A做的东西让B接是很需要时间的，如果A已经离职或者服务于别的项目，那么很可能导致项目难以持续。

3. ODC的付费形式是按月付费，可以大大降低客户的成本风险，以及可以节约现金流。

4. ODC的服务的交付大部分都是增量式，比如2个周一个迭代，客户可以尽早发现项目中的问题，尽早给予反馈进行修复。甚至尽早终止项目来减少损失。

5. ODC服务需要把双方都理解为自己的同事，开放(O), 合作(C). 没有信息影藏，双方都是想把产品或服务做好。

6. 更容易激发双方的创造，不用过于盯着一开始定义的功能，不用过于在乎KPI (Kill people idea), Business value才是最重要的。

7. ODC使开发人员有更长时间来不断加强对客户的业务领域的理解，从而提交更好的产品和服务。

8. ODC使的软件提供方更容易做出计划，从而可以让开发人员更专注于一个客户的项目，想想固定价格的项目，很多友商固定价格的项目常常一个人同时做好几个，根本没时间来深入理解客户到底需要什么。

9. ODC的项目也更容易规划开发人员的个人发展，更容易做出一个长期的计划，从而增加员工对公司的认同，一个能留住人才的公司，肯定是可以提供更好的服务的。

ODC的好处远远不止这几点，我们使用ODC成功提交了大量的项目，当然单单使用这种合作模式也是不够的，软件行业想在ODC服务模式下提供高质量的服务依然没有那么简单，具体怎么做，欢迎阅读我的

ODC的问题

ODC的模式固然有很多好处，但是这世界上从来没有任何一个模式是完美的，经过这几年的服务，ODC也有几个常见的问题, ODC一个最大的好处是可以让人员稳定，可以留住人，但是最大的问题也是留人问题：

项目周期太长，开发人员觉得枯燥

有的项目做的时间比较长，比如5年以上，那么开发人员使用的技术就没有那么新，虽然这个对项目本身问题不大，但是技术人员第一都是喜欢追求新技术的。其次开发人员和别的项目或者开发人员讨论，觉得自己的技术已经没那么时髦了，容易产生浮躁的心里。

其实，解决这个问题的方法有几种：

• 在现有的项目里使用新技术，比如很多公司在使用的Powerbuilder可能需要更换为WEB系统或者新的技术，不然将来谁来维护？

• 部分功能或者子系统使用新技术，比如部分使用NoSQL, Elastic Search，Cloud等新技术除了提高系统的性能，降低维护的任务外，开发人员也可以学到很多新东西

• 更换部分人员，更换部分新成员到项目，老成员可以做别的项目

但是，这些都需要客户方的大力支持，ODC提供方是很难单方面进行改进。

报价增长太慢，不符合开发人员薪水增长预期。

这个也是一个常见问题，程序员的薪水每年都希望提升，而大部分公司程序员薪水的提升是和程序员给公司能带来的价值/收入来决定的，也就是基本上和报价关联度比较大。当然，我们可以不关联，那么如果不关联会带来更多的问题。这里面出现的矛盾是，正常情况我们和客户都会说每年有一个百分比的报价提升，但是这会受到几个因素的影响，一是这个百分比是否和整个市场薪水变化同步，而是部分开发人员能力提升较大，自己期望高于这个百分比的薪水涨幅

这个问题解决方法其实也是有三种：

1. 降低利润
2. 客户接受对应报价的提升。
3. 人员离开项目

在人员的生产效率没有降低的情况下（理论上每年应该都有提高，因为对项目业务更熟悉，使用的技术更熟练），我个人一直觉得第二种是对客户最好的一种方式，因为 报价的提升是恰恰是成本最低的，同时想想这个开发人员对项目的过去几年已有的贡献，他应该享受某些程度上的不可替代带来的回报提升。

开发人员同一项目时间长了，皮了！工作效率下降。

当我们很多东西都熟练的时候，我们原来8个小时的工作量很多时候6个小时做完了，虽然某种程度对客户的产出没有变化，那么时间长了，我们人就比较消极，在一种消极的情况下，稍微有一点有挑战的新任务，都会没有好的产出。

这种解决办法，我觉得只有一个，那就是换人！

“富成一个废人”

ODC项目时间长了以后，大家压力不是太大，所以容易进入舒适区，舒适区呆久了，一旦换个项目，很可能适应不了新的节奏，新的知识或者丧失了学习的能力，从此“富成一个废人”。

这种解决办法，就是ODC我们也需要不断提高我们的质量和效率！使用正确合适的开发过程来避免这些发生，参考我的敏捷系列

总结

废话少说，最后几句重要的。

1. ODC 卖的不是时间，是服务呀，时间人人都有哇
2. ODC 是一种合作方式
3. ODC 的产出是服务 （软件或者咨询)
4. ODC 是为了提高质量和效率，不是为了多挣钱, 多挣钱只是ODC的附属产物
5. ODC 是为了更好的员工发展规划做基础，员工Happy，才能做好服务，客户才能Happy

背景

作为一个分公司负责人，绩效考核，薪水定级这些事情直接关系到分公司的生死存亡，所以向来都是我工作的主要内容之一。尤其是软件公司，人才是唯一的资产，而绩效考核往往决定是否可以吸引人才和留住人才。

分公司成立快5年了，也做了很多项目，其实考核的方案也每年都有变化，而也在薪水提升和管理上吃过不少“吃亏不讨好“的事，比如干过这样的蠢事：有个员工表先不好，为了激励他，给他进行了加薪。但是，加薪后还是一直表现不好，当我们辞退的时候，他竟然问我，如果我表现不好，你为什么给我加薪？ 类似的事情，有几次处理的不好，主要的原因就像我第一篇 管理沉思录系列(一):开篇, 小公司，人少，项目一个萝卜一个坑，把坏萝卜拔了，坑就很难很快填上，不敢顶失去项目的压力，但是恰恰是害怕失去项目，却为公司发展带了一些管理的债务。

另外，也有个别些员工受到一些“风”的吹动，心里难免会躁动不安，提出了离职。员工离职的原因林林总总，千差万别，但是背后可能原因基本都是一个，觉得薪水低了。这个时候，为了保住项目，很多人选择的方法都是给这些提高薪水留住人，但我的想法不同，我一定会留人，但是绝对不是提高薪水留人，下面我来说一下原因：

为什么不能随时调整薪水？

公司必须有考核制度

一个公司如果薪水的定义，完全凭老板自己来定，或者随时来调整，那么员工如何保证自己把精力放到自己的工作之中，放到自己的能力提高之中，放到产品的质量，效率和服务来？

如果一个公司没有考核制度，那么没有“政治能力”的人就会很吃亏。一个软件公司能变成“后宫”。

薪水的调整必须有定义好的时间点

考核一定是对一个周期的考核，而这个周期不能对有的人是一个月，有的人是一年，如果这样，就说明你有一个“任性”的领导。

拿我们分公司来说，这两个时间点就是：

• 每年的考核制度更新时，也就是1月1号
• 客户项目报价的调整，也就是新的合同签订时。

薪水是双方的“合同”，是一种承诺，体现了契约精神。

一般，每年薪水的调整时，会和员工进行沟通，员工如果同意了，其实就是对公司的一种承诺，对客户的一种承诺，在这个周期内应该遵守承诺。随意调整薪水，如果工作内容没有变化就伤害了契约精神。（注：我第一分工作没到合同周期结束我辞职了，我给公司支付了赔偿，第二分公司，我是等到合同期结束才辞职)

不能造成 “会哭的孩子有奶吃” 的局面

很多管理人员可能遇到这样的场景：资深员工找你加薪，或者暗示你他们的所得低于付出，甚至旁敲侧击的告诉你有很多公司能给他更高的薪水，你怎么办？这个时候，这个人可能是公司关键人物，可能是某个项目的核心成员，你可能也认同他的一些想法，然后给他加薪，这个看起来很合理，但是这个时候你违反了考核制度，也没有到调整薪水的时间。同时带来了更大的危害，因为你的行为并不是推动公司发展，加薪是因为他提出了加薪的要求 而不是他工作更出色了。这会带来几个严重的问题:

1. 没有不透风的墙，大家会纷纷效仿，大家相互比较的不是谁的表现更出色，而是谁去找了老板加薪。
2. 大家都想办法把自己编程“关键人物”，平时信息不分享，自己做的东西只有自己知道，然后对老板提出威胁。
3. 公司里默默无闻，踏实干活的人将享受不到这个“福利”。
4. 大家都学会了“哭”，因为“会哭的孩子有奶吃”。 那么老板就等着疲于“哄”孩子吧。

如何调整薪水？

薪水调整的时间点和方法

每个公司，每个管理者都有不同的方法，不同时期都有不同的考核制度，但是我觉得有一点是不变的，那就是不管什么考核，都要“公平，公正，公开”，同时，不要随意打破规则，新规则没出来，所有人都必须遵守老规则。

就拿我们分公司来说，薪水调整的时间点和方法。

1. 要想提高薪水，首先提高能力，能力提高了，就提高对客户的报价。
2. 如果考核周期中觉得自己不公平，可以提出改进考核的建议。
3. 要求加薪需要在正确的时间点，一个考核周期没结束或者报价没变化时尽量不要要求随时加薪，重承诺。每年对考核进行修正，可以提出考核制度需要改进的地方，可以提出考核制度不公平的地方。另外一个时间点就是和客户谈新的报价或者合同之前。
4. 可以做更多的事来提高薪水，可以给公司带来更多的价值或者收入。

不要让员工讨价还价

比如制定一个清晰的考核计划，严格的执行，同时让员工贡献自己的想法，以免出现不公的事情。给员工清晰的薪水提升路线、时间、方法。

做好这些后，如果一个员工告诉你他找到了一份好工作而要离开时，这个时候你的立场一定要坚定，不要模棱两可，也不要发出错误的信号，让其他的员工感觉你通过加薪而留住了他们，对那些不想为公司工作的人不要留恋。

写在最后

所以，加薪是一把双刃剑，用好了，事半功倍，用不好，事倍功半！

我也在不断学习和思考，愿君与我同行，愿我们公司的小伙伴一起出谋划策，打下一片江土。

感谢公司的这个平台，让我这个毛头小子，不知天高地厚的人做了几年事业部负责人，然后又从2011年开始作为西安第一分公司的负责人至今。虽然分公司人员并不多，但是依然经历了很多事，才有了许多的思考和实践！

为何一直没有写管理相关的文章

我其实是一个很喜欢思考的人，对团队管理，公司建设等相关的东西很感兴趣，但是一直没敢记录一些相关的想法，主要有一下几个原因：

害怕得罪人

管理人员有几类：

1. “全是假话，没有真话”—我很讨厌这种人
2. “假话全不说，真话不全说”–有一定修养，但不愿得罪人，算是好的管理人员
3. “假话全不说，真话全都说”— 我就是这种人

我就是上面的第三种人，我这个人比较简单，喜欢有一说一，所以很多时候说话的时候不分场合，喜欢说真话，所以容易得罪人。而任何管理的方法和认识，很多时候很难照顾到所有人，很难和很多人达成一致，而又的时候，我说的一些管理的方法和思考，正好和有些人的冲突，那么别人就会觉得我是公开反对。

管理经验不足，不敢分享想法

由于只是分公司的负责人，而且人并不多，相比那些“大领导”，我的管理经验算个毛？对自己一些管理的思考缺乏自信。

害怕流失员工

我的一些管理的理念，可能别的人看了，有的人表示赞同，有的人嗤之以鼻，最多是关掉网页罢了，但是假如我单位自己员工看了，他和自己的领导理念不一致怎么办？我说的那些人不认同怎么办？那么是不是这些人会流失？流失了项目怎么办？

害怕员工误解

比如我之前写过加班有罪, 当我们偶尔需要加班的时候，很多人就会误解，会觉得我言行不一致，觉得我自己打脸了，很多人喜欢看别人打脸，但是我一直认为领导要敢于打脸，不要该打脸的时候硬撑着，随后我又不得不写一篇当我谈 “加班有罪” 我在谈什么？, 所以很多时候，一篇文章很难把一件事情说的通透，就拿加班这件事，我们认同加班有罪，但是我们如何能够做到不加班，恰恰需要大家的共同努力。（注：我们基本不加班，但是不代表着零加班，所有的人6点整就走人, 所有人都看着表走的公司，你真的敢去吗？)

害怕得罪领导

如果领导看了，觉得我的很多想法不对，和领导的想法不一致怎么办？

文章其实是一种交流和信息的流通，我觉得很多管理人员不愿分享自己的管理想法，应该也有我上面的几个担忧吧。

为何我现在要分享一些自己的管理想法和心得

一个害怕得罪人的领导不是好领导

我觉得，作为公司的管理人员，我们需要首先需要考虑公司的员工，考虑员工的发展，那么公司发展好了，公司文化建设好了，才能让员工发展有一定的基石。从管理的角度思考，当公司多余10个人时，很难所有人对所有的事情都有一致的认识，必然有个别人的一些认识，个人素质等与整体不一致，那么作为管理人员，必须兼顾大部分的想法，让大部分人认可公司的价值和文化，那么一些管理的方法，制度等等必然会得罪一些人，如果我们害怕去得罪人而选择很多中庸的做法，那么反过来，害得还是大部分员工。

分享管理的想法和经验可以提高自己的管理能力

通过分享自己的想法，会有以下一些好处:

• 会对自己的一些想法进行总结。
• 通过总结，会对自己的想法进行梳理，同时还可以验证自己的想法。
• 可以看到自己的成长，对事情认识的提高，很多年以后，也许觉得自己当时的想法是什么样，为什么那么幼稚？
• 如果有有兴趣的人，对你的观点进行讨论，必然会激发出一些新的思考和认识。

so, why not share your thoughts?

和员工交流

我一直提倡员工与自己多沟通，有什么想法可以多交流，现在的交流方式已经非常发达，邮件，电话，微信，会议室一对一，活动等。我也努力创造各种交流的机会，但是中国人尤其是IT人员，很不善于沟通，也非常羞涩于和你交流想法，这让沟通的效果很不理想。由于对很多东西的误解和不理解或者了解，很多中国的员工会在离职的时候才表达自己的想法，最终让自己和公司都遭受不必要的损失。所以，通过写一些文章，员工可以看到自己领导对事情的认知，以及做决定背后的原因。

小公司也有很多经验，“小而美”也很难

之前一直觉得分公司是个小公司，但是这几年，尤其是今年经历的一些事，我发现小公司其实很难管理，有些事情在大公司很好处理，比如，大公司大项目，50个人，走几个人不是任何问题，但是小公司，一个萝卜一个坑，走一个人你可能都头疼，类似的事情很多。

另外，小公司的数量很多，而且也会越来越多，依据“长尾理论”，这个是很正常的，即使是大公司，里面也有部分，部门里也有团队，其实我这里遇到的问题，解决问题的方法，他们都能用的上。

“小而美” 是趋势，能做到“小而美”，很难，做好了，何尝不是能力的体现呢？

让其它人理解你做的一些决定

在一个公司，我们肯定要和很多人，甚至是很多部门打交道，那么我们有的时候把自己做的一件事再三解释，不如通过文章传播一下自己的想法，这么做的原因，这样可以节省不少时间，同时也可以争取到相关人员或者领导的理解。

之前的文章写过 单元测试最佳实践 有兴趣的可以看一下，今天列出我的单元测试规范：

单元测试规范：

• 所有public方法必须被单元测试覆盖
• 只测试public方法
• 不要依赖其它的类，除非是静态Helper或者测试框架的类。
• 所有需要依赖类都必须被mock。
• 必须很快速的运行，单元测试里不能有耗时的代码
• 使用一些工具，比如NCrunch 可以在后台实时运行单元测试，随时知道自己写的代码有没有破坏测试。
• 文件，外部Service和数据库的存取都必须mock掉
• 单元测试要可以无限次的重复运行
• 单元测试不是要实验想法，不要去测.NET本身的问题。

CSS和JavaScript的规范网上有很多，今天列出一些规范

• JS代码一定要使用模块话，比如RequireJS, ES6等等
• 不能写内联样式
• 不要直接在页面写CSS和JavaScript代码 （放到独立文件里）
• 不要在JavaScript写HTML代码，除非是是组件里，尽量使用HTML Template
• BR 标签只用在段落里，不是用来换行的!!!
• CSS的命名需要和内容匹配，不要写成left-nav, 要是你想放到右边呢？使用side-nva.

就是这么几句，能做到就很不容易！

沟通是软件开发过程中极其重要的一部分，今天主要列一下做项目的时候沟通的规范

• 和客户沟通之前先和团队沟通。
• 第一时间提出你遇到的问题和障碍。
• 了解团队每个成员擅长的东西。
• 不要浪费时间寻找方案，如果团队成员有人有相关经验。
• 如果你自己对某些需求或者方案不确信的时候，一定要找团队一起沟通一下。
• 沟通的时候必须态度端正。
• 沟通的时候必须讨论事情本身，不得有人身攻击。
• 沟通的时候所有人都有表达想法的权利。
• 必要的时候 “Show me the code”!

给客户提交前除了完成之前提的Definition of Done, 良好的代码规范等，我根据大家比较容易忽略的地方，列出来作为这一方面的规范。

• 给客户列出按计划或者需求定义但是没有完成的功能 （这样，客户就不会把这类问题当Bug）
• 给客户准备测试数据
• 确保你的测试数据和你给的客户的版本匹配 （容易出错的就是数据库脚本和客户用的不一致）
• 列出客户需要注意的地方，比如数据库连接字符串，API地址等。
• 确保你的最后一次改动，程序能够工作 （容易出错的是你发现了一个错误，然后就改了，但是你觉得是小改动，没有测试，但是导致客户连主页都进不了）
• 确保客户测试或者运行系统需要的所有信息。

之前我讲过Git flow, 请参考我的文章敏捷实践系列(四)：代码管理流程

想知道个整体概念的，就看一下下面的图

我们团队的Git规范

• 使用Git时，总是使用SSH连接
• 任何时候不要在代码里包含密码，尤其是数据库密码，服务器密码，即使你删掉了，因为Git history可以看到所有历史！！！
• 严格遵守Git flow
• 每一次提交都要写清楚修改的是什么
• 每天离开办公室必须提交所有的代码到Git服务器
• 频繁提交 （small workable piece of code）
• 如果你feature分支没有完成,不要合并回Develop分支, 请参考之前文章 Definition of Done
• 仔细检查config的设置，不要用自己本地的覆盖了服务器上的。
• 每一个新的feature必须在一个新的分支上。
• 解决冲突后，一定要测试！！！

Definition of Done: 就是对做完一个功能的标准是什么，只有我们提前定义好了标准，我们才知道结果是一种什么样的期望。

我们团队的DONE标准

我们大家原来的时候总有一个习惯，你问进度如何，总是说快完了，马上完了，如果期望这个东西是10个小时做完，当天下班时，你问开发人员，他说的这个”马上”一定是至少还得一天，基本上他说90%了，那基本上就是还需要40%的时间来完成剩下10%的功能。
如果我们设置一个中间状态，那么事情永远到不了我们想要的质量，因为大家着急把功能做完，但是没有测，或者没有单元测试，或者还有一个小功能没有实现。

• 所有任务只有 “DONE” 和 “NOT DONE” 状态，没有90%完成这样的。
• 代码写完了，签入了，编译通过，符合当前版本的需求。
• 代码Review过了。
• 持续集成没有错误。
• 单元测试覆盖通过了。
• 部署到对应的环境并且测试通过了。
• 任何编译，部署和配置的改变都已经开发并且文档或者交流过了。
• 如果需要文档等都已写或者更新。

完整的DoD

细节就不解释了，如果需要解释的，请在文章后留言。

我一直认为一拿到任务就开始写代码是有问题的，而这是很多人的习惯，结果就是不断的修改，我还是那句话，作为程序员我们是要把代码写对，而不是把它改对。

下面我就说一下拿到任务后整个流程应该是什么:

1. 充分理解需求，不要立即写代码
2. 设计 （主要是思考如何实现）
3. 找出需要和别的代码交互或者集成的部分
4. 开始一个新分支
5. 设计接口 （尤其是需要和别人交互的代码）
6. 实现接口
7. 编译通过
8. 单元测试覆盖全代码
9. 所有单元测试通过
10. 冒烟测试通过，就是至少自己点一点，测一测
11. 功能测试通过
12. 合并Develop代码到这个分支
13. 若有冲突解决冲突.
14. 重复7到11.
15. 合并回Develop