《联盟》这本书被很多人追捧，我个人看完以后觉得也不错，提出了一个雇主和员工的一种新型关系，全书一直围绕这一观点，个人觉得略显啰嗦，也许是受我程序员的性格影响的原因吧。和这本书相比， 显然《创业维艰》这本书对我影响更大，《创业维艰》这本书直击我的心灵，而且很多场景我都似曾相识。

感悟

《联盟》强调的是重建雇主和员工的关系，让雇主和员工之间达成联盟，新的忠诚观允许公司和员工对彼此做出承诺，把过去的商业交易转变为互惠关系的框架。雇佣关系可以转换为一个联盟：一份由独立的双方达成的，有明确条款的互惠协议。

我个人对这个是认同的，原来我们也强调我们希望和员工签订的合同是一份”心里契约”，但是在中国目前这种环境，这种关系是否凑效，我觉得还需要观察，为什么这么说？我和员工建立过不少次”心里契约”，比如我们和客户一起给我们员工做了培训，我们付出了大量的精力给实习生做了培训，甚至我们每个年初都和大家谈了新一年的薪水等等，但是却多次被部分员工单方打破这个 “契约”，甚至有的人告诉我：”我知道这样很不应该，但是我违反法律了吗？”，为什么？我个人觉得是因为”信誉观”不同。

1. 个人信誉，很多人不重视，这个从小或者教育中体现的并不多。
2. 信誉代价，在中国，不守信誉的人付出的代价太少。欧美国家如果个人信誉差，在贷款，找工作很多方面都有影响，在中国，你这个银行办不了信用卡，却可以在另外一个银行办，你在一个公司表现很差，不是很容易被别的公司知道，原因很简单，因为你去一个新的公司，别人只是把你当个”物品”使用，依然可以能带来收入，不过好在很多好的公司，开始做一些背景调查了。

所以说，我觉得联盟是我们追求的一个方向，但是现在实际的还是需要有制定一些约束，比如如果培训如果付出了不小成本，必须签订对应的合同规定相关的义务。

不过比较好的是，越来越多的人，眼界越来越宽，格局在提升，不再只是追求暂时多点收入的不择手段，我相信联盟在中国会有适应的空间。

本书内容

几乎没有公司会直截了当地提供有保证的职位；这种保证会被员工们认为是幼稚、虚伪的，或者兼而有之。相反，雇主会含糊其词地谈论录用和任期问题：他们的目标是留住“优秀”员工，而时限是——不确定的。这种模糊性实际上破坏了信任基础——公司要求员工向其做出承诺，但不会报以相同的承诺。

许多员工的对策是做两手准备，一有机会就跳槽，不管他们在面试过程或年度考核中如何表忠心。

双方的行为方式与其官方立场公然矛盾。 由于这种相互的欺骗，双方互不信任。自然，也没有哪方会从这种关系中充分获利。雇主不断失去有价值的人才，而员工无法充分投入目前的工作，因为他们正不断地在市场上寻找新机会。

与此同时，管理者被夹在中间。他们连承认这个问题都十分谨慎，更不用说解决它了。他们不是思考如何以有远见的方式促进员工发展，而是担心如何在完成重要项目之前保证团队的完整性。 没人想冒被抛弃的风险，因此没人投资于长期关系。

许多人力资源主管和高管在培训和开发项目上花了重金却眼睁睁地看着员工在几个月后离职，难免感到沮丧。如果你认为员工是自由人，自然的反应就是削减培训预算。为什么要为竞争对手培训新员工呢？

雇主、管理者和员工需要一个新的关系框架，一个他们彼此承诺可以真正保持的关系框架。

通过联盟重建信任与忠诚

双方的承诺

雇主和员工建立的关系基于他们为对方增加价值的能力。 雇主需要告诉员工：“只要你让我们的公司更有价值，我们就会让你更有价值。”换句话说“我们将让你更抢手！”

员工致力于帮助公司取得成功，而公司致力于提高员工的市场价值。

我们是一个团队，不是一个家庭

你会开除你的家庭成员吗？不会。但你会开除员工。所以不要再告诉员工我们是一个大家庭了。相反，企业更像是一支球队,有明确的目标，队员们为了这个目标和自己的发展聚在一起，有人不合适就离开了，有人留了下来, 球队经理可以决定裁减或者交易球员

硅谷真正的成功秘笈：员工拥有创始人思维

拥有创始人思维的人会推动变革、激励人心、出色地完成任务。具备创始人思维并不一定意味着你要开办自己的公司，开创性思维在市场变化剧烈的今天尤为重要，过去的高绩效员工总是在重复着自己的工作，一旦市场变化，这些技能都将变成负债。 只需要几个开创性员工，就能带来巨大影响。

我们要鼓励员工在公司进行开创新工作，约翰拉赛特是一个被迪士尼开除的动画设计师，理由是他的疯狂想法让他无法专心工作。乔布斯雇佣了他，制作了玩具总动员。后来皮克斯被迪士尼用70多亿美金收购，约翰拉赛特成为迪士尼首席创意官。

任期制：培养开创性员工的利器

将员工在你的公司职业生涯规划为一系列连续的任期，你可以更好地吸引和留住开创性员工。

在每一段任期中，管理者和员工都要制定一个任务目标，让双方都能长期受益。任期代表雇主和员工对某项具体任务的道德承诺，任期制让雇主和员工建立信任、相互投资，也保留了雇主和员工适应变化的灵活性。

诚实地谈论任期

向他们说明，先有工作将如何为他们创造改变职业轨迹的机会，他们的责任是利用在这里的工作经验抓住这种机会，为自己创造长期价值，这种价值将在他们离职后的职业生涯中体现的最明显。

公司里的三类任期

轮转期：针对高度可换的岗位，提供标准化培训，通常针对入门级员工。

转变期：个性化设计的一个时期，核心承诺是员工将有机会改变自己的职业生涯和公司，一般来讲一个任期2-5年。

基础期：雇主与员工保持高度一致性，员工认为这是他最后一份工作，雇主也希望这名员工一直干到退休。

协调员工的目标和公司的目标

你的任务是根据员工的具体任务目标而不是他的全部生活进行协调， 你不需要无条件地支持员工的价值观和理想，但你必须尊重他们。目标协调的三个步骤是：

1.建立和传播公司的使命和价值观。

2.了解每位员工的核心理想和价值观。

3.合作协调员工、管理者与公司的使命和价值观。

最终，一致的兴趣、价值观和目标将增加公司与人才之间维持长期稳固联盟的概率。

如何执行转变期计划

1.开始对话，确定目标。

——任期的整体目标是什么？

——成功的任期将给公司带来什么？

——成功的任期将给员工带来什么？

2.定期检查以交流反馈。至少每个季度要进行一次双向对话，既检查员工的贡献，也考量公司的帮助。

3.在任期临近结束前，开始制定下一个任期计划。管理者和员工制定公司内的新任期计划，或者，双方都认为员工应该去另一家公司任职。

如何处理任期中的意外

如果员工愿意在公司内部换一个岗位？那就通过对话安排好交接，结束一段任期。

投资在员工的人脉上

1.聘用有人脉的人。问问面试者“除了你，你认为我们还应该招入哪位重要人才？”

2.教会员工如何通过交谈和社交媒体从人脉中发掘情报。

3.执行有助于员工建立人脉的计划和政策。包括：鼓励员工使用社交媒体展示自己；为员工建立人脉基金；为员工社交参会提供方便；在公司办公室举行活动。

4.让员工与公司分享他们了解的信息。比如每周有半天时间交流各种信息。

打造终身联盟：前同事联络网

投资于同事联络网的成本远远低于想象，而回报则远远高于想象。同事联络网能帮你雇到优秀人才；前员工能提供有用的情报；前员工能推荐客户；前员工是你的品牌大使。

1.决定同事联络网的成员。删除掉存在纠纷和法律道德风险的前员工。

2.明确定义与前员工关系的期望和收益。常见的方法有：员工推荐奖金、产品折扣和测试白名单、举办活动、为前员工颁发荣誉、向前员工通报最新消息等。

3.建立周详的离职机制。在离职面谈中与员工巩固终身关系，收集信息进入数据库。

如何最大限度减少办公室政治

我所说的政治，是指员工在职场进阶的过程中，依靠手段，而非业绩和贡献为自己谋取空间。

几乎所有的办公室政治都是由公司老板开的头。你可能会觉得委屈：“我讨厌政治，不爱耍手腕，但是我的员工们却乐此不疲，这跟我他妈没有一点关系。”

其实你错了，公司内部的办公室政治并不在于你本人是否爱耍手段。而事实上，正是那些缺乏政治头脑的老板们却常常带出一支善于勾心斗角的队伍，因为他们常常在不经意间助长了公司内部激烈的政治斗争。

办公室政治是如何产生的？

公司CEO无意间对政治行为的鼓励或放任，往往是办公室政治的源头。

就拿给管理人员定薪酬为例来说吧，如果那些资深员工时不时地找你要求加薪，示意你他们的所得远远低于应得，甚至暗示你他们手头还有别家公司伸出的颇具诱惑力的橄榄枝，你会怎么办？

如果对方的要求合情合理，你也许会酌情考虑，然后给他加薪。这种做法听起来无可厚非，但其实你已经就此为办公室政治的蔓延埋下了祸根。

这样说吧，你对员工的加薪对促进公司的发展没有任何作用。员工获得加薪是因为他提出了加薪的要求，而并不是因为他真的工作十分出色。

你这样做的后果有三个，我们来一一分析一下。

1.公司里其他跃跃欲试的员工很快就会照葫芦画瓢，因为没有不透风的墙。无论是这一轮竞争者还是那个先吃螃蟹的人，加薪与否都与工作表现和能力无关。你花时间考虑的，不是对方的工作业绩，而是政治问题。最终，这些资深员工的加薪标准将演变为：先到先得。

2.仅仅因为对政治手腕不敏感，公司里那些默默奉献的员工将无缘这份计划外加薪。这对他们来说，是一种极大的不公平，轻则忍气吞声，重则直接炒你鱿鱼。

3.你的员工从此次事件中总结出：会哭的孩子有奶吃，会耍手腕的员工有钱赚。于是乎，你手下的员工都开始跟你玩手段、耍手腕了，准备做好听他们的集体嚎哭吧。

如何将办公室政治的发生率降到最低？

招聘员工时，要衡量对方的野心有多大。

每个人都有野心，但并不是每个人都是天生的野心家。那些以公司的发展为依托，从而实现个人职业发展的野心是恰如其分的，是无可厚非的。与此相反，那些只关注个人成功而将公司利益置之不顾的人拥有的野心却是非常的不当的。

建立严格的流程来防范潜在的办公室政治，并认真执行。

• 业绩评估与业绩奖励

• 机构设置和职权划分

你需要做的，是定期考量公司的机构设置，搜集所需的信息，在下属还没发现任何预兆的时候就做出决策。决策既出，立即执行，不给小道消息和流言蜚语留一丁点儿机会。

• 员工提拔

在提拔某个员工的时候，他的同事肯定会揣摩他受重用的原因。究竟是因为业绩好呢，还是会耍手腕呢？如果答案是后者的话，那么他们很容易产生这样的反应：觉得自己不受重视，从而跟被提拔的员工对着干。

• 当心道听途说

所以，作为公司的一把手，你必须考虑到自己的言行在全公司的影响和可能会引发的蝴蝶效应。千万不要因为自己的言行，而助长公司的不良风气。

适度的野心

在组建管理团队时，大多数新创业的公司都倾向于把“智商”作为选拔人才的主要标准。然而，一支智商出众但野心过盛的团队却不会对公司发展做出积极的贡献。

从宏观的角度来看，只有当资深主管们把集体成就放在个人成就之上，从全局角度而非个人角度来考虑问题时，这个公司才有可能实现利益最大化。公司利益的最大化就意味着个人利益的最大化。不然，零的1%还是零。

主管的野心指数应保持在适当的范围内，这一点相当重要，因为这是维系员工工作积极性的一个重要前提。如果一个主管对于个人前程的关注超过了对公司业绩的关心，那他手下的员工一定会想：我干吗要加班加点地为这家伙卖命？最能激发员工积极性的做法莫过于让他们怀揣使命感去工作，让他们相信这份崇高的使命值得他们把个人抱负暂放一边。所以说，能将理想抱负控制在合理范围内的主管比那些野心勃勃的家伙更有价值。

以“团队”为出发点来考虑问题的人说话时很少使用“我”，哪怕是在谈论其个人成就。在面试中，他们总会把功劳推到从前的合作伙伴身上。相对于工作待遇和职业发展，他们更关心这家公司的实力。如被问及为何离开上一家公司，他们往往会把责任归咎于自身，检讨自己判断力不佳而做出的错误决策。

彼得定律和坏榜样法则

彼得定律：意即在一个集团中，员工只要表现出众，就能获得提拔，直至被提拔到一个他不能胜任的岗位。

