以人治天下,贤则大治,不贤则大乱。
以术知天下,术高多宵小。
以法治天下,法令莫不从,民生定。
作为一个研发,你最讨厌什么?
"小功能,十分钟能搞定吧!"
"需求都清楚了吧,明天老板要看效果!"
"有个急事,插一下!"
"这个地方,还要调整下,稍后给你更新的文档!"
"这个当初肯定不是这样定的,是你们的问题"
"代码怎么被覆盖了?"
"测过的代码怎么没上线?"
"这个线上问题是谁谁的变动引起的。"
"这个为什么没测到?"
... ...
需求张口就提,说变就变;开发时间不明确,无法控制;测试不规范,不全面,质量无法保障等等,不一列举。
没有规范约束,没有流程限制,没有章程遵循。 可能对于某些场景会很高效,但问题也是层出不穷。
一个公司成长到了一定的规模,如果还是如上这种,那么唯一的结果只有:混乱。
一个完整的研发过程包括哪些活动?
需求 => 开发 => 测试 => 上线。
确定要做什么 + 做成什么样 + 怎么做
比如:
要做什么:发表文章的功能页面要改版,以更好的适应用户的操作习惯。
做成什么样:新的功能布局 + 新的编辑器支持 + 表情符号支持 + 话题插入支持 + 图片编辑支持 + 自动实时保存支持。
怎么做:输出详细的 prd 需求文档 + 需求评审 + 资源调配 + 排期 + 进度控制。
相对来说,前两步多是产品自身范围内的工作活动,是需求的基础。最后一项则是和关联研发人员的协作,支持。以成品 prd 文档作为媒介,进一步展开后续的流程。
一个公司会有很多个产品,每个产品负责不同的业务范畴,那么便会衍生出不同方向的需求。
需求有大有小,重要性也不尽相同,所以需要有一个排序的流程。
将所有的需求都摆在桌面上,由上层来结合公司发展方向及公司战略来筛选哪些需要做,每一项的优先级。
产品形成成熟的需求文档后,则要进行需求的宣讲,评审。也就是把上述的过程内容阐述给后续流程的研发人员(包括开发和测试等)。
所谓评审,既要评,又要审,也并不会是一锤定音,一遍过。 对需求内容的整体方向,产出,roi等综合进行考评,合适的的方保留,不合适的去掉,可以改进的继续改进。
对于比较大的,比较重要的或者比较复杂的需求,项目,可能需要经过多次评审,多次改进才能最终定稿。
这一流程节点产出是要作为整个研发流程的指导性文件,应该做到不厌繁琐,力求能够尽善尽美。否则越是往后流程的返工,成本越大。
我们讲一个需求或者项目,即为在特定的资源条件下实现特定的目的。
既定的资源包括时间,人力及设备成本等。
需求周期一般是既定的,比如,老板说下个月什么功能上线,你就得上线,转圜余地不大。
所以涉及到人力需求则要在如上既定时间周期下去安排,调配人力资源。包括开发及测试等。
其它成本包括服务器,网络,外部付费技术资源(安全、校验)等,是不是需要采购新的服务器,是不是需要拓宽网络,是否是需要引入外部的校验API等。
这一阶段,主要是确定每个流程节点的时间需求,确保每个流程能够在合适的时间开始和结束。
需求确定后,流程流转至开发人员,此时,开发人员应根据既定的 prd 需求文档,产出详细的技术方案文件。
闻道有先后,术业有专攻,每个人都有自己擅长的领域。单人主导的技术方案至少要经过交叉人员评审后方可定档实施。
比如,
数据怎么存储?表字段设计的合不合理?需不需要分表?
需不需要介入缓存层?需要哪种形式的缓存?
系统间怎么交互?交互方式?
接口设计是否合理?前后端交互流程?
哪些是核心业务逻辑?哪些业务可以拆分异步处理?
需不需要引入新的技术?
... ... 等等。
编码开发其实占用的时间并不多。
就好像炒菜一样,菜品的清洗,准备往往是最耗时的,反而入锅翻炒也就一会儿的事。
我一直秉信 Code Review 是能够极大保障代码质量的。
Code Review 关注点包括:代码设计、功能实现、复杂性、测试友好性、代码风格、命名、注释、文档等。
Code Review 的形式可以采取代码库流程,或者集体拉会形式等。
开发流程结束后,流程流转至测试。
研发环境一般要提供完整的开发、测试、灰度、线上环境区分,以供不同阶段不同流程需要。
这一阶段,开发人员需要将开发结果部署到测试环境,提供给测试人员。
如有必要,也需要提供相关测试数据支持。
测试案例输出及评审通常和开发并行,由技术方案流程确定后起始。
测试人员根据既定的需求及技术方案文档设计测试用例,包括新功能、变动功能及回归功能等。
测试用例完结后,需要和开发人员进行沟通评审,确保测试用例的完整性。
测试环境及测试用例就绪后,开始流转测试流程。
测试包括功能测试、集成测试、回归测试、灰度测试、线上验证等。
由此节点开始可能需要横跨所有后续流程。
测试往往是产品质量的最后一道防线。
及早发现问题、提出问题应为首要,尤其不要试图掩盖问题。
上线前一秒发现问题都是居功至伟。
功能上线,不同公司可能操作方会略有不同,开发、测试、SRE人员都有可能操作这一流程。
上线后功能验证必不可少,由测试或者产品执行,确保产出和目标相符。
流程至此完结。