从项目管理的角度

从管理日勺角度来讲，当然是尽量的赶上计划E向公布时间，或者尽量快的完毕

项目。不过由于多方面原因的影响，项目管理是一种欲速则不达日勺过程。假如这

个计划公布日期早于这个实际合剪公布日期，那你越往这个不合理的日期赶，工

期内积累的问题就越多导致后期收尾的时候爆发，成果反而也许连合剪公布日期

都赶不上。借用《让子弹飞》里面的一句话，步子迈得太大了，轻易扯着蛋。给

项目组定一种个合理的看得见的小目的，步步为营，一步一步朝着看得见的并且

合理的每一种小目的前行，每一种小目的的积累，才能最终走向项目的成功。

因此务实的项目经理应当认识到如下几点：

1.项目组可以以快节奏的步伐在前行，不过项目经理自身一定要清晰日勺认

识到，我们明面上是在赶那个计划公布日期，不过项目组实际的目H勺应当是那个

客观存在的合剪公布时间。

2.伴随项目日勺进行，那个客观存在的合剪公布时间会逐渐明朗。它与计划

公布时间的差异也逐渐显示出来。此时有些项目经理往往会通过加资源日勺措施来

尝试缩短这个合剪公布时间。不过真实日勺状况是，除非你前期日勺资源配置不合理,

否则在这种状况下加资源，对项目协助不大。

3.项目经理必须有某些坚持。领导或者业务部门常常会有某些压力下来，

规定赶那个计划公布时间，同步规定你想尽任何潸施去赶上这个计划公布时间。

而现实状况下，假如你可以调整某些需求的范I韦I,你还是有戏。否则，你要嘛此

时报喜，后期报忧，要嘛此时报忧，后期不忧。掩盖问题往往可以让人开心，不

过不代表问题不存在。

4.项目经理能做好的I其实就5点:

a.控制好了需求；

b.及早的发现问题，汇报出来并处理；

c.不出现资源空闲的状态；

d.运用好每个资源去做擅长的事，迅速有效的推进多种任务；

c.不挥霍资源去做某些对项目目日勺总体没有协助的工作，或者某些后期会

推翻的需求。

基于这样的认识下，本文有

自身组员整组

项目责任感一定要分成每一个

小迭代

项目经理是打杂的

不做一半的功能

控制需求

不让细节影响你的

风险管控

目标

外部依赖最不可控

正确的里程碑要点

必要的时候，任务

要步步紧跟

自我管理

做当前，看后续

#项目责任感

项目经理应当有这个的责任感，你要为这个项目的任何一件事情负责，由于

这个事情会影响到整个项目H勺工期，而你为整个工期负责。

一种例子，我发现目前H勺项目有一种紧急的问题需要项目组外H勺人帮忙处理。

于是我把邮件发出去，告知Wendy赶紧处理这件事情。

儿天过去了，Wendy还没有处理。我想，我已经把问题说出去了，接下去就

是Wendy的事情。

Tracy是个喜欢做测试日勺人，不过她不喜欢跟项目组外的人沟通，尤其是还

要到其他部门去找人问人。这些对她来说就是杂事，并且她对其他部门日勺人也不

熟，一种一种问明显效率不高。

你可以自己去帮她找到需要口勺信息，也可以找一种对这方面比较熟口勺人去处

理，不过你绝对不能让她自己去做。

“为何我口勺手下不能处理这样简朴口勺问题？假如连这种事情都要我来帮忙的

话，那我这个项目经理做来干什么？她当项目经理得了。“这种想法千万是不可

取的。

你当这个项目经理H勺目日勺并不是管人，指使这人做什么那人做什么。你H勺目

日勺只是把项目迅速推进完毕。

#控制需求

在所有原因当中，需求对项目的影响力，至少占50%以上。可以控制好需求，

项目就成功了二分之一。控制需求，有如下几点：

1.必须有人可以当好产品经理这个角色

一种项目组当中，其实人人都可以影响需求。不过管理需求H勺，是产品经理

这个岗位。假如你H勺项目组当中已经有一种很好的产品经理，恭喜你，项目经理

