项目迭代源源不断，临时需求层层叠叠，开发者如何做好项目管理

背景

我之前尝试梳理了我们日常的项目迭代流程，标准的流程可以协助团队很好的完成工作的同时，还能帮助团队避免重要工作的遗漏。

虽然是"半路入门"项目管理，但是幸运的是我有一个"贤内助"------我的好友，我从好友那里学习到了许多经验，同时阅读了她还推荐的项目管理相关书籍：《微权力下的项目管理:如何在有责无权的状况下带领项目团队获得项目成功 (第2版)》（以下简称《微权力下的项目管理》）、《极简项目管理：让目标落地、把事办成并使成功可复制的方法论》（以下简称《极简项目管理》）、《PMBOK第六版》，收获颇丰。

纸上得来终觉浅，虽然断断续续的在团队内部兼职着项目管理的工作，但是我还是受到好友的鼓舞，去专门系统的学习了一下项目管理的知识，并在去年11月份的时候参加了 PMP (项目管理专业人员资质认证)，并以 3A 的成绩通过了考试。

学以致用，正如书中写的那样：

要找到适合自己的项目管理方法，只能靠自己不断地学习和实践来总结和提炼。一旦形成自己的套路，很多问题都将迎刃而解，而且自己终身受益。

我将过去在实际业务场景中，调整适配之后的项目管理方法，做了适当的调整和剪裁， 整理成一篇实践心得分享给开发者们。

应用从概念开始

开始分享怎么做之前，先分享几个和项目管理有关的概念。

项目

《PMBOK第六版》中给出的定义是：

项目是为创造独特的产品、服务或成果而进行的临时性工作。

项目具有临时性的特点，所以它有明确的起点和终点，这点比较重要，在我们实际工作中的体现之一为：项目迭代范围与排期。

项目管理

《PMBOK第六版》中给出的定义是：

项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理运用与整合特定项目所需的项目管理过程得以实现。

项目管理有两个关键作用：使组织能够有效且高效地开展项目和达成业务目标。

项目经理

《PMBOK第六版》中给出的定义是：

项目经理是由执行组织委派，领导团队实现项目目标的个人。

项目经理不同于职能经理，职能经理专注于对某个职能领域或业务部门的管理监督。

开发者显然也不是项目经理，所以在做项目管理中，也需灵活变通，通常我对自己的定位是：项目管理流程及规范的提倡者和践行者。

变更管理流程

完整的变更管理流程

项目管理中，实施整体变更控制贯穿项目始终，且项目经理对此承担最终责任。

在项目收尾之前，几乎所有的变更都要走变更流程。完整的变更管理流程如下图：

而我们实际工作中的流程与上面的流程略有不同，所以我整理了另外一个流程：临时需求（含缺陷）的处理流程。该流程更贴合实际工作中的场景。

临时需求（含缺陷）的处理流程

其中日常维护中，对于临时需求（包含缺陷）的处理也是有标准的可执行的流程。

临时需求的处理流程，在实际开发中也很重要，因为这种情况一般会阻塞当前的开发。所以一个标准的流程，可以帮助开发者省去很多时间。

尤其是其中的系统支持性的校验和延迟处理，可以侧面帮助开发者缓解阻塞问题。

流程中的几个注意事项也起到了重要作用，值得重点关注一下：

• 部分提出的新的需求，如果明确系统不支持的，可以直接给出关闭需求的结论；
• 重复判断的任务池是待处理任务池；
• 后续版本一般是最近一期的迭代版本；
• 如果是产研自行发现的优化需求，自动进入验证可行性节点。

项目管理经验之谈

正式进行经验分享之前，我们先来思考几个问题：

• 如何能够花费较少的成本去实现既定目标？
• 开发频繁被打断，怎么保障实现既定的开发目标？
• 需求插队，打乱排期并导致研发堵塞？

许多开发者应该对上述问题并不陌生，而我自己在日常工作中也时不时的被打断开发，于是我尝试摸索解决问题的方案，经过不断的优化、完善，形成了下面的解决方案。

"小步快跑"的任务池

对于临时插入的需求，可能会导致研发过程减慢，对此的策略是 ：将需求放入任务池，并区分需求的类型，然后进入需求处理流程，得到最终结果之后，更新任务池最新状态。

研发会自驱的拉动任务池的循环。

任务池类型

主要包括两大类：待解决任务池和待支持任务池。

任务池循环

任务池循环主要有5个阶段：

第一阶段：接收任务

• 问题群中的问题或需求
• 产研自主发现的需求

第二阶段：任务分类

• 一般根据是否阻塞性问题进行分类，具体情况可灵活应对

第三阶段：任务更新

• 任务池分为待处理和已处理
• 状态包括待处理、已上线(上线时间)、不出来
• 新接收任务会进入待处理任务池

第四阶段：处理流程

• 处理流程见前面的"临时需求（含缺陷）的流程"
• 任务处理结果包括三种：待处理(后续版本)、已上线、不处理

第五阶段：任务池更新

• 根据当前任务的处理结果，更新任务池中的状态。
• 处理完成移至已处理任务池

使用第一性原理思维

