一切从项目Kick Off开始

一切从项目Kick Off开始

假如项目也终于要启动了。还记得那些突破重重阻 碍的需求吗？现在这些PK胜利的需求已在眼前，要决定“谁来做”、“何时做”了。

于是，我们也踏上了新的征程，这一切都从项目的Kick Off开始。

Kick Off是足球比赛 开球的意思，

现在被广泛用于开始做某事，

在项目里指的是项目的启动大会，而启动大 会及其准备工作（主要是团队组建和各种计划的确定），就是所谓立项阶段的工作内 容，

如图所示。

立项阶段的工作内容 帅哥美女，我们需要你 这么煽情的标题是告诉大家，这节要聊的是“团队组建”的话题。

因为有些项目经理并没有行 政上的管理权，也就意味着每次项目都需要去跟不同团队的主管、经理要人，所以其中 的艰辛也只有经历过才能体会。

我做过的一个项目，在需求阶段由于合作部门的 Product Owner 太忙，

所以屡次无法兑现承诺，被 逼无奈，我只好给他的主管写了一份邮件，抄送给了一些相关人员，争取资源。下面就 是当时的邮件与回复。

发送时间：2008年9月9日 11：53

主题：银行会项目，Product Owner的资源问题

重要性：高 Hi，××，不好意思，打不通你电话，这个事情比较急我还是发邮件说明一下。

银行会的项目时间很紧，现在我们碰到了一个问题，王××由于手头 A 产品的客户问 题很多并且都很紧急，占用了不少时间，导致能够做本项目的时间不足，他自己也很辛 苦。

现在已经产生了一个小问题：今天原本要做的测试用例评审，但是到现在还没法确定时间，希 望我们能一起防止问题扩大！希望能提高本项目工作的优先级，不然需求的延期很可能导致整个项目的延期，希望× ×可以支持，帮着协调一下，非常感谢。

发送时间：2008年9月9日 13：22

主题：答复：银行会项目，

PD的资源问题 已经安排××接手处理有关A产品的客户问题。王××会集中精力参与银行会项目。这样的方法快速有效，却似乎少了点人情味儿，个人不建议经常使用。好在有这么几点 可以降低团队组建的难度，一是我们启动的项目都是经过产品会议，大老板们认可的， 所以基本的资源有保证，但资源充足的情况就比较难得了；二是经常合作的都是相对固 定的人，沟通也比较顺畅，

所以说 项目组新人不太适合做项目经理，通常要和团队混到脸 熟以后再说，这可不单是个人能力问题。

在项目的组织结构中，项目经理并不是结构中的顶端，

我会组织一个**“项目督导委员 会**”，这很有必要，成员一般是项目成员的老板，甚至老板的老板，他们的任务也很简单 ——“背黑锅”和“买单”，因为权力越大，责任越大。

当项目因为种种原因出现重大变更的 时候，比如成本、时间、需求等，

我会向他们提出申请，获得批准后才执行变更，这也 是项目经理对自己和项目成员的保护。而在整个项目过程中，各种资源的提供也需要靠 他们，除了人，还有很实在的项目经费，有可能的话都尽量多要一点，最好有富余，

但 也要尽量省着用。整个项目期间，各种信息会随时知会督导委员会成员，但大多数情况 老板们无须有什么动作，所以他们也乐于参与。同时，对于项目成员来说，知道老板们 随时在监督项目，并且看得到自己的努力，所以也会做得格外卖力。通常在项目中，项目经理下面会有这样几种角色，如图所示。

如图典型的项目组织结构 产品经理（PD），负责这个项目的需求，他们中的某一个可能兼任项目经理；开发经理及其团队，负 责开发相关的任务，

其中开发经理需要负责开发的时间计划与任务分配，并全程掌控设 计、编码直至上线的过程；测试经理及其团队，负责测试相关的任务；UE（用户体验团 队），对于互联网、软件类产品来说，负责产品给用户的展现，比如交互效果、视觉效 果等；服务团队，负责产品帮助的编写，以及上线后的服务工作等；如果项目牵涉了其 他产品，我们还会设置各种职能的接口人以协同工作；更加复杂的情况，还会有其他角 色出现，

