【转贴】资源不足怎么办？

张康大长弓

项目管理十大知识领域中，项目资源不足或许是最常见，却是最棘手的问题。从广义上讲，权力不足以掌控项目全局、时间不足以制定周密的计划、人力资源不足以支持项目的难度和强度等情形都属于资源不足。
很多项目经理习惯性地认为会哭的孩子有奶吃，一方面项目可以得到领导的重视，另一方面资源充足的团队就相对轻松一些。你会说，要明确现状，获得理解和支持。但这是一句废话，没有任何的驱动意义，也没法以结果为导向实现项目的交付。
而且，你的潜台词还在说，领导眼瞎。一个项目的规划和实施，你的领导比你心里更清楚。他不是看不到这样的现状，而是人力资源缺乏的现状并不是他一时半会就能立马解决的问题。所以，你的预防针变成温馨提醒和进度汇报就足够了。
重要的是，基于这样的现状，作为项目经理，你能做点什么或者应该做点什么让这眼前的浓雾散开，可以窥得见一缕美好的阳光呢?
项目经理需要站在企业的角度去思考问题，运用灵活变通的理念做好项目管理，切切实实为企业解决问题，可采取的具体措施如下。

01 简化项目的解决方案

也许你从一开始就设计了比较完善的项目建议书，这里面包含了一个巨大的项目工作范围，你的SOW和WBS可能也写得很详尽。但此刻，你的团队里只有2个后端开发人员，没有前端工程师和数据库开发工程师，也没有测试人员来保证项目的质量。

这是一个多么悲伤的话题啊，就像你选定了要演奏的曲目，确定了音乐会的时间和场地，但仅有2个音乐师能够出席。所以，那个音乐指挥家挥舞着指挥棒在想，可不可以把这场音乐演奏会变成音乐独奏会?

这样的情况下，你依然需要淡定地把项目方案建议书和需求规格说明书重新审视一遍。结合用户需求思考和权衡，哪些功能是目前比较关注的，而哪些功能是未来系统需要关注的。这个其实并不难，如果你和用户开放地沟通过，项目功能的轻重缓急，你应该心里有数。
所以，你很有必要在此基础之上，整理出项目当前阶段的需求规格说明书来。不要一味地喊叫资源不足，这样的方式只会引起领导对你做事能力的怀疑，而不能解决根本问题

张康大长弓

02 确定核心功能的优先级



关于个人工作效率的经典之作《高效能人士的七个习惯》一书里依据纵坐标(重要性)和横坐标(紧急性)来划分任务，有如下四种组合：

(1)重要且紧急，迅猛龙式出击。　
(2)重要但不紧急, 准备好未来的方案、策略和计划。
(3)不重要但紧急，学会说不，拒绝任何承诺。
(4)不重要也不紧急，可以研究下隔壁的妹纸为何每次遇见你都会笑得很好看。

一个大型的项目，利益相关方会很多。常常会有很多年轻而对项目管理知识无知的利益相关方从方便个人利益的角度出发，突然过来很莫名地给你讲，XX报表要放在你的系统里实现而且某大领导非常重视。

这时，你需要做的就是果断拒绝，不要给任何承诺。很明显，这是不重要也不紧急的事情。因为凡是重要且紧急的任务，领导都会在需求讨论会上明确地强调多次。项目经理心里要有一杆秤，哪些人的需求是需要理会的，哪些人的需求是不用过多关注的。

整理完核心功能和关键任务的优先级列表后，你会发现项目一半的范围进行了裁剪。这是一个好的趋势和结果，因为缩减和明确项目范围永远对项目的如期交付是有利的。

而一个项目的实施，10个人有10个人的计划和结果，2个人也有2个人的计划和结果。当你无法争取标配的资源获得对这个项目的足够支持时，只能关注核心功能并在核心功能范围内进行任务的优先级排序。

张康大长弓

03 制定可行的迭代计划



迭代这个词现在很泛滥，但很多人都不明白需要迭代什么。项目经理首先要明确，在这些核心功能清单中，哪些是需要放在持续的迭代计划当中的。

不是项目所有的功能都需要迭代，成熟的功能基本都是一次开发就落地实现，如果你说要迭代设计登陆和退出功能就显得非常**和无知。通常需要迭代的任务都是那些比较复杂的，业界技术不是很明确或者用户未来期望也不是很明确的功能，比如权限体系、报表体系等。

迭代周期不要过短(团队Hold不住，时间都会浪费在代码分支合并冲突检测、各种测试、Bug修复、上线发布中)，也不要太长(否则失去了敏捷开发的意义)，为了给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为项目经理的你，需要和开发人员探讨每个里程碑的实现程度。

张康大长弓

04 设计前瞻的系统架构



如果你有幸遇到一个有全局观、有前瞻性的系统架构师，项目会顺利很多。系统的架构就像交通工具的骨骼，你需要和架构师进行密切的沟通。开发未动、架构先行的准则是保证系统未来不会宕机和崩溃的重要准则。

所以，你不要期望“老牛破车”的架构和框架之上，能继续朝里面添加或者迭代什么功能，也不要指望它能够跑得有多快、有多远。甚至，更多的可能是，你在项目功能进行迭代的时候，它已经无法兼容和承受这么多的负荷，变得支离破碎，牵一发而动全身，瞬间就宕机挂起。

系统架构和框架的前瞻性、灵活性、兼容性是分布式开发、多用户并发环境里必须要考虑的重点和难点问题之一。

张康大长弓

05 明确系统的关键逻辑



前面已经很明确了，留给开发团队仅有的2个人员的开发时间没剩下多少了。如果你还不主动出击，驱动关键业务方，明确系统逻辑和规则，就会导致后续再多的开发人员都需要无休止地熬夜加班。

尽早地确定系统逻辑和规则，本质上是为了给开发人员、测试人员节省更多的时间，从而保证系统的质量和性能。系统逻辑和规则的确定，最好的方式是最终都能够用正式的邮件确认和统一过。

业务方不会明确地告诉你业务规则和逻辑是什么样子的，所以需要你主动牵引，按照需求会议的讨论内容，结合你对业务的理解、对用户的研究整理出符合当前的系统逻辑和规则，并请业务关键人员进行确认回复。

因为只有明确了逻辑和规则，你才真正地为开发人员扫除了顾虑和障碍，才能在有限的时间内聚焦在业务逻辑和规则的实现当中，而不是写一行代码出现一个疑问，然后朝你问十万个为什么，之后仅有的时间又会浪费在解释和思考当中。

所以一个合格的项目经理对项目的思考和规划需要是最全面的，并且都能够是前瞻性的，至少比团队当中任何一个成员都需要有超前的思考。

onlylong

读书时成绩可以说明一切，工作后的评判标准没有统一的了，给了很多成年人钻空子的机会，哈哈哈，看起来很努力，实际没成果还没法说他什么