当我在做技术管理时我在做什么 - 4. 事 - 项目管理

上一节：3. 人 - 团队管理

事 - 项目管理

前面团队管理中说“团队是由一群追求一个或多个共同目标的人组成，通过一些规则约束在一起工作”，而项目管理则是为了让团队能在资源、人员限定的情况下，能按预期达成目标的手段和方法。

核心思想：有的放矢

项目管理的注意3点：

1. 目标清晰 - 要做什么、什么时候完成
2. 控制节奏 - 有了目标，就要管理好节奏，是一步到位还是小步快跑
3. 制定规范 - 无规矩不成方圆，现代化团队作战讲究统一、标准、量化

1. 目标清晰

在项目开发中，有3点需要清晰：

• 需求清晰 - 要做什么，做给谁用，做成什么样
• 任务清晰 - 安排什么人，在什么时候，具体做什么
• 节点清晰 - 要在什么时候做完

针对以上这3点我制定了以下文档、规范：

• 明确需求 - [Beansmile PRD文档规范]
• 明确任务 - [Beansmile Trello使用规范]
• 明确节点 - [Beansmile Agenda]

下面分别说下具体的做法。

[Beansmile PRD文档规范]

PRD（产品需求文档），相当于是产品的工程设计图纸，是给开发人员使用的，它的主要目的是陈述产品是什么，有什么功能，给什么人用，是什么样子。因此我认为一份PRD中应包含以下7部分：产品说明文档、产品信息结构图、产品功能结构图、逻辑流程图、原型图、功能点列表、设计文档，如「图4-1」，主要是说明每份文档是什么、有什么用、大概长什么样。

∆ 「图4-1」Beansmile PRD 文档规范

开发人员常说我不怕需求复杂也不怕需求太多，最怕的是我费心费力使用了优雅的设计模式、重构了代码、加了单元测试后PM对我说句“xx需求不要了”。所以如果作为产品PM，当整理过一份完整的PRD后，其实已经对产品的逻辑性、合理性做了一次梳理，再传达到开发团队手里时，能有效减少返工、无效需求的“折腾”。在这里要认清的一个事实就是：没有不变的需求！所以我们要做的只是尽量减少无效需求传导到开发手中，让开发的输出更有价值。

[Beansmile Trello使用规范]

Trello是个看板风格的协作工具，上手十分简单，但由于Trello本身十分松散灵活，100个团队有100种用法，因此为了方便统筹管理，我制定了一些使用流程并整理成规范文档[Beansmile Trello使用规范]（见「图4-2」），包含对list、label使用以及card生命周期的流转，让每个任务从需求转化为任务，到分配、评估、开发、部署、测试、上线，意图让每一步都清晰可预期，参与员之间协作配合清晰可见。
我们的项目管理布告版也会对客户开放，我们希望让客户从一开始就可以参与到日常开发流程中，可以了解项目的开发具体进度，也方便收集对需求任务的讨论、BUG反馈，以及给客户分配一些他们所要配合的工作（如一些基础服务帐号注册），让协作由内而外都可以贯通。为此我特意把这个文档写了英文版，以发放给国外合作的客户参阅以便了解我们是怎么使用Trello的。帮助客户培养成合理的协作习惯，这其实对我们进行高效项目管理也会更有利。

∆ 「图4-2」Beansmile Trello使用规范

[Beansmile Agenda]

一个项目开发，需要定一些时间节点，如什么时候正式立项，以便项目经理可以召集开发团队、召开立项会议；什么时候做交付演示，以便让QA工程师可以准备用户故事；什么时候正式上线，以便项目组技术组长可以准备交付文档；时候做营销推广以便运维人员可以做好服务器压力测试调整服务器配置……

前面在说如何解决团队协作清晰化中，提到了使用“团队日历共享计划 - [Beansmile Agenda]”（见「图3-16」），因此我要求项目经理给每个项目添加2种事件类型，一个是CHECKPOINT（检查点），一个是DEADLINE（最后期限）。CHECKPOINT是阶段性的时间节点，DEADLINE是当前版本最终的交付限期；一个开发版本内可以有多个CHECKPOINT，但只有一个DEADLINE。

做事应有始有终，我要求每个项目的每个大版本开发，都要定一个DEADLINE（最后期限），期限是构成目标的要素，没有期限则没有目标，没有目标何从谈管理。

CHECKPOINT则是一些阶段性的目标，到达一个DEADLINE之前，可以有多个CHECKPOINT；一个CHECKPOINT可以是任何关键事件，如阶段演示、交付演示，可安排阶段小结会议来讨论技术问题调整开发计划。

个人todo管理tips

在日常工作中，往往又有一些个人的代办事项，如某项技术调研、培训文档准备等不适合放入协作的任务列表的，也要管理起来，我现在的做法如下：

