甲方对需求不明确，如何做项目计划？

甲方对需求不明确，如何做项目计划？

上周品至去项目现场见客户，和甲方详细的汇报了在做项目的情况后，甲方说：“我们打算做一个招聘系统，你研究一下，给我列一个计划。”

这显然是另一个商机啊!大侠暗自开心，并连连向客户保证道：“好的，没问题!一定令您满意。”

开心过后，大侠冷静下来，陷入沉思：

这样没有详细需求的项目，怎么列计划啊?怎么列的计划才能令客户满意呢?怎样列计划才能让公司获得更多利益呢?

为了完善项目管理的体系，很多公司都会建一套项目知识库，一方面持续积累项目的经验和过程资产，另一方面项目知识库也可以作为对后续项目的指导和借鉴。

对于毫无头绪，需求不明确，又没有经验的项目经理。最好的方法就是参考项目知识库了。

通过了解公司的所有项目，借鉴已经成功完成的类似项目，匹配现在客户的需求，可以整理出一套可供汇报的项目文件(包括项目需求、项目预算、项目计划、项目人员投入等基础内容)。

对于公司没有项目知识库，或者项目知识库中没有类似项目可参考的，可以采用这个方法来做。

第一步：需求调研，了解背景。

任何一个项目的建设必然要有充分的理由，比如客户那边会需要提交项目立项申请详细阐明项目建设的必要性。

当拿到毫无头绪的项目的时候，可以通过“元思维”(参考文献：《高纬度思考法：职场问题解决篇》细谷功)寻找“上层目的”，做为什么的分析，分析这件事为什么要做，甚至有时候需要分析为什么的为什么。

我们可以通过和客户多次沟通，了解他们做这个项目的本质意义是什么，为什么要做这个项目。

比如大侠的客户要做的招聘项目：

为什么要做这个项目呢?原来是因为客户每次招聘志愿者的时候，都是通过给各个高校联系然后发通知，或者把招聘的信息挂在公司官网上。收集到的报名信息都在联系人的邮箱里，然后再下载下来一个一个筛选。这样给工作人员带来了很多工作量，还为此专门成立了一个小组。

那这里就会有人反驳，如果不知道原因，自己多方尝试也无法从其他人那里获取到更多信息的情况，该怎么办呢?

这个时候就要大胆假设，然后多次验证。

通过假设客户的各种情况，找到客户需要建设这个项目的各种原因，然后整合成一个汇报方案，给客户汇报。通过多次汇报，就能慢慢了解客户的背景和内容。

通过第一步，必然获得：项目背景。理想状态下我们可以获得：需求内容、客户预算、计划周期。

第二步：依据已知，列大计划

有了项目背景、需求内容、客户预算、计划周期后，对于项目经理来说计划基本已经形成。

项目经理可以采用反推的方法，通过大的计划周期，确定项目的关键节点，然后根据关键节点填入具体可能完成的任务。

比如：大侠的这个项目想要在X年内上线，预算金额为X万元。

那么通过反推，可以知道每个阶段应该投入的人员情况，需要多少人?什么级别的人?可以知道项目各个阶段应该投入的工时。然后就能反推出具体的需求。

当然反推法因为容易不自觉的把时间和金额穷尽化(人的本性)，所以通过反推法也会带来很多风险，比如客户预算降低，成本包不住，需求增加等等。

如果在第一步只能获得必然输出：项目背景。那么然而相对来说也是比较简单的了。因为可以发挥的空间更大了。

项目经理可以结合背景，了解业务，大胆假设小心求证，尽可能周全的考虑客户的业务需求，然后出一个具有可行性的需求方案，根据需求方案列出项目计划、人员投入、项目预算等。

通过第二步，必然获得：需求概述、大计划。理想状态下可以获得：详细需求文档、项目预算。

第三步：细化分析，列详细计划

如果这个时候，客户已经认可了方案(包含需求概要、计划、预算)，那么项目经理对于客户的要求“我们打算做一个招聘系统，你研究一下，给我列一个计划。”已经做了一个完整的回复了。

之后项目确定后(签订合同，或商务确认没问题提前投入)，那么项目经理可以根据需求列项目团队的内部工作计划了。

如果这个时候，客户还没有认可，那么本质是因为方案不能匹配客户的需求。这个时候可以继续重复第一步，了解客户本质需求。

项目经理的文章的写的越来越多，对项目经理的认真也变的越来越清晰了，就仿佛在吹开覆盖在它上面的雾，起初只有白茫茫的，到后来有了影子发现了它，然后看到它的轮廓，慢慢的可以看到它的本体。

今天的主题是需求不明确，其实很多时候都会遇到这种情况，有的是领导给安排一个工作，然后剩下的内容全靠自己主动了解。

如果项目经理的主动性不强，其实很难推动项目。对于今天的主题，从方法上其实不难，更多的在于项目经理的主动性。

加油，项目经理们！