坏榜样法则：依据该法则，一个团队内部无论哪个层面出现了滥竽充数的人，他们都会像蛀虫一样影响其他成员，最终使得能力出众的人也渐趋平庸。这条法则的原理就是：员工会拿他们上级中能力最差的那个人做参照物。

超级混蛋

只有聪明还远远不够。出色的员工同样还要能吃得了苦，担得住事，并且善于和团队成员和睦共处。

公司需要选拔大量头脑灵活且责任心强的员工来发现机构运作中的漏洞，并协助解决这些漏洞。然而，有些头脑灵活的员工不但帮不了公司，反而会给公司制造更多的麻烦。出现问题时，他们不是立即找出其中亟待修复的漏洞加以解决，而是拼命挑毛病，以凸显自己的高明。具体来说，他会质疑公司的前景，贬低公司的领导者，以此来衬托自己。有这种习惯的员工越聪明，产生的破坏力就越强。也就是说，聪明人产生的危害性会达到最高点，因为人们对聪明人往往坚信不疑。

他们为什么这么做呢？

1. 寻求关注
2. 天生叛逆
3. 思想不成熟

一个公司是由集体的力量造就的，员工如果不能成为这个集体中值得信赖的力量，那么无论他的个人能力有多强，对于公司来说都是没有价值的。

恶狗咬人咬得才狠。如果你跟前有这样的恶狗，你就必须早做了断。 （这个我深有体会，今年就碰到了一个CW的恶狗）

该不该招资深人士

创办技术型公司，意味着你自此开始了一段和时间赛跑的艰难旅程，这段旅程将持续至你生命的最后一刻。没有哪一家刚刚创业的技术型公司能摆脱产品“保质期”这个魔咒。再伟大的想法过了期就会一文不值。

任用那些曾有过相关创业经验的人可以加速成功的进程。

聘请资深人士加盟新创业的公司，有点儿像运动员为提高比赛成绩服用兴奋剂。如果使用得当，你有可能刷新纪录；如果使用不当，你就会一败涂地。

首先，要求他们顺应公司的企业文化。他们来自不同的公司，拥有不同的企业文化，而且有些企业文化的确比你公司的更胜一筹。但要记住，现在他们是在你的公司就职，那就必须接受你这里的文化，适应你这里的办事风格。 在这个问题上，不要因为对方资格老而轻易让步。坚持你的原则，推行你的企业文化。

其次，制定一个清晰明确的高标准工作要求。

你要先确保自己的员工出类拔萃——不管是新人，还是老将。不能只满足于对方比你更胜任这份工作，因为你聘用他们就是为了让他们做你不擅长的事。

具有讽刺意义的是，管理技术部门最先懂得：一个管理出色的质量控制部门无法生产一款高质量的产品，却能告诉你产品研发团队何时生产了一款质量低劣的产品。类似情况是，一个高质量的人力资源机构无法给你创造一个管理完善、企业文化成熟的公司，却可以告诉你，你和你的管理者何时没有尽到职责。

招聘

• 你非常清楚每一个公开职位所需要的技能和才干是什么吗？
• 你的面试官准备得充分吗？
• 你的管理者和员工有没有向求职者积极介绍公司的情况？
• 面试官们能按时到场吗？
• 管理者和招聘人员会及时联系应聘者吗？
• 你能和最强的公司展开强有力的人才竞争吗？

报酬

• 就你公司的统计数据而言，你享受的福利合理吗？
• 和与你展开人才竞争的公司相比，你的薪水和股票期权福利如何？
• 相对于你的薪酬制度，你的绩效排名如何？培训与融合
• 聘用员工之后，从该员工及其同事，以及管理者角度而言，他需要多长时间才能体现出生产力？
• 加入公司之后，员工需要多长时间才能清楚公司对他的期望？绩效管理* 你的管理者会给予自己的员工前后一致、清晰明确的反馈吗？* 你公司的书面绩效评价报告质量如何？
• 你公司所有的员工都能按时收到自己的绩效评价吗？
• 你能有效地管理工作表现不佳的员工吗？

#工作动机

• 你的员工来上班时激动兴奋吗？
• 你的员工对公司使命怀有坚定的信念吗？
• 他们每天喜欢上班吗？
• 有没有员工消极怠工？
• 你的员工清楚公司对他们的期望吗？
• 员工们是安心留在公司还是辞职人数比往常更多？
• 员工们为什么辞职？

有效人力资源的几项要求

流程设计师

人力资源主管颇有点儿像质量监察部门的主管，他必须精通流程设计。准确衡量重要管理流程的一个关键是，看其是否具备出色的流程设计和严格的流程管理。

真正的外交官

没有人喜欢打小报告的人。如果管理团队对其缺乏完全信任，人力资源部门不可能有效地开展工作。管理者必须相信，设立人力资源部的目的是帮助自己改进工作，而不是对自己进行监管。优秀的人力资源主管会真心实意地为管理者提供帮助，不会因为发现了问题而大肆表功。他们会直接找管理者解决问题，提高管理质量。 如果人力资源主管将自己的知识深藏不露，玩弄权术，或搞阴谋诡计，那他就毫无用处。

行业知识专家

薪酬、福利、最佳招募方法等变化极快，人力资源主管在行业之中必须建有深厚的关系网，对所有最新情况了如指掌。

CEO信任的智慧顾问

感觉灵敏的人

当公司管理质量开始下滑，所有人对此毫无觉察，但感觉极其敏锐的人却能察觉出公司正在走下坡路。你需要这样一个人。

可以从朋友的公司挖人吗？

这里的朋友是直：

• 重要的生意伙伴
• 朋友

从朋友公司挖人的一个理由经常是：反正他们也在找新工作。

替你的朋友想想，这个时候他肯定在为公司的生死存亡而奋战，没有什么比失去一个优秀员工而让人伤心，而且其它员工会把这当做公司没落的征兆，更让你朋友觉得打击的时，他其它员工会认为连他的朋友都挖他的墙角。

思考这种动态关系有一个简单的方法：如果你丈夫离你而去，你希望自己最好的朋友和他约会吗？他肯定会和其他女人约会，所以，让你的朋友得到他难道不好吗？这看似符合逻辑，但其实并非如此，你肯定会失去朋友。

1.除非该员工极其出色，否则你无论如何也不要从朋友的公司挖人。

2.“挖人的反身性原则”：某公司挖走你的几名员工，会让你惊恐震惊，那么你就不应该挖他们公司的任何员工。

3.制定政策：将那些规定未经CEO（或高级主管）同意，不得雇佣其员工的公司名单列举出来。在录用前，要保持公开，并与其所在公司的CEO进行沟通，对他进行背景调查。

4.当你告诉你的朋友从他公司挖人了，就意味他都不如这名员工对你重要，别指望你们还能继续做朋友。

处理这种情况的最佳方式就是公开透明。看清了雇用出色员工和背叛珍贵友谊之间的矛盾之后，你就应该将事情公开，告诉员工，你和他现在所属的公司有重要的生意往来，在录用他之前，你必须和他所在公司的CEO进行沟通，对他进行背景核查。告诉他，如果他不同意，你会立即中止录用，并对此保密。在录用之前，要和朋友进行交谈，这样才能更好地判断录用他的员工对你们的关系所带来的影响。此外，你还有可能避免用人不当，因为往往有些应聘者在面试中表现极佳，但进入公司之后，表现却不尽如人意。

如何避免大公司主管难以胜任小公司工作的情况发生？

第一，在面试过程中将具有破坏性的不匹配情况筛选出来。

雇用一名大公司主管之后，你会面临两种危险的不匹配情况：

节奏不匹配。

这样的主管已经习惯于等待邮件到达，等待电话铃声响起，等待会议被安排得井井有条。在你的公司里，他会长时间处于等待状态。 如果这位新主管总在等待（根据他自己的受训经验），其他员工就会充满疑虑。你会听到这样一些言论，如那家伙整天都在干什么？

技能不匹配。

管理大公司需要的技能和创建新公司大不相同。管理大公司时，你往往对这些任务比较擅长，例如复杂的决策制定、次序优先、机构设计、流程改进，以及部门交流。创建公司时，没有机构需要设计，没有流程需要改进，部门之间的交流非常简单。但同时，你必须能够非常熟练地实施高质量的招聘流程，具备丰富的专业领域知识（你自己负责质量控制），懂得如何从零开始创建流程，而且在把握新方向、制定新任务方面要非常有创造力。

如何筛选？

你可以询问如下几个问题：

1.“你上班第一个月会干什么？”——如果答案是要用一个月去适应和了解，那么这样的人不要聘用，因为小公司没有那么多需要了解的。

2.“这份新工作和你目前的工作有什么不同？”——挑选那些能意识到工作差异的应聘者。

3.“你为什么要加入一个小公司？”——想加入你的公司的正当理由是渴望变得更加有创造力。

将新人的融入和面试看得同等重要。积极帮助新人融入公司。

1.促使他们积极创造。每日、每周，甚至每天给他们制定目标，确保他们做出相应的贡献。

2.确保他们明白自己的职责所在。如果30天后，你觉得他们还没有掌握情况，就要毫不犹豫地解雇他们。

3.把他们放入集体。给他们列一份他们需要认识并向其学习的员工名单，并要求他们提交一份汇报，汇报自己从这些人身上学到了什么。

在没有招聘经验的时候，怎样才能招到优秀的人才？

知道自己要什么

**你必须意识到自己非常无知，不要妄想仅靠面试应聘者就能学会如何招聘。虽然面试过程对你可能很有启发意义，但将其当作唯一的知识来源却很危险 **。这样做会让你很容易落入下面的陷阱：

第一，凭外表和感觉聘人。

第二，挑选与众不同的人才。
你会想象一个完美的主管形象，然后把实际应聘者和你理想中的形象进行对应。这一观点之所以错误有以下几点原因：首先，你不能雇用一名想象中的主管来管理一个充满可能性的公司。你必须为处在其次，你想象中的主管形象往往都是错误的。你设想的这个形象的基础是什么？最后，让招聘团队理解这么抽象的一套标准极其困难。其结果是，每一个人都想在应聘者身上寻找与众不同的东西。

第三，看重的是应聘者身上没有弱点，而不是其长处。经验越丰富，就越清楚公司里的每个员工都有严重的缺点（包括你自己）。金无足赤，人无完人。因此，招聘时要看重应聘者的长处，而不是其身上没有弱点。每个人都有弱点，只不过有些人身上的弱点比较明显而已。因为其人没有弱点而对其加以聘用意味着你将愉快感作为优先考虑的因素。当然，你必须清楚自己需要应聘者具备什么能力，然后找出具备这种能力的人，忽略他在其他方面的弱点。, 当然人品差的人就不要录用了。

想知道自己需要什么样的人才，最好的方法是在该职位上亲自体验一番。 不是名义上的，而是真正履行职责。 CEO往往不愿意干职能性工作，因为他们担心自己缺乏相应的知识。这种担心恰恰是你应该干这类工作的原因——学会相应的知识。的确，亲自体验是获得招聘所需要的所有知识的唯一方式，因为你要为公司寻找合适的主管，而不是普通主管。

第四，引进专家也十分有益。

如果你认识一位出色的销售主管，先和其进行面谈，了解他获得成功的原因，搞清楚他的哪些能力最符合你公司的需要。如果可能，将该领域专家纳入面试流程。不过，要注意，这些专家并不完全符合招聘条件。也就是说，他对你的公司缺乏了解，不知道公司的运作模式以及公司的需要。因此，不能将决定都推给专家来做。
最后，你心里要清楚自己对加入公司的人有什么期许。这个人在第一个月会做什么？你期望他加入公司的动机是什么呢？你想让他立刻扩大部门规模，还是在下一年只招一两个新人？

控制招聘流程

1.写下你想要的能力，以及你愿意忍受的缺点

一名主管很可能收到其它团队成员的喜欢，但工作起来却毫无效率，同时他也可能工作十分高效，影响十分深远，却受到大家的鄙视，但是后者明显要很多。

2.设置检验招聘标准的问答题目

3.组成面试小组

4.秘密调查和公开调查

单独做决定

只有CEO能全面了解招聘标准，制定招聘标准的基本根据，面试官和应聘者推荐人反馈回来的所有意见，以及各类持股人的相对重要性。

我们都知道，员工培训是非常重要的，可以让员工尽快具备岗位技能，也对员工个人成长大有帮助，不过风险就是，在中国这个市场环境里，培训很可能就是为别人做嫁衣，好不容易你辛辛苦苦带人，投入大量精力和成本培养人，最后别的公司直接拿去用，比如你付出了巨额的成本，但是别的公司仅用你培养成本10%的涨薪就可以轻松把有些人挖走，虽然被挖走的人N年后还是一样继续原来的那点积累（因为不想自己培养的，也别指望你去了会培养你），但是公司却实实在在遭受的损失，所以对那些还在花力气培养人才的公司，我们要怀着一份敬意，如果所有的公司都不愿意培养人，而是直接去挖，那么行业将慢慢无人可用，我今年招了几个社会实习生，有几个就是来蹭培训的，后来意味自己学了很多东西，在我看来只是刚刚学了几个API，还没入门就要远走高飞，我只能祝他们在新的岗位上能大放异彩吧。

