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

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

架构设计

对于比较复杂的项目，一般会进行 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 个维度，详细讲解了研发阶段的整体流程，这套开发模式，基本都是复用大厂的流程，只是在相关环节做了简化。

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

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