在人间做韭菜的那些年(3)--项目推进迭代流程

Posted on Edited on In Views:

项目推进

互联网做项目都是一把梭，在企业没有现有的项目管理系统的前提下，需要有一套行之有效的项目推进的步骤，以下是笔者认为还算ok的一套流程:
image.png

项目推进迭代流程.xlsx

prd阶段

基本输出

这个阶段是pd同学在做头脑风暴，根据需求方需求和以及自己做的市场调研做出的产品设计的描述，会有业务架构图、数据流、资金流、数据流等一些信息，同时会有涉及到界面交互的信息描述。
这些设计都是根据需求来的，有的是现有需求，有的是未来的需求做提前的准备，也有解决历史问题等。
这个阶段pd同学会输出一份prd的设计文档，这个prd文档会到下一个步骤用。

参与人

如果项目复杂，pd同学内部会有一个全体的评估，因为有些prd的设计是一个人做出来的，难免考虑的不是很全面，如果有设计不合理的地方，推进到下一个阶段会遭到技术同学的无情蹂躏。
如果项目牵涉到多个团队的情况，在产品设计层，主牵头的pd团队会召集其他团队的pd进行多次讨论敲定产品设计，主要是打通业务流程，划分每个团队的职责边界。
另外ui视觉交互会直接和pd讨论，让ui输出一份视觉交互稿，这个交互稿同样在下一个步骤使用。

项目评估

此阶段pd会发起邮件通知如下人员参加prd评审:

  • pd
    • 牵头产品团队的pd
    • 如果涉及到多个团队的pd会拉上其他团队的主要负责人。
  • 技术/技术架构/技术风控
    • 开发团队小组人员
    • 架构师(涉及到主要架构调整的)
    • 运维相关的风险控制相关人员，以及技术安全相关(可选)
  • 前端开发
    • 团队的前端开发
  • 测试
    • 相关业务团队的测试人员
  • ui视觉交互
    视觉交互人员
  • 产品风控
    • 法务
    • 合规
    • 监管
  • 业务方
    • 实际提出需求的人员，比如运营人员、市场人员。

这个会议的主讲人pd同学为主，ui设计为辅的旋律，同时pd和技术在会议上会出现打架斗殴的现象，哈哈哈，如果技术和pd的方案出现冲突，双方会敲定都能接受的方式；
同时在达成一致的时候，ui交互稿也会做出调整；
其他角色会在宣讲过程中提出自己的意见和建议；
会议纪要一般是pd同学在做；

这个会议会存在pd设计被重新打回的情况，另外本次会议达成的一致，以及带会下去解决的问题，这些不一致需要敲定下一个时间去再去沟通达成一致，就是多次开会，不过下次会议只会拉上和冲突问题相关的人员，其他人员时间宝贵，不相关的就不会拉上。

如果项目很大，又很紧急，这个时候，技术可以提前做架构上的工作，以及可以做的提前要做的事情，但是不会出排期，以及具体分工。

交互&视觉

参与人
  • ui
  • 技术
  • 测试
  • 前端
    上一个阶段经过多次互相伤害，在业务流程match、技术同学实现得到认可，ui同学得到认可就会进入交互&视觉阶段，根据上一个阶段的达成的一致，重新和技术以及质量同学走一遍。

主旋律是ui同学携带ui设计稿，串通用户操作的行为，讲解一些交互细节。

技术方案评审

上一个阶段过了之后，技术同学会输出一份系统详细设计，然后拉一个会议进行一波评审。

参与人

  • 后端开发
  • 前端(非必须)
  • 测试(非必须)

这里边的测试人员会根据这个系分输出一份测试用例。
这里整理了一份系分设计的模板:
系分设计模板

涉及各个模块的类图、流程图、以及整体的架构设计、数据库设计，表的设计、各系统之间的关联和交互、风险控制等等。
这里说一下韭菜集团贯彻的三板斧：

  • 可监控
    系统运行对技术参数和业务运行是否正常的数据可以有一个监控和观测的口子
  • 可应急
    如果线上系统发生了故障，比如机房故障、或者代码逻辑引发的bug、依赖的第三方系统服务不可用，都是不可以事先预测的，那么如果出现了这种问题，我们在架构上或者说是技术实现上要做防御性建设的处理。
    机房挂掉(挖掘机技术哪家强，中国山东找蓝翔)可以使用多机房部署、异地多活等，代码逻辑出现问题导致的资金损失，要先止血，关键链路可以切断(实现的时候要做配置开关)处理、渠道路由切换、回滚等，第三方系统不可用，比如缓存系统不可用，可以使用降级方案。
  • 可灰度
    一个新功能上线默认认为是存在风险的，因此要先进行小范围的机器部署和发布或者进行路由配置，测试流量进入新迭代的逻辑或者机器。