为什么要进行培训？

• 培训确实能够提高公司的生产力，也更容易推进绩效管理，提高产品质量。
• 培训非常有利于员工留任。

员工离职，排除一下经济原因，公司的业务原因，工资原因之外，下面有两个常见的原因：

第一，他们讨厌自己的管理者。 缺乏指导、 职业发展前景不明朗、 收到的反馈多为负面的，这些因素通常会令员工感到惊恐不安。

第二，学不到东西：公司没有投入资源，帮助员工学习新的技能。

如何对员工进行培训？

最好的培训导师是CEO本人，作者写的很多培训文件至今还在被人们使用。比如：好的产品经理和坏的产品经理。

1.职能培训。最好从与员工最密切的话题开始：胜任自己工作所需要的知识和技能。培训具有强制性。

2.管理培训。为管理团队设定期望时，管理培训是最佳着手点。这些课程会告诉管理者如何按照你的期望办事。

3.其他培训机会：邀请各路精英，分享自己的拿手技能。与谈判、面试和财务等相关的培训不仅能加强公司在这些方面的能力，还能鼓舞员工的的士气。

管理者只有两种方法可以提高员工的产出：激励和培训。

这里的 “高管” 我们也可以理解为重要项目中重要的人。

解雇”高管”，我们可以说他们表现糟糕，但是既然要解雇，说这些已经于是无补，事实上出现这种情况是因为自己很差劲，解雇高管是因为公司面试和整合系统出了问题，我们必须找出原因，才能避免以后这类事情的发生，可能的原因如下：

对高管的职责定位不清。

连自己想要什么都不知道，更别说招聘高管的标准了。很多时候，CEO们仅凭自己对高管这一职位不切实际的想法和主观感觉来进行招聘。这种错误的做法往往导致所招高管缺乏关键的、必要的才能。

招聘高管时，看中的不是对方的长处，而是对方没有弱点。

在进行群体面试时，这种做法尤为普遍。招聘小组往往在应聘者身上吹毛求疵，并不关注他是否具备你所需要的、作为一名世界一流的管理者的特质。因此，以这样的方式招来的高管也许没有明显缺点，但在你需要他大显身手时却表现平庸. 如果你招聘的人不具备你所需要的世界一流的实力，你的公司也就成不了世界一流的公司。

大和小庙偏招尚。

一直以来，风险资本家和高管招募人员给CEO们的错误建设是：要按高于招聘的原则招人。他们会说，“想想未来的3~5年，公司规模将会有多大”。如果公司规模很大，那么能招到一个有本事运作大规模公司的人，这当然再好不过。如果打算快速壮大公司规模，那么能招到一个内行的人也很有必要。但是，如果公司规模不大，而且你也没打算壮大公司规模，那么招的人只要能胜任接下来的18个月的工作即可。如果你要招的人在18月后才会崭露锋芒，那么还没等他有机会一展才华，公司就会将其拒之门外。因为公司其他员工肯定会心有不平：他有没有做出任何贡献，我们凭什么要给他优先认股权？这类问题会频频出现。 事实证明，风险资本家和高管招聘人员说的也有一定道理，他们只是从以前的失败中吸取了错误的教训而已。

对招聘职位一概而论。

世界上并没永远了不起的CEO、营销负责人或销售负责人。这名销售负责人的了不起之处仅限于在你的公司，在接下来的14~24个月之内。他的这一职责和微软公司或脸谱网（Facebook）的同一职位并不相同。不要招那种类型化的应聘者，这不是拍电影。

管理人员个的人抱负和公司目标相悖。

如果人员的个人抱负和公司目标相悖，就算他的才华再出众，公司也应该将其拒之门外。

没能令管理人员融入公司。

将新人引入公司并委以重任非常困难。其他员工很快会对其评头论足，该新人的期望也许和你不同其对工作在很大程度上也许并不明确。因此，在解雇高管之后，一定要检查并改进公司的人才招聘计划。

有关公司规模的特殊情况

解雇高管的一个相当普遍的理由是，当公司规模扩大到原来的4倍，高管的工作效率就会变低。因为在这时，管理工作就会变成全新的工作，每个人都需要重新定位自己，以适应新的工作。经营一家有着200多名员工的全球性销售公司和一个只有25人的本地销售团队大不相同。幸运的话，你雇来的25人团队的人也许会慢慢学会了管理200人的团队。如果不走运，你就要为新的工作任务另聘合适的人选。这既不是管理人员无能，也不是公司系统错误，这是现代社会的真实生活。不要试图避免这种情况，这只会让事情变得更糟。

有关公司快速扩大规模的特殊情况

如果你研发出一款非常棒的产品，市场也很需要这款产品，你就会发现，自己迫切希望公司以极大的速度发展壮大。要想成功实现这一愿望，除了聘用合适的管理人员之外，别无他法。所谓合适，是指这个人曾有令其他规模相当的公司迅速壮大的成功经验。请注意，这与直接继承一个规模很大的公司或以你自己的方式运行一个规模很大的公司完全不同。一定要确保你聘用的是有快速发展能力的管理者。此外，如果你还没有准备给他们大量的预算去发展他们的组织机构，那就不要聘用他们，让他们保持当前状态即可。经验丰富的、有快速发展能力的管理者对建设成功的创业公司来说非常重要，以至于招聘者和风险资本家往往还没有等公司准备好，就极力建议CEO们将他们招进公司。

如果非要让我说一件事情是可以让管理者水平有明显提升的事情，那就是学会解雇员工，今年我解雇了一个”伪工作者”，这件事我做的不够好,如果让我之前仔细研读了这本书，那么我相信结果或者说过程会有大有不同。

要想保持企业文化的延续性，留住最优秀的员工，我们要在裁员时采取了正确的方式。下面是我从本书学习到的如何解雇员工

保持头脑清晰

如果公司没能实现自己的财政计划，形势严重到了必须辞退那些不惜重金聘请而来的员工的地步，这对CEO而言，无疑是巨大的压力和沉重的负担。在这样的时刻，我们很难顾及未来，因为过去会将你压得毫无喘息之机，而这正是你必须要面对的。

当机立断

一旦决定解雇，那么必须尽快执行。如果走漏消息，就会横生枝节，麻烦不断。员工会质询管理者，公司是否要裁员。如果管理者不知情，员工就会认为他愚蠢。如果知情，他要么不得不向员工撒谎，令消息进一步走漏，要么保持沉默，令群情更加激愤。

对解雇的原因要有清晰的认识

不管是因为经营不善，还是员工绩效表现不佳，都必须实话实说。

对管理人员进行培训

整个裁员过程中最重要的一步就是培训管理团队。如果将未经培训的管理人员置于裁员这一极为尴尬的情境之中，他们大部分都会无法应对。

对管理人员的培训需遵循一条黄金法则：自己的员工要自己亲自辞退，不能将这项工作推卸给人力资源部门或某个更严厉的同事，不能像电影《在云端》中那样雇用一家外包公司来完成。

为什么这么严格？为什么不能找些强势的管理者出面，替你完成这一棘手任务？公司的声誉和管理人员的声誉都取决于你的表现

解雇时说话要果断，这是一次解雇行为，使用”我已经决定” 而不是”我认为”这样含糊不清的话。

向公司全体人员发表讲话

在执行辞退决定之前，CEO必须向公司全体人员发表讲话。CEO必须为管理者们解释辞退的合理性。如果这一点做得好，管理人员在辞退时就会更加容易。务必牢记财捷集团前CEO比尔·坎贝尔告诉我的一句话：话是说给那些留下来的人听的。这些人会非常关心你对待他们同事的方式。你辞掉的员工之中，有很多人都和留下来的人关系亲密，因此，你一定要给予他们足够的尊重。毕竟，公司还要向前发展，因此你必须把握尺度，不要过度表达歉意。

一定要让大家看见你，你一定要在公司出现

在向公司全体人员发表讲话、告诉大家许多人将被辞退之后，你也许会不愿意在公司里四处走动，和大家交谈，而更愿意去喝几杯酒。千万别这样。一定要在公司出现，一定要让大家看见你，一定要积极参与公司事务。

鼓励式管理造成的错觉

作为公司的最高管理者，我以为我能从容应对坏消息。但事实刚好相反，面对坏消息，我比任何人都紧张。让我彻夜难眠的事，工程师们却并不在意。毕竟，我是创办公司的CEO，是那个和公司息息相关的人。一旦发生可怕的差错，他们可以一走了之，我不能。因此，面对损失，员工们会更加冷静。

更愚蠢的是，我以为我唯一的职责就是为公司解决问题。如果我早就想明白这一点，我就会意识到，只有我一个人操心，根本没有任何意义。例如，担心这个产品不够完善，但实际上，编写代码修复产品的人不是我。

更好的办法是，将问题交给不仅有能力修复产品，而且对修复产品充满兴趣和动力的人。假如我们失去了预期的一笔大交易，整个公司必须搞清楚其中的原因，这样才能共同解决我们在产品、营销和销售流程中出现的各种问题。如果坚持将问题留给自己，那么问题就很难被解决。

为何要实话实说？

对公司出现的问题做透明化处理很重要，主要原因有三：

信任

没有了信任，沟通就会中断。具体来讲就是：

在人类的所有交往之中，沟通量与信任程度成反比。

请考虑下述情况。如果我完全信任你，我就不需要你对自己的行为或其他举动进行解释，因为我知道，你所做的一切，无论什么，都符合我的最大利益。反之，如果我不信任你，那么再多的谈话、解释或说理对我都没有任何影响，因为我不相信你说的是真话。

在公司里，这一点十分重要。随着公司的成长，沟通成了公司最大的挑战。如果员工完全信任CEO，沟通的效率就会大大提高。实话实说就是建立这种信任的关键。一名CEO在一段时间内拥有这种被信任的能力，往往是一家管理良好的公司和一家管理混乱的公司之间最大的差别。

参与解决问题的人越多越好

为了创建一个出类拔萃的技术公司，你必须雇用大量的精英人才。而不让这些精英人才参与解决公司最大、最棘手的问题完全是一种浪费。一个人，无论多么出色，他都无法解决自己不了解的问题。正如开源社区所倡导的：“只要有足够多的眼睛，就可让所有问题浮出水面。”

健康的企业文化就像过去的路由信息协议：好事不出门，坏事传千里

允许自由并公开讨论问题，公司才能迅速解决问题。企图掩盖问题只会令所有员工感到灰心。因此，CEO应该采取的做法是：建立一种奖励文化，而不是惩罚文化，对那些公开提出问题并为其找到解决办法的人予以奖励。

最后一点想法：只有经营过公司，你才会体验到那种巨大的心理压力，才不会过于乐观。作为CEO，你要勇敢面对压力，直面恐惧，实话实说。

创业中的挣扎

创建公司之初，每一位企业家都怀揣着一个清晰明确的成功梦想。你会创造一个极其优越的环境，雇用最能干的人加入你的团队，你们会齐心协力，研发一款令客户满意的产品，让这个世界变得更美好。

为了使梦想成为现实，经过了无数个日夜的辛苦奋斗，你却发现，事情并没有按计划进行。从一开始，你的公司就没有跟上你所设想的步伐。你的产品出现了难以解决的各种问题，市场和你想象的大不相同，你的员工正在失去信心，有些人已经辞职。在辞职的员工中，有些人还是非常优秀的，他们的离去令剩下的人们开始怀疑继续留在公司是否明智。资金越来越少，风险投资家告诉你，由于近在眼前的欧洲经济危机，你的公司将很难筹集到资金。在一次竞争中，你输给了对手，失去了一个忠诚的客户，失去了一名极出色的员工。你的压力越来越大。究竟是哪里出问题了？你的公司为什么没有按预想的轨道运转？你真有足够的能力去实现梦想吗？当梦想变成了噩梦，你会发现，自己陷入了旋涡之中。

关于挣扎

挣扎是你想知道自己为什么要创办公司时的状态。

挣扎是人们问你为什么不退出，你却不知怎么回答时的状态。

挣扎是你的员工认为你在撒谎，而你却认为他们也许说得对的状态。

挣扎是你食之无味时的状态。

挣扎是你认为自己不应该当公司CEO时的状态，是你明知自己力不从心、明知无人能取代你时的状态，是所有人都认为你是白痴却没有人会炒你鱿鱼的状态，是自我怀疑变成自我憎恶时的状态。

挣扎是你在和别人谈话却听不到对方在说什么时的状态，因为你一直在挣扎。

挣扎是你想结束痛苦时的状态。挣扎就是痛苦。

挣扎是你去度假，想放松心情却使心情更差时的状态。

挣扎是你周围簇拥着一大群人，你却感到茕茕孑立、形影相吊时的状态。挣扎是冷酷的。