可以轻松诸多。不过世间事不会如此幸运，由于现实生活中，并不是所有的产品

经理都这样棒。作为一种对项目完毕负责的项目经理，当你们组没有一种好日勺产

品经理日勺时候，你必须意识到，你至少要饰演好二分之一日勺产品经理，除非你自

身对项目的完毕也没什么责任感。

2.管理需求日勺人要平衡工期和功能友好程度

需求其实有两个极端，一种是尽善尽美，尽量的让功能更友好，顾客体验更

佳；一种是尽早交付，一切改善性的需求都可以牺牲。

只满足前者，项目工期也许会不停的迟延，由于诸多功能的工作量其实是在

细节的优化，而不是重要流程日勺完毕。只满足后者，很也许会出现一种让顾客很

不满意日勺产品。

一种有经验或者产品意识很好的产品经理，可以很好的平衡好这两点。假如

产品经理不能平衡好，那只好依赖项目经理来平衡。这点，假如产品经理或项目

经理不是天才的话，只能通过经验来学习。

例如我们在做一种注册日勺页面，里面有个都市的输入框。都市日勺输入框可以

做得很友好。假如要项目尽早完毕，那么这个输入框我们只要让顾客自己输入就

行。一种比很好的设计就是两个下拉环框，一种选择省份，然后再选择都市。不

过一种更好的设计是让顾客既可以选择，也可以自由的在这个输入框里面输入拼

音首字母，中文，然后系统就会自己显示相匹配的都市让顾客选择。后两者口勺改

善肯定会花时间，不过假如这两种改善都不做，让顾客只是自由输入的话，后期

维护的时候就会出现顾客输入不原则的都市数据，假如我们需要顾客的都市数据

做某些其他功能，就会有错误数据的风险。

3.懂得对不重要日勺需求说不

假如你不能平衡好工期跟功能改善的话，有一点你一定要意识好，就是你一

定要懂得对不重要的需求说不。这很简朴，你对•种需求说不，只要这个需求不

是一种会导致其他功能依赖口勺关键需求，就算这个需求背面发现必须实现，你可

以补上，总体工作量并没有增长。不过假如你花资源去完毕了这个需求，背面却

发现这个需求是不重要的或者可以简化的J,那你已经挥霍了某些工作量。两者的

代价相比，明显前者的代价比较小。

4.理好需求优先级

需求的优先级应当满足如下几点：

a.确定不变日勺需求应当先完毕，假如项目组去完毕了某些功能，成果背面

发现需求要改，那前期日勺某些工作量己经挥霍了。

b.被其他需求依赖的）需求应当先完毕，只有这样，才能不挡住依赖它的需

求的开发。

例如登录功能，诸多登录后口勺页面都需要目前登录的顾客信息。

c.主流程，或者关键需求应当先完毕，改善性的需求应当后完毕。

例如信息列表页面，诸多功能需要顾客在信息列表里面选择要操作日勺记录。

因此信息列表是关键需求。而在信息列表页里面一种列显示格式日勺美化，这属于

改善性需求。

#风险管控

风险管控是项目经理一种非常重要的技能。一•种好H勺项目经理应当尽量在初

期把所有的风险都列出来，一种一种处理。一种流畅日勺项目，从前期到后期风险

点应当是倒三角形的，就是前期风险诸多，后期风险越来越少。而项目管理不畅

的，则是一种正三角形，上面风险少，到后期风险就多了。

项目经理应当尽量的找出所有的风险点。假设有一种点，你不确定他是不是

有风险口勺，那虽然我们把初期把它当作一种风险点重视起来，带来口勺代价也远远

不大于在后期等它爆发出来的时候再处理。

我们现实中就有一种很适合H勺例子。我们有一种功能是SSO,让合作方去调

用我们H勺接口实现免登录直接从他们日勺站点跳转到我们的站点继续使用。由于关

系到第三方，因此我们前期就有些紧张届时候这一块会不会出现什么东西不可控。

不过大家也就是想想而己，没有太在意。

在项目后期的时候，需要跟第三方站点联调，通过他们H勺站点来测试我们的

