好，将数据导入正常运行觉得没有问题后，再通知技术部的人来看结果。所以每次我们打电话通知技术部的人时，他们都非常热情，因为他们知道软件基本上没有问题，和他们负责的另一个项目成了鲜明的对比，所以他们在后期项目验收时明显地站在我们软件厂商的立场帮项目验收了。
对那种技术或业务水平非常一般、只关注自己的想法、又有权力欲的客户，一定要早先知道，小心不要让其对项目造成恶劣的影响。笔者一同事在负责一国企大型项目时，就遇到了这样的客户，最后他忍无可忍，指着客户的鼻子骂“你懂什么啊你”。
虽然客户的上司心里有数，但场面上还是会维护自己的同事，而我们软件厂商虽然更明白且心里支持，但最后还是我们的总经理打电话向客户陪不是。事情结束了，后期那客户对项目的态度就变得很差了。得不偿失。
三．项目情况介绍
介绍项目的情况，如项目金额、项目模块、软件体系，包括项目要上几个模块、客户最关心的模块是哪几个、公司现有软件的功能、哪些模块和客户的出入较大、哪些模块需求相符、哪些模块要重新开发、项目选哪几个模块作为突破口等等。在项目进行过程中，常会遇到客户需求变更的情况，这要求项目经理预先有了解和预估。
这样公司的领导也就明白客户观注的重点是什么，而我们的难点又是什么，项目大致的进度是什么样的。因为作为一个公司的领导，关心的是这项目需要投入多少人力、财力，什么时候项目结束，给公司会带来多少利润。至于技术点或是细节问题，领导很少会关心。
在对自己软件熟知的基础上，自然更要知道客户关心的是什么，不然投入整个公司的资源，花三四个月开发一个客户不认可的东西出来，再推翻重来，岂不是耽搁公司的发展前景。
四．项目工作量预估和问题分析（这是最难的工作）
这个问题直接决定项目周期的长短和人员的投入及调配，也是项目经理最难定的一个量，需要在实践中不断积累经验。一般是按调研后的需求分析说明书来确定工作量，根据各个模块的难度和开发量决定投入的人手和时间，预估项目中的问题难点，包括技术瓶颈、负载压力等。很多问题的发现和预估则靠多年的工作经验。
这方面内容是项目经理争取优势资源配置的重要依据，所以有些技术难点不防有限度地夸大一些，但牛皮不能吹破了，不然以后领导对你的印象就是夸大其辞。
笔者有一次向领导申请公司牛人来负责软件中的权限设计，将话说过头了，结果领导听后反驳了一把。日后笔者再向这位领导申请资源时，领导遇到自己不懂的技术，总会去问问其他同事后再答复笔者，而不是之前那样，笔者提什么要求都当场一口答应。让笔者花了半年以上的时间才重新建回了信任关系。
项目工作量的预估要在熟知需求的基础上，没有太多经验的项目经理一定要多读几次需求说明书，明了客户的需求重点和关心的结果，有经验的项目经理都会关注需求说明书，更何况是经验不多的项目经理了。对需求说明书中有疑问的、有岐义的一定要标注出来，和相关人员讨论清楚，甚至和客户谈清楚需求点，以防出现方向性错误。
五．项目工作计划（这是最核心的工作）
本项目的工作计划，包括资源的申请、人员的搭配、团队的组建、开发进度的安排，计划分期的重点，如第一期大约到什么时间，主要完成的任务是什么，需要投入什么样的人，各自负责什么。
注意时间点的把握，如果项目实际进度和计划的时间出入较大，项目后期将非常被动。笔者提供一些参考数字：一个半月以内的一般多报一个星期，三个月内的一般多报两个星期，半年以内的一般多报一个月，一年以内的一般多报一个半月到两个月，为项目预留出足够的时间。
在国内，软件厂商签约时都处
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
