第一，画一下大家一般讲研发管理的范畴：确定怎么样立项，怎么样确定商品目的，怎么样把控项目进度，怎么样驱动商品一代代健全与怎么样调动团队积极性等。
在时间周期上来讲，大家总结为 5 个重点步骤：选方向、定目的、控进度、带团队和排干扰。
合适套的，则是在这五个重点步骤的一些步骤和工具的用法。
1、高效研发的5个重点步骤
第一步：立项——定方向
在豌豆荚的整个研发过程中，立项称为ProductBrief或者Project Brief。团队的商品经理会写作一个1－2页的文档，然后和实行团队进行评审，假如评审通过，立项就成功了。文档一般包括会包括以下内容：
1、愿景：一句话表达了解要干什么；
2、剖析市场机会和趋势，决定目前方案；
3、确定目的用户的特点和核心需要；
4、现存的解决方法和各自的优劣势；
5、该项目对豌豆荚的利益点；假如不做该项目，什么角逐对手会做，对角逐对手的利益点；
6、需要什么技术的支持和驱动，什么技术是豌豆荚的弱项；
7、人力需要；
8、项目的紧急程度，是不是需要迅速推进；
9。 发布方案；
10、核心衡量指标，用来衡量成功的指标。
第二步，OKR 体系——定目的
对一个项目来讲，设定目的是尤为重要的，由于这决定了怎么样去做，与能做到何种程度。豌豆荚采纳的目的管理是从 谷歌 引进的 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、多方位交流（谷歌 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，是豌豆荚一个特殊的节日，开始于2026年，类似黑客马拉松。一般在新年假期回来的那一周，商品设计师和工程师们 3|5 人组成一队，在连续48小时的时间里，充分展示工程团队的创意和想像力，完成一些比平时开发更 geek、更有趣的东西。
豌豆荚为了鼓励大伙更好的完成挑战，也会设计一些特别有特点的奖品，历史上2026 年提供的是苹果刚出 Macbook Retina，2026年是 谷歌 Glass，2026 年则是技术员最喜欢的 Herman Miller 顶级座椅。
在历史的 Hackday 中，有不少作品最后都成了要紧商品对外发布，譬如 MUCE、豌豆洗白白和 IAS（应用内搜索），都成为了豌豆荚极具特点的商品。
2、控制兴趣：PolishWeek，让公司慢下来，对已有商品的细节进行精细化的过程。在很多开发和新品上线的过程中，大家会担忧由于走得太快而对商品的细节关注不够。在连续3个工作周后，第4周一般是 PolishWeek。在 Polish Week 的这一周，豌豆荚内部不会进行新品或新功能的开发，而主如果对现有些商品和服务进行打磨，解决一些细节问题和小 bug，譬如商品内一些字体的统一等等。平均每一个 Polish Week 会解决商品中各种 Bug 大约 200 个。
2、高效研发的步骤和工具
过去几年豌豆荚做 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、周三和周六，每次持续 1|2 个小时，包含Product（Review）、Design（Review）或Business（Review）。Product Design指的就是 PD，主要的视觉设计师或商品设计师需要全员参加。
第二要获得 EngineeringTech Review 的批准。这更接近于传统上的技术设计，主如果看某个功能在工程设计上是如何做的。做这个设计的团队和所有工程师需要全员参加，也会有一个人来 host，还需要几个指标的 review。这个过程是帮助有关的工程师把设计考虑更全方位，包含流量、游戏的带宽重压的需要等等。
第三要获得 MarketingReview 的批准，主如果看商品上需要怎么样引入 marketing 团队的配合，需无需做一些传播，需无需注意公关方案等等。
同时对于更小的一些 Beta 测试则不强制需要。这类 Review 事实上是帮助整个团队、整个公司去理解目前非常重要是什么，其实也是打造一个高标准的过程。
来源：知乎