大家想想也可以理解，这个组织结构肯定会随着项目的进行不断微调，我们也无须在项 目一开始的时候就把人凑齐，一般来说，最关键的几个人到位了，就可以继续做下面的 事情。

他们通常是项目经理，需要统筹管理整个项目；

PD，开始写需求文档；

开发经 理，制定项目的开发计划。

别忘了最初的约定 约定，就是说好的，

谁在什么时间要做什么事情，在项目中，就是项目计划。

我们日常的项目，如果是基于网页的软件或手机应用的小版本升级，典型的项目周期在 两周到一个月；大一点项目，最多不超过三四个月。项目的几个重要环节大家都已经很 熟悉，所以这里最重要的一件事情就是：再次评估“工作量”并推算出“工期”。

还记得 BRD(需求文档） 里给各项需求做的工作量初评吗？

现在把这些信息再一次拿出来参考，因 为从产品会议结束到制定项目计划的日子中，PD们同时也在做PRD的细化，开发的 同学看到PRD时，每个功能点的工作量评估得已经更准确一些了。更重要的区别在于，初评工作量的时候是开发经理之类的角色统一评估的，未考虑谁来做，而现在是开发经 理根据团队里开发工程师的能力特点、擅长领域等因素，“因事择人”，把各项开发任务 分配给最合适的人（当然，要把高手调入项目的关键路径）。之后，每一位领到任务 的开发工程师自己评估工作量，为各自的任务买单，承诺最可能时间。之前的初评只是 一个参考，毕竟每个人对自己最熟悉。常用的方法是“三点估算法”，

即评估出最乐观的 工作量、

最悲观的工作量、

最可能的工作量，

然后按下面的公式估算出工作量：

“工作量 =（最乐观+最悲观+最可能）/3”

或“工作量 =（最乐观+最悲观+最可能×4）/6”

这里的工作量粒度也会比初评的时候细，至少精确到“1人天”，短期项目甚至是“1人小 时”，按照经验，我们的“1 人天”通常等价于 5～6“人小时”，

而并不是按照一天工作 8小 时计算，因为每个人都很难保证持续高效，并且不被其他事情打断。一个没人打搅的日 子，能有5个小时高效的工作，就已经很不错了。

之后，开发经理会把项目中各位工程师评估的工作量做汇总，推算出工期，

需要注意的 是，工作量只是说某人完成这件事需要多少时间，而工期是转化到日历上，说明这件事 从何时开始到何时可以结束。

这时候要考虑到各项任务的依赖关系，以及项目成员在这 段时间内的其他工作，并适当留出机动时间。

比如某个开发任务只需要工程师甲做“2人天”，

但它需要等工程师乙“5人天”的任务完成 后才能开始，

那么这两个任务就没法并行，工期也就是“7工作日”而不是“5工作日”；又 如开发团队每周五下午有周例会，项目中的成员必须要参加各种评审会议，还需要响应 随时可能发生的线上故障，排工期的时候都需要考虑到这些。

加班是业内普遍存在的现象，我觉得长期加班对团队士气打击很大，

所以一直让开发经 理、测试经理评估资源的时候留一点余量，甚至我在汇总项目计划的时候会再留一点， 但每次仍然还是有人加班。也许是习惯问题，大家不喜欢一下班就走，反而愿意上班时 不时看看新闻，晚上时不时做点工作的方式吧。反正不管给大家多少时间，任务总是在 最后一刻完成。

项目管理的新手总是认为可以通过加大资源投入来缩短项目时间，一般来说，如果各个 任务相对独立，则可以更多地并行，通过投入资源来缩短时间，

比如给一大片果园摘苹 果就可以采用此方式；

但如果任务互相依赖严重，就只能更多地串行，这时候加人也往 往无能为力，就像我之前提过的那个“十月怀胎”的例子，更坏的情况，是在软件项目 中，经常因为“延期、加人、老人带新人耽误时间、新人的产出质量不佳需要‘擦屁股’， 更加延期”，而进入恶性循环。

同样的，因为日常项目的资源瓶颈一般在开发阶段，所以其他计划会在开发计划初步确 定之后再与之配合生成，而对于项目经理来说，需要在更大的粒度上把开发计划、测试 计划、发布计划等合并成为项目计划，并确定项目的几个里程碑，也是监控点，

通常是 需求完成、编码完成、发布上线，在项目进行中，一定不要忘了这最初的约定！

如图 所示是一个魔方计划的粗略时间安排。

魔方计划的粗略时间安排 沟通从头开始 从项目开始直到结束，我们无时无刻不需要沟通，由沟通问题导致的项目不顺利也占了 极大比例，常见的情况有“干系人权责利不明确，出工不出力，心不在焉”；“对需求的理 解不一致总是到最后一刻才发现，不能防患于未然”，“遗漏了利益相关方，导致项目考 虑不周，不能发布”等，所以有必要一开始就约定好项目的沟通方式。

项目沟通方式各有不同：周期：以“日”或“周”为单位，主要取决于项目时间的长短及变化的频率。

渠道：会议、邮件等，需要在成本和效率之间取得平衡。

发起者：一般由项目经理、开发经理、测试经理主导相应的沟通。

参与者：发起者确定参与者，不要遗漏项目边缘的同事。 不管选择何种沟通方式，目的都是相同的——为了项目成功。一般来说，常做的项目，

通用的沟通方法有如下几种，供大家参考。

项目晨会：自项目进入开发阶段至发布日止，开发经理每日召集相关人员，主要是PD、 开发人员、测试人员参加。

**项目日报：**自Kick Off起至发布日止，项目经理每日发给项目的所有干系人，测试开始 后以测试日报为主。

评审会：相应PD召集需求评审；相应开发人员召集设计评审；相应测试人员召集TC[7] 评审；产品可用之后，项目经理尽快召集功能评审[8]，项目所有干系人参与评估。

**项目变更申请：**项目发生重大变更，项目经理与项目督导委员会沟通后确认变更。

**发布预告及公告：**项目经理在项目发布前两个工作日发预告给项目所有干系人，项目发 布成功后发公告给所有干系人。 不可或缺的誓师大会 上面说的团队组建、时间计划、沟通方法准备好以后，我们就可以举行誓师大会了，也 就是项目Kick Off会议。

**项目Kick Off会议，**我们简称KO，也许有的人会觉得很形式 化，但我认为很重要。我们自己全程参与项目，所以对各种信息都已经了解，但是还有 很多项目成员在KO之前很可能完全不知道这个项目是要做什么，而且KO的很大作用是 在心理上的，

就好比如图3-5所示，周瑜在战前发表“演讲”、敬天地鬼神，鼓舞士气。自 古以来，就有这样的KO。

电影《赤壁》里的KO KO通常只需要15分钟左右的时间，在这15分钟内，需要传达的信息有如下几点。

项目背景 我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听 众“痛下决心”为终极目标。

项目意义、目的与目标 我们去哪里？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众“面 带桃花”为终极目标。

需求、功能点概述 我们怎么去？说现在，具体用什么方法促使“过去”到“将来”的转变，以让听众“跃跃欲 试”为终极目标。

上述这三部曲其实和 BRD 里的项目背景、商业价值、需求描述大同小异，可以借用， 下面三点就是新鲜的了，也正是之前三节准备的内容。

项目组织架构 目的是让项目成员互相认识，明确有什么事应该找谁。

关键人物都要到场，比如很重要的督导委员会成员，他们可以高屋建瓴地给项目成员描 绘项目的重要性和伟大前景，说不定还会一时兴起追加一点团队建设费啥的，非常鼓舞 士气。

项目的早期，务必要让老板们多多参与，反复确认正确的方向，这时候做各种调 整的成本都比较低。

注意也不要遗漏工作不多的项目成员，比如小型项目的大多数活动是开发及其相关过 程，所以经常会忘记服务部门、配合部门的接口人。如果他们不知道相关信息的话，那 么即使项目本身顺利发布，之后也会带来很多配合上的问题，比如培训没有到位，客服 对新功能不熟悉等，从而导致客户投诉。

介绍成员的时候，气氛好的话可以让报到名字的人跟大家示意，我参与的项目中一般成 员互相都已经熟识，而这批人又特别爱演，所以经常会变成很欢快的一段个人秀。

项目计划 让所有人了解两个关键点：

第一，项目的时间点与里程碑；

第二，各个时段需要的资源，即每个人要在各个阶段做什么事情。

这点就不多说了，项目管理其实很深奥，我也只是个初学者，但我们也可以最简单地把 它理解成“计划与控制”，各种手段都是为这两点服务的。

沟通计划 重要，因为太多事情的不顺利都是沟通的问题，大家都做 不到一直主动、彻底地沟通，所以有个规矩来逼着做一些沟通的工作，并且在项目开始 的时候就约定好，可以免去很多麻烦。

最后提一点，凡是会议，就总会有人缺席，所以别忘了把会议记录发给所有干系人。任何时候都要心中有“树” 项目就要正式开始了，在这里我简单分享一下对项目管理的理解。感兴趣的同学可以阅 读项目管理的相关书籍，并根据项目的情况，灵活应用最合适的项目管理方法。

做项目的目标无非是多快好省：范围大、时间短、品质高、资源省。但又要马儿跑又想 马儿不吃草的事情是没有的，

有理智的老板们也都明白这一点，所以我们通常是在上述 4个要求中做平衡。上面所说的目标对比经典的项目 TRQ：

项目时间（Time）、

项目资源（Resource）、

项目质量（Quality），

几乎一样。一点小区别就是Q（质量），我觉得把Q解释 为“Quality+ Quantity”（品质+数量）更准确，而我所经历的项目，Q更多的是表达 Quantity（除非有特殊情况，“品质高”这点是不会舍弃的，所以可变的是项目范围）。综合一下，我们做项目的本质就是在保证品质的前提下，在时间要求、人财物花 费、项目范围三点上做平衡。

工作中能碰到的几乎都是常规的项目，公司或团队已经做过无数遍了，所以该有哪些 人、按照何种顺序做什么事情也相对清晰，之前说的团队组建、时间计划、沟通方法 等，都已经默认了这个前提。

但偶尔碰到一些全新的项目，我们该如何入手呢？

这里简 单介绍一下如何走最初的几步。

在了解背景、目的、目标等的前提下，明确任务之后，首先分解任务，即著名的 WBS[，要重视完整性，保证“滴水不漏”，比如工作环境准备，有时候需要单独的会 议室、额外的机器，各种福利的申请……一开始不考虑流程及资源限制，也不用把任务 排序。

有经验的项目可以利用原来用过的 WBS 模板，自顶而下地优化并套用，无经验 的项目可以自下而上，列出一个个最小的任务点，再组装起来。

WBS做完，看上去就是 倒过来生长的树，

在之后项目进行的过程中，任何时候都要心中有这棵“树”！如图所示就是我自己通过多次的项目，总结出的“产品模块级项目的WBS模板”，图中 只展开了一小部分，如果全部展开的话，有上百个大大小小的任务点。

图 产品模块级项目的WBS模板 我会把这些任务排序，几次实践之后就会发现绝大多数任务是有相对固定的执行顺序 的，渐渐地这也就成为经验了。

接下来，应对每个具体的项目，评估出每项任务的工作 量，安排人力资源去完成任务，把工作量转化为工期，也就得到了项目的时间计划。

随着做的项目越来越多，你应该一边做项目，一边形成自己的WBS模板，以后再遇到类 似项目的时候，不管规模大小，这些事情总是大同小异的，你就心中有“树”了。

我们都知道，实际工作中，其实任何项目都没有这么清晰的步骤，做完这个再做那个， 通常我们都是“边计划、边行动、边修改”，这是现实，是无奈，但不论怎样，我们终于 要甩开膀子干活了。