技术项目管理

如何做好一个技术项目的管理？

目标分析

• 对于任何事情要有清晰的目标才能精确把握。
• 目标：如期交付有质量保障的项目产出。
  • 关键词：如期交付(守时守信)、质量保障(保质保量)、项目产出(完整结果)。当然还有最重要的因素：人 + 过程 。
  • 既要结果，又要过程，当然，还要这里面人舒服 。
• 总结：
  • 1. 项目目标：如期交付(守时守信)、质量保障(保质保量)、项目产出(完整结果)；
  • 2. 人员目标：舒服、有成就、有成长；
  • 3. 过程目标：风险控制、信息同步。

项目启动

预先定义好项目目标、衡量结果（ROI）、人是尤为重要的。

• 1. 目标：你为何要做这件事？
• 2. 目标：你的目标有没有足够明确？有没有清晰的大图？
• 3. 目标：做这件事的意义是什么？
• 4. 结果：你有没想清楚个目标的关键因素，核心指标是什么？
• 5. 结果：有没有附加的影响和因素？是好的还是坏的？
• 6. 人：你自己是否足够清晰能够完成项目的重要因素？尤其是大的项目top-down的思考。
• 7. 人：你能为大家提供什么来确保顺利的分工配合？越俎代庖阻、撒手不管都是不可取的。
• 8. 人：这个项目需要哪些人？哪些角色？他们核心关键是哪些？
• 9. 人：参与这个项目的同学能得到什么？失去什么？共赢吗？
• 10.人：参与的同学的成就感在哪里？

需求评审

这里是需求细化明确重要节点。作为一个项目PM你必须要做到小需求了如指掌、大需求合理拆分。

• 遇到问题怎么办，列出常见问题
  • 1. 需求(描述或意义)不明确、理解不一致。 解：不要牵强、不要害羞。描述不清楚的讲(写)清楚；意义不清楚的增加解释。PM都要搞清楚搞明白，这样你才能够在中后期答疑解惑环节，节约信息同步成本。实在不行就回到最开始的目标上去：意义在哪里？
  • 2. 关键人员没拉到到位。解：这个其实我们经常会遇到，原因也有很多。事前列好人员信息版(可以放心里)是一个很好的习惯，我个人习惯用钉钉群公告+云雀 note 页。事中则需要补救和充分沟通了，还好我们的同学都很能相互理解。
  • 3. 需求范围膨胀。解：这个问题也是我们项目中常见导致项目最终崩溃的原因。所以你是需要提早接入需求的，最起码要比评审早。确认好项目的人员投入数量、投入度，确认好本次重要目标和次要目标。适当的时候要做需求拆解，不要做超量(加班也可能搞不定)的计划。不要做好好先生。你要清楚你的职责是如期交付有质量保障的完整结果。
• 几个重要的点
  • 1. 需求评审要提前做好信息充分公开有会议邀请，关键人员要拉到位。
  • 2. 评审后关键参与人明确自身工作目标和职责。
  • 3. 重要信息、问题和困难收集。同时做好信息公开同步。
  • 4. 重大设计、困难单列单独跟进。

项目排期

• 常见问题
  • 排期时间过长。 解：拆分、加人、分阶段。建议最小工作单元评估最好不要超过2人日 。
  • 其他项目排期冲突。解：分析是产品节奏冲突还是人员(资源)冲突，确认好各自目标再共同协商总体排期。
  • 重要阶段未给足充分时间，如设计阶段、系统联调、冒烟、测试、内测等经常忽略项。解：提前协商沟通好协调。

设计+测试评审

规范

• 1. 重要流程有图、有文字、有用例覆盖。
• 2. 重要设计方案、测试方案要提前沟通讨论评估风险和影响。
• 3. 需要考虑资金、安全、性能、风险的，单列 todolist + checklist。
• 4. 重要设计影响对外同步。

对于技术型的PM，最好满足：

• 1.项目中的核心设计者；
• 2.业务 owner 或核心，其中一项。

研发过程

因为变化是家常便饭，这里有个原则是信息跟踪和同步评估要充分

• 1. 项目空间任务列表(aone有批量功能)
• 2. 排期进度表(云雀)
• 3. 需求变更记实录表(云雀)
• 4. 人员负责表(云雀)
• 5. 风险跟踪列表(云雀或aone)
• 6. 过程进度日报：模块进度条百分比、当日工作主要内容、风险同步与处理。
• 7. 重要逻辑影响对外同步(如表逻辑、业务逻辑变更的，需同步对应使用方)。

冒烟+联调+提测

• 在联调阶段作为PM最好能设计出几个经典业务场景作为联调目标，对项目的整体质量做提早把控 。

• 重要项目建议：

  • 1. 全量(70%+)含凭证冒烟。
  • 2. 流程覆盖设计+测试执行(PM)
  • 3. 闭关联调+分模块分阶段联调半日目标进度。
  • 4. 独立的项目联调环境准备。
  • 5. 关键链路的日志标要求。

• 无论是作为核心开发还是纯PM，此阶段都需要主动去检查项目的研发交付程度。包含但不限于主业务流程、特殊分支逻辑等 。

测试

• 测试 bug 要督促做到日清，不能日清的需要有原因跟踪。
• 本阶段一般也是codereview集中阶段。
• PM应直接或间接的对于关键链路设计、流程日志记录、编码规范要着重把关。
• 同时产品发布+回滚方案在本阶段要做准备了。
• 注意事项
  • 0. 安排处理好项目测试环境，确保稳定性。
  • 1. 安排各系统CR节奏，并跟踪反馈。
  • 2. 安排发布计划讨论和准备。制定并总结初步发布执行计划(单点对应明确责任人)。
  • 3. 安排讨论确定版本限制兼容方案。
  • 4. 安排准备线上功能开关和灰度方案。
  • 5. 重要项目要有发布预演。
  • 6. 预发和线上不隔离的系统要注意单独考虑预评估发测试风险。有必要的给出操作步骤。

产品验收

• 意义
  • 1. 项目产品信心建立。
  • 2. 项目产品功能体验review。
• 一般性准备
  • 1. 产品验收checklist；
  • 2. 验收环境准备；
  • 3. 验收数据准备；
  • 4. 验收问题列表；
  • 5. 变更列表(云雀或aone)，此时的改动要特别注意变更风险和范围评估；
  • 6. 数据、BI、埋点验收准备；
  • 7. 产品验收数据收集(可选)。

项目发布

注意事项

• 1. 提醒系统发布前中后检查，建立通知机制（发布群）。
• 2. 系统发布要注意API变更、数据及表结构变更等对线上逻辑的影响评估。(一般预发布已经做了)
• 3. 发布后的线上检查，特别注意检查本身会否影响线上功能和数据。
• 4. 最好做到发布功能有开关+线上白名单。
• 5. 复杂项目的发布一般会选在在晚上，但同时要做好分班跟进计划。
• 6. 发布完、线上验证完毕后，项目发布邮件及通知同步要到位。