软件项目管理存在的问题 项目管理中存在的问题
软件项目管理应注意的问题有哪些？
软件项目从角色分工方面可以划分为研发、开发和实施三类，每个类型的项目有各自的管理过程。
下面笔者就公司实施类项目的经历，从项目经理的角度谈一谈实施类项目管理过程中应该注意的一些问题，希望大家共勉。
确定项目概况 俗话说：“万事开头难”，项目开始阶段是一个非常重要的阶段。
项目经理在接手一个新项目的时候，首先要尽可能的多从各个方面了解项目的情况。
要在项目启动阶段就要了解：这个项目是什么类型的项目，具体做什么事情，是谁提出来的，目的是解决什么问题，客户方直接责任人是谁及他对待项目的态度。
我们提出这些问题，并根据掌握的情况分析这些问题，目的是要找到这个项目验收的最终落槌人，并根据他的工作特点制定相应的后续工作策略。
确定项目干系人 要了解这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来。
项目经理需要提前了解每个方面的人对这个项目的看法和期望。
事先做足功课，可以让你在实施中碰到问题的时候，分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而顺利的将问题解决，让事情向你所希望的方向发展。
请记住一句话：“没有永远的敌人，只有永恒的利益”。
提前确保后勤保障体系 “兵马未动，粮草先行”，这里的“粮草”就是资源的储备，就是参与项目的人员的业务、技术培训。
根据项目特点确定项目人员规划，人员配备以期达到互补，这样对于项目实施和提高人员素质很有帮助。
不是每个开发人员都适合目前的项目，最好向公司提前申请符合项目特点或者比较容易过渡的开发人员。
或者是在项目需要增加人力投入的时候能够提前向公司说明，以保证有比较合适的人选。
意义非凡的项目接口人 和客户谈需求，协调资源，一定要客户指定统一的接口人，不能张领导、王领导都来说几句，如果他们意见不一致，那你就成“夹心饼干”了。
所以，项目最初就要和客户方项目经理确定一个接口人，有什么需求你们内部先统一再和项目组谈，我不参与你们内部业务部门之间的矛盾之中，这样可以很大程度上减少客方不必要的干扰。
项目接口人不一定就是客方项目经理，有时候他会指派一个人和你接口，那这个人的关系也要处好，团结一切可以团结的力量。
如果遇到需求确定或者变更等需要做主的事情，那一定要请示客方项目经理，并且拿到具有证据效果（如：签字，邮件等）的反馈才行。
项目情况及时反馈 把项目过程中遇到的问题、进度及时向公司反应，以便能争取更多的支持。
对于客户的提问或咨询也要及时反馈，但不能不懂装懂，胡乱答应，对于不太把握的事情还是要和客户委婉的解释随后给予答复，争取到时间就要及时的去确认并且以最快的速度反馈给客户，让客户觉得项目组很负责任，态度很积极。
如果他提出的问题被你耽误了好多天或者干脆就忘记反馈，那客户的感觉可想而知，随后的工作就麻烦了。
确定项目范围，避免完美主义 很大部分项目经理是从技术开发做起的，有时候在谈需求的时候，对于客户的要求不能进行合理的分析或不能对项目的成本控制引起足够的重视，觉得这个问题不太复杂，又对客户具有惧怕心理，就觉得做也没有关系，到头来需求超出了项目的范围，从而对后续工作造成不利因素。
顾客是上帝，但我们不是基督徒，对待客户的态度力求做到不卑不亢。
制定项目范围要注意及时刹车，避免需求膨胀。
建立沟通渠道，注意保存证据 说到沟通，通常就是指会议、邮件、电话、口头确认等，但还有一样比较不被注意的形式就是建立统一信息发布区域，能保证项目成员、客户可以从一个统一的地方获取信息。
邮件的形式具有不容易被识别和信息分散的特点。
建立统一信息发布区不但有利于信息发布还有利于保存信息的版本变更。
对于调研日志，会议记录，项目周报等尽量放到信息发布区中。
有些客户不喜欢签字，怕承担责任，我们在保证优先签字的原则下，退而求其次，要保证客户的反馈是书面的（比如邮件），对于自己发出去的邮件不要随便删除。
合理引导客户 不同的客户对IT项目的理解不同，有的比较专业，有的一知半解，有的完全陌生，面对不同的客户谈需求、系统设计的时候要因人而异。
能够说明不同解决方案之间的优缺点，能够引导客户向有利于项目推进或实现简便的方案上靠拢。
牵涉到不同业务部门之间的问题能在技术上找到解决办法的，就不要在业务上寻求解决问题的方法。
注意环境问题 实施类项目大多需要项目组安装测试环境，在测试环境的安装过程中，注意域名配置，各服务器时间不同步的问题。
对于这种环境问题怎么强调都不过分。
记得一次配置测试环境中hosts表中域名和中间件配置的域名的一个字符没对应上，导致配置过程出现了问题，耽误了时间。
遇到问题注意分析日志，有时候日志提示的信息可能是由其他问题引起的，所以需要全面的分析问题。
对于以上罗列的一些问题都是在项目管理过程中的经历和总结，希望能对大家有些帮助，在碰到同类问题时起到引导和提醒作用。
项目不同...
国内应用软件项目管理的若干问题有哪些
项目管理意识 不能真正区分项目实施和项目管理的工作任务，是目前存在的普遍问题。
可概括为“没事做”和“没人做”并存的现象，这往往由开发骨干兼任项目经理所致。
一方面，如果设立专职的项目经理，专做项目管理而不做任何分析、设计、编码、测试等具体的技术实施工作，就会感觉“没事做”，或是在打杂。
另一方面，由于主要或全部精力均忙于具体技术工作，各种项目管理任务（如：项目分析评估、项目计划的制定检查调整、上下左右的沟通、专业资源调配、项目组织调整、项目财务控制、风险分析对策等）不可避免地疏于顾及，项目管理的事情“没人做”，导致项目控制的问题“积劳成疾”，后悔莫及。
在中、小型项目中，管理任务可能不饱和，有条件的项目经理可以兼任项目技术主管或业务咨询，关键在于要有将项目管理工作区分出来的意识和责任感。
项目成本基础 项目管理的精髓是必须在规格（Specification）、成本（Cost、Resouce）和进度（Schedule）之间取得平衡。
而目前国内的系统集成企业，普遍没有建立专业工程师的成本结构及运用控制体制。
因而无法确立和实现项目成本的指标、考核和控制，导致公司与项目经理之间的责任不清。
直白地说，项目经理可以不计成本地申请资源，“韩信点兵，多多益善”，而公司处于两难，答应则可能投入太大，拒绝则必须承担项目失败的责任。
上级经理成了项目经理。
不建立专业资源成本结构，就无从实现项目的成本管理，就不会有真正的项目管理。
项目管理制度 规范化而且切实可行的项目管理制度，必须因企业、因项目而异。
一般而言，应是项目管理原理、企业行业特点和项目规模性质、企业开发文化素质等各种因素综合的产物。
产生的过程应是，由具一定的理论素养、丰富的规范化项目实施经验和总结能力的资深项目管理专家，结合企业的具体情况，有针对性地制定，并经培训、试行、调整予以落实贯彻。
国内目前的普遍情况，或者是企业无项目管理制度，仅凭个人经验实施项目管理；或者是书生制度，照搬教条，纸上谈兵，束之高阁。
其结果是，不仅实际的项目管理无所依循，而且也使项目监管层难以落实项目的间接监控和支持。
专业服务组织 国际上的企业级应用软件的开发组织，基本上分为产品研发和专业服务两类。
国内由于市场成熟度低等原因，多以直接面向客户需求的项目型开发为主，应属专业服务型的技术组织结构。
目前国内的差距主要在于，一是公司策略上将项目实施部门定位为配合系统产品销售的成本中心，而未能作为一个独立核算的业务单元或业务方向；二是基本采取层次性的业务管理性组织结构，而缺乏业务管理和专业管理（诸如运营经理、资源调配、资源开发、行政助理、项目会计、项目质量监控等）的分工合作的矩阵结构；三是缺乏纵向专业深度的设计和结构。
专业服务组织结构的差距，使专业服务部门市场定位模糊，发展方向迷茫。
平时不利于专业队伍建设，不能持续有效地发展和提高技术队伍的专业素养；售前活动中，不利于程序化地组织售前支持及控制售前风险；项目实施中，不利于合理及时的项目资源的调配，不能将运营（Opeation）监管和项目监管有机结合，以确保项目监控状态。
项目计划 项目计划是项目经理实施项目管理控制的基础。
目前的差距主要有：一是项目计划的制定不够严谨，随意性大，可操作性差，因而实施中无法遵循，如项目计划过于粗略，落实Beakdown（“粒度”）不足；没有做到任务、进度、资源三落实。
二是缺乏贯穿项目全程的详细项目计划，甚至采取每周制定下周工作计划的逐周项目计划方式，其实质是“项目失控合法化”。
三是项目进度的检查（与进度计划比对）和控制不足，不能维护项目计划的严肃性。
软件设计项目管理的难题是什么？
项目经理或主管在构建软件项目时遇到了大量的问题。
转换工作中的缺口 客户需求与开发团队计划的工作之间存在着缺口。
安排的工作与实际工作之间也存在着缺口。
重要信息在这些缺口中丢失。
需求没有完全满足，而完成的工作并不影响客户需求。
需求管理工具试图解决这一问题，方法是提供这些缺口的链接以形成可跟踪矩阵。
这些链接很快就变得过时且毫无意义，并给项目主管带来很大的维护负担。
团队协作和沟通很差 由于存在完全不同的文档，而且它们不一定是最新的或与实际工作进展同步，因此团队的协作和沟通受到了阻碍。
项目主管必须花时间收集来自不同计划和列表的状态，而团队成员必须花时间发送状态报告并更新文档。
这影响了团队工作效率，特别是当团队成员为了提供其工作状态而中断时。
团队工作流的效率低下，其原因是团队可能要等待工作完成后他们才能开始，但他们缺少一种可靠的机制来确切获悉工作已完成。
有时，仅仅在团队成员之间传递工作、跟踪问题或收集状态就用掉了工作的全部时间。
更正系统问题困难 即使项目主管发现必须进行项目过程更改时，在项目团队中实现适当的更改也是非常困难的。
进行流程更改对团队的工作效率有很大的影响。
团队成员要完成工作就必须不怕麻烦地查找流程信息或正确的文档模板。
对于分配到包含不同流程的多个项目的团队成员，查找正确的流程信息甚至会更加困难。
为了决定应用哪些策略和规则，团队成员必须记住使用哪个流程。
因此，团队成员对流程产生了厌恶感，而且不理会流程的更改，从而削弱了项目主管的作用。
跟踪，但没有管理 获得项目的重要衡量标准对于跟踪状态和做出决策十分重要。
由工具生成的大部分衡量标准没有以统一的方式进行存储或访问。
创建报告需要手动将信息从不同的工具剪切和粘贴到一种报告格式中，变得费时又费力。
因此，项目主管需要花非常多的时间从众多不同的工具收集衡量标准，以使项目计划保持最新状态并通知项目团队。
通常，项目主管会身陷于跟踪细节，而没有进行项目风险分析和项目过程修正。
项目管理主要存在哪些问题
对于许多项目经理而言，项目团队管理恐怕是他们所面临的最头疼的问题之一，而团队管理恰恰又是项目管理过程中最重要的部分之一：尽管成功的团队管理不一定能保证项目的成功，但失败的团队管理必然导致项目的失败。
在一个项目团队中，有各种不同的人员，他们具有不同的背景，有着不同的特长，也具有不同的性格特征。
如何充分发挥每一位团队成员的积极性和特长，并保证这些积极性和特长的发挥能够与项目目标保持一致，是每位项目经理在团队管理中所必须处理好的问题。
有趣的是，我们在中国的古典小说《西游记》中找到了这样一个非常生动、非常成功的案例。
让我们来看看《西游记》中的“项目团队管理”在《西游记》中，唐僧师徒四人历经千难万险，从“东土大唐”出发，最终完成“西天取经”的任务。
从项目管理的眼光来看，这本身就是一个项目的实施过程，也符合项目的一般特征，即“特定性”（项目任务为“西天取经”，项目交付物为“佛经”）和“过程性”（完成取经任务，提交项目交付物———“佛经”之后，该项目即宣告结束）。
任务完成过程中的其他要素也很齐全：包括项目交付物的“受益人”（唐朝皇帝）、项目的“资助人”（如来佛祖）、项目实施过程中的支持保障体系（各位神仙）等。
《西游记》中的“项目团队”也很符合项目团队的一般特征：唐僧师徒四人构成了项目实施团队，其团队成员有着不同背景、能力和性格特征；而唐僧这位团队领导人也面临着许多项目经理在团队管理中所面临的一般问题：项目团队成员并不是他自己挑选的，而是项目实施组织的管理机构指派给他的。
唐僧的三个徒弟，甚至包括白龙马，都是“上级领导”观音菩萨在他出发前确定的；换句话说，他没有“选人权”。
项目团队成员的技术能力都强于他（至少都能腾云驾雾，论武功更是个个比他强），都有一定的来头（原来都是天宫中大将以上职位），个别人还有一定的管理经历（如猪八戒曾是水军元帅）。
团队成员业务能力和工作态度各异，有业务能力强但心高气傲的（如孙悟空），有业务能力中等但工作态度不认真、不积极，“推一下动一下”的（如猪八戒），也有尽管勤勤恳恳、任劳任怨但业务水平较差的（如沙僧），如何将这些人组成一个具有战斗力的团队是一个大难题。
尽管名义上有一定的“行政权力”，如“惩罚权”（念“紧箍咒”）、“解聘权”（将徒弟撵走）等，但自己也知道缺了这些人（尤其是业务能力强但心高气傲的那位）项目就无法完成；况且“绩效考核权”和“奖励权”都在上级领导手中（取经完成后的封赏工作都是如来佛祖负责的，唐僧连“建议权”都没有）。
但就是这位缺乏“行政权力”，“技术能力”也不强的唐僧，带着这个团队完成了常人看起来难以完成的任务。
由此看来，作为“项目经理”，唐僧确实有许多值得学习之处。
软件项目管理中会有哪些问题呢？
一、为什么项目进度会拖延？因为没有按照项目计划进行！ 二、为什么不按照项目计划执行？因为进度总会有拖延，缓冲时间总会被用光。
三、为什么在计划时候不规划得更细更贴近现实一些呢？再细也总有额外的工作出现。
四、为什么不充分评估每一个工作，让预料之外的工作尽可能少呢？因为确实无法评估下去了，很多认为是原子级的工作都会产生出各种问题。
五、没有可以参考的其他项目的项目计划吗？因为两个项目的不同点太多，很难重用。
软件项目管理中的失误有哪些？
随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。
计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。
这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。
笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。
误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。
因为无论开始时有多么细致， 以后对需求的修改几乎是必然的。
分析：这是一种非常危险的思想。
实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间 进度达不到要求。
正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面 要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。
并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽 早地对需求变动问题进行沟通。
误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。
分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。
随着开发进度的推进，往往会有一些需求的 改变。
而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。
不过，这并不表明“软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现”。
实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。
假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。
由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。
这样才可能花费少， 容易被实现。
误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。
分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是 着重编码阶段，而是着重系统总体详细设计阶段。
一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体详细设计阶段45%，编码阶段10%，系统测试阶段34%。
误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。
分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。
可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。
但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。
伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。
工作量是很大的。
所以切合实际的方式应该是对一般 的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。
误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。
分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。
由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。
他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。
显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。
如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。
误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。
分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。
要想提高公司的软件项目管理水平，这就需要提高公司的整体 参与意识，需要公司各个部门协同作战。
例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。
误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。
分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。
如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。
否则，可能会“好 心好意做坏事”。
因为尽管其个人能力很高，但是为了使...
软件项目开发中常见的问题有哪些？
问题一 需求容不明确、把握不充分 （这一点非常重要） 这是我们经常遇到的问题。
一方面，由于客户（需求方）IT知识缺乏，一开始自己也不知道要开发什么样的系统，或者懒于系统地整理出来，经常是走一步算一步，不断地提出和更改需求，使得实现方叫苦连天。
另一方面，实现方由于行业知识的缺乏和设计人员水平的低下，不能完全理解客户的需求说明，而又没有加以严格的确认，经常是以想当然的方法进行系统设计，结果是推倒重来。
因此，需求分析必须注重双方理解和认识的一致，逐项逐条地进行确认。
问题二 项目工作量化 软件开发的量化是一项很重要的工作，必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素，将一些定性的内容定量化。
软件开发经常会出现一些平时不可见的工作量，如人员的培训时间、各个开发阶段的评审时间等，经验不足的项目经理经常会遗漏。
同时，还有如下一些原因也是很典型的： （1）出于客户和公司上层的压力在工作周期估算上予以妥协。
（2）设计者过于自信或出于自尊心问题，对一些技术问题不够重视，或者担心估算多被嘲笑。
（3）过分凭经验。
由于有过去的成功经验，没有具体分析就认为这次项目估计也差不多，而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多，而且是一个新的行业。
问题三 项目组织成员数量与其技术素质的关系 每个公司都希望以最少的成本完成项目，人手不足是大多数项目都会面临的问题。
还有一种情况是项目组成员的技术水平达不到项目的要求，公司只能提供这些分配好的技术人员，或者由于项目经理的失误，在项目工数估算时没有明确要求技术水平，寄希望于员工自己努力。
问题四 开发计划安排不充分 没有良好的开发计划和开发目标，项目的成功就无从谈起。
开发计划太粗略，主要反映在以下几个方面： （1）工作分担责任范围不明确，工作分割结构与项目组织结构不明确或者不相对应，各成员之间的接口不明确，导致有一些工作根本无人负责。
（2）每个开发阶段的提交结果定义不明确，中间结果是否已经完成，完成了多少模糊不清，结果是到了项目后期堆积了大量工作。
（3）开发计划没有指定里程碑或检查点，也没有规定设计评审期。
（4）开发计划没有规定进度管理方法和职责，导致无法正常进行进度管理。
问题五 设计人员能力不足 项目组设计人员能力的低下是项目失败的原因之一。
一方面，由于对技术问题的难度未能正确评价，将设计任务交给了与要求水平不相称的人员，造成设计结果无法实现。
另一方面，随着资源外包现象的日益普遍，一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司，这些公司的设计能力如不加仔细评价，就会对整个项目造成影响。
问题六 项目经理的管理能力不足 有及时把握进度。
项目经理自己也不知道项目的状态，下属人员报喜不报忧，害怕报告问题后给自己添麻烦。
进度管理必须随时收集有关项目管理的数据，开发人员总是担心管理工作会增加自己的工作量，不愿配合。
软件项目中出现问题了,原因是什么
最主要的问题是：1、需求调研工作做得不细致需求调研不是跟客户聊天，要能在客户提出的需求的基础上，进一步的分析和设计，要挖掘出客户的真实想法，本质需求。
2、项目管理出问题结构性不合理、代码设计质量低、没有足够的测试等3、总结来说：投入不足呗。
我们在做北京住房公积金管理中心的呼叫中心系统，客户需求1000多页，不会出现问题的！
项目管理机制中存在的问题以及解决办法？
从总体上看，当前我国工程项目管理信息系统主要是按照工程项目的规划、设计、施工、运营等几个阶段进行开发的，但大部分软件系统主要应用在施工阶段，包括造价管理软件，管理软件，质量管理软件、文档管理软件、资源管理软件管理软件等，造成项目各阶段的信息和项目各管理流程信息之间无法实现数据交换工共享。
工程项目管理信息化是一个系统工程，日，事，清涉及到项目管理理念、人员素质、管理模式、IT技术、应用等因素，要多方协调和考虑才能将信息技术整合到工程项目管理和业务之中，以提高工程项目管理效率和管理水平。
项目管理工作中经常会遇到哪些问题？有没有什么软件能较好的实现这...
以下这些问题都会遇到：1、 项目年底结算时严重超支，但不知道是具体哪里出了问题，也无从下手查看2、 项目合同信息有变化，不能动态更新至所有项目参与人知道，导致项目错误判断投入3、 工程上面的物资千头万绪，无法理清哪个项目的具体用料和物资成本4、 所有项目只能在年底结算，不能随时掌握项目的实际利润。
5、 领导无法了解每个工程项目的具体进度和计划利润和实际利润情况实现比较好的有北京的一家公司，名字叫信德宏方项目管理软件，可以看一下...
-