挣扎是违背承诺、粉碎梦想的地狱，是一身冷汗、五内俱焚的感觉。

挣扎不是失败，但会导致失败。如果你孱弱不堪，你更容易失败。

大多数人都不够强大。史蒂夫·乔布斯到马克·扎克伯格，所有出色的企业家都会经历挣扎，而且是苦苦挣扎，因此，人人都会挣扎。不过，这并不意味着你一定能挣扎成功。你也许会挺不过去，这就是挣扎的恼人之处。

挣扎是成就伟大的竞技场。

#如何走出挣扎

不要扛下所有责任。人们很容易想当然地认为，令自己烦恼的事情一定会令自己手下的人更加烦恼。事实恰恰相反。除了负有最大责任的人以外，没有人会把损失当回事，没有人比责任人更感同身受。当你无法分担所有负担时，你要将某些负担分担出去，找尽可能多的人来共同解决问题，即使这些问题事关企业的生死存亡。

这不是国际跳棋，而是国际象棋 科技行业往往极其复杂。底层技术只要一有变动，竞争就会发生变化，市场也会随之发生改变，而人们则会使出各种招术，以求自保。因此，就像《星际迷航》中下三维国际象棋一样，总有一步棋可走。你认为自己已经无路可走了吗？你觉得这步棋怎么样：作者凭着200万美元的后续收益以及340名员工的阵容带领公司上市，计划在下一年实现7500万美元的收益？作者走的就是这步棋。那是2001年，人们普遍认为，对一家要上市的科技公司而言，这是有史以来最糟糕的时机。走这步棋时，作者手头只剩下能维持公司运营6周的资金。天无绝人之路，总有一步棋可走。

只要坚持下去就有转机。在科技型竞争当中，明天和今天看起来完全不同。如果你能坚持到明天，也许就会发现，在今天看来似乎毫不可能的解决办法会赫然出现在眼前。不要过分苛责自己。公司身陷困境也许都是你的错，因为人是你雇来的，决定是你做的，而且接受任务时，任务的风险性你是知道的。每个人都会犯错，每位CEO都会犯无数错误。要正确评估自己，过分苛责自己于事无补。

请记住，这是区分男人和男孩的方法如果你想成就一番事业，这就是挑战。如果你不想，那你根本不应该开办公司

做分公司已经快五年了 ，虽然离真正创业还十万八千里，但是从一开始做分公司的时候，我就以 “创始人” 的心态来做的，如果一开始”兴趣”和”冲劲”多一些，但是随着你经历的事情越来越多，越来越多经历一些你不曾想过的事情，你会发现兴趣或者冲劲和做好一个公司之间离着十万八千里，就拿最近一年公司的一些奇葩事情，让你对人性都有了更多的认识，这个时候，我发现作为一个公司的负责人，身上需要的修炼的品质太多了，这些包括心态、包容、冷静、激情、智慧、领导力等等，我面临着不小的压力，而一个负责人很多时候是孤独的，你的事情很难别人帮你或者思考，于是我开始读了不少书籍，**<<创业维艰>>这本书从标题上就让我找到了认同感，而且英文名是“The hard Thing About Hard Things”** 如何完成比难更难的事, 于是我就迫不及待的用了一个周末的时间读完了，下面就记录了我对本书的介绍和读书笔记。

作者简介

本.霍洛维茨，硅谷最早一批做互联网的，1999年与网景之父马克.安德森共同创立Loudcloud公司，在互联网泡沫时，多次带领公司起死回生，最后把公司16亿美元高价没给了惠普。后来有成立了风险投资公司，投资了Skype, Facebook,Instagram, Twitter, Pinterest, Airbnb等等知名互联网企业，被称为”硅谷最牛的50个天使投资人”之一。

艰难创业

书的第一部分讲述了作者艰难的创业，一开始加入网景，但是竞争对手是微软的IE浏览器，98年买给了AOL, 99年作者创办了Loudcloud, 融资，扩张，但是我们知道99年正是互联网泡沫时期，泡沫破灭后，难以融资，走途无路时，决定上市，但是上市后股价从6美元降到2美元，一系列努力让股价变好后，有来了911的事件，最后破产，LoudCould被卖掉，留下了Opsware软件，上市后估计跌至0.35,如果股价不能提到1美元，公司就完蛋了，作者经过了一些列的努力让股票回到了8美元，最终以14.25亿美元买给惠普赚取了第一桶金，随后作者和马克.安德森创办了风险投资公司，投资开头说了那些至今都依然闪耀万丈的互联网公司。

第一部分主要是创业故事，需要大家自己品读，下面我读书此书时记录的文中一些不错的文字。

• 对于一家企业来说，真正的难题是什么呢？真正的难题并不是设置一个宏伟的、难以实现的、大胆的目标，而是你在没有实现宏伟目标之时不得不忍痛裁员的过程。真正的难题不是聘请出色的人才，而是这些“出色的人才”逐渐滋生一种优越感并开始提出过分的要求。真正的难题不是绘制一张组织机构图表，而是让大家在你设计好的组织结构内相互交流。真正的难题不是拥有伟大的梦想，而是你在半夜一身冷汗地惊醒时发现，梦想变成了一场噩梦.

• 人们经常问我，我们两人在18年里更换了3家公司，却一直保持着极高的工作效率，这是怎么做到的。大多数合作关系要么过于紧张而令人难以忍受，要么紧张不足而缺乏效率。人们要么相互挑战，导致彼此交恶，要么陶醉于彼此的奉承之词而无所受益。就我和马克而言，即使是18年后的今天，他依然对我的想法吹毛求疵，让我感到烦恼，我对他亦是如此。但事实证明，这种方式对企业的发展有益无害。

• 无论是谁，你的人生需要两类朋友。第一类是当你遇到好事时，你可以打电话与之分享喜悦的朋友。他的喜悦不是那种蒙着羡慕、嫉妒面纱的虚假喜悦，而是发自内心的真诚喜悦。第二类是当你身陷困境时，你可以打电话与之分担、向其倾诉的朋友。

• 研发出好产品是创新者的职责，而不是客户的任务。 客户只知道根据对现有产品的体验来判断自己想要什么。

• 在每周的员工会议上，我加入了一个名为“我现在没有做什么？”的议程。通常，在员工会议上，大量的时间都用来进行回顾、评估以及改进员工们所做的事情，如研发产品、销售产品、服务客户、聘用员工等。然而有时候，你没有做的事却是你真正应该关注的事。

• 创业公司的CEO不应该计算成功的概率。创建公司时，你必须坚信，任何问题都有一个解决办法。而你的任务就是找出解决办法，无论这一概率是十分之九，还是千分之一，你的任务始终不变。

• 人们总是问我：“当一名成功的CEO的秘诀是什么?”遗憾的是，根本没有秘诀。如果说存在这样一种技巧，那就是看其专心致志的能力和在无路可走时选择最佳路线的能力。与普通人相比，那些令你最想躲藏起来或干脆死掉的时刻，就是你作为一名CEO所要经历的不同于常人的东西。

• 大多数管理书籍的重点都是如何正确地做事，不要将事情搞砸。但我的经验却是，把事情搞砸之后，如何深刻理解那些你必须要做的事。

企业文化这个话题太大，有很多学者，企业家谈论这个话题，每个人都有不同的想法，我在这方面没有什么经验，但是想基于自己目前的认知来谈谈对公司文化的感受和想法。

什么是企业文化

先看一下百度百科的定义:

企业文化，或称组织文化（Corporate Culture或Organizational Culture），是一个组织由其价值观、信念、仪式、符号、处事方式等组成的其特有的文化形象。

职工文化，也称企业职员文化，是与企业文化相对应的文化形态，职工文化以职工为本，是一种素质文化，企业文化以企业为本，是一种管理文化。

企业文化是在一定的条件下，企业生产经营和管理活动中所创造的具有该企业特色的精神财富和物质形态。它包括文化观念、价值观念、企业精神、道德规范、行为准则、历史传统、企业制度、文化环境、企业产品等。其中价值观是企业文化的核心。

企业文化是企业的灵魂，是推动企业发展的不竭动力。它包含着非常丰富的内容，其核心是企业的精神和价值观。这里的价值观不是泛指企业管理中的各种文化现象，而是企业或企业中的员工在从事经营活动中所秉持的价值观念。

反正上面的定义我是记不住，那么什么是企业文化呢？ 随着这几年的不断的认识，我对企业文化有了一些自己的看法。

每个企业都有自己的企业文化

其实一个企业不管怎么样，他都有自己的企业文化，很多时候大家觉得自己所在的公司没有企业文化，其实我想说“没有文化不也是公司的企业文化吗？”，所以说不管你有没有提出“口号”，这个公司都会自发的形成一种文化，只不过这种文化大部分时候都不是你想要的。比如，人员充满抱怨，做事得过且过，这不也是一种“文化”吗？

团队活动是一种文化吗？

原来，我一直认为举行团队活动就是一种文化，比如爬山，打球，聚餐等，但是后来我觉得这个还不能算是企业文化，这个只能算是一种活动，他能够提升团队的凝聚力，因为爬山、打球、聚餐这样的事情哪个公司都可以举办。

我所认为的企业文化

我个人觉得，企业文化是一种能够让你实现目标，让你公司能够提供更好的产品或者服务的东西。

企业文化的作用

企业文化重要吗？我认为企业文化很重要，企业文化主要有一下的作用：

1. 弘扬公司的价值观，促进公司的发展，实现公司的目标
2. 聚集有助于实现公司目标的员工
3. 使员工乐意为公司的发展贡献自己的汗水

如果一个企业没有企业文化，那么每个人都会有自己的文化，这个文化很难统一，这样很难一起做出优秀的产品或者提供优秀的服务。

我们的企业文化

我觉得企业文化，很难在公司刚成立的时候就建立，而是一个不断发展和完善的，应该是从员工日常工作中提炼出来的。通过这个可以影响现有或者以后新加入的人。

那我们分公司来说，一开始我一直想建立的是一种敏捷的文化，但是敏捷包含的东西太多，经过几年的实践，我发现很多新加入进来的人不知道什么是敏捷，甚至有些老员工对敏捷的理解也比较浅, 那么把敏捷作为公司的企业文化，操作起来有一定的困难。

Quality & Productivity

我们发现，要想有竞争力，我们必须要在两个方面突出 “高质和高效 (Quality & Productivity)”, 在我们专注这两个方向来建设我们的企业文化的时候，我们很多的一些好的做事方式就出来了，比如，为了高质和高效，我们采用敏捷的开发过程，我们对质量的追求就需要我们正确理解需求，减少bug, 使用测试驱动开发等。我们对效率的追求，就让我们必须学习新的技术，持续集成，使用Git、多使用快捷键等，另外高质和高效不只是针对个人，而是针对团队，那么久要求我们有较好的团队文化，比如不要团队内部人身攻击，讨论问题不要假大空:”Show me the code”.

Responsibility & Passionate

高质和高效让我们掌握了做事的方法和标准，知道了我们的目标，但是，后来我们发现光有这是不够的，如果没有责任心，光有方法或者标杆是不容易达到我们定义的标杆的，而一旦责任心下降，质量和效率都下降，即使我们使用再优秀的开发过程和开发工具。那么我们文化里就需要强调责任心，我们每个人都要有责任心，对团队负责任，对自己负责任，对客户负责任，对公司负责任。拿我们做项目来说，不是别人安排你做啥你做啥，而是你要把软件/项目做好，需要啥就做啥，比如，有的人就是看到了装作没看见就是很不负责任，所以，我们需要鉴别一个人是不是有责任心。

Responsibility 责任心

在这里面，我想说个误区，有的人觉得，钱给的越多，责任心越大，我觉得这是一个伪定义，第一，钱多少才算是多呢？第二，如果一个人的责任心根据钱的多少来计算的话，那么管理者永远都要陷入这个里面。

事实证明，钱涨一点，短期有一定的激励，最多多做一点事，但是责任心还是没有变化的。通过我的观察，那些拿1万块的人很认真负责的人，在他们拿一千块钱的时候也很认真负责。我并不是说，我们需要克扣员工的工资，我们仍然需要给员工一份相对满意的薪水，我只是说一个人的责任心不会随着钱的变化而变化，换句话说，有责任心的人一定会把接手的任何东西都尽力，如果觉得钱少，他会提出钱少，或者换一份工作而不是消极怠工或者是降低产出。

我们公司曾经辞退一个“装睡不醒”的没有责任心的人，我曾经多次花力气想叫醒他，希望他能够有点责任心，但是事实证明 你永远无法叫醒一个装睡的人。

Passionate 激情

这个是我们今年才加进来的，公司项目的稳定，不少人长期做一个项目，时间长了就有点“皮”了，现有项目觉得“轻车熟路”，因此没有学习和进步的激情，其实这个世界变化很快，尤其是科技技术行业，变化和创新日新月异，新技术层出不穷，而且这些新的东西真的是进步，极大提高生产力或者服务水平，拿软件行业来说，移动的飞速发展，让原来的传统软件向移动端转移，Cloud技术的发展和成熟，极大的提高了我们的运维，大大加快的发布和升级的周期，大大节省了成本。

