企业中，最重要的因素就是人。这些人儿，不能全部是所谓的精英，否则眼高手低整天扯皮没人干活，最终窝里斗；也不能全部是乌合之众，这样最终会走向劣币驱逐良币的结果。一个合理的企业架构必须是层级的，除了给新入行的一个虚无缥缈的晋升路线，更重要的是保证各个层次的活儿都有人干，替代的目标也明确。“爱干干，不干滚”，是所有股东希望看到的组织模式。

研发部门，作为一个必须出实际成果才能有所交代的整体，必然要承受大部分压力。一个普通的、发展不好的企业，如果有一个产品总监滚蛋了，大概率是企业的幸事；而如果一个研发总监滚蛋了，对企业并没有多大影响，不论是正向的，还是反向的。

因为研发体系整体上是有逻辑的，除非差的太离谱。研发血统是深入企业骨髓的，外部变革资源的引入，只会在天长地久中被慢慢吞噬，大多数时候并没有什么鸟用。所以陆奇改变不了百度，有些东西，是基因。

在这个演进过程中，每一代（以斗争分代）研发，都会对流程和规范添砖加瓦。期望向好，也期望在发生问题的时候能够抓到倒霉的替罪羊。至于最后盖的是皇宫，还是修的坟墓，就不是研发们所能掌控的了。

看上面的描述，好像要写一篇非常牛逼的吐槽文章。但是让你失望了，下面要给你展示的，是一个说了等于没说，但又不得不没有的一个东西。说它无用，因为它务虚，有职业素养的员工不需要强调这些；说它有用，是因为有些老板认为，所有的员工，都是没有职业素养的。有这种感觉的老板，肯定也会认为招聘团队是吃屎的，一群苍蝇只会引来蛆，不会吸引蜜蜂。

开始我们简短的表演。

一、研发小组的工作来源

1、任务来源

研发要正确区分任务来源，作出合理的计划，应对突发状况，并能够做到思考改变，形成正向循环。

计划：产品需求、技术需求、线上bug、线上工单，其它相关任务，走排期计划
突发：突然情况包括：线上监控、线上突发故障、临时紧急安排
思考改变：来自研发内部，针对架构、质量、稳定性、扩容、易用性、高可用、工作量等

2、团队目标：

团队和个人目标应该明确，能够被追踪。

（1）研发团队目标，分解自公司整体目标；产品部门的输出，会传递产品的目标
（2）研发团队的重要目标：线上稳定性、研发质量
（3）研发团队其它目标：人才梯队、团队能力

二、研发组工作要点

迭代任务
起始：需求评审、排期、分配
期间：方案讨论、设计讨论内审、代码、评审、自测、QA测试跟进、沟通

技术需求
起始：需求提出、需求讨论、需求宣讲、分配、排期
期间：方案、设计、评审、自测、QA测试跟进、沟通发版

线上Bug
起始：线上Bug    内部过会、分配、排期
期间：编码、自测、QA测试跟进、沟通
线上工单
起始：内部过会、分配、排期
期间：处理、沟通 、总结

线上发版
起始：上线列表互相确认、上线申请、发版次序、脚本、资源申请、checklist、人员安排
期间：代码合并、 发版、检查状态、线上回归、沟通发版同步、总结

突发情况
起始：反馈来源
期间：监控、工单、临时安排，组长负责 或 组长指派

工作推进注意点：

1、晨会：9:30必须准时开，不等迟到的，迟到发组内红包。
2、联合站会：跨组的、重点任务，由主责拉站会，研发阶段由研发主责、测试阶段由测试主责牵头，频率、时间点由主责决定，有阻塞、风险，要同步出来。
3、需求会：原则上，组长要参加，也可由组长安排组内人参加，听完需求，要当天完成：jira、邮件、组内同步、需求问题、组间协调问题、排期等。
4、组长规划组内知识沉淀：例如规范执行、编码问题、设计问题、易遗漏的要点等，在wiki上开辟组内专栏。
5、专项会议：要提前组织好：提前约会议室，同步参会人员、会议目标、内容范围、问题、讨论重点，务必控制好时间，保证会议有效果、不能跑题、有结果。
6、工作分配好：要保证组内每个人清楚，方向在哪儿，怎么做事，自己每天有哪些事，与谁沟通，底线要求是什么。
7、关注和回复重要沟通渠道：微信群、qq群、叮叮、邮件

三、团队沟通

1、沟通对象

（1）与上级沟通
（2）与成员沟通
（3）与相关组沟通
（4）与其他部门沟通
（5）极少，对外沟通

2、沟通方式

（1）Jira、邮件、流程工具
（2）拉会
（3）qq、微信、叮叮，及其它即时通讯工具
（4）单独沟通

3、沟通内容

（1）背景：发起方描述清楚，相关方补充
（2）问题：清晰罗列存在问题、危害、位置、原因
（3）诉求：各方简明表达诉求
（4）结果：讨论结果
重点：效果、效率、闭环

四、周盘点

1、Todo

每周todo要安排好时间和人员、检查进度。

2、计划进展

（1）任务类别：产品需求、技术需求、线上bug、工单
（2）重点进展：任务描述、进展、相关方情况、风险、阻塞
（3）稳定性/可靠性：解决的问题、进展、风险、阻塞
（4）易用性：任务描述、进展
重要：重点工作单独罗列。

3、突发情况

（1）背景描述
（2）人员安排
（3）进展描述
（4）风险披露
（5）结论，通报

4、质量措施

（1）sonar：审查结果消除数量
（2）自测：单元测试用例数量
（3）接口测试：桩模块数量、测试数据条数

5、能力提升

（1）技能培训（人次）
（2）业务培训（人次）
（3）流程培训（人次）
（4）新技术分享（次）
（5）最佳实践分享（次）
（6）代码质量优化技巧分享（次）

END

这种东西，是属于软件工程一类的范畴。领导们都希望，有一门方法论，能够明确的管理这些虚拟资产，同时能够合理约束这群蝼蚁。但软件工程在国内是非常尴尬的，尴尬到了形同虚设的地位。周围的很多人，包括我，几乎无法确切的说明软件工程是什么。是敏捷开发么？好像也不尽然，还有大多数弟兄处在传统的开发模式中。敏捷开发意味着需求的不断变更，不断的加班—这就是打着敏捷开发的龌龊行为。

更要命的是，这些方法论的布道者们，面对领导和客户的压力。手忙脚乱之下，就经常推翻自己制定的规则，频频打脸，没有信服力。所以每个企业的规则和流程，都是四不像，一直在演进，而且几乎无法复用。

话说回来，规则这东西，就和炒股一样，指导别人容易，等自己真正做起来，很难。把绳子套别人脖子上，很爽；等真正套到自己头上，就觉得疼了。