SSO接口和接下去的流程是不是可用的。成果这时候发现，由于第三方安全管控

很严格，外部人员无法访问他们的站点。于是我们的测试工作就停滞在那边。背

面弄得鸡飞狗跳，两个企业的IT以及架构组的人讨论来讨论去看这个问题怎么

处理。

公布时间最终还是由于这一点迟延了。

#外部依赖最不可控

风险管控尚有个要点要记住，项目组能处理的问题，算是小问题。需要项目

组外的人员处理日勺，才是大问题。由于项目组外日勺人员不受你调配，他应承你的

时间不一定是你满意的时间；虽然是你满意口勺时间，也不一定真的就能保证在那

个时间完毕；就算真的完毕了，也不一定就到达你想要的效果。

#必要的时候，任务要步步紧跟

项目经理并不是把任务简朴分出去就可以不管的。假如你的开发人员不是很

有经验，或者技术实力很强，思维很缜密，那你应当紧紧的跟进你分发出去日勺任

务。

1.你应当常常去看一下他们日勺任务开发到了什么程度，可以的话，让他运

行给你看一下。

2.问一下有无什么问题，有什么可以协助他日勺。由于很有也许他就有个问

题在纠结，而其实你由于经验或者理解更多H勺背景，很简朴就为他指出简朴H勺处

理方案。

3.你在检查日勺过程当中，也会有也许发现某些他也许还没发现的问题，或

者跟这个任务有关联的问题。

任务的完毕进度和完毕质量，是影响项目进展的一种重要原因。项目经理的

一种重要职能，就是协助每个任务的迅速推进。

#做目前，看后续

当我们把目前的做的迭代的需求，流程，依赖以及其他的疑问理清晰，让项

目组可以顺利推进的时候，项目经理不应当再专注在目前的迭代，而是要开始想

整顿下一种迭代的事情，让大家在完毕目前迭代的时候，不需要暂停在那边，去

等待梳理卜.一种迭代的问题。

举一种例子，目前的迭代我们在做顾客登录的功能，做完这个迭代，接下去

我们就要做登录完的首页展示。开发组在做登录向时候，项目经理也跟着在那边

捣腾登录的细节。等下一种迭代开始I肉时候，项目组才发现首页展示只有原型图，

UT跟HTML都还没做出来，而其他功能更没有准令。于是项目组就只好花两三天

的在那边等UI和HTMLo

#固定的项目组组员

这是一种很简朴的规定，不过并不是所有的人都会重视。

正如随便加一种开发人员进来并不可以立即让整个项目进展加紧，换一种人

的话，整个进展肯定也会受影响。

#组员潜力

每一种程序员，测试人员，美工，产品经理，都比你想象H勺要聪颖。假如你

没有对你组员的能力有个清晰的认识，那你可以尝试给他H勺任务增长某些难度,

超过你本来日勺预期一点点。他能完毕，你后来可以再增长某些难度。直到他直接

跟你说他搞不定。假如你觉得你已经有个清晰日勺认识了，那你也应当记得，只是

你觉得。

我们有一种项目，里面有个很棒的程序员Joy,平常是个很低调的人。项目

经理分任务口勺时候，就给他几种特定的模块让他完毕。他也坚守岗位，做好他份

内的事。项目由于种种原因，不停的迟延。不过Joy还是很诚实的做好他的本分。

后来有人跟Joy讲，你后来要把自己当devlead看，所有开发的事情你统

筹。

Joy还是一种很低调的人，他继续做他本分的事情，只不过这次的本分就是

统筹负责所有的开发问题。

接下去就是项目日勺问题一种接一种欧J被迅速处理掉，其他程序员也得到强有

力的协助，迅速处理到自己手头中的bug。

项目进展很快赶上了本来的计划。

你真的很好的发挥了你组员口勺潜力了吗？

#人人看到全盘

项目经理可以很好H勺分派好任务，让各个组员可以较独立的工作，这是不错,

但也不见得就是好事。由于软件开发是一种团体的工作，各个人做H勺事情之间均

