#rickgao

项目延期漫谈记录

延期问题所在

• 在联调前后端方案数据迁移还没确定下
  • 前端交付延迟了两个小时
• 前端同学对新项目的开发流程不熟悉，开发效率有点低
• 测试作为新人对整个测试流程不是很清楚
  • 不知道有自动流程，导致手动流程时间过长
  • 涉及到相关的配置项目不了解

个人思考

首先，问题一定不是出在测试同学身上的；

其次，去回顾一个项目的延期也不应该从对应的人身上去找原因。

虽然个人的原因在所难免，但是想要解决问题，人的因素应该是作为一个可控点来把握

流程问题

该需求的周期为

1. 产品在周五的需求评审提出需求
2. 通过后，对应的研发进行项目小组的评审
3. 前后端给定排期（过于乐观）
4. 测试开始介入
5. 联调（需求改动）
6. 测试（没符合预期）
7. 上线（延迟）

流程的问题点出现在

• 排期过于乐观
• 测试介入时间过晚
• 需求有些许变更

我认为以上三个问题的根本性在于：测试同学过晚介入

我认为，如果研发团队是

• 有测试同学
• 研发团队本身是没有写测试用例代码习惯的。

解决问题的方式应该是：这种团队中测试同学介入的时间应该和研发保持一致。

原因如下：测试用例应该在研发给定排期前确定

• 开发惯性
  • 因为一个团队有测试同学且没研发写测试用例代码习惯团队，在这种惯性下，研发同学的排期绝对是紧凑的，一个老需求还在测试过程中，新的需求就过来了，是不会有过多的时间去或自觉的进行项目细节拆分。
• 需求明确性
  • 前端、后端、产品三位同学对业务的理解水平是不一致的
  • 测试用例的确定，可以让测试、前端、后端及产品对需求目标更为明确

新人培训问题

现有新人培训的问题主要出现在

• 新人对部门整体认知不足
• 老人在带新人总会存在知识诅咒（即把一些前置知识觉得是理所当然，众所周知）

这会导致新人在成长中存在盲人摸象的问题

解决方式应该是，每个部门应该有一个整体概览的介绍

• 部门职责
• 相关系统
  • 每个系统的操作手册入口
• 工具使用
  • 不同的部门用不同的入口
• 如何解决问题

内部链接

如何解决问题

虽然已经有文档的沉淀，但是文档存在以下问题

• 延迟及误差
• 知识诅咒的问题，导致有些问题没有记录下来
• 文档在哪里看

解决思路有

• 创建一个部门群（产品，研发、测试）
• 把问题描述出来
• 群里@特定组leader
• leader制定人去负责

如何提问题是一门学问，比如：

• X-Y PROBLEM
• 《提问的智慧》中文版

业务文档沉淀问题

项目维度的统一入口

内部链接

敏捷开发问题

主要的方向在于：

• DevOps流程

很多很多

• 具体到项目就是（特指前端）

很多很多

工作积极性

积极性的问题，其实公司已经在通过OKR的制度在解决中。

如何把OKR的精髓落地才是问题的所在

团队模式

总感觉FT（Feature Team）是一个很好的方向。但是每个公司有每个公司的背景，暂且不表。