对于第一性原理思维的运用，源自我之前读到的一篇文章（去年读的文章，忘记是哪篇了，回头找到了我补充在文章底部），读完之后恍然大悟，原来可以：借助第一性原理，寻找规律，从而找到解决问题的最佳方案。

什么是第一性原理

第一性原理指的是，将问题拆分成最基本的事实或规律，根据这些已知信息，不断推演和计算，从而找到解决问题最优路径的方法。

该思维比较出名的应用例子有：

• 埃隆·马斯克降低火箭发射成本的故事。将火箭发射成本进行细分，发展火箭可重复使用发射技术，简化设计和改进工艺以降低火箭制造成本
• 亨利·福特降低汽车制造成本的故事。将汽车拆解为最基本的部件，利用装配线和流水线工人批量制造汽车

用第一性原理思维去思考

想要运用第一性原理思维去思考问题的解决方案，可以从三个关键点出发：

• 归零：重头算，回归最基本的概念，找寻最基本的基石。
• 解构：用物理学思维分解现象，层层拨开，找到改变的突破点。
• 重构：重新建造一条新的赛道，新的模式，新的方法把原来的给替代掉。

案例：电商平台

我们这边目前一个比较严峻的问题是，大部分项目是需要跟第三方进行配合，所以大多数情况下，我们的排期也受第三方的影响，尤其是功能（如接口对接）确认、测试和上线三个时间节点上。时间周期会受第三方影响产生波动，时间成本也会受影响。

图1-1：多项目任务跟进图

上图中，目前8月的绝大多数项目，都阻塞在功能确认的节点。

在这类情况下，我们需要思考的问题是：如何花费较少的成本去实现既定目标。

从这个问题出发，进行拆解：

• 归零：传统的开发模式是等到需求完全确定之后才进入技术设计，但是这次等待时间较长，所以这次区别于传统开发模式，采用新的开发流程。
• 解构：成本的构成主要是人力成本和时间成本。人力成本相对固定，哪个阶段时间成本较高，就在该阶段进行改进。
• 重构：重新组合开发流程，在等待需求完善和已知需求开发、设计双线下，工作并行，缩短项目上线时间。

建构和重构这两个阶段，我们做了以下三件事。

第一：提前进入准备阶段

在于第三方确定的过程中，我们已经进入了准备阶段，包括编码及数据枚举 、不同流程的梳理及绘制流程图 、待确认清单整理等。

1、如下为本期的支付优惠方式的枚举

1-优惠配置-普通
2-优惠配置-拼团
3-尊享优惠
4-企业优惠

2、如下为待确认清单整理

• 可选的支付优惠方式是多选还是单选；
• 如何区分会员用户和尊享用户；
• 用户是否可能即使会员用户又是企业用户；
• 多重用户角色怎么做支付优惠方式的选择。

在需求讨论的时候，已经确认了70%左右的项目内容。缩减了需求评审中的对于不确定或没全部拉通点的讨论时间。

第二：提前进入设计阶段

等待产品原型的过程中，我们已经着手进行功能设计，根据之前需求讨论中确定的部分，尤其是重难点功能、实现方案、方案伪代码。

这样，在产品原型更新之后，可能就剩余了部分需要设计的功能，节约了部分的等待时间。

1、如下为支付优惠方式的伪代码

/**
   * 通过不同订单和用户类型的优惠方式
   * @param {Object} param 订单和用户信息
   * @return {Array} 返回的支付优惠方式
   */
getEmployerPayTypeListByData(param) {
  const { orderType, userType, configPayDiscountMap } = param;
  let payDiscountTypeList = configPayDiscountMap[orderType][userType];
  const customizedMap = {
    exclusive: 3, // 3-尊享优惠
    enterprise:4, // 3-企业优惠
  }
  // 如果用户类型是尊享用户或企业用户 优惠方式需要新增一种
  if (userType === 'exclusive' || userType === 'enterprise') {
    const customizedDiscountTyp = customizedMap[userType];
    payDiscountTypeList.push(customizedDiscountTyp)

  }
  return payDiscountTypeList;
}

---

第三：提前进入开发阶段

当设计评审通过之后，我们就进入了开发阶段。

等到全部功能确认之后，进行开发排期的时候，由于在前面阶段中已做了确定部分的开发，排期自然会比没有提前准备的时间短一些。

这样一来，项目可以比没有做以上准备的情况早一些实现上线，进而达到了缩短开发周期的目的。

总结

文章结尾对项目管理做下总结：

• 项目管理是有必要的，可以帮助提高团队成员的工作效率，从而使项目能够更快、更好地实现。
• 项目管理的前提是团队成员明确各自的责任，所有工作已区分和明晰并已形成流程规范。
• 明确了项目管理主流程及每个节点事项、额外流程以及临时需求（含缺陷）的处理流程。
• 用第一性原来思维思考问题，帮助完成"花费较少的成本去实现既定目标" 的目标 。
• 引入"小步快跑"的任务池，研发自驱的拉动任务池的循环，疏通研发阻塞，减少被打断风险，保障项目目标的实现。

文末留一个关于多项目管理协同 的思考，未来会拓展关于多项目管理协同的流程规范。

新年伊始，万象更新，祝福全体开发者，新年新气象，技术越来越精湛，代码越写越畅快。