欢迎关注公众号 《小姐姐味道》 ,一起进步!

# 研发里那只看不见的手

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

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

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

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

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

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

开始我们简短的表演。

# 一、研发小组的工作来源

# 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

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

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

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

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,​进一步交流。​


关注回复 技术 关键字 ,即可 获取 海量资源

鲁ICP备2020043359号-1