如果我们不保持学习的激情，我们很难提供高质和高效的服务，而我们发现那些有激情的人能够保持对新东西的关注，而且对新东西学习，新方法或者新事物投入一定的时间，这个为公司未来的业务发展做出贡献。

另外，激情可以让公司充满活力，热烈的讨论，对生活的激情比如喜欢跑步，对技术的热情，经常学习或者分享能够让公司生气勃勃，这样的公司，让任何进入公司的人不会感觉死气沉沉，感觉这个公司充满活力，充满阳光。

总结

企业文化是一种能够让你实现目标，让你公司能够提供更好的产品或者服务的东西

企业文化很重要

我们的企业文化是“高质，高效，责任，激情” (Quality, Productivity, Responsibility, Passionate)

我们整个公司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个人，走几个人不是任何问题，但是小公司，一个萝卜一个坑，走一个人你可能都头疼，类似的事情很多。

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

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

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

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

前言

在工作中或者在面试中，我经常碰到的开发人员就是对单元测试不重视，这一类基本上都表现出了一种“无知的自信”，总觉得自己写的代码质量很高，直到一次次虫子(Bug)把自己咬的头破血流时，才发现原来自己的代码已经到了剪不断理还乱的状态，而每一次修改一个bug，都需要走一遍“墨镜迷宫” （看上图)。还有很多人知道单元测试或者写出了单元测试，但是就是写了一个方法，上面标注了一个[Test]属性而已，甚至很多的人单元测试上面标注的是[IgnoreTest], 每次看见这些，我都深深的感到推行单元测试之路是艰难的，是遥远的，但是我依然坚信是是渴望也可及的，只要有着深深的信念，坚强的意志，无谓的勇气，一头扎进去泥巴堆里，假以时日，当大雨来临，必将带走泥巴，从此你拔剑扬眉，哦，你不用拔剑了，因为你就是剑。。。

为了让更多人能够拔剑扬眉，也为了我们公司刚入职的新人做一些培训，我精心准备了单元测试的一些知识，在此为你奉上，我尽量用简短的语句来描述，如果你不清楚我说的某一些点，那么欢迎你发邮件给我 wangdeshui@outlook.com，我可以针对集中的点发篇文章，如果你想知道我说的所有点怎么实践，那就联系我，试试加入到我们公司来。

• 前言
• 什么是单元测试
• 为什么要使用单元测试
• 单元测试难以推动的原因
  • 太花时间
  • 测试不是我的工作
  • 系统可测试性差
• 单元测试最佳实践
  • 实践一: 三到五步
  • 实践二： 运行快速
  • 实践三：一致性
  • 实践四：原子性
  • 实践五：单一职责
  • 实践六：独立无耦合
  • 实践七：隔离外部调用
  • 实践八： 自描述
  • 实践九： 单元测试逻辑
  • 实践十： 断言
  • 实践十一：产品代码
• 最后，单元测试常用技术及工具

什么是单元测试

单元测试是开发者编写的一小段代码，用于检验被测代码中的一个很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

执行单元测试，是为了证明某段代码的行为确实和开发者所期望的一致。因此，我们所要测试的是规模很小的、非常独立的功能片段。通过对所有单独部分的行为建立起信心。然后，才能开始测试整个系统。

为什么要使用单元测试

• 单元测试使工作完成的更轻松
• 单元测试使你的设计更好
• 大大减少花在调试上的时间
• 能帮助你更好的理解代码

没有单元测试

• 任何代码都是在假定其他代码是正确无误的情况下编写的。
• 修改一处代码时无法得知会对其他代码产生怎样的影响。
• 任何一处改动都需要进行功能级别的整体调试。

单元测试难以推动的原因

太花时间

很多人认为单元测试很花时间，但是想想我们在下面几点话的时间，我经常看到为了测试一个简单的API方法，我们很多人必须让前端跑起来，甚至自己写一个客户端才能调用

• 调试上花的时间
• 对自认为正确的代码，花了多少时间确认代码是正确的。
• 定位Bug所耗的时间

测试不是我的工作

很多人认为测试不是自己的工作，但是想一想每次测试提出一个bug所花的时间，以及你改bug所化的时间，所以下面2点是很重要

• 内在质量的重要性
• 测试应该是辅助，好的软件是开发设计出来的，不是测试出来的

系统可测试性差

• 系统耦合度很高，我们需要提高我们的团队的设计能力。

单元测试最佳实践

实践一: 三到五步

• SetUp
• 输入
• 调用
• 输出
• TearDown

实践二： 运行快速

###为什么？
单元测试运行很频繁，是辅助开发的，在开发过程中运行，如果慢影响很大

多快较好？

• 单个测试小于200ms
• 单个测试套件小于10s
• 整个测试小于10分钟

实践三：一致性

任何时候同样的输入需要同样的结果

    Date date=new Date()
    Random.next()

这样的代码都需要Mock掉，不然时间每次都不同，结果就会不一样。

实践四：原子性

** 所有的测试只有两种结果：成功和失败**
不能部分测试通过

实践五：单一职责

一个测试只验证一个行为

** 测试行为，不要测试方法 **

• 一个方法，多个行为    —–>  多个测试
• 一个行为，多个方法   —–   一个测试
  这里的一个行为，多个方法一般指这个方法调用private, protected, getters, setters
• 多个Assert只有在测试同一个行为时可以接受

实践六：独立无耦合

单元测试之间无相互调用

• 单元测试执行顺序无关
• 不同的顺序无影响

单元测试之间不能共享状态

比如一个测试里设置了一个属性值，然后在另外一个测试里用，如果必须共享可以放到Setup里

实践七：隔离外部调用

• 单元测试需要快速运行，且每次结果一致，所以需要隔离一切对外部的调用。
• 不使用具体的其它真实类，就是不要new
• 不读数据库
• 不读网络
• 不读外部文件
• 适当时候可以构造一个相同的内部文件来Mock
• 不依赖本地时间
• 不依赖环境变量

实践八： 自描述

• 单元测试是开发级文档
• 单元测试是方法的描述

实践九： 单元测试逻辑

• 单元测试必须容易读和理解的
• 变量名，方法名，类名
• 无条件语句,无Switch
  办法：分解if到多个测试，所有的输入都是已知的，所有的结果都是一定的（Mock）
• 无循环语句
• 无异常捕捉
  ** 测试预知的异常，用ExpectedException方法 **

实践十： 断言

• 断言信息最好包含Business Information

• 断言信息包含出错的具体信息如果失败

• 适当时候可以封装自己的Assert
  比如：

  Assert.IsProgrammer(Jack)
  Return Jack. Cancooking() && Jack.CanCoding()

实践十一：产品代码

• 产品代码无测试逻辑

不能有：

    If(global.IsTest){…}

• 测试代码和产品代码要分离
• 不要在产品代码里有任何只供测试用的代码
• 使用依赖注入

最后，单元测试常用技术及工具

下面是.NET程序常用的单元测试需要的技术和工具，其它语言请自信比对。

• 面向接口编程
• 依赖注入(Castle, Unity, Ninject)
• Moq
• 测试工具(xUnit) 
• .Net Nunit
• 代码覆盖率测试工具Ncover
• 自动运行测试辅助工具NCrunch

开篇

这样的场景你是不是很熟悉？客户让你做一个软件，你需要他给你写出需求，当它给你写出需求后，在你认为时间非常紧的情况下，你辛辛苦苦，加班加点，费劲九牛二虎之力，最后赶在最后时刻给客户提交了，你满怀希望等待客户给你的表扬，你万分坚信领导对你的辛苦会给予高度认可和鼓励，你觉得很快就要带一朵“小红花”时，最后你得到的是绵绵无绝期的等待，甚至是客户的不满意，这是为什么呢？这种情况在我的团队里也会出现，有时候我让改一个东西，经常得到的回复就是:”客户就是这么要求的，而且描述很清晰，不能改！”, 最后如果不改的结果就是客户不满意。

为什么我们听客户的，客户却不满意？

客户如果说要一个 “杯子”， 我们是怎么做的？

我们的很多程序员一般是这么工作的，客户说我需要一个 “杯子”，然后程序员就在网上或者生活中搜索杯子，于是程序员就得到了很多杯子，现在各种各样的茶杯，各种各样的酒杯等等，这时候程序员就按自己的喜好选中了一个杯子，聪明一点的程序员可能会衡量一下制造不同杯子的时间成本，选定以后就开始进行模仿，最后你没日没夜，加班加点终于把杯子做出来了，客户会说：怎么会做一个这样的杯子要这么久时间？ 因为市场上已经有人做出来过，所以客户就会觉得照抄应该很快，其次客户会觉得这个杯子不是他想要的，如果是抄一个别人一样的杯子，那为什么不直接买一个呢？

客户如果说要一个”杯子”， 他要的不是一个”杯子”

实际上，客户说要一个“杯子”， 他要的不是一个杯子，他要的不是用来装水的，这个就像我们对一个女孩说：“我想和你一起看明早的太阳”，我们都知道他要的不是白天而是夜晚，不是吗？

所以，当客户说要一个“杯子”时，他要的不是一个“杯子”，因为“杯子”只是一个名词，显然客户要的不是一个名词，而是一个”动词”, 所以我们要想到的是这个杯子用来干什么？我们脑子里要想是不是几个老人在喝茶？一对情侣在喝咖啡？一个婴儿要用来喝奶？还是单身狗要用这个“杯子”？

可见，当客户要一个“杯子”时，他要的是一种场景，一个动态的场景，一个有人使用的场景，这个场景就是用户体验，你想想老人喝茶的杯子和单身狗要用的杯子能一样吗？

要自信的对客户说 “NO”

这个还是那句话，就是“为什么你都听客户的, 客户却不满意？” 我举个简单的例子，你生病了，你到医院去看病，你告诉医生怎么给你治疗，有的人甚至是在网上查了查资料，或者曾经有别的医生给这个病开个药方，然后你给医生说你要吃什么药，还有的人拒绝血常规检查，最后他的病要么没好，要么拖的时间很长，最后你还对医生非常不满意。你想想你的客户给你提需求的时候，是不是有的时候就和这个病人一样？

为什么医生会对你说 “NO” ，甚至不管你了呢？ 因为医生比你更知道怎么治疗，如果按你说的肯定是不行，那么回到程序开发，软件设计上，做一个程序员或者高级软件开发人员，为什么不能给客户说 “NO” 呢？因为我们比客户更知道怎么开发，我们比客户对软件更专业不是吗？

协助客户改进需求

当然，我们不能简单粗暴的对客户说 “NO”, 由于我们对软件更了解或者说更专业，我们就可以给客户一些更好的方案，由于客户对技术的不了解，经常会提出一些既耗时又非常“愚蠢”的方案，那我们需要利用我们的专业知识来告诉客户什么是更好更省时的方案，有的时候需求稍加改动会让客户体验更好，而且开发更快，我相信这样的场景在不同的项目里有很多。

最后

所以，当我们拿到客户需求的时候，我们不是卷起袖子就开始编码，而是第一步想想客户要的到底是什么？他说的真的是他想要的吗？ 他想要的说了吗？我们需要知道客户的项目的远景是什么？我们需要站在整体的角度，站在更 High level的角度来看需求。

举个例子，我曾经做过的一个项目，客户说要做房间预订，还要分淡旺季，还要有Offer, 还有内部员工不同价，团队当时想的很复杂，想到了想艺龙那样的，但是当我去了客户那边了解后，他们只有5个公寓而已，而且只是给集团员工别的地方来的提供住宿从而计入别的分公司成本而已，我觉得hard code出来一个版本都够用好几年，而且这样的话，原来的估计至少得半年以上吧，当你清楚客户最终需要啥的时候最多两个礼拜就弄完了。

总之，听客户没错，但是无脑的听客户的，完全听客户的就有问题了，就像如果你完全听你媳妇的，然后她错了后，她会说：“我让你那样做，你就那样做吗？你自己脑子是干什么的!”

为什么软件项目需要 Team Leader

多年以前，当我接触敏捷时，我接触到一个概念，叫做 “自组织的团队”，当时我看了一些估计从没做过敏捷的一些凭空捏造的很多文章（事实上，这类人现在越来越多），那些文章多见名猜意，提出了自组织的团队就是团队自己组织，不需要Leader, 一开始我也是这么认为，甚至想尽一切办法向这个方向靠拢，而且成功的提交了一些项目，甚至于连我自己都相信这是自组织的结果，但是后来一想，我在团队里的所想所做不正是一个Team Leader 需要做的吗？

自组织团队的形成需要一个过程，而且目标只能无限靠近，难以完全达到