• 不需要协作的，放入 Wunderlist（可跨多终端）;
• 需要team范围知晓的、有明确日程安排的，放Agenda;
• 跟具体项目相关的，放在对应的项目trello board

2. 控制节奏

项目开发有如组织团队赛跑，需要控制好节奏，什么时候要留力调整速度，什么时候要加速冲刺，都应该有规划。

我根据这些年来的项目开发经验，整理了一份开发流程规范 [Beansmile开发流程规范]（见「图 17」），划分出几个阶段，每个阶段有主要参与的角色及其主要任务、有输入输出的结果，以便项目参与者明确自己角色的任务。

项目开发流程大纲：

- 选定项目管理框架/风格：Kanban + Scrum
- 选定项目管理工具： 
    - 默认：Trello + Scrum Extension
    - 其他：Redmine，Teambition，Worktile，Tower
- 角色安排：项目经理，产品经理，项目组长，开发，测试，运维
- 流程安排：
    1. 需求确定 - 确立需求可行性
    2. 项目评估 - 根据PRD评估开发量，确定项目周期
    3. 项目确立 - 项目组角色安排，项目周期、确定技术栈
    4. 开发    - 日常开发迭代
    5. 验收交付 - 交付项目，收集客户反馈
    6. 项目结束 - 进行项目汇总，总结开发收获、工作流程改进意见
- 会议安排：
    * 项目启动会议 - 成立开发组、通告项目背景、周期、技术栈
    * 项目阶段会议 - 阶段性小结，了解当前实现进度及出现的问题，调整下阶段的目标和做法
    * 项目总结会议 - 进行项目汇总

∆「图3-15」Beansmile开发流程规范

3. 制订规范

所谓无规矩不成方圆，在一个完整的开发流程中，每个环境牵扯到不少细节，团队会不时增补新人员，要形成统一的团队风格，少不了要制定一些规范文档，让团队每个成员可以达到一致的行事风格和输出，其他对接同事协作时则有规可循。特别的，一些输出文档我都给出了样例，这样负责输出文档的同事只需做“填空题”，关注输出内容本身即可。

以下是我制定的跟项目开发流程相关的系列文档例子：

• [Beansmile开发流程规范]（见「图 3-15」）
• [Beansmile PRD文档规范]（见「图 4-1」）
• [Beansmile Trello使用规范]（见「图 4-2」）
• [Beansmile Trello board template]
• [Beansmile项目周报规范文档]
• [Beansmile阶段小结会议规范]
• [Beansmile项目总结会议规范]（见「图 4-3」）
• [Beansmile项目总结报告规范]
• [Beansmile会议记录书写规范]

∆ 「图4-3」Beansmile项目总结会议规范

小结

如果有一些成熟完整的项目管理工具，可以辅助解决一些流程的规范、自动化，自然会省事不少，但工具很重要也只是辅助，我接触了解过一些开发团队，使用了一些复杂、强大的项目管理工具，然而管理层不去推行、监督，执行层不落实执行，工具再多再强大也是没有意义。因此在工具的使用上，适合自己团队的才是最好的，不用过于纠结在工具选择上。例如，我们使用Scrum管理框架，但也不是完全照搬Scrum全家桶，我们有每日站会、有Sprint 评审/回顾会议（我合并为“阶段小结会议”）、使用Backlog列表、任务评估使用Story Point、使用User Story做验收交付文档，没有Scrum Master（但有项目组长），根据团队的实际情况做了简化调整，可以落实执行的方案才是好方案。

总的来说，即使团队只有一个人时，做事也应该有章法，才能做到事多不乱，团队壮大了再由己及人，保持团队一致的调性。只有做到以上这些，我们才能从复杂多变的环境中做到“有的放矢”，从容应对变化。

关于项目管理有几本书推荐阅读：

• 《最后期限》 —— 被称为“中国第一本项目管理小说”，以一个虚构小说告知项目最重要的4个要素：找对人，分配正确的任务，激励，团队建设。
• 《人月神话》 —— 本书自第一版以来，畅销20余年不衰，是软件领域绝无仅有的必读经典
• 《Scrum权威指南》 —— 不到20页的文档里简明阐述了Scrum是什么、怎么进行Scrum，特别是在2016年版引入了“Scrum价值观”的概念，鼓励团队成员相互敬重，彼此成为更有能力和独立的人。
• 《技术管理之巅 : 如何从零打造高质效互联网技术团队？》 ——　1号店技术总监出品，推行扁平话、OKR目标管理、Scrum和Kanban的实践、自动化测试等，从技术团队组织架构、产品开发流程、制度规范建立、企业文化、大数据与技术管理创新、移动技术开发、实用应用架构设计等方面。

下一节：5. 物 - 技术管理