楼仔

V2

2023/02/26阅读:45主题:橙心

项目管理的研发阶段

项目需求评审完毕之后,研发阶段正式开启,在上一篇项目管理流程中,已经介绍过研发阶段的整体流程,这篇文章会详细说明研发阶段的一些细节,以及我们合作过程中,遇到的一些问题。

整个团队合作的模式,其实也是参考大厂的标准。

架构设计

对于比较复杂的项目,一般会进行 2 轮技术方案设计,第一轮为架构设计,第二个为详细方案设计。

架构设计,也可以理解为项目的整体框架设计,包括项目用到的技术栈、涉及的功能模块等。

这个是我们最初版的架构设计图,非常简陋,当然思路还是比较清晰的,最终的方案设计详见大厂篇的《技术派整体架构方案设计全过程》。

架构设计,或者说的概要设计,可以非常简单,主要是保证你的项目,在大的方向上是没问题的。

其实有很多同学,去开发一个稍微复杂的功能模块时,就直接去扣细节,这个是不对的,你应该先有一个整体思路,然后和内部同学沟通确认后,再去落地详细的设计,那么这个沟通确认的环节,就可以理解为你整体设计的环节。

技术方案设计

架构设计完毕后,需要进行详细的技术方案设计,包括库表设计、每个模块的交互流程&实现细节、底层复用逻辑等,整套技术方案,主要围绕下面这幅图展开。

比如注册登录的实现细节和交互流程,需要尽可能详细,因为在大厂,这些核心逻辑都需要进行技术方案评审。

包括库表的 DB 设计,也是技术方案中非常重要的环节,我们在设计 DB 时,前后讨论了 2-3 轮,最终才确定 DB 的字段,以及各 DB 之间的交互逻辑。

比如这个是用户表:

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `third_account_id` varchar(128) NOT NULL DEFAULT '' COMMENT '第三方用户ID',
  `user_name` varchar(64) NOT NULL DEFAULT '' COMMENT '用户名',
  `password` varchar(128) NOT NULL DEFAULT '' COMMENT '密码',
  `login_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '登录方式: 0-微信登录,1-账号密码登录',
  `deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间',
  PRIMARY KEY (`id`),
  KEY `key_third_account_id` (`third_account_id`),
  KEY `key_user_name` (`user_name`),
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='用户登录表';

有了完整的技术方案,再经过 1-2 轮的方案评审,就不会有大的问题,很多项目后面出问题,或者埋坑,就是因为前期的技术方案做得不到位,技术派详细的技术方案见大厂篇的《技术方案详细设计》。

项目排期

基于我之前的项目经验,我谈一下大厂的项目排期的一些经验:

  1. 项目排期每天不要排满,建议预留 20% buffer;
  2. 如果项目时间紧,可以采用分批提测的方式;
  3. 排期要有里程碑,开发、联调、提测、上线、验收等;
  4. 项目排期不能仅到上线阶段,还需包括线上灰度和项目验收;
  5. 前端排期依赖UI设计。

下面是我之前带项目的排期要求:

以上只是作为参考,我们没有这么严格的要求,因为大家都是业余时间开发,所以不会去太卡节奏,我先贴一下我们排期的任务表。

项目排期,需要明确任务、责任人、优先级、完成时间,通过这个去保证项目的正常推进。

作为项目负责人,你需要时刻去跟进项目的进度,把控项目的风险,并且知道整个项目哪里是卡点,需要你去协调和沟通。

根据我这么多年带项目的经验,the 好的项目排期,就是一个项目进度控制的关键灵魂,排的太紧,你忙不过来,排得太松,领导大概率会给你拍回来,排得不紧不松,同时还能预留一些 buffer,并能预判一些风险,这个每几年的工作经验,是很难控制好的。

每日站会

为什么要提这个呢,因为有的同学平时闷声不响,最后给你憋大招。所以你需要知道大家每天的工作进度、问题和风险,方便你推动和协调解决,甚至会对项目节奏临时调整。

我先说一下大厂的玩法,站会怎么开,这个也有讲究,10-15分钟最佳,每位同学都要参与:

  1. 昨天做了什么?
  2. 今天打算做什么?
  3. 遇到什么问题?

注意一点,站会时间早上或晚上最佳,方式比较灵活,前期可以每周2-3次,后期就每天都开。

不过对于我们团队,肯定是没有时间每天都去开早会的,这个仅给大家一个参考。

每周例会

大厂的项目周会,主要是一起过本周的整体进度,即只过方向和节奏,不过细节。

不过我们团队,由于不开每日早会,所以我们也只能在周会去过项目进度的问题。

我们周会的时长是 1 小时,每周都开,基本都是定在周五晚上 8:00-9:00,如果问题比较多,也可能会开到晚上 10:00,由于我们很多问题细节,都在平时已经沟通和消化,周会主要根据排期,说一下每个人本周的工作,遇到的问题,最后再自由讨论。

问题反馈

这个其实应该放在测试环节,但是单拎出来又太少,就还是放在研发阶段来讲。

在项目测试过程中,会遇遇到很多问题,最开始时,我们是采用在 github 提 issue 的方式。

对于这种方式,会有一个非常致命的问题。

由于大家比较忙,白天上班,只有晚上才有时间去解决问题,碰到加班,可能好几天就没时间跟进,特别是当问题太多时,大家不知道优先级,大家改的问题优先级其实比较低,重要的卡点问题会卡很长时间,阻塞其它同学的测试。

然后这个也不能汇总和归档,也不能进行分析,比如我想知道提给小灰的 bug 数量有多少,分配的是否均匀,用这种方式,完全没法整。

后来我们跑了 2 周,完全跑不下去了,进度卡着不能动,有的同学很闲,有的同学很忙,最后还是换成表格的方式。

每一条 bug 需要包括模块、具体工作事项、类型、优先级、开始时间、完成时间、完成情况、提出人、负责人、备注,其中备注中一般会放问题哦截图。

项目前后修复了 200 多个 bug,每隔一段时间,我们会把修复完的 bug 归档,然后新开一个表格,重新记录问题。

写在最后

本文从架构设计、技术方案设计、项目排期、每日站会、每周例会、问题反馈这 6 个维度,详细讲解了研发阶段的整体流程,这套开发模式,基本都是复用大厂的流程,只是在相关环节做了简化。

作为一个研发,我们不能只关注编码,当你成为你一个项目管理者,或者团队管理者,这方面的软实力是非常重要的。

最后也希望,我的这篇文章,能给个大家一些启发和借鉴。

分类:

后端

标签:

后端

作者介绍

楼仔
V2