就拿一个足球团队来说，就拿 “宇宙队” 巴萨来说，也是需要一个教练，同时也需要组建团队，买卖球员，队伍文化建设，战术打法等等，那么软件项目团队来说，自组织团队同样需要组建，文化建设，代码规范，Team Rule, 团队磨合，质量意识，技术交流，客户需求范围把控，会议组织，冲突解决，开发流程等等。

自我保护，害怕承担责任是大部分人的天性

在没有一个好的敏捷文化的公司，大部分的程序员都不愿意做更多的事情，话句话说，更愿意做明确分配的事情，因为做的事情越少，自然问题越少，那么责任就越少，这是一种本能的自我保护，这也是大部分人难以成长的重要原因，所以必须要一个人来承担更多的责任，当然方法可以是把要做的事情分的更细，更明确，最终每个人做的事情更细，更多，更明确，那么每一个人要承担的责任就更多了。

###被领导惯了

很多中国的孩子，尤其是很多现在正处于黄金时代的程序员，独立意识确实要差一些，从小被父母装在一个大 “笼子”里，比如去哪里都是大人在前面牵着后面的小孩，老师严格教条的作业却只有一个标准答案，甚至在我看了写错一个字要重写一百遍一样猪一样的惩罚还至今流传着，忘了教育的本质是要把字学会而不是把字写一百遍，等等类似的东西，使我们不敢去思考，习惯被别人领导。

比如，我爱爬山，和我一起爬山的大部分人去一个没有去过的地方，都喜欢走在我的背后，因为他对未知有恐惧！习惯别人牵着走。

这个问题，我以前以为对高智商的程序员来说应该很少，后来经过10几年，我发现这和其它行业的人一样多。

所以，如果没有Leader, 大家不知道怎么干！ 没有Leader组织，大家不知道干什么？

软件团队Team Leader的诞生

由于上面的原因，我们需要一个Team Leader, 但是由于太多人习惯被领导，害怕承担更多责任，我们就急需要一个Team Leader, 但是一个好的Team Leader是非常难找的，因为一个好的Team Leader要做很多事情才能把一个Team变成好的Team.

不懂技术的Team Leader在软件项目里成功的概率很小

由于软件项目来说，一个不懂技术的人可以当一个Team Leader, 但是要想当一个好的Team Leader是难于登天，因为如果你不懂技术，那问题太多了，你怎么知道大家的评估时间靠谱？你如何向客户展示你的方案，你的优势？由于文人相亲，有技术的人一般会鄙视不懂技术的人瞎指挥，从技术人员喜欢鄙视技术人员这点就不难想象的出来。

请不要举马云的例子，你啥时间看到马云去直接领导一个技术团队了.

不懂管理的Team Leader 也难以成为优秀的Team Leader

因为Team Leader难找，所以在中国又一个常见的事情不断上演，那就是 “学而优则仕”，同样这个在我的团队里也大量存在，这是没有办法的事情, 因为如果他不懂管理，他还至少是一个程序员，相比不懂技术的管理人来说，如果他管理做不好，那对公司就没有什么价值了。

学而优则仕

在软件团队里，我们都知道一个Leader懂技术是多么的重要，那么我们唯一的选择就是沿用了中国多年的传统，那就是“学而优则仕”，比如上小学时，老师不都是让学霸的当班长吗？ 所以很多技术还不错的人，都在团队需要的时候 “被挺身而出”，“被临危受命” 成为了Team Leader，但是这样出来的Team Leader 由于由于没有太多的管理项目的知识，没有团队管理的经验，往往也有不少问题，请继续往下看！

Team Leader 你不再只是编码，请炖一锅石头汤

由于“学而优则仕”，导致大部分软件团队Team Leader更多的专注于技术，就自然把更多的时间花在编码上，因为编码是立即可以看到的产出，而忽略了一个Team Leader要做的更重要的事情，比如团队文化建设，项目过程，质量保证，进度跟踪等等的事情。很多时候，我们缺少这些依然把项目做完了，但是实在很多加班，甚至是Team Leader卷起袖子一个定俩的情况下干完了，这样大部分情况就是客户感觉还OK, 但是难以达到满意。这还是自我保护的意识，害怕客户看不到自己实际的编码产出，实际上忽略了团队整体的目标的重要性。

关于技术团队Team Leader应该做什么，我本文就不想讲太多，有时间我会再写几篇关于Team Leader的文章，但是本文我强调的是技术团队的Team Leader不能只是编码，他要意识团队管理的重要性，哪怕这个“重要性”在别人看来什么都没有，不用害怕，因为我们只需要最终的项目成功来证明。

三言两语难以让大家明白Team Leader应该做什么，我就用一则寓言故事来告诉Team Leader 请炖一锅石头汤。

很多年前，有三个士兵，他们从战场回来既饥饿又疲倦，这时他们来到了一个小村庄。然而由于粮食遭遇欠收和连年的战争，村民们迅速的将它们的一小点粮食藏了起来，并在村子的广场中接待了士兵们，搓着双手，哀叹着他们是多么缺少食物。

士兵们平静地与村民们交谈着，第一个士兵对村庄的长老说道：“既然你们的土地收成不好，不能分给我们点吃的，那么我们将会与你们分享我们所有的：如何用石头做一道好汤的秘密。”

自然啦，村民们都十分好奇，很快他们就升起了火，架起了城里最大的一口锅，士兵们将三颗光滑的石子丢到了锅里。“这将是一锅好汤”第二个士兵说；“不过如果有一撮盐和一些欧芹那就更棒啦！”一个村民跳了起来，喊道“多幸运啊！我刚刚想起来家里还剩下些呢！”于是她跑回家，带着满满一围裙的欧芹和一根萝卜回来了。随着锅里的水渐渐煮沸，村民们的记忆力也变的越来越好，很快地，大麦，胡萝卜，牛肉还有奶油，统统被投入了这个大罐子里。

他们吃啊跳啊唱啊~直到深夜，美妙的宴会和新结交的朋友让每个人都感到焕然一新。当早上三个士兵醒来时，他们发现所有村民正站在他们面前。在他们脚边放着有一包这个村子最好的面包和奶酪。“你们把最好的礼物送给了我们：如何从石头里做汤的秘密”，一位长老说道，“这一点我们永远也不会忘记。”第三个士兵转身冲大伙说到：“这并没有什么秘密，但是有一件事是确定的：只有一起分享，我们才可能举办一次宴会。”说完，他们又踏上了路，慢慢走去了。

上面这个故事，我希望Team Leader能够明白虽然士兵并没有什么，但是他却让大家把好东西都拿出来一起做了一锅好烫，村民就是你的团队成员，一开始都把好东西藏起来不是吗？你需要做的就是拿出你的“秘密配方” 和大家一起炖上一个鲜美的石头汤吧！

上一篇 敏捷实践系列(四)：代码管理流程 给大家详细的讲解了一下Git flow, 本周我们就把一个客户的所有项目实施了Git flow, 如果说你详细看了那篇文章，那么你就能了解为何要进行Git flow 以及如何对一个新项目按Git flow的流程操作， 但是当我们整理已有的项目时，我们发现了以下几个问题需要一些方法处理。

错乱的分支名如何解决

问题

我们遇到的一个项目，一开始生产环境用的是master分支，突然客户提出他们有一个客户有特殊需求，让打一个分支出来，团队成员就打出了一个master-quickfix 分支，但是后来这个分支上功能越来越多，慢慢的团队成员就把这个分支当做master分支用了，此时develop和 master-quickfix 分支也早已分道扬镳。然后所有的客户又需要相同的功能，这样如果想合并会master将是非常难的，因为冲突太大。 经过沟通和核实，我们发现现在的master-quickfix其实承担了master的角色，所以我们要让master-quickfix当做master.

方案

方案一 用master-quickfix 代码覆盖master

git checkout master-quickfix

merge master - ignoring master's changes
git merge -s ours master

git checkout master

# finally merge all our stuff to new master - actually it replaces the master with master-quickfix
git merge master-quickfix

# now master-quickfix can be deleted
git push origin: master-quickfix

然后我们就看到master上代码已经和原来master-quickfix上一样了，但是这个方法有一个问题就是 master-quickfix上的提交日志没有了，如果你不在乎提交日志那么就可以使用这个方法。

方案二 改分支名

git branch -m master new_master         # Rename branch locally    
git push origin :master                 # Delete the old branch    
git push --set-upstream origin new_master   # Push the new branch, set local branch to track the new remote


git branch -m master-quickfix master         # Rename branch locally    
git push origin : master-quickfix                 # Delete the old branch    
git push --set-upstream origin master   # Push the new branch, set local branch to track the new remote

使用这个方法，就可以看到master-quickfix上的分支的提交记录，过程当中会删除旧的远程master分支，以及master-quickfix分支
，所以需要你确认要删除的分支有备份及没有问题，危险系数5星， 我在做这个操作的时候向别人确认了多次。我操作的时候手都抖呀！

不同的客户不同的分支问题

问题

原来有一个项目，项目有不同的客户，导致不同的客户的代码在不同的分支上，这导致代码难以管理，功能散乱在各个分支，时间久了，开发人员都不知道每个分支上有哪些功能。

解决方案

针对这个问题，我们的想法是不同客户使用同一套代码库，还是使用Git flow, 因为不同的客户需要不同的功能，这其实就是一个SaaS系统，所以我们把系统改为SaaS系统，代码用同一套，不同的客户使用什么功能使用SaaS管理端来配置。 这样做有很多好处，比如：给A客户做的功能很容易再卖给B客户，同时很容易给不同的客户做个性化的配置，例如界面样式等等。 当然，这个需要你的强大的沟通能力，因为改为SaaS需要时间哪，时间就是金钱嘛！

如果你的客户不同意，或者你需要项目遵守一些”特殊规则或者某个国家特殊政策”，导致整套系统非常不同, 那么我的建议是你重新建一个代码库给这个特殊客户，而不要用分支来区分。

总结

由于我们团队的敏捷程度还可以，所以推行Git flow的流程除了以上几个技术上的问题以外，其它的都很顺利。 如果你想实行Git flow，那么再次提醒务必完全理解这个流程再开始。请阅读：敏捷实践系列(四)：代码管理流程

本来没有这么快到流程以及技术部分，但是因为公司需要，所以就临时写了这一部分。

我们已经从SVN 切换到Git很多年了，现在几乎所有的项目都在使用Github管理。对与那些还在坚持使用SVN的，我实在想不出原因，权且称作守旧派吧。

Git的优点

Git的优点很多，但是这里只列出我认为非常突出的几点。

1. 由于是分布式，所有本地库包含了远程库的所有内容。
2. 优秀的分支模型，打分支以及合并分支，机器方便。
3. 快速，在这个时间就是金钱的时代，Git由于代码都在本地，打分支和合并分支机器快速，使用个SVN的能深刻体会到这种优势。

感兴趣的，可以去看一下Git本身的设计，内在的架构体现了很多的优势，不愧是出资天才程序员Linus (Linux之父) 之手

版本管理的挑战

虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

1. 如何开始一个Feature的开发，而不影响别的Feature？
2. 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
3. 哪些分支已经合并回了主干？
4. 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
5. 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?

大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。

Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范

Vincent Driessen 同学为了解决这个问题提出了 A Successful Git Branching Model

下面是Git Flow的流程图

上面的图你理解不了？ 没关系，这不是你的错，我觉得这张图本身有点问题，这张图应该左转90度，大家应该就很用以理解了。

Git Flow常用的分支

• Production 分支

也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

• Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

• Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

• Release分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

• Hotfix分支

当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

Git Flow如何工作

初始分支

所有在Master分支上的Commit应该Tag

Feature 分支