这三个发布前提是韭菜集团每个技术团队的必须要践行的，否则不能发布。

接口评审

这个步骤理论上可以和技术方案评审 合并，也可以单独拿出来和前端同学评审

参与人

  • 后端
  • 前端(api)
  • 其他依赖当前系统的对接人(rpc)

主讲人是后端开发，对前端接口的形式和参数、返回值进行说明，收集接口使用人的建议。
每个公司都有自己的一套api mock系统，开源的有rap2.
参考:

功能开发

这个阶段是梭哈阶段，针对系分设计完成编码实现，编码阶段涉及的东西很多，这里抛一偏编码军规。
参考:
Api 文档管理系统 RAP2环境搭建

这里说一点我对开发层面的一些看法。
如果一个业务功能能通过pd设计的方式优雅解决掉，就最好不要通过技术手段去实现掉，设计大于实现，抽象大于编程，每一行代码都透露着线上问题的淫笑，选择大于努力。
敬畏每一行代码。
salute！
你懂我意思吗~

接口联调

这个阶段是各个后端服务能力的开发相互之间联合调试的阶段，发现存在的问题及时修复。
常用远程debug进行调试。
目前大部分的工程搭建都是spring boot，因为可以参考spring boot的远程调试：
spring_boot_cloud(3)JDWP远程调试详解以及调试spring-boot-loader的启动与加载全流程

代码评审(CR)

技术人员的核心输出是code，良好的编码不仅能让系统稳定，还能提高系统的维护性以及扩展性，可读性也是要保证的。
优雅的编码就像写诗一样，不仅会喜欢上这个过程，还会让人无法自拔，提高技术热情。
设计模式能组织代码优雅编排，同时满足扩展性和可读性。

参与人

  • 后端技术
  • 测试同学
    代码评审第一是为了发现当前编码存在的问题，第二是优雅编程。切记不要在CR的时候炫技装逼，有伤大雅，格局不够大。。。

测试用例评审

CR之后，技术同学会发起提测，申请测试资源，测试人员在之前的系分产出了一份测试用例，技术同学提测后，会对整个测试用例进行评审，因为中间在编码阶段技术会可能发现一些坑，对现有逻辑改造等，这些需要告知到测试，让测试回归一下。
另外开发同学在邮件提测的时候要声明：

  • 提测的业务需求范围
  • 提测的功能(可以部分功能提测)
  • 对那些业务范围需要回归一下
  • 后端代码分支、系分文档地址
  • 前端代码分支
  • 数据库坐标
  • 提测建议

冒烟测试

开发同学对自己开发的系统自己进行全局性的测试，测试粒度比较粗，主要功能是否实现，有无系统报错，数据是否正确等等。
这里尽量把问题都自我发现掉，最好不要让测试去发现，养成owner意识。

测试

测试阶段是质量同学的职责，根据之前评审的测试用例，对本次开发的需求范围进行测试，包括功能测试，压力测试等等。
测试同学测试验收完毕之后，会通知开发同学发布uat环境。
如果测试有问题，开发同学消灭bugs。

UAT

UAT是最接近生产环境的一个环境，数据库都是线上的数据库，程序是本次需求的程序，有些问题由于业务丰富度以及数据的丰富程度，不会在开发和测试环境暴露出来，到了uat环境就会暴露出来。
uat环境测试同学验证完毕之后，会通知开发同学进入线上环境，如果有问题，通知开发同学消灭bugs。

上线

这个是我们最终要交付的环境，我们都要敬畏的系统，所有同学的一致目标环境。
uat环境在测试同学验证完毕之后，会给开发同学发起上线通知，开发同学将代码发布到线上机器。
发布完毕，测试同学会对正式环境进行一波验收和回归。
这里在测试的时候可以使用三板斧里边的灰度方式，减少测试数据影响范围。
没问题皆大欢喜，有问题解决bug，如果是阻塞问题要是用三板斧里边的应急策略。
正常上线完毕之后，要对系统的运行情况能监控，有的是技术上的监控，比如内存、cpu、磁盘、网络、io等进行监控，出现技术故障的时候可以提供参考。
第二种就是对业务进行监控，我们在实现业务的时候，比如交易笔数、访问量、退款笔数、这些数据都是业务数据，我们在编码的时候需要按照日志规范打印这些日志，监控系统根据日志模板抓取app的日志，抠出来里边的业务数据，
比如退款笔数1小时达到了1500笔，而1000属于每日平均水平，这个时候就会触发监控系统的报警。