凡事预则立，不预则废。IT项目管理中的项目计划既是CMMI的一个关键过程域，同时也涉及到PMBOK的启动和计划阶段，涉及到范围管理，成本质量管理和风险管理等多个知识领域的内容。
对于如何做一个项目计划，在实施过程改进后一般会形成明确的项目主计划模板，因此本文重点在于根据做项目计划中遇到的问题和项目实际的一些改进方式和措施来分析如何优化改进项目计划。
问题的提出制定项目计划的时间按业界的标准一般应该占用项目周期的30%左右的时间，而我们现在做项目计划的时间一般在10%左右，所以存在项目计划中很多细节问题考虑不全的问题，或者是有些问题根本没有根据项目实际情况进行分析和裁剪而直接采用项目计划模板中的内容。
整个项目计划的制定过程中经常遇到的问题有：
项目的范围经常发生变动，从而导致项目延期，或者版本实现的用户功能不能满足用户的需求而导致用户满意度下降。 估算数据不准确，用例的复杂度没有一个较好的估算方法，很多时候项目成员估算时都采用通过估算工作量再反推用例复杂度的做法；导致估算数据有偏差直接影响到项目进度。 在编排项目进度计划时，由于对IT项目管理有明显的资源约束，如架构可能就是瓶颈资源，因此很多时候关键路径并不是最快的可以完成的项目周期，这个时候应该如何去考虑资源约束对项目计划进行优化。 在项目计划制定过程中制定了度量计划，质量计划和跟踪控制计划，但这些计划间究竟相关关系是怎么样了，这些计划的内容是如何体系到后续的跟踪控制中的。 在项目计划阶段如何做好项目风险管理计划，以及如何保证关键核心的风险能够分析到不被遗漏，如何去量化一些风险参数以及如何确认某些耗成本和资源的风险减轻措施是否值得去做。 IT项目管理与其它工程项目管理最大的区别在于IT项目管理中人的因素是一个需要重点考虑的问题，在项目计划中我们如何根据项目实际情况切实可行的制定相关的人力资源计划和沟通，培训计划。 解决思路项目计划阶段的相关问题会涉及到项目管理的很多知识领域。每个问题的解决思路都可能不同，但究其根源主要还是应该首先在项目经理个人的技能和素质的持续改进和不断提高上面。项目经理是一种复合型的角色，既需要有相关的技术知识积累又需要熟悉和了解整个业务和模式，同时还需要具备团队建设，沟通技能，时间管理等软知识的积累，具备对概率，统计和运筹等基础知识学科的积累和应用。
对于项目管理的知识体现结构可以通过思维导图整理出来，如下：
下面根据每个问题提出相关的解决思路和方法。
1 项目范围规划时候充分考虑干系人，四要素和功能依赖的平衡
开始一个新项目或版本时候，首先是和用户一起确认需求，进行项目的范围规划。项目经理在做范围规划时候应该平衡好范围，进度，质量和资源四要素，另外在确定项目范围时候还需要考虑到相关用户功能的前后置依赖关系，对于那些需要依赖系统一些没有开发的基础功能的用户功能，即使提前开发出来了也用不上，这块要跟用户确认清楚。
2 通过历史经验数据收集，复杂度估算类比，功能点法等提高项目估算准确性
估算前提是项目范围必须要很明确，项目范围明确了才可能准确地进行WBS分解。在WBS分解的时候推荐采用先功能后按生命周期的这种分解方式，这样在后期较容易对相关的功能划分增量和核算每个功能具体的成本和投入。在项目估算过程中会用到很多项目历史版本的数据，因此必须做好数据收集和项目复盘工作。
专家法估算更多的时候依赖于专家的实际经验数据和自我积累，但这种估算很难量化出来，为了将这些估算经验量化或形成项目组织级的估算模式，在条件允许时候可以同时采用功能点法和专家法进行同时估算，积累功能点估算的相关数据，为后续完全采用功能点法估算打下基础。
3 考虑资源和关键路径双重约束来安排好进度计划
由于有关键资源的约束，安排项目进度计划已经不是简单的求关键路径问题，而是还需要考虑由于关键资源约束引起的活动排队和等待的问题。
另外整个进度计划过程应该遵循WBS分解->确定活动和任务->确定依赖关系->关键资源和角色矩阵确认->对任务分配资源->对超负荷资源或资源不足进行反复的平衡这几个重要步骤来完成一个版本的项目进度计划。
4 根据项目的质量目标来贯穿项目计划中的质量计划，度量计划和后续跟踪控制
质量计划的一个重要内容就是确定质量目标，质量目标也是项目的一个重要目标，这个应该在做项目计划时候提前确定下来，而且项目的质量目标会体现到后续的估算中。对于项目度量计划也是一样道理，首先是项目自身有度量的需求，项目经理需要去关注项目的进度，成本和质量，时刻了解到项目的健康状态和偏差，这样才能够及时地去调整资源和进度，保证项目目标的实现，项目应该多去寻找度量指标的内在关系和影响，找到问题的根源，这样度量计划才能够真正发挥价值。
这里我整理后的各度量指标间的关系图如下：
7 在项目一启动就制定风险管理计划分析风险，并适当对风险参数进行量化
风险管理必须贯穿整个项目管理过程，从风险管理计划制定，到风险的识别分析和风险的具体应对和跟踪。风险分析一定要分析到风险的根源，减轻计划和应急计划也是根据风险根源进行的。风险的不确定性应该量化，你需要用这些量化的数据去分析。
什么时候需要对风险实施应对措施，你风险应对的投入是否划算？风险在项目不同的时间点对你项目的质量，工期的影响程度究竟有多大。风险的量化需要我们收集数据，采用相关的风险模型进行模拟。如风险图或Riskology工具提供的蒙特卡洛模拟器。
8 根据进度计划确认人员投入期，根据技能评估和培训需求收集来计划培训的安排
IT项目由于自身生命周期的限制，需要在项目的不同阶段投入不同角色和数量的资源来保证项目任务的完成，这个应该根据项目进度计划进行安排。
项目成员的知识和技能水平对软件项目的质量有至关重要的影响，因此项目计划阶段应该对项目成员技能进行评估，同时根据培训需求收集表收集相关的培训需求，并将相关的培训计划安排到整个项目计划中，同时对于培训的效果后期还需要专门和相关人员进行沟通和确认。
实践情况总结以上问题都是在项目中出现过的相关问题，应该具有一定的代表性。在项目管理或日常工作中，很多时候并不是我们解决问题能力差，更多的时候是发现不了问题或发现不了引起问题的根源因素。项目计划和管理中的多个问题都是通过整个项目团队的复盘总结，开发过程的评审，项目经理自查等多种方式发现的。
1.通过与业务用户的多次沟通确认项目版本的范围。
项目一般会提前2-3周同用户讨论下个版本的具体用户需求，所以作为用户接口的技术管理部一般会提前一个月收集各个事业部的相关业务需求，这样才能够保证项目的各个版本很好的迭代起来。对于收集到的用户需求，根据需求的重要性和紧急程度确认各个需求的优先级别，同时每个需求都还会附加上业务期望的解决和上线时间。
在第一次讨论完成后，项目组会组织BA，架构和项目经理共同开会讨论用户需求信息，项目组内部讨论一般会根据该功能实现后可能的使用频度，实现的工作量，实现该功能对系统已有功能的影响等多个方面对用户需求进行讨论和规模工作量的初步估计，给出一个具体的项目周期和范围的几对可选值。如1个月可以实现前6个需求，2个月可以实现前十个需求，同时对那些暂时使用频度不会很高，对系统的增值价值不高的需求提出自己的意见。
有了这些基础信息后再组织和用户的第二次业务讨论，这个时候用户基本可以从几对可选值中选择可以满足自己的安排。如果存在很多个功能优先级都很高，又对解决期限有强烈要求的时候，这时候产品经理就会考虑在项目人力资源上的多投入来满足用户的需求。
这里通过项目多个版本实践，强调的几点是：
1)一些用户提出很紧急的需求对整个用户群或系统来说并不紧急，如一些业务管理员的操作新需求，这些功能基本上一个月才使用几次，使用人数在1/1000以下，所以花费较大的人力资源实现这种需求对整个系统的增值并不高。一般这种需求即使用户优先级高，IT通过讨论后也会降低其优先级。
2)如果用户需求存在对系统的核心模块重大改造时，一般会延期实现或考虑替代方案，如项目在系统管理和工作流模块，经过多次的系统测试，回归测试和验收测试才运行稳定，如果用户提出的新需求对这块存在重大改造，那对整个系统引起的风险是相当高的。
3)在项目范围确定中存在了需求挖掘过程，IT协助用户将点的需求扩展为面的需求。如项目的V4.1版本用户提出了在齐套清单功能上，增加对清单内容表格的搜索功能，这个功能后期转化为了对整个系统的GRID都支持模糊搜索。
通过这种方式确认出来的项目范围和项目周期就和用户很好的达成了一致，保证了后续计划和执行阶段工作的顺利开展。
2.不断地对估算方法进行总结和实践以提高估算准确性
对于专家法估算，困扰项目的一个主要问题是如何把用例复杂度估计的准确点，因为在估算时候WBS的工作包基本上都会分解到1个用例的粒度，但很明显的是各个用例的复杂度是明显不同的，组织级在用例复杂度上面根据基本流+扩展流+业务规则的流总数来进行的定义。由于第一次估算时候软件需求还没有出来，因此问题转化为了如何较准确的确认清楚软件需求的流总数，这个数据的估算难度相当大，更多的只要依赖专家的经验。
在项目的前续几个版本中，对该复杂度的估算也不是很理想，很多时候只能倒推的方式来进行估算，为了进一步估算准确，从V2.2版本开始项目关注与各个版本的复盘和历史数据的收集，争取找到需求页数，用例数，流总数，业务对象数，数据库设计字段数，界面元素各数，工作量，代码行这些因子的关系，收集数据如下：
通过对这些采集数据的关联性分析，基本得到的可以借鉴的经验数据如下：
用例复杂度可以和用户需求建立一定的对应关系，关系可以体现到页数，如果更细化一点可以体现到用户需求中的输入输出列表和数据项，但要求用户需求足够细化。
用户需求中可以看到的是处理，而处理更多的是体现业务规则，原有估算中把业务规则的一个流和基本流扩展流等同看待有问题，这里根据项目经验提出业务规则对用例复杂度的影响权重应该加大，3-5个业务规则复杂度应该到2，5-10个业务规则复杂度应该为3或4,对于出现超过10个业务规则的用例必须进行子用例的拆分。这样在用户需求写得较好情况下很容易根据用户需求判定出用例的复杂度。
对于设计界面操作的用户需求，当其用户需求说明书涉及到的输入输出项超过20的时候要考虑增加估算用例的复杂度，在这里数据项再每增加10个用例复杂度加1。
在项目大版本，而且刚开始用户需求说明书不够详细的情况下，在软件需求完成后必须进行第二次估算，这点在项目 V4.0版本中按此规则进行，由于软需已经完成，需求和设计人员都可以较为准确地估算出用例的规模和复杂度。确立该规则的一个重要原因在于需求和设计开发工作量比一般为1:5，说明需求阶段2天的工作量偏差反映到设计开发阶段将是10天的工作量偏差，这个工期偏差对项目来说往往是致命的打击。
所以工作量比例分布仅仅是经验数据，很多时候不能完全地不加分析地采用，更多的时候还需要考虑到设计开发工作的实际情况和特殊性。在项目项目中第二次估算时估计出设计开发总量后，项目经理都通知到各大功能的设计负责人对功能进行功能点的细分，并对该模块的开发进度进行细排，细排后发现保存和载入默认值这块有一周的工作量，但体现到需求文档仅仅是一句话；对于部件的版本控制需要考虑抽象和复用出公用的版本控制服务，但前期作软件需求的时候这个公用服务根本没有需求用例对应，根据这些情况，项目经理进一步对进度计划进行了细化并增加了一个人力资源投入。
确定了估算的规模后，另外一个重点要确认的就是项目的生产率和工作量比例的分布，需求阶段的生产率经过多个版本的积累已经较稳定在0.8到1之间，但设计开发的生产率由于项目成员的变动导致不稳定，V4.0版本项目有三名新员工参加，因此需求与设计开发的比例数据不能够完全采用上个版本的复盘数据，在这里项目稍微做了调整，将需求与设计开发的比例调整到1:5左右，以使设计开发的工作量适当增加。
如果一直停留在估计需求规模层次上，估算准确度是很难提高的，而且项目也迫切地需求了解到代码行的生产效率情况，每个人在设计开发阶段的工作量的实际分布情况，因此在V4.0版本，决定在南京项目组推广个体软件过程，并引入了PSP Studio工具对过程数据进行了准确记录，如下：
由于结队中有一名新员工，配置管理编码生产率为：6223÷313×8≈159行/人日。而全是老员工的部件管理功能的代码生产率为 14500/55 = 264 行/人日。所以基本上可以得出有新员工的时候编码生产率可以取150行/人日。而对于全是老员工可以取250行/人日。这个数据的采集和积累对项目后期的编码工作量估算有很好的指导意义。对于PSP具体应用请参考项目组高波提交的《PSP应用最佳实践》一文。
具体的采用PSP Studio收集数据见如下截图：
另外对于将估算的经验更好的文档化或量化出来，个人建议在大功能版本时候采用功能点进行估算，或者同时采用专家法和功能点法进行估算，根据多个版本的积累来推算出功能点法的生产率数据，否则功能点法很难用起来。项目项目Q02.01版本在第二次估算中采用了功能点法，得出的一些经验生产率数据如下：
具体的功能点法原理和使用方法也在项目组内进行了培训，并形成了相关的使用文档，使项目成员都能够理解功能点法的具体使用方法。
注：数据收集和分析是清楚知道自己效率的基础，也是项目计划逐步收敛和偏差可控的基础，不要想着一开始计划就准确无偏差，而是应该通过持续迭代计划不断的调整基准参考。
3.考虑资源和关键路径双重约束来安排进度计划
项目的V4.0版本是一个15个人的3个月的大版本，通过最后复盘的5万多行代码行产出也基本可以说明这点。
资源约束和依赖关系约束一直是排进度计划的两大要点，V4.0版本分解到最后有200多个任务项，如果全部依赖关系都建立差不多有50个依赖关系，这样即使Project能够自动计算关键路径，项目经理拿到这些数据也无从下手。因此制定进度计划应该遵循先粗后细的原则，首先应该在工作包这个层次对依赖关系和关键路径进行寻找，在做这个工作之前，项目组首先对角色责任矩阵进行了识别，如下：
图中可以明显地看出架构工程是项目的关键资源，必须在架构结构上优先保证架构设计工作。整个V4.0版本共6个工作包，因此可以得到的粗进度计划图如下，其中红色为关键路径：
对该粗进度计划进行分析可以得到以下结论：
需求不存在前后依赖总工作量55，三个BA考虑加班三周总工作量为54，可以满足需求三周完成。 架构设计跨度10天，由于关键路径，其它任务都无法进行，这里必须进行调整，因此调整计划为架构设计和最后一周需求并行，这里压缩工期5天。 视图管理在关键路径上，造成了配置管理和产品结构浏览任务的等待，但视图管理和总体架构设计关系不大，架构花一天完全可以考虑清楚，因此视图管理在这里考虑闯红灯提前进行结队开发，压缩工期3天。 整个项目共可以结队5组人员，其中除了属性类型管理功能外，其它功能都基本安排饱和，而且设计最多带两个编码，一个任务上最多安排三个资源，不能再通过安排更多的资源来压缩工期。先分解再集成，粗粒度工作分解后能够形成并行作业，同时长周期工作分解后能够快速形成上游输出推送到下游活动，减少等待时间。在关键资源受限情况下，需要首先考虑最大化地提升前期的资源利用率，其次才是关键路径。
通过粗进度计划的编排，项目经理基本对整个进度情况就有了总体的认识，这个时候才能够进一步分解工作包为任务，排细化的进度计划。在进度计划的制定中，我们常使用固定工期的方法进行，这个方法好处就是某个进度延误可以通过周末加班赶工而不影响后续的任务，但这个方法的一个大弊端就是在估算和下达任务时候思维里面老是按照一周的概念再考虑问题，有时候反而无法充分利用资源，设置的关键路径也无法起到很好的作用。
因此可以更科学的采用固定工时的方式来排PMS任务，工时可以直接从估算的数据中取到，在对任务分配资源的时候，优先保证关键资源分配到关键任务上面，同时当关键资源承担多个任务的时候一个普遍原则是：
设A1,B1是两个关键任务，A的后续依赖任务是A2,B1的后续依赖任务是B2，A1可以比B1早3天开始，A2到结束关键路径长为L1，B2到结束关键路径长为L2.
A.当两个从后续任务开始算起的关键路径长差不多时，关键资源优先开始可以提前开始的任务。即优先开始A1任务。 B.当L1比L2短3天以上时候，这个时候反而要优先开始B1任务，虽然这个时候开始要闲置关键资源，这点很重要。这个可以根据运筹学的最优化方法进行建模，去寻找最优解。但在进行进度计划制定时候不可能采用这么复杂的方法，更多的是采用一些普遍的经验和原则。
通过设置了关键路径，对任务安排了相关资源后，Project就可以自动的生成出整个版本的工期了，在生成工期完成后需要进入到资源负荷图对资源负荷情况进行确认，如果考虑到加班，资源负荷在120%，因此当负荷超过120%的时候就需要对资源负荷情况进行适当的调整，如此反复多次，可以得到一个比较可行的进度计划。
在V4.0版本进行完第二次估算后，项目经理又对进度计划进一步细化和完善，得到了每一个功能确切的可以交付测试的时间点，根据最后的时间情况来看，属性类型管理和视图管理都提前交付测试，部件管理，批置管理和产品结构浏览正常交付，但集成时间多花2天，工程变更延后2天交付，偏差都在受控范围内。
4.确定项目的质量目标和质量计划
一个软件项目除了进度目标外，另外一个最重要的目标就是质量目标，而质量目标并不是简单指版本发布的时候测试问题全部解决，而更多关注的是你版本发布后的缺陷泄露情况，这个质量目标在项目完成的时候无法马上得到数据和进行验证的。所以一般是通过间接控制的方式，即可以去估计我们期望的缺陷和BUG的发现情况，当质量目标高的时候，就期望在评审和测试阶段近可能多的发现BUG，直接自然泄露到版本发布后的缺陷就少。
由于一个项目版本的总缺陷数量应该是一定的，只是在交付后发现出来还是在交付前发现出来。如果能够在交付前发现出来我们软件的质量就高。BUG缺陷密度，总缺陷数，交付后缺陷数，代码行这些指标间有着相互影响和作用。在做一个项目版本的时候，应该对这些关系有比较明确的了解，具体关系如下图(中间为交付前BUG比重)
上表说明当交付前缺陷密度过高的时候就很难保证交付后的缺陷密度很低。所以根据经验应该将交付前BUG的比重控制在80-90%的范围内。上表中的绿色底纹数据是我们可以参考和借鉴的数据。
根据项目历史版本数据统计，缺陷密度一般在4-6之间，因此交付密度采用0.8或1都是可行的。对于交付后的软件的缺陷数据，CMMI三级的企业一般在0.5-1.5个/千行代码，CMMI四级企业在0.5个/千行代码。所以根据业界这个标准和组织级的建议，项目V4.0版本采用的交付后缺陷密度为0.8个/千行。
在项目 V2.6版本，项目就根据组织级的规程仔细进行了复盘，其中得出的需求规模是39用例，产出的代码行是30068，实际的缺陷总数是319个，测试阶段的BUG数量为115个。
因此可以得出的总缺陷密度为8.17个/UC，而跟测试BUG相关的测试缺陷密度为3.8。因此在项目V4.0版本项目的估算中也采用了这些数据，并取得了较好的效果，具体的对比和偏差如下：
如果项目某个版本用户提出特殊的质量要求，就需要对项目的质量目标进行调整，质量目标在确定后将直接影响到估算的工作量分布，因此在制定项目计划的时候一定是先制定出项目的质量目标，然后在根据质量目标去指导和约束估算过程。
质量目标预计出来的数据在项目执行和跟踪过程中也有用处，我们时刻要使用该数据去检查我整个项目过程是否出现偏离，如果预计的需求缺陷是160个时候，如果需求阶段实际完成缺陷只有50个或更少，这个时候就要进行分析是否是同行评审过程有问题，该发现的缺陷没有发现出来，是否需要重新组织评审或增加预审时间，只有这样才能够真正保证上游缺陷不泄露到后续工作中。
需要注意的是项目质量目标的确认过程不仅仅是项目组成员自己确定，更多的是需要和QA和测试负责人根据该版本的业务需求共同讨论和确定，QA可以根据其它项目情况或业界的一些标准给出有建设性的意见，测试也可以根据项目前续版本的测试情况来确认项目是否可以达到制定的质量目标。
项目质量目标确认后，还要进一步的确认项目的质量策略，质量策略就是你为了达到这些质量目标而需要采用的方法或手段。如质量目标要求高的时候，推算出评审需要发现100个缺陷，如果采用单人复审或多人复审就根本做不到发现这么多缺陷，这个时候就要考虑哪些要采用审查的方式以及审查的具体比例规划。
在项目质量目标确认后，在后续的项目执行过程中要时刻关注这些目标的执行情况，如评审是否充分，测试是否发现了预计多的BUG，当出现较大偏差的时候要及时分析原因和采用相关的应对措施。
制定项目的风险管理计划风险管理是项目管理的一个重要内容，风险管理的过程贯穿整个项目生命周期。风险管理计划中首先要确定风险管理小组的成员和各自的职责，对于项目项目，风险小组负责人为项目经理，项目B为核心成员主要负责分析需求方面的风险，架构为核心成员主要分析技术方面的风险，用户主要分析业务方面的风险。
风险小组确认后就要确定风险管理过程中需要使用的相关的工具和方法。其中包括风险识别的方法，风险分析的方法，风险监控的方法和风险应对的方法。这些方法和工具组织级都有明确的定义和指导原则，对于存在多种方法时要根据项目实际情况选择。
对于项目的风险来源和分类，组织级都有明确的标准和定义，项目一般都可以直接采用，但需要注意的是有可能需要项目实际情况对其进行裁剪。如项目本身不可能存在采购方面的风险时候，就需要将其裁剪到，这样在后续的风险识别和分析中都不用再过多考虑。
项目在制定具体的风险管理参数的时候，虽然组织级有了明确的参数具体的含义定义，但项目更多应该根据实际情况进行调整。如组织级定义项目延期两个月该风险后果为0.8，但当项目版本周期仅仅是1个多月的时候，这个时候当项目延期一周后果就相当高而应该取0.8了。所以这里项目经理应该特别注意进行修改。
项目计划中的风险应对策略不是针对某个特定风险的，所以这里的应对策略更多是通用的应对策略：如开发原型，技能评估和培训，数据模拟等。当遇到实际的风险时候，如何去应对还要根据风险的实际情况进行分析。
项目计划阶段就应该分析出项目在当前状况下的所有风险，并对风险进行优先级排序，当确认了是项目的关键风险后，需要制定这些风险的减轻计划和应对措施，这些内容都需要体现到PMS进度计划中，PMS进度计划必须包含这些内容才是一份完整的进度计划。
当我们积累了足够多的历史数据后可以对风险进行组合分析和量化分析，对于风险量化分析可以采用决策树和蒙特卡洛模拟等方法进行。具体的方法可以参考以下文档：
制定项目的人员培训和技能评估计划在IT现阶段项目计划中有专门的资源计划，这里面有相关各阶段软硬件资源的需求，个人认为在这里更重要的是人员培训和技能评估计划的制定，因为需求不稳定和人员流动一直被公认为软件项目的两大最高危风险。
项目系统早在V2.2版本就开始考虑培训需求的收集工作，每个项目成员都有很多相关的培训需求而且可能会比较发散，因此项目首先通过历史版本的总结，从业务，技术和管理相关的培训列出的可能的培训课程，然后制作成相关的数据库表格，规定每位成员最多只能选择三门希望参加的培训课程，然后对培训结果进行汇总分析，排定培训安排的优先级别计划。
如下图：
这样根据收集的数据进行分析后，得出具体的培训计划安排。通过这种方式确认出来的培训计划将很有针对性，可以满足大多数项目成员的培训需求，同时培训课程是大家选择出来的，培训的积极性和主动性也较高。
在项目计划中除了安排培训外，还需要制定相关的技能评估计划，第一个是有效的检查培训的效果，第二是考查项目成员的真实技能情况便于后期安排有针对性的指导。在项目项目的V4.0版本中，由于有多名新员工，因此项目一开始就安排了相关的培训和以师带徒的辅导，同时制定计划要在阶段任务开始时候对新员工的技能进行一次当面的沟通和确认，以安排后期的需求和确认新员工是否达到项目要求。
因此在项目中，项目5月底项目经理专门和每位新员工进行当面沟通确认技能情况。涉及了项目开发模式，工作流，系统管理，文档管理，系统业务，数据库等多项内容，并对各个分项内容进行技能评估，绿色表示技能基本达到，红色表示技能有明显欠缺。新员工在经过培训和自学后基本可以胜任编码工作，但遇到功能模块跟工作流和系统管理接口部分的开发时候，需要设计人员仔细讲解。
效果评价对于项目计划的优化改进实施体现在项目项目管理的多个版本中，具体的效果可以总结为以下几个点：
对于在1到1个半月左右小版本，估算准确度在90%以上，一般只做一次估算即满足要求，项目进度偏差也很小，基本都正常发版。 对于大于2个月的版本，项目一般做两次估算，第一次估算准确度在70%左右，软件需求完成后第二次估算准确度在90%以上，因此第二次估算完成后对进度计划进行调整，调整后项目进度偏差可以控制在5%以内。 从V2.1版本以来的项目多个版本，由于前期跟业务沟通的充分，用户需求变更很少，基本没有出现过需求频繁变更对项目进度和质量造成影响情况。 项目形成了一套大版本进度计划排定，关键资源和关键路径考虑的方法，使得2-3个月的大版本也可以在计划需求阶段排出较为细致的进度计划来。 项目重视风险计划和风险的管理，风险转化为实际问题的情况很少。 培训计划，技能评估，异地沟通和团队管理在项目项目已经形成了相关的规程和方法，项目基本可以做到个别人员流失不会对整个项目造成较大冲击。注：本文为我多年前担任专职IT项目经理进行项目计划，项目过程管控方面的最佳实践输出，当前来看一些内容仍然具备参考价值。