分支名 feature/*

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留

Release分支

分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

维护分支 Hotfix

分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

Git Flow代码示例

a. 创建develop分支

git branch develop
git push -u origin develop

b. 开始新Feature开发

git checkout -b some-feature develop

# Optionally, push branch to origin:
git push -u origin some-feature



# 做一些改动


git status
git add some-file
git commit

c. 完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature

d. 开始Relase

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

e. 完成Release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0




git tag -a v0.1.0 master
git push --tags

f. 开始Hotfix

git checkout -b hotfix-0.1.1 master

g. 完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push




git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

Git flow工具

实际上，当你理解了上面的流程后，你完全不用使用工具，但是实际上我们大部分人很多命令就是记不住呀，流程就是记不住呀，肿么办呢？

总有聪明的人创造好的工具给大家用, 那就是Git flow script.

安装

• OS X

brew install git-flow

• Linux

apt-get install git-flow

• Windows

wget -q -O - –no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

使用

• 初始化: git flow init

• 开始新Feature: git flow feature start MYFEATURE

• Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE

• 获取Publish的Feature: git flow feature pull origin MYFEATURE

• 完成一个Feature: git flow feature finish MYFEATURE

• 开始一个Release: git flow release start RELEASE [BASE]

• Publish一个Release: git flow release publish RELEASE

• 发布Release: git flow release finish RELEASE
  别忘了git push –tags

• 开始一个Hotfix: git flow hotfix start VERSION [BASENAME]

• 发布一个Hotfix: git flow hotfix finish VERSION

Git Flow GUI

上面讲了这么多，我知道还有人记不住，那么又有人做出了GUI 工具，你只需要点击下一步就行，工具帮你干这些事！！！

SourceTree

当你用Git-flow初始化后，基本上你只需要点击git flow菜单选择start feature, release或者hotfix, 做完后再次选择git flow菜单，点击Done Action. 我勒个去，我实在想不到还有比这更简单的了。

目前SourceTree支持Mac, Windows, Linux.

这么好的工具请问多少钱呢？ 免费!!!!

Git flow for visual studio

广大VS的福音
GitFlow for Visual Studio

大话西游里有一段因为没有沟通的经典, 结局如何大家都知道。

唐僧：你想要啊？悟空，你要是想要的话你就说话嘛，你不说我怎么知道你想要呢，虽然你很有诚意地看着我，可是你还是要跟我说你想要的。你真的想要吗？那你就拿去吧！你不是真的想要吧？难道你真的想要吗？……

悟空：…

敏捷项目沟通尤其重要

敏捷开发多采用短迭代，要求尽快交付可以工作的软件，所以项目的需求文档就很难像原来的瀑布开发模式一样面面俱到。这就要求我们多进行沟通以确保双方的理解一致。根据以往很多项目的经验来看，失败的项目很多都是缺乏沟通，成功的项目必然是沟通做的比较好的。

敏捷经常出现的沟通问题

你以为你以为的就是你以为的

有时候，我们很多人做项目，拿到项目的需求以后，自己简单看了看，然后就开始做了，等到我们做完一个迭代以后，拿给客户看时，完全不是客户要的东西，因为我们对项目的需求的理解比较片面，就是自以为是。

不敢沟通

还有的人，尤其是新入团队的人，客户写的东西或者说的东西，自己没有完全理解，然后又不问，他总觉客户已经说过了，已经写过了，然后再去问客户，是不是不妥？如果按自己的理解或者猜测万一对了呢？， 然后就碰运气。 事实上我们的猜测都常常都是错误的，尤其是在我们对项目没有更全局的了解的情况下。

拖延

还有一类沟通的问题，就是我们自己也发现了问题，需求上的，或者客户的流程上的，但是我们总是心想等到明天沟通，明天再等明天，其实是希望这个问题自动消失，但最终的结果往往越来越严重。

不敢沟通客户的问题

在我的一些项目里，比如我们团队觉得客户那边需要提高，比如需求都很碎片化，客户的UI改来改去，希望客户能提供一个比较接近Final Design的设计，但是总觉得说出客户的问题不好意思，或者对客户的不尊重，实际上我们提出问题和自己的想法才是对客户最大的尊重。

沟通方法单一

我们很多人习惯了一种沟通方式，不管什么问题都是同一种，所有的问题都写邮件或者所有的问题都用语音，这也是很没沟通效率的方式。

敏捷项目如何沟通

平等沟通的意识

首先，我们要理解，敏捷项目里的沟通，不管是与客户还是与团队成员，大家都是平等的，沟通项目相关的问题都是平等的，尤其是把客户也当做自己团队的一部分，客户也是希望项目做好的那一个人, 只有这样，我们才能畅所欲言，无所顾忌，更不会有想法掖着藏着。

多种沟通方式结合

小平说： “白猫黑猫，抓住老鼠就是好猫”，沟通也一样，下面是常见的几种沟通方式。

• 面对面
• 视频
• 语音
• IM 文字沟通
• 邮件沟通

这几种沟通方式的效率一般情况下由高到低，所以我们尽量选择沟通效率比较高的方式， 因为当我们能看见对方的时候，我们可以根据对方的表情就可以看出来对方是否真的理解了自己所说的。

但是实际当中我们需要多种沟通方式的有效结合，比如离岸团队面对面的机会比较少，我们可以视频和语音，但是视频语音由于他强调及时性，需要大家的时间都合适，但是视频语音也有缺点，很难有文字记录，虽然可以录音，但是视频和语音很难搜索内容，也较难在组内传播。 那么文字沟通有时候就体现出了很多的优势，有历史记录，多人可以参与等。

但是IM得文字沟通也有一些不足，比如很难通过图形沟通，对图形标注等，除此之外，很多时候很难及时给出答案等，那么邮件的优势就是不需要客户立即回复，也给客户更多的时间思考，同时格式化的文档更容易把一件事情描述清楚。

所以，我们在沟通的时候，要结合情况选择最适合，最快速能够把问题沟通清楚的方式。

一图胜千言

软件项目很多时候，图形化的沟通非常重要，我们很多项目的设计，以及架构，开发人员难以达到统一的认识，就是缺乏图形，设计图或者架构图。我们都知道，人对图形的记忆力要好于文字。

系统之间的交互，软件如何部署，项目的架构封层等，这些用图形来表示往往一页纸就可以，而且大家看后，很容易理解，很容易记住。因为只有别人对你的想法理解了，别人才能够发现你的问题，才能给出建议。我觉得软件项目，非常重要的两张图，一个是 Architecture Diagram, 一个是Use Case Diagram, 这两张图可以大大节省项目的开发沟通时间。

原型或者草图

敏捷项目流行边做边改，但是我对这个是不太认可的，客户付钱是让我们把事情做对而不是把事情改对。那么怎么样能够在做之前尽量就明白要做什么？那就是先做一个原型，我说的原型是不需要花太多时间的，如果花太多时间就得不偿失了，比如UI我们可以先在开发之前先画出Wireframe, 如果需要交互，我们可以先做交互的Prototype. 现在有很多工具比如Invision都可以建立静态图形之间的交互，这样可以大大减少返工的时间。

提出问题时尽量给出方案

很多人只问问题，所以导致客户回复的很慢，因为客户需要思考，但是有的时候客户思考后给我们的方案又不适合，所以一来二去就浪费了很多时间，那么好的方法是就是，我们给客户提的问题，想想是不是我们没有方案呢？ 还是我们有多个方案不能确定是哪一个方案呢？很多时候我们其实有方案的。

我们都知道我们上学的时候都喜欢做判断题，其次是选择题，其次是填空，最不想做的就是问答题，想想我们要想得到客户的快速反馈，我们是不是想想应该给客户出比较容易做的题呢？

其实，凡是我们提的方案被客户采纳的，我们做起来也更顺手，也就更有效率。

总结

最后，沟通最主要的两点：

1. 如果你想要，就一定要说，不说，别人怎么知道你想要呢？ （敢于沟通）
2. 要想尽一切办法， 让客户觉得：“你以为你以为的就是你以为的” （确认自己的想法)

上篇文章我提到了敏捷的心法，但是我想除了心法之外，更重要的是敏捷的意识。

为什么意识更重要？

意识：辩证唯物主义的解释是，意识是物质运动变化的场所，意识是人脑对大脑内外表象的觉察，即它可以辨识自己脑区中的表象是来自于外部感官的还是来自于想像或回忆的。

我们这里说的意识，一是你能主管的去想一件事情，另一个就是你对一件事情的发自内心的认可程度。

敏捷，光有心法是没有用的，有没有要敏捷的意识，敏捷的意愿。有没有主观的愿望去做，我们经常说的话：没有成不成，就是看你想不想做。

欲推敏捷，首先要培养敏捷的意识

我举两个例子：

一个是最近推行**”无车日”**, 无车日本来是想让大家绿色出行，减少二氧化碳的排放，但是结果是什么，结果是堵的一塌糊涂。 为什么？据说原因如下：有车的人想，本来平时不开车，但是今天无车日，路上车少，那我就开车肯定不赌。这样造成的结果是，坐公交的人觉得无车日大家都挤公交，开车的人觉得今天无车日开车应该不赌，所以开车。造成的结果是，公交也堵，开车也堵。这就是政府和民众对环保的意识不够，如果政府意识够了，那么政府是不是多提供公共交通的数量，以及提高公共交通的便捷以及服务？如果民众意识够了，那么我是不是可以走着去上班？我是不是可以骑自行车？我是不是可以跑步？若能如此，无车日才有了真正的意义。

另一个例子，就是我看到的道路旁边的自行车道栅栏，政府甚至花了不少钱来弄这个，但是效果呢? 我看到的情况是很多地方没人用，甚至造成地段的拥堵。为什么？ 有些地方自行车道里面有面包车在里面堵着，还有的地方有人逆向骑过来，试想，如果你骑自行车有这样的经历，你还会骑自行车道吗？骑到中间你飞出来？ 如果这个自行车道没人用，那么另一个问题又来，本来3车道，现在一个车道停车，一个车道过车，原来没有自行车道时，如果前面的车临时停车，其他的人还能利用空的地方错开车，现在就能硬等，这样岂不是更堵？结果就是，本来就赌的路，硬硬的把路切一块空着浪费了！

从上面的两个例子，我们都能感觉到，都是为了要把事情做好，但是，就是意识层面没做好工作，才导致截然相反的结果。（以上只是我自己片面的感觉，真正的事实数据请看官方数据）。

如何培养敏捷的意识？

首先，我觉得培养敏捷的意识之前，首先要知道是什么事敏捷的意识，我觉得敏捷的意识就是：

• 高质、高效的做事情
• 持续的学习
• 团队精神，Good team player.
• 责任心
• 关心客户的价值
• 解决问题
• 努力改变现状，不抱怨现状。

其次，那么如何培养敏捷的意识呢？我个人觉得两种方式：

• 招聘具有敏捷意识的人。 其实我列的敏捷的意识和大家想象的SCRUM那些无关的。

• 培养已有的人具有上面提到的敏捷的意识，方法比如说是宣传、强调、加薪、惩罚等等各种方法，关键是推行的人自己有没有这个意识来推行敏捷。

最后，最重要的是要让大家知道为什么要敏捷，敏捷解决的问题是什么？敏捷对工程师自己的好处是什么？因为只有人敏捷了，项目才能敏捷，所有的项目都敏捷了，公司才能说是一个敏捷的公司。若如此，强行推行一个SCRUM框架，持续交付等等，就必然走向文章开头的那两个例子，结果只能是适得其反。

愿君更饮一杯酒，敏捷路上无故人。

且行、且思、切记！

(注：佛光，图片拍摄于2015-6-6 太白山)

开篇：

悟空：师傅，为什么你写东西，喜欢写系列呢？
师傅：因为很多东西需要长期的实践呀。
悟空：怎么又开始说敏捷了
师傅：就像一本好书，常读常新，人生不同阶段过的都是不同的人生呀。
悟空：师傅，为什么你原来用上、中、下呢？
师傅：因为原来只写了个上中，别人一直问下，现在如果只写一二，别人要问，我就说写完了呀!
悟空：。。。。。。

敏捷是什么？

其实别人问敏捷是什么？几年前我觉得很好回答，但是现在我觉得很难回答，就像你问天龙八部里的扫地僧：“功夫是什么？” 我觉得他可能真的会被问住的。你再问：功夫是“降龙十八掌”？， 是“九阴真经”？，是“一阳指”？他可能说不是，但是待会儿他可能会说：“也算”。

所以很多人问我什么是敏捷，我其实很难定义，用了SCRUM算吗？用了Kanban算吗？用了Target Process,Trello算吗？我也只能说：“也算，也不算”。

还有人觉得用了持续集成，用了测试驱动开发，用了结对这个应该算是敏捷了吧？ 我只能说如果你用了“轩辕剑”，“倚天剑”，“屠龙刀”，”莫问剑”,”游龙剑”，你就是高手吗？君不见，扫地僧一把扫帚就制服两大高手？ 由此我们可以看到功夫要好，更重要的是内功，是心法。

敏捷的心法是什么？

这个心法其实就是武林高手总结的敏捷宣言

• 个体和交互 胜过 过程和工具

• 可以工作的软件 胜过 面面俱到的文档

• 客户合作 胜过 合同谈判

• 响应变化 胜过 遵循计划

这个其实就是：“九阴真经”，“易筋经”，“六脉神剑”，“葵花宝典”（正宗的是不需要自宫的）

知道了心法，其实每个人的修炼方法都不一样，但是前人为了后人节省时间，给出了自己修炼的一些经验和原则，那就是十二条原则。

1. 最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户

2. 欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争优势

3. 频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度

4. 在整个项目中业务人员和开发人员必须每天在一起工作

5. 以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作

6. 在开发团队内外传递信息最有效率和效果的方法是面对面的交流

7. 可用的软件是进展的主要度量指标

8. 敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调

9. 持续关注技术上的精益求精和良好的设计以增强敏捷性

10. 简化——使必要的工作最小化的艺术——是关键

11. 最好的架构、需求和设计产生于自我组织的团队

12. 团队定期地对运作如何更加有效进行反思，并相应地调整、校正自己的行为

注意：上面我说的是这是前人根据自己修炼的过程总结出来的经验，那么也就是说只是经验，100%可以拿来自己用？那就不一定。

比如有一条原则说：情人节一定要给老婆买花？那么问题来了，没老婆怎么办？ 当然是先找个老婆。总不能买花送给别人老婆吧。

比如，上面有一条：“在整个项目中业务人员和开发人员必须每天在一起工作”， 很多时候很难，那么怎么办？第一创造条件能让业务和开发人员每天在一起工作，这个一起不一定是坐在一起，可以每天及时回复你的邮件，也可以你自己就当业务人员，那么你自己不就是每天和自己在一起？

怎么样才算敏捷了？

尽管公司实行敏捷也很多年了，这个问题，我想说我不知道怎么回答，因为我们也还在努力变得更敏捷，但是我理想中的敏捷，应该是这样子的：“草在发它的牙，风在摇它的叶，小鸟在唱他的歌，而敏捷团队的Leader静静的座在那里一句话也不用说”，此时敏捷就像空气一样充满了整个房间，知道有一天PM高了，这个时候大家说：“哎呦，最近是不是不敏捷了?”

怎么开始敏捷呢？

重要的事情说三遍:

• 读书，实践!
• 读书，实践!
• 读书，实践!

前言

PS. 本文只描述IT行业。

博客园果真人气比较高，我之前准备写个 “领域驱动系列”，然后感觉大家不感兴趣，看来用的人不多，所以一直没动力续，但是昨天写了 加班有罪, 却收到了很多个赞，让我感到有点意外。

我今天看了很多评论，感觉很欣慰，大家其实对加班的看法和担忧其实都是正确的，但是很多人可能忽略了一些前提，如果盲目的下班就走，数着秒下班，那我写这篇文章就有罪了。

为什么加班是有罪的，加班有罪 这篇文章已经做了较多的阐述，那么光说加班有罪是不够的，公司或者老板可以提倡不加班的文化，但是如何才能做到不加班？直接一刀切，到六点就赶大家走这样肯定是不够的，可能很多公司如果现在立马这么做，可能就倒闭了，员工可能还得找工作。

加班有罪的对立面也不一定是正确的

我们很多人想问题，可能是非黑即白，我们提倡不加班，但是我们要想如何不加班，如果我们技术水平低，别人1个小时做完的，你可能一天也做不完，如果你写的程序员出现了紧急的bug, 如果你上班时间在看电影，QQ等，你再不加班把任务做完，哪个公司敢用你？ 我前篇文章说过，并没有说你一分钟都不能多待，比如每个月有8个小时的加班，我认为都是正常的。

如果你上班时间也没有好好干，那么不加班更有罪，因为你是上班时间休息了。

如何不加班?

我们实行敏捷很多年了，但是同样有很多人一说到敏捷，就只知道SCRUM, 没有抓住敏捷的本质。就算过程用SCRUM, 那么其实也就是一个管理层或者从上到下的东西，但是并没有对程序员每日的工作有多大的帮助。我们同样需要很多的工程实践，技术成长等来提高我们每天的工作效率和质量。

那么我认为从程序员的角度，如果你想理直气壮的准点走人，那么一下几点可供参考。

• 工作时间要保证

  我个人觉得上班时间工作是天经地义的，可能有的人羡慕Google等有更宽松的时间，羡慕很多公司都不需要工作8小时，但是前提先想一想，我们是否有那些公司的工程师的能力和效率，如果没有，还是在上班时间好好工作，如果有，与其羡慕，不如赶紧加入你羡慕的公司，前提是人家要你。

• 上班的时间要用来工作

  我们很多人上班时间一会儿刷下微博，一会儿看看微信，尤其是QQ闪个不停，还有号称是要学习的，加了一堆技术的群，美其名曰学习技术，我也加了些群看看，实际上发现基本都在里面灌水。原因很简单，有的时候问个问题，基本问问题的人描述不清，别人怎么回答？ 问问题，你就不能上StackOverflow吗？ 原因是自己只会用百度，好吧，我无话可说。

• 进公司隐瞒自己技术水平

  现在IT行业有个怪圈，我觉得迟早得拨乱反正，本来作为一个程序员答答题，上机写写程序等是非常正常的，但是你要是这样来招人，很多人就很不乐意，说我没那么多时间，我只给公司请了2个小时假来面试，你看着他的简历应该是会的样子，这就极其考验面试官，很多时候越是写程序不行的，越是最比较厉害，尤其是看到概念比较多的。你还真不容易判断出他不行，但是一进来，你发现就完全不行，ASP.NET 你让写个HttpModule不会，MVC你让统一地方处理一下异常不会，你说做权限控制，他写不了一个Filter, 你说WCF 想扩展功能写个Behavior 他说我们用的时候就是顶一个接口标记Contract, 深入的没看过，总之各种不行。然后你布置个很简单的任务，就是说一个高级程序员必须会的，他得花时间再学习，然后才能有产出，你说怎么办？上班时间都在学习，你说活还干吗？

  针对上面的情况，一种方案是直接不用这个人，第二种就是要争取个人同意让他多干一会儿，不然你还得背上黄世仁的名，其他人看到你说的不加班是假的。

• 降低自己的薪水，给自己留学习的时间

  我们有的时候，确实进来后，发现周围的人都比自己强，而自己的薪水也和他们差不多，如何衡量，就是如果你的薪水比市场其它公司要高不少，而且你进来后发现你比别人差不少，就证明你要多了，这样公司可能按同级别薪水的人要求你，你的产出肯定是比别人少，这样你想完成任务，就得加班，那么就到了我说的恶心循环，最好的方式就是主动降点薪水，然后留下班后的时间给自己学习，公司也不会对你要求太多。其实这样，你的收益更大。

• 提高工作效率，改变工作方式
  我们很多人，做事方式和方法有问题，比如连需求都没搞清楚，就开始写代码，然后删了又删，改了又该，这样很简单的一个东西，必然要做很长时间。有的人代码写完后自己下次都要想很久才能知道啥意思，这就需要我们多改进自己的工作方式，多向效率高的程序员学习等。 同时有很多东西提高效率，比如你是否可以并行的做一些事情来提高效率，比如使用Resharper就可以大大提高效率，写单元测试可以避免你为了测一个方法每次都要把系统跑起来debug呢？持续集成可以帮助你把你修复bug更靠近你产生bug的时候等等。

• 下班后多学习

  上篇文章我也提出了，不加班不代表下班后不学习，我招人的时候，经常问的一个问题，就是你如何提高自己技术水平，很多人回答了我一个无法反驳的答案就是:”通过做公司的项目学习”，但是这是远远不够的，一般如果只是这样，除非你天赋异禀。我是不相信你这样就能够成为大牛的。 比如我们需要了解工程实践，了解新的技术，了解一切帮助提高质量和效率的东西，了解一切提高沟通和管理的书籍等。

前言

加班在很多行业司空见惯，于是 “过劳死” 开始为更多的人关注，
IT行业尤为严重，但是普通职员再关注也起不了多大的作用，老板让你加班，或者是潜规则让你加班。我们从几年前就开始不提倡加班，我们也基本没加班，但是最近做了一个项目，出现程序员加班，甚至我自己本人都投入了很多下班后的时间，让我又一次思考加班的问题。作为一个分公司经理，我鼓起勇气写下此文。

脑力劳动不应该加班

加班无非就是增加工作时间来增加工作产出，比如机器制造，我们让机器多转几小时，肯定多生产一些产品，比如我们让人搬砖，多搬几个小时，虽然最后比较累，无非就是搬的慢了，但是还是能多搬一些。但是这些可以说基本都是机械性的工作。

但是，软件行业其实是创造性的，同时很多时候依赖高度的抽象，加班会持续破坏创造力，我们想想，我们让孩子连续学8个小时的数学课试试，显然我们知道那不合理。而且我们知道脑力劳动比体力劳动很多时候更累，更需要休息，这个本来是显而易见的，我们每个人都切身体会，但是我们很多老板，很多客户都想不明白。

加班的恶性循环

这个场景是否遇到过？

晚上加班到11点，然后感觉很饿，然后外面饭店都关门了，只剩下肯德基了，于是打了个车去肯德鸡，由于好饿，买了个全家桶, 然后回家太累了立即上床睡觉，然后你发现吃的太撑了，睡不着，最后迷迷糊糊的睡着了，此时已经是半夜三点了，然后你做了个梦，梦见周末你在玩，老板打电话让你赶紧回去加班，这个时候闹铃想了，第二天该上班了，由于昨晚吃的太撑，早饭实在不想吃了，你飞一样赶上公交车或地铁，座位别人坐完了，车上全是人，一个女的挤了你一下，你抬了一下头用你那睁不开的眼睛看了一下他，那个女的觉得你很猥琐，恶狠狠瞪了你一眼，你心里正想着，老子眼睛都睁不开了，都累成马，还有心情看你？ 你正郁闷，听到一声：”软件园站到了”，你就又开始了下一天的循环。

我们看到，如果上面的场景持续发生，先从你的身体开始，你的肚子开始圆了，作为男人的你胸部开始变大，头发开始变少，颈椎病也来了，同时，因为你天天加班，你反而不习惯周围的人不加班了，你开始觉得你的家人都很懒，你的客户都很懒，你的朋友都很懒，你的同事都不错，因为和你一样。最后你挂了，留下了大千世界给其他人。

加班导致创造力低下

我们看到很多人工作勤勤恳恳，看似非常努力，但是却很难做有创造性的工作，我们看到很多学生学习很幸苦，但是最近几百年中国都没有颠覆新的发明和创新，我们一直引以为傲的 “四大发明”，离我们都比较远了。当然国外也好不到哪里去，最近30年几乎没有什么大的创新。 飞机让我们飞上了蓝天，蒸汽机使我们有了火车，电话让我们更快的交流，互联网让我们有了更多的信息互通，等等这些都快一百年了。

我们人什么时间可以自己飞上天？ 我们生命如何延长100年？ 我们可以不睡觉吗？ 我们如何只吃少量的食物能够存活？我们必须用大规模使用石油和天然气？ 我觉得至今没有解决的原因，就是我们没有那么多的时间来思考和创造。

回到软件行业，加班使我们不段的做机械工作，不断的复制拷贝，我们大脑被这些东西塞的慢慢的，我们哪有时间去思考更好的解决问题的方法？我们哪有时间去学习何成长？

为什么说加班解决不了问题？

加班的主要目的是增加产出，但是我们大家最终选择了这种简单粗暴的方式，就是加班来增加产出，但是想一想，我们每天工作8个小时，就算一天不吃不喝不上厕所，我们也就是24个小时，产出最大也就三倍。

我们都知道，一个优秀的工程师是一个普通工程师效率的10倍，甚至百倍。那么我们就需要考虑的是，我们其实是要提高工作效率，也就是8个小时之内提高效率，比如，我们使用自动化，我们使用快捷键，我们使用持续集成等等这样的方式都可以提高效率，而加班却给大家造成了恶意引导，让大家觉得我总是可以通过加班来完成工作，而忽略了我们本质是要提高效率。如果我们一开始的出发点就是我们不要加班，我们提高效率，工程师自然就会更多的考虑8小时之内的效率，比如使用番茄工作法，比如不要写会儿代码，看会儿微信，就会想到单元测试保证质量避免返工等等，而真正提高了效率，我们个人才算是成长了。

不加班不代表下班后不学习

当我强调不加班的时候，很多人开心的露出了笑容，但是如果这样，那可能就完了，不加班不代表你不提高自己，不加班需要我们提高效率，如何提高效率，那就要不断找新的方法，不断的去学习，不断的提升解决问题的方法，不但的反思回顾。

下班后需要看书，IT人员，比如英语是不是需要学习？ 技术需不需要学习？工程实践是不是需要学习？ 架构，算法，设计模式，Clean Code等等都需要学习。同时，也需要看一些非技术之外的书，我们可以看到很多技术图书作者使用大量的比喻来描述问题，如果你不观察生活，你不读书，如何用这些简单的生活场景描述复杂的技术呢？

不加班不代表你的表的闹钟定到下午6点，我们提倡不加班，但是不代表你一分钟都不多干，你和单位划清界限，你是不是把今天的工作任务完成了，或者你至少把手上的单元测试通过了，你至少要把你今天的代码Commit了吧。所以，一般你一个月加班总时间不超过8个小时，我觉得应该是OK的。

今天不加班，各位老板你敢吗？

不加班需要勇气，需要能力，我们大家都顶着各样的压力在加班，但是我想说，我们这个世界不是东西太少而是太多了，美其名曰我们选择多，实际上我们得到的东西质量都下降了，企业之间相互抄袭，导致价格不但下降，利润不断降低，整体服务质量不断下降。各种创新越来越少。

一个没有创造力的行业是不长久的，总之，我觉得越来越多的公司会开始主要到提高员工工作效率，而避免加班，尤其是软件行业，谁敢抛弃短期利益（可能会丢掉一些项目），但是长远来看会大大增加企业的竞争力，因为员工成长，全员创造一定会极大提升企业的价值，最终一定是名利双收。

如果你觉得我文章写的很有道理，请推荐给你的老板。