有交叉。我做的功能，接下去就要调用你的接口。你做日勺页面，接下去就要跳转

到我的。

Bruce做一种功能，是要显示企业人员信息日勺列表。里面有个操作，选择一

种人员计算出勤率。这个操作不是Bruce完毕了，他只要直接调用Lisa日勺页面，

LisaH勺页面会直接计算出勤率并显示出来。Bruce认识，他只要简朴传一种人员

的ID过去就可以了。

Lisa做这个出勤宓的页面，由于这个人员是属于业务人员，常常要在分企

'也跑，因此只能计算他在某一种分企业的出勤状况。她认为大家都懂得。

等大家都完毕了，QA在测试口勺时候，发目前人员信息列表里面点进去，显

示不了出勤页面。整个流程都走不通了。

后来才发既有2个问题没处理好，一种人员信息跳转到出勤页面前要传递目

前的分企业信息，一种是出勤页面还要增长选择分企业的功能。

这2个问题一种是QA测出Bug,一种是需求尚有局限性。而这本来是应当

在开发周期内就可以发现并处理日勺问题。

本源就在于，Bruce跟Lisa在做手头任务的时候，都没有去考虑跟其他人

的关联。而他们2个人都没有去考虑的话，其他人更不会去考虑了。

假如Bruce或者Lida在做任务的时候，去想想他们彼此怎么串联起来，这

问题自身就很简朴了。

项目组日勺每个人，可以重点在自己手头的任务，不过思绪必须是在全盘，大

家脑子里面都要常常去想想，整个系统是什么样子的I,我的功能前后的依赖是什

么样的。项目经理平常要引导大家这样想。

#一定要提成每一种小迭代

步伐迈得太大了，你就不懂得你迈得对不对，迈得够不够快。项目是不也许

一步到位的。把一种大目的分解成每一种小目的，整个项目工期提成若干个短迭

代，一种一种口勺完毕。每一种完毕的小目的都能协助你理清整个项目口勺进度，方

向，协助你审核一下目前的思绪是对的还是错口勺，出错了，也可以及时口勺调整。

#不做二分之一的功能

假如我们做了2个功能，不过我们每个功能都做了二分之一没所有完毕，那

目前为止我们总计完毕了多少个功能？1个？

不是时，完毕了0个。一种功能除非真正完毕并且通过产品经理日勺检查，否

则你永远不能确定这个功能是不是尚有某些遗漏的地方。

100个完毕度为90%的功能合起来，完毕的功能还是0个。你很兴奋你口勺程

序里面有诸多功能，不过你试了一种又一种，成果发现每个功能都是半成品，没

有一种功能可以对的处理你口勺问题。

对于半成品H勺功能:

1.你其实并不懂得你还剩多少工作量，由于已经“完毕”日勺工作不能验证

说是真正完毕的。

2.你没法给业务部门或者客户做演示，由于这些功能没做完。

3.假如业务部门让你暂停一下，就先按照目前已经有口勺功能去让客户测试

一下，你会哑巴吃黄连，有苦说不出。

因此我们做功能的时候，要保证我们在做的功能已经是真正完毕了，我们再

去接着做下一种功能。

#不让细节影响你的目的

项目组日勺人很轻易沉浸在功能的细节当中，为某些友好美观日勺显示，炫丽区I

功能或者很酷的设计挥霍大把的时间，忘掉了这个项目日勺最终目日勺是什么。其他

人可以投入，不过项目经理一定要可以抽身事外，专注在项目的全局。沉浸在细

节当中很轻易让人忘掉工期，忘掉项目的最终目日勺。

我这个提醒信息的颜色会不会太淡了？要不要再调深某些？

我这个按钮是不是可以往左边移10像素，这样更好看？

这个地方要不要来一种自动提醒，这样会更友好一点？

我这个面板日勺显示要不要使用渐变欧I?1秒内渐变完毕会不会太快？顾客

会不会还没看够?

你先把功能完毕再说好吗？后来有的I是大把日勺时间美化这些。

#对的的里程碑要点

我们碰过一种项目，项目经理的汇报说，目前的状态是开发完毕。成果