【希赛主持人】：
网友[cuiyi] 说：田顾问，我是国企的研发部门，怎样才能对项目进行有效的管理呢？怎样才能有效的进行人员管理呢？
【希赛嘉宾/田俊国】：
国企的文化首先是一大难题，纪律松散、奉献意识差，一加班都叫苦连天，不加班事情又做不完。我觉得几点你可以尝试：
1、用外部的力量（临时聘请人员、做得好的公司的人）来刺激一下你的团队。
2、封闭——找机会封闭，与你的文化隔离。企业文化不好的公司，采用隔离，抓短期还是有效的办法； 3、大胆任用有激情的年轻人，有能力没激情，不如有激情没能力；
【希赛主持人】：
网友[zbstar] 说：IT 项目管理中，如果项目经理不懂技术，或水平不如项目组的某人高，是不是领导起来就很困难？换句话说，项目经理是不是应该是项目组里技术水平最高的？
【希赛嘉宾/田俊国】：
我不这么看，我在01 年后就不搞技术，但是我还领导了好几个高新技术的项目，项目经理要是技术本身有问题，但是对技术一点不懂也不行，否则你很难管束你的技术下属，对很多技术工作你至少应该知道如何干及需要的时间，但你不要亲自去干。
项目经理要干的事情就是协调资源、上下左右沟通、项目决策，为项目的顺利进行营造良好的环境。 项目经理的职责：
1、保证项目成功和项目各个利益相关方满意； 2、指导和控制项目的日常工作； 3、项目决策； 4、应对变化； 5、如实反映情况；
【希赛主持人】：
网友[tianchengzhi] 说： 那么项目经理除了管理软件工程的那些环节外，还有哪些也需要进行关注和管理的？
【希赛嘉宾/田俊国】：
沟通、风险、团队及文化、干系人利益、环境、激励、公关等等；软件工程应该是对技术人员的方法论。项目管理则大一些，就是要研究如何在复杂多变的环境下干好一件事。
【希赛主持人】：
最后，请问田顾问，给学习项目管理的网友与实施项目管理的企业一些建议吧。
【希赛嘉宾/田俊国】：
1、不要想着一下子设计一套完美的项目管理体系然后再进行项目管理，要一点一点改进，一点一点提高，
戴明的每天提高1％在那里都有用；
2、努力做好宣传和学习，尤其对项目组一般员工的学习；
3、注重事件管理，就每一件事用项目管理的思想进行分析，用项目管理的思想和理念改变员工的习惯； 4、要坚持，不要轻易放弃你们公司的管理体系，尤其是找一个“不合适、不适用”之类的借口，放弃执行公司的体系；差不多就这么多了。
【希赛主持人】：
由于时间关系，我们今天的聊天就到这里，谢谢大家的提问，也谢谢田顾问的精彩解答。 我们下次嘉宾聊天再见。
论项目计划
摘要
本文讨论了一个作者参与的软件项目的项目计划制订的若干问题．项目所开发的产品是一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机．
作者是该项目的软件开发组负责人兼软件架构师．作者针对项目计划的制定采取了：分而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果． 正文
2002年6月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容，联网的计算机也可以实时观看用户的书写过程．另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机．作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构架师的角色．对于这种实时通信且具有联网功能的软件项目，我认为首先需要制定一个良好的项目计划，才可以保证项目开发的成功．
总结这次项目的经验，我认为行之有效的策略有三个，分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。
一、分而治之
将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀，这种方法人类已经采用了几千年．这里我们也可以用于项目计划的制定．因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力．为了解决这个问题，可以将整个项目分解为一些更小的组织体，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。
比如针对这次项目中采取的RUP开发过程模型，我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划．
除了按时间段分解的角度来制定项目计划，我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的．同时因为本项目的特点，我省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不是那么必要了．以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生．
二、逐步求精
计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自身无法掌握的因素，因此存在很大的难度．而解决这一困难的法宝就是逐步求精．按照先框架后细节，先粗后细地进行项目的计划．
比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的内容主要是做出时间上的安排．因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了2003年4月，预留一个月用于写申请报告．总的时间进度确定后，大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结．
等到确定这改项目后的RUP 开发模型后，就可以继续对项目计划进行第二改求精了。其实RUP 过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品．这样我就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段我再具体地制定每类计划的详细内容．
比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整．
三、经验数据
要制定一个良好的计划离不开精确的估算．不过项目计划是在项目开发的早期制定的，而在早期要完成精确的估算是非常困难的．要解决这个问题的关键就在于“经验数据”．由于整个软件产业都还十分年轻，经验数据的积累都普遍不足，才导致这一现象的出现．
但是因为这次项目开发的产品在国内还没有开发过，再加上公司没有积累深厚系统的项目历史数据．针对面临的困难，我选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整．
Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法．当然，请专家增加了项目成本，不过最后得到高质量的项目计划还是值得的．比如，在某专家的建议下我们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的中间件产品，这个策略的调整在后来证明是正确的．一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了．
最后谈一下使用的工具软件．在制定项目计划过程中我采用了Microsoft的Project 2003绘制甘特图．因为项目的进度安排是和项目中每个人都是息息相关的，所以在做甘特图前我首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的颜色标识关键任务，放大任务摘要信息，突出里程碑信息等．这在有些项目管理者看来似乎是小事，不过我认为一个赏心悦目的甘特图可以带给观看者好的心情，而好的心情可以大大提高工作效率。
同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依赖关系时我采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”我填入5%-15%，也就是说当任务完成90%左右时就可以结束转而执行下一个任务．因为本项目中的所有人员
几乎是全程参与，所以我不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。
配合Project 2003使用的估算软件是Software Productivity Research的KnowledgePlan.这款工具软件的最新版加强了对Microsoft Project 2003以及RUP开发模型的支持，而且其中的Project Template功能允许用户采用自己定制的WBS来进行估算，这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助．
在上述三个策略的指导下，以及合适工具的辅助下，使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定，获得了国家中小企业创新基金的支持．
项目完成后发现的问题是早期计划的估算结论偏差还是较大，看来还是受到缺乏经验数据或者经验数据不够精确的影响，所以在以后的工作中需要开展有效的度量的工作，为公司积累覆盖面广且尽量精确的经验数据．
项目管理的沟通管理
发布：华夏学习网 www.edu114.cn 时间：2006-11-04
回想一下你所经历的项目，有没有出现过以下这样的情况：客户在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭……
可能你遇到的情况比上面谈到的还要复杂。问题到底出在哪儿呢？其实很简单，就两个字??沟通。以上这些问题都是由于沟通引起的，沟通途径不对导致信息没有到达目的地。“心有灵犀一点通”可能只是一种文学描绘出的美妙境界。在实际生活中，文化背景、工作背景、技术背景可以造成人们对同一事件理解方式偏差很大。
在项目中，沟通更是不可忽视。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。 沟通管理的体系
一般而言，在一个比较完整的沟通管理体系中，应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息，什么时候需要，怎样获得。信息发布使需要的信息及时发送给项目干系人。绩效报告收集和传播执行信息，包括状况报告、进度报告和预测。项目或项目阶段在达到目标或因故终止后，需要进行收尾，管理收尾包含项目结果文档的形成，包括项目记录收集、对符合最终规范的保证、对项目的效果（成功或教训）进行的分析以及这些信息的存档（以备将来利用）。
项目沟通计划是项目整体计划中的一部分，它的作用非常重要，也常常容易被忽视。很多项目中没有完整的沟通计划，导致沟通非常混乱。有的项目沟通也还有效，但完全依靠客户关系或以前的项目经验，或者说完全靠项目经理个人能力的高低。然而，严格说来，一种高效的体系不应该只在大脑中存在，也不应该仅仅依靠口头传授，落实到规范的计划编制中很有必要。因而，在项目初始阶段也应该包含沟通计划。 设想一下，当你被任命接替一个项目经理的职位时，最先做的应该是什么呢？召开项目组会议、约见客户、检查项目进度……都不是，你要做的第一件事就是检查整个项目的沟通计划，因为在沟通计划中描
信息系统项目管理师论文材料及范例
