标签：
第十章 打造帮派文化
----我的团队管理风格
从一开始，我就想让PayPal员工紧密团结，而不是出于事务关系待在一起。
除了工作时间，其它时间也要更多地交流和活动。
初创公司早期要让员工尽可能地个性相像，因为观点一致，更容易高效运转。
每名员工只专注于一件事情：
因为角色界定明确可以减少矛盾，消除竞争更易于建立长久的纯粹的工作关系以外的交情。
内部和谐也是初创公司存活的关键。
一位早期创业公司创始人在问答网站 Quora 上面的一个 提问最近很火，
大家给出的答案超过了 100 个，评论数更是超过 15 万条，这其中也包括我本人的。
在提问中，这位匿名创始人就下面这件事征求 Quora 社区的意见：
“我在硅谷经营着一家年轻的创业公司。我唯一的雇员表现非常好，但他最近刚刚当了父亲。
这意味着他必须在晚上 6 点至 7 点之间离开公司。
我理解他，不过员工的奉献仅限于工作时间，这对于一家创业公司而言太难了。
你要是公司首席执行官，该怎么办?”
这篇帖子的确激怒了 Quora 社区中的许多人(你也能从他们的反应中感受到这种情绪)，
但作为一家公司的创始人，我理解他的难处。
几个月前，我也曾遭遇同样的问题。
当时，一位高级安卓工程师离开了我的公司，此人很有能力，也是我们团队中一位重要成员，
但这件事让我最终重新考虑自己的态度，并逐渐意识到保持一种积极向上的企业文化如此重要的原因。
对于上面那位提出这个问题的创始人，
我希望他能意识到在创造积极的企业文化过程中所应吸取的一个痛苦但却极其重要的教训，
以及这种教训所带来的独特的机遇。
以下即是我在 Quora 上面告诉他的一句话：
“决定这件事成败的关键人物就坐在你的面前，要求回家看孩子。
听听他的想法吧，从他身上学习一些东西。他知道什么样的环境能让自己处于成功的最佳位置。”
我们很容易就会深陷日常琐事，专注短期工作效率而不可自拔。
但企业文化很重要。为员工营造一个积极的环境，会提升团队的整体幸福感，你的公司也会因此变得更好。
最终，相比最好的员工离职给公司工作效率造成的损失，让他多工作一会儿所创造的价值，就变得微不足道。
这是我本人十分赞赏的一句话：“你雇了一名员工，一个人就走了进去。”
当公司的工程师亚历克斯告诉我他打算离开时，我简直不相信自己的耳朵。
如果在他与我们一起工作的时候，我们能随时关注他的情况，
那么我可能就会知道他正在承担的是自己不想做的管理岗位。
他希望在这里每天从事的工作除了能满足一家创业公司的基本需要外，还可以继续完善自己的技术或经验。
在这次谈话结束后，我又与我们的首席软件工程师聊了聊，他谈到了他对管理的预期看法，
他是这样说的：
“你是愿意在 6 个月以后在家与妻子谈一谈那些正让你感到困惑的事情呢，
还是愿意二人经常开诚布公地进行交流呢?”
我自认为是个逻辑思维很强的人，所以这番话也赢得了我的共鸣。
我们随后做出了一系列改变，其中之一就是改变我们彼此之间的交流方式。
过去，我们会提前安排好会议日程，或是打断员工正在做的事情，让他们参与讨论;
现在我们使用 Slack——这个企业协同工具提供了一个不错的平台，
让团队可以在闲暇时间自由讨论和分享他们的观点，最终帮助他们进行开放式交流。
另外，它还不会像以前那样让员工分心。
看到 Slack 对我们的团队变得如此重要，我觉得很有趣，毕竟，我是一个很喜欢面对面交流的人。
所以，当直接交流变得更合适的时候，团队主要通过 Slack 进行一般性交流，
也就成了一件更轻松、更不会分散注意力的事情。
团队内部的交流越来越变成一种非常宝贵的体验。
然而，做到这一点并不容易，作为创始人，关键是要对自己的才能有清楚的认识，
若想成功打造一个团结、积极的团队，就必须找到具有互补技术的团队成员——这一点显而易见。
一个不太容易理解的事情是 ，互补技术还伴随着不同的个性、不同的交流技巧、不同的兴趣和和不同的期望。
作为一个创始人，你的职责就是发现、抓住和利用机遇，
最终创造一个环境，在这种环境下分歧不仅能共存，而且还能促进企业成长。
如果你不确定自己公司的企业文化应该是什么样子，那么就该花时间与员工交流一下。
没有人能无所不知，你之所以要创建一个团队，就是为了不必什么事情都亲历亲为。
我现在与最优秀的一些工程师、UX 设计师和可穿戴设备专家一起共事。
在遇到什么难题时，我会坦诚布公地说，“我真不知道，还是让我们大家来想想办法吧”。
一个团队不仅要欣赏这种态度，而且还要给予尊重——这种事情通常发生在你打造行业职场未来的时候。
结果就是，互相尊重并理解我们从彼此身上学到的东西，从而让这家公司走向成功打下良好的基础。
每个人对理想环境的预期和看法并不一定与我想象的一样。
从这种角度讲，我作为一个创始人的努力目标就是，创建一个能够超出我们团队预期的工作场所。
我告诉亚历克斯，他是一位很有责任心的员工，有权做出适当的改变以推动公司的前进，
结果一个摩擦层几乎立即被消除了。如果你能让团队成员有机会去改变公司的文化和环境，
那么环顾四周，便会看到公司在一群快乐的人的共同努力下所取得的进步。
（作者：德鲁·奥斯丁(Drew Austin)，他是 Augmate 联合创始人，StartFast Accelerator 项目导师，
纽约 FounderDating 执行董事，SXSWStartup Village 顾问。）
阿里、腾讯以及一些创业公司是如何进行研发管理和绩效考核的？
在知乎上，这个问题得到了超过5000位网友的关注，
显然，BAT获得的巨大成功使得巨头们的管理模式成为了人们好奇的焦点。
豌豆荚创始团队成员丁吉昌这个问题下做了一个豌豆荚研发管理的详细分享。
本文已获作者授权。
首先，画一下我们通常讲研发管理的范畴：
确定如何立项，
如何确定产品目标，
如何把控项目进度，
如何驱动产品一代代完善
以及如何调动团队积极性等。
在时间周期上来说，我们归纳为 5 个关键步骤：
选方向、
定目标、
控进度、
带团队和
排干扰。
相配套的，则是在这五个关键步骤的一些流程和工具的使用。
在豌豆荚的整个研发过程中，立项称为ProductBrief或者Project Brief
。团队的产品经理会撰写一个1－2页的文档，然后和执行团队进行评审，
如果评审通过，立项就成功了。
文档一般包含会包含以下内容：
1. 愿景：一句话表达清楚要做什么；
2. 分析市场机会和趋势，决定当前策略；
3. 确定目标用户的特征和核心需求；
4. 现存的解决方案和各自的优劣势；
5. 该项目对豌豆荚的利益点；如果不做该项目，哪些竞争对手会做，对竞争对手的利益点；
6. 需要哪些技术的支持和驱动，哪些技术是豌豆荚的弱项；
7. 人力需求；
8. 项目的紧急程度，是否需要快速推进；
9. 发布策略；
10.核心衡量指标，用来衡量成功的指标。
对一个项目来说，设定目标是非常重要的，因为这决定了如何去做，以及能做到何种程度。
豌豆荚采纳的目标管理是从 Google 引进的 OKR 体系（Objectives& Key Results，目标与关键成果），
这跟传统的 KPI（Key Performance Indicator，关键绩效考核）稍微有些区别：
1. OKR 首先是沟通工具：豌豆荚共有 300 多人，每个人都要写 OKR。
为了便于沟通，所有这些OKR都会放在一个文档里。
任何员工都可以看到 CEO 的这个季度最重要的目标是什么，HR 团队这个季度的目标是什么。
2. OKR是努力的方向和目标：
OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。
3. OKR必须可量化。
比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」，肯定不是一个好的 OKR，
因为无法衡量，好的OKR是「今年的跑步时间较去年增加一倍」。
4. 目标必须一致：
制定者和执行者目标一致、团队和个人的目标一致。
首先，制定公司的OKR；
其次，每个团队定自己的 OKR；
第三，每个工程师或设计师写各自的OKR。
这三步各自独立完成，然后对照协调这三者的OKR。
在豌豆荚，OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。
5. 通过月度会议Review ，时时跟进OKR：
在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。
6. 通过季度会议 Review ，及时调整OKR：
互联网的变化非常快，所以豌豆荚每季度有一个OKR 的 review，
调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）。
为了更好的理解如何制定OKR体系，我们看个例子：
目标（Objectives）：发布有影响力的新功能，将 XXX 产品做成用户可以每日使用的产品。
关键成果（Key Results）：
日活跃用户量为XX；
使用XX方式，提高XXX核心指标；
目标设定以后，非常重要的就是执行，一般的项目管理实际上就是控制进度。
1. 任务/进度勤同步。
整个公司所有人的 calender，包括会议、要做的事情、项目的时间节点都需要及时同步。
在整个战略布局上，如果某个项目工期非常紧，就必须进行更多的沟通，确保每一个环节都没有问题。
2. 站立会议 (Daily Sync)：
每天进行站立会议，一般控制在十分钟之内，每个人说明自己今天要做的工作，
需要什么帮助，有谁可以帮忙，可以更有效的调节资源和公关。
3. 多方位沟通（Google Docs / Gmail / Hangouts）：
对非紧急的事情，两个团队或者是两个人一起讨论所有的设计。Hangouts用于做快速响应。
4. 周会（Weekly Report）：
每周总结。豌豆荚的团队产品经理要做周报，汇报这周的工作、发布、取得效果以及数据。
5. 数据系统：
MUCE 是豌豆荚的数据系统，上面有全公司所有的产品数据和运营数据。
MUCE 的数据能够用来验证产品的假设、方向等。
项目是由一个个具体的人来执行的，所以带团队非常重要，
在人员管理上，豌豆荚有三个基本原则：
1、Re-Organization& 换组：
公司鼓励员工换组，每个人都有机会到喜爱的团队做更有趣的事情。
只要在原团队的绩效合格，每季度都可申请换团队或换工作内容。
员工的绩效不与 OKR 挂钩，公司鼓励员工挑战难度、超越优秀，
低 Level 的事情做不到优秀会被惩罚，做事不及格也会被惩罚。
2、One on One：
在带人方面， One on One 非常重要。
One on One 指的是每个团队的 manager 需要定期（最佳间隔是每周一次）
与自己团队中的每个成员进行一对一讨论或者对话。
在豌豆荚，manager 首先是一个教练，应该帮助自己团队的成员成长。
通过 One on One，manager 需要了解每个团队成员现阶段的状态和遭遇的困扰，
分享职业规划，帮助他们正确地处理问题，更好地实现个人成长。
3、个人 OKR 和 Performance 体系：
每个员工在每个季度初需要确定自己本季度的 OKR，
在一个季度结束后需要根据自己这个季度的工作完成情况给 OKR 打分。
每半年公司会进行一次 Performance Review，主要是 review 员工过去半年的绩效，
并根据 Performance Review 的结果变更 Job Ladder（业务职级）和薪酬。
值得一提的是，在豌豆荚，所有的个人Performance Review 的成就内容及级别都是全公司共享公开的。
这个对于很多公司来说是不可想象的，豌豆荚为什么要这么做？
因为一方面对于豌豆荚来说可以做到更为公平和透明，
另一方面也给每位豌豆提供了更好学习和成长自己的样本，
激励大家在产品研发中更高质量的挑战和要求自己。
1、激发兴趣：
HackDay，是豌豆荚一个特殊的节日，开始于2010年，类似黑客马拉松。
通常在春节假期回来的那一周，产品设计师和工程师们 3-5 人组成一队，
在连续48小时的时间里，充分展现工程团队的创意和想像力，完成一些比日常开发更 geek、更有趣的东西。
豌豆荚为了鼓励大家更好的完成挑战，也会设计一些特别有特色的奖品，
历史上2012 年提供的是苹果刚出 Macbook Retina，2013年是 Google Glass，
2014 年则是程序员最爱的 Herman Miller 顶级座椅。
在历史的 Hackday 中，有不少作品最终都成了重要产品对外发布，
比如 MUCE、豌豆洗白白和 IAS（应用内搜索），都成为了豌豆荚极具特色的产品。
2、控制兴趣：
PolishWeek，让公司慢下来，对已有产品的细节进行精细化的过程。
在大量开发和新产品上线的过程中，我们会担心因为走得太快而对产品的细节关注不够。
在连续3个工作周后，
第4周通常是 PolishWeek。
在 Polish Week 的这一周，豌豆荚内部不会进行新产品或新功能的开发，
而主要是对现有的产品和服务进行打磨，解决一些细节问题和小 bug，譬如产品内一些字体的统一等等。
平均每个 Polish Week 会解决产品中各种 Bug 大约 200 个。
过去几年豌豆荚做 Windows 版的时候，尝试过一个月、两个月、一个星期、两个星期的发布节奏，
整个模式跟 Chrome 比较像，有功能发布就希望尽早的发。
我们在服务端上每天都有更新，客户端会慢一点，现在大概是两周一个版本，
如下图所示：
在开发节奏上，前两周的时间用于开发，然后截取分支准备发布，接下来两周进行测试，
同时进行另一个开发，每一个迭代都控制在两周之内。
相对而言，服务端的发布比较好操作，可以做很多的回归测试和自动化测试，
不太需要手工的测试来做发布，但是 Windows 和 Android 都会有一些 Beta 的发布，
在内部很难模拟用户的使用场景和用户的环境，
所以在 release 之后的过程中一般会抽样 1%、5%、10% 这样一个节奏来做验证，
主要是看某些指标是否达标。
这个流程刚开始执行的时候问题特别多
。比如在这周开发完成以后，测试发现根本测试不了，有很多很多的 Bug，
工程师只好利用第二个研发周期去修 Bug，然后又会影响第二周期的开发，
这样问题越来越多，就会导致流程很难进行，然后进入恶性循环。
为了解决这个问题，首先在操作层面上一开始先用一个月的迭代来让大家适应，
同时要求 Master 分支必须是可用的（比如某人提交了代码跑不起来，或者没有经过测试，
给其他同事带来了阻碍，就会被要求请全团队喝咖啡）。
其次加强单元测试和回归测试，确保每个迭代的研发质量是可控的，
后面的测试主要是回归和校验，减轻相互重叠的压力问题。
一个月的迭代跑顺了之后，再跑到两周、一周的节奏，
整体来看，差不多用了半年的时间，豌豆荚就完全跑顺了这个流程，
想快可以快，想慢也可以慢。
工欲善其事必先利其器，为了提升产品研发效率，
豌豆荚内部开发了一款项目管理工具Wandoulabs。作为内部的沟通工具，
它主要用来做跨团队沟通，全公司所有员工都会使用。
重要的 roadmaps 必须在这里登记，登记了以后，
一个项目需要多少设计师、需要多少marketing、每个阶段是什么样以及工程师的发布状态都可以在这里看得到。
这就是前面提到的Wandoulabs，
大概逻辑如下：不同的标记分别代表研发状态、发布状态、负责的团队及这个事情的重要级别。
对于重要的发布，豌豆荚有三个最基本的要求：
第一要获得 Product／Design Review 的批准。
一个功能开发以后，无论是界面还是整个 UI，如果会影响到用户的操作，或者影响到商户的收入，
比如我们的广告系统或者和合作伙伴的一些策略调整，
这就需要做 Design Review。Design Review 在豌豆荚里面的时间大概是每周的周一、周三和周六，
每次持续 1-2 个小时，包括Product（Review）、Design（Review）或Business（Review）。
Product Design指的就是 PD，主要的视觉设计师或产品设计师必须全员参加。
第二要获得 EngineeringTech Review 的批准。
这更接近于传统上的技术设计，主要是看某个功能在工程设计上是怎么做的。
做这个设计的团队和所有工程师必须全员参加，也会有一个人来 host，
还需要几个指标的 review。这个过程是帮助相关的工程师把设计考虑更全面，
包括流量、游戏的带宽压力的需求等等。
第三要获得 MarketingReview 的批准。
主要是看产品上需要如何引入 marketing 团队的配合，
需不需要做一些传播，需不需要注意公关策略等等。
同时对于更小的一些 Beta 测试则不强制要求。
这些 Review 实际上是帮助整个团队、整个公司去理解当前最重要是什么，
其实也是建立一个高标准的过程。
我在上海工作期间，接触过一些盛大的员工，
从他们口中碎片式地了解到一些关于盛大的员工积分体系的情况。
前些天在一个闭门活动中听到了更为完整的陈述和不同角度的剖析，
于是引发了我更多的思考。陈天桥强势推动的这个体系始于美好的愿望，终于残酷的现实。
反思这个积分系统的思想，不仅对员工的绩效管理，也对产品开发有着现实的借鉴意义。
1. 需求
陈天桥认为程序员是一群喜欢宅的人，不愿意将时间花费在和别人打交道上，
也很不喜欢由经理制约自己的命运。
因此，他希望在企业内部建立一套机制，可以让员工的职级迁移是自动的和公平的。
这个诉求我想在今天依然是充满吸引力的——不用看领导脸色的晋级该有多爽！
2. 价值
这样一个系统的价值要从两个受众群体来看：
对一线干活的员工来说，是一个解缚获得自由的价值。
每个员工只要管好自己就好，靠努力靠本事升级，再也不用拍领导的马屁了。
对管理者来说，是一个解压获得聚焦的价值。
经理不必再费心去管理员工的职级，做好项目管理，管事不管人。
从价值上说，这个积分体系的初衷确实切中两个受众群体的痛点。
3. 设计思想
将目标落实需要一个合理的设计。
这个积分体系的设计灵感源自盛大的核心业务——游戏——的升级体系。
和游戏世界一样，升级的唯一制约因素就是经验值，与其他任何人的主观意愿都不再有任何关系。
通过个人的努力获得升级，从而获得更多的收入与更多的特权。
只要所有人都遵守同样的游戏规则，那么游戏中的各种机会对于所有人来说就是公平的。
4. 游戏规则
规范整个积分体系的运行规则是复杂的。我对规则的框架进行提炼，来展示最核心的指导原则。
1)、经验值的获取
有两种主要途径：常规途径和任务途径。
常规途径就是上一天班赚一天的经验值（类似游戏里的挂机）。
任务途径就是完成某个任务后获得这个任务所提供的经验值（类似游戏里的打怪）。
2)、市场化
所有项目都以任务为单位，每个项目都带有确定的经验值。
项目的拥有者可以将部分或全部任务（连同相应的经验值）放在任务池里供全员挑选。
3)、自主性
每个人都可以自由地从任务池中选择自己想做的任务。
4)、竞争性
多方竞争完成一项任务时，只有一方胜出获得全部经验值，其余各方均一无所获。
5)、协作性
多个人组队协作完成一项任务时，获得经验值在团队内分配，分配方式由团队内部协商决定。
5. 反思
这个看似完全市场化的竞争模式，在投入运行的初期获得了积极的成效。
但随着时间的推移，这个积分系统被越来越多的员工所厌恶，并最终轰然倒下。
为什么？
这个设计存在着一个隐蔽却是致命的漏洞。
体系的设计者在源于游戏的设计灵感中只看到了游戏中每个玩家的练级，
却忘记了在游戏世界之上还有一个“神”的存在，是这个“神”决定了游戏里的全部规则。
因此，在积分体系的设计里，设计者忘记了对“神”的设计，
或者说，设计者其实是无法设计这个“神”的。
每一项任务应该分配多少经验值，这是个非常困难的判断。
这个绝对值并非最重要的（当然，会影响经验值的累积），
而任务与任务之间的相对经验值差异才是真正的关键所在（决定了经验值之间的兑换关系）。
写一篇宣传稿的经验值与写一个表单代码的经验值应该是什么关系？
当成百上千个性质迥异的任务放在一起的时候，
定义它们之间的兑换关系就是一件只有“神”才能完成的工作了。
玩游戏的朋友都知道，打怪练级也要挑性价比高的打。
在盛大的积分体系里，自然而然大家在挑选任务时会首先考虑性价比高的任务，而不是重要的任务。
那么，重要却性价比低的任务怎么办呢？等性价比高的任务都做完了，自然就有人去做性价比低的任务。
或许积分体系的设计者是如此预想的。
但系统的运转并非如此。
动态的任务池里不断地有新任务被加入，投放任务的人为了让自己的任务能够被尽快完成，
就需要开出更有吸引力的经验值“悬赏”。
最终的结果必然是，富人总是可以让自己的任务被完成，不论任务是否重要或紧急。
穷人则根本找不到帮手，连自己团队的人都指望不上。
只能要么自己搞定，要么让任务不断延期。
于是，富者愈富，穷者愈穷，看似公平的体系却出现了预想之外的两极分化。
要改变这种两级分化的局面，最容易想到的方式就是给予穷人补助。
于是，积分体系试图通过为穷人提供较多的经验值（也就是发放均富卡）来帮助穷人提高“悬赏”的能力。
较为隐蔽的手段是宏观调控，利用杠杆来指引资源的走向。
这样与公司的战略方向更为契合的项目就会分到更多的经验值包（类似“政策倾斜”）。
而简单粗暴的做法则是直接给各级领导发放经验值补贴，
由领导自行决定如何发放这些补助（类似“货币刺激”）。
但这种干预既违背了积分体系追求公平的初衷（反而主动制造通货膨胀），
也未能从根本上解决两级分化的问题（只是缓解而已）。
一些子公司开始规定禁止经验值跨公司流通（类似游戏里的账号不能跨区登录）。
当然，这依然只是暂时地缓解困境，分化会继续在部门层级上开始产生影响。
盛大的积分体系的出发点是美好的，只是这样一个体系本质上是在运营和管理一个社会。
所有现实社会中的经济复杂性都将在这个体系里出现，
而体系的设计者们却忘记了诸如“经济危机”、“贫富差距”、
“通货膨胀”这些全球各国都还未获良策的经济问题。
在讨论中，我问了一个问题：“积分体系上线之前为什么没有先做一个小范围试点呢？”
得到的答复是：“可能（设计者们）太相信它的完美无缺吧。”
积分体系给了我很多启发，从产品角度看可以有这么几点：
第一次做一件事情的时候，不要过分自信。
高估复杂性只是浪费一些资源，但低估复杂性则可能是灭顶之灾。
用户量大的时候一定要进行灰度测试。
学一点经济学和社会学，无论做什么设计，都会让你的思考更有深度。
不要拿游戏里的东西作为现实产品的原型。
游戏的世界每分每秒都是虚假的，其中可借鉴的不是规则，而是行为。
?
或许，在积分体系的最初，陈天桥是认为自己就是那个“神”的。
标签：
原文地址：http://www.cnblogs.com/neoyan/p/4383528.html
