IT项目管理过程中易出现的问题及解决方法.docx
《IT项目管理过程中易出现的问题及解决方法.docx》由会员分享，可在线阅读，更多相关《IT项目管理过程中易出现的问题及解决方法.docx（11页珍藏版）》请在冰点文库上搜索。
IT项目管理过程中易出现的问题及解决方法
IT项目管理过程中易出现的问题及解决方法
大多数IT专业人士本身并不是专门的管理人员，他们都知道，自己随时都可能被要求管理一个项目，却很可能会遇到很多问题。
下面我们就将一些常见的问题及其答案介绍给大家，希望能够对大家有所帮助。
一、什么是ROI?
所谓ROI指的是投资回报。
商业管理人士希望能够通过一种定量的判断标准来了解在进行了一定的资源投入之后能够从项目上得到的收益如何。
有的时候，IT项目给公司带来的收益体现在公司的财政状况上，也有的时候，这种收益体现在财政状况之外的其他方面，还有的时候是两个方面兼而有之。
通常，对项目进行投资回报分析有三个原因：
一是证明现有项目的价值，二是证明对项目进行先期投资的合理性，三是使下一步的具体行动更具说服力。
二、如何计算项目的投资回报？
在大多数财政性投资回报的计算当中，了解下面这些信息都是必需的：
1、项目成本：
维护与运营成本（包括项目分析期内的每一年）
2、财政收益（如果有的话。
包括项目分析期内的每一年）
3、每年的现金流动（从每年的财政收入中减去成本支出）
在进行非财政性投资回报计算时，根据计算方法的不同，需要的一些数字。
一般来说，包括成本投入和能够表明业务进展的非财务方面的数据。
（如时间、数量或质量等）在大多数情况下，你可能要计算财务上的投资回报数据。
应用商业投资回报计算器或是其他的同类工具，任何人都能够简单快速的完成对投资回报的计算。
三、什么是成本效益分析？
在任何的商业-IT决策当中，决策者都会面临多种选择。
你可以选择“A”方案，也可以选择“B”方案，还可以哪个方案都不选。
最后只有一个方案是“最佳”的。
成本效益分析（CBA）会对各种可供选择的方案（技术、项目等）进行比较，通过比较让决策者了解哪种方案是最佳的。
好的成本收益分析可以帮助决策者计算出能表明项目影响力的数据。
有的时候，成本收益分析是对两个或更多的可选方案的成本和收益进行系统的评估，让决策者了解哪种方案能够给公司带来最大的价值。
但同时，成本效益分析又是为了让大家对项目投资回报的预期更理性。
它可能包括用在每个内部员工身上的平均成本、系统预期的使用年限、资本费用和用于雇佣合同工的费用等。
四、到底什么是风险管理？
风险管理的目的是确定项目可能出现的问题以及新系统运行起来之后可能出现的问题，确定这些问题一旦出现会造成的影响。
风险管理的另外一个组成部分就是对问题出现的可能性进行评估。
综合考虑了所有的因素之后，项目经理就能够对项目风险做到心中有数了。
在项目计划当中，项目经理应该列出所有出现可能性较高的风险及其可能带来的消极影响，当然，那些出现可能性一般的风险也不能忽视。
要采取切实的行动来消除或减轻列举出的各种风险。
五、什么是项目计划？
在项目开始之前，项目经理先要制定项目计划。
项目计划的制定可以帮助项目经理对项目的任务和工期进行预测，还可以帮助项目经理对未来几个月内的详细工作进行规划，合理配置人员和各种资源。
设定一系列一致的项目管理规程会对项目管理有所帮助。
项目计划中应当包含的要素有范围管理、风险、沟通、人员配置等。
同样，制定项目计划的关键是通过对项目的界定来更好的通过管理实现项目预期。
例如，如果你对范围变化请求的批准程序作出了界定并且同大家达成了一致，那么在项目开始之后对变化进行管理就会简单得多。
六、项目交付的重要性如何？
项目交付非常重要。
因为它可以帮助项目经理获得股东和项目赞助人的认可，并且可以让股东和项目赞助人了解项目的进展状况。
项目交付是项目进展的切实成果，如项目计划或项目计划的某个特定组成部分，比如：
状态报告等。
七、项目影响分析的目的是什么？
项目完成之后会使公司某些方面的运作产生变化，而项目进行过程当中又必然要求一定的成本投入。
对项目进行前后的不同状况进行比较就是项目影响力分析。
这是决定项目是否应当继续进行下去的一个重要判断标准。
八、商业案例与成本收益分析是否等同？
两者是相似的，但并不完全等同。
两者都是通过事实来让决策者做出更为明智的决策。
商业案例是一种鼓吹似的文档，它的目的是劝说各个利益相关的群体和部门采取某些具体的行动。
与成本收益分析相比，商业案例更全面。
比如说，商业案例当中通常都会包括对战略性结盟的讨论，而这通常是成本收益分析所不具备的。
成本收益分析仅仅是对一些可行的选择方案的“中立”评估，它涉及到各种可供选择的方案的成本、收益、风险、回报等关键数据，并且通过比较让决策者了解哪种方案最有利。
商业案例当中通常都包括成本收益分析的结果。
九、什么是范围管理？
对项目范围进行界定的目的是清楚的描述项目的逻辑范围并在此问题上征得大家的一致。
对项目范围的陈述用于界定哪些要素在项目范围之内，而哪些要素在项目范围之外。
能够界定的项目范围所涉及的方面越多，项目进展起来就会越顺利。
下面这些信息可能会起到帮助作用：
1、范围内和范围外的任务类型（业务需求、现状评估）
2、范围内和范围外的生命周期流程（分析、设计、测试）
3、范围内和范围外的数据类型（财务、销售、员工）
4、范围内和范围外的数据来源或数据库（账单、公司总帐，薪水明细）
5、范围内和范围外的部门（人力资源、制造商、供货商）
6、范围内和范围外的主要功能（决策支持、数据输入、管理报告）
十、项目范围蔓延是如何发生的？
很多项目经理都能够意识到大的范围变化，但是对小的范围变化就不那么细心了。
因此在实际工作当中就往往有这样一种趋势，很多项目经理没有经过太多的思考就把新的工作增加到了项目当中。
我们所说的项目蔓延就是指一个项目接受了很多小的变化的情况。
当这些小的变化都聚合到一起的时候，项目小组才意识到他们承担了太多的超额任务，已经无法按照原有的时间和预算框架来完成项目了。
十一、什么是项目成功完成的标准？
项目的质量是由客户而不是项目经理决定的。
项目经理可能并不了解客户对项目的预期，这可能会增加项目经理的工作难度。
在这个时候判断项目是否成功完成的标准就派上用场了。
有了这个标准，项目小组和客户之间在项目交付期望上就达成了一致。
这个标准应该被包含在项目计划当中。
十二、SLA的作用是什么？
服务品质协议（ServiceLevelAgreement，SLA）以契约的方式体现了客户对服务供应商的IT要求。
尽管随着时间的不断推移，服务品质协议的文本也会有所改动以适应新的IT功能的发展。
它最初是用来保证网络服务的带宽和连通性的。
十三、项目资助人和利益关系人之间的区别是什么？
项目资助人是为项目出资的个人或团体的代表。
而利益关系人则是与项目有直接利益关系的个人。
如果项目会对某人的工作产生影响，那这个人就是利益关系人。
有些利益关系人直接参与到项目当中，也有的利益关系人委托了代表来实现自己的利益。
十四、什么是项目审计？
在项目审计过程当中，项目经理会提出一系列问题，以确保项目按照原有的程序和规程进行。
例如下面的这些问题：
1、关键的利益关系人是否参与了项目计划的制定？
2、项目资助人和主要利益关系人是否正式批准了项目计划中对项目的界定
3、工作计划是否被用来对小组成员的工作进行管理和监督？
4、工作计划是否准确的反映了实际的工作情况？
5、项目经理是否能够明确说明项目在某个时间的实际进展状况以及按照计划应该达到的状态？
6、项目的具体目标是否能够实现？
7、项目的成本、工期和质量是否都处在计划的轨道上？
8、已经预计到的风险是否得到了控制？
是否查明有新的风险存在？
9、问题是否能够被及时发现并得到解决？
尽管在大多数公司当中，公司内部的项目管理办公室（PMO）就可以提供项目审计服务，但是服务供应商也应该单独提供该服务。
实际上，有很多顾问在项目审计方面都有着丰富的专业经验。
有的时候，让外部机构和专业人士承担项目审计的职责能够使项目审计更为正规，也更能够引起公司高级管理层的重视。
十五、如何判断“从属”项目任务？
“从属”项目任务是指那些要依赖于其他任务的完成才能够完成的项目任务。
例如，在为企业内部互联网做一个视觉效果之前，你需要首先对商业需求进行评估。
项目任务的依赖性主要体现为两种形式：
只有在某项任务完成之后，旨在完成该从属项目任务的工作才能够开始进行。
你的工作直接影响到下一个人的工作，你的工作成果直接为下一个人完成从属项目任务服务。
十六、什么是项目里程碑（projectmilestones）？
项目里程碑是指项目进展中最主要的任务。
项目里程碑应该被列在项目计划当中，以便让股东了解在项目进行过程当中的那些时间段会有主要的项目任务完成。
十七、哪些阶段与项目相对应？
与项目相关的阶段包括：
1、探索阶段。
在这个阶段当中，公司要对是否需要进行某个项目进行判断。
在探索阶段，项目经理要领导大家根据公司目前的业务状况进行项目需求分析，并且了解项目需要的资源是否具备。
2、开始阶段。
在这个阶段当中，项目经理要对项目进行初步的计划，争取利益关系人的通过，并且争取到所需的预算。
3、设计阶段。
在这个阶段当中，项目经理要对现有的状况进行分析，决定你要做哪些工作项目，看看需要通过项目的完成实现哪些目标。
在大多数项目当中，利益关系人都会首先对项目需求进行界定，明确说明需要什么。
然后技术小组再界定如何实现这些需求。
对项目需求的界定是项目成果能够满足公司业务需求的基础。
4、构建阶段。
在这个阶段当中，项目经理要明确如何开展项目。
5、测试阶段。
在项目启动之前，这个时候你应该了解项目实际带来的效果。
6、实施阶段。
这个阶段需要培训使用新系统的用户，与利益关系人进行沟通，产品投产。
7、评估阶段。
在进入评估阶段之前，项目经理并不知道新的系统是否能够满足公司的业务需求。
而在对项目进行了评估之后，大家才能够判断是应该对项目计划进行修改，还是维持原有计划不变，又或是扩大乃至取消项目计划。
十八、什么是过程质量控制？
它与过程质量保证有何不同？
尽管过程质量控制和过程质量保证都是项目小组为了保证项目的高质量完成而采取的持续行动，两者之间还是有区别的。
这种区别体现在诸多方面，而最重要的一点就是没有质量保证的质量控制只能在问题出现之后才发现它，而不能防患于未然。
项目小组的每一个成员都必须有质量意识，争取把项目进行过程当中出现的问题的数量降到最低。
项目经理和项目小组成员都必须明白，质量管理的首要目标就是在不出问题的情况下完成项目，第二个目标则是尽可能及早发现问题。
分析一个项目经理的面试
一、背景
梁军（化名），北京某软件公司的项目经理，男，30岁，大学本科，在两家企业都担任过项目经理，能力都比较被认可，但最近所在企业经济效益较差，多次拖欠工资，梁军决定跳槽，仍以应聘项目经理为主，简历发出去后，面试机会很多，经过一些电话的初步筛选，梁军一口气面试了近20家企业，但没想到基本都是第一轮顺利通过，到了后面几轮，尤其是到了关键轮次，就再也没有了消息，梁军有些郁闷了。
二．分析
梁军找到我，“刘老师，请您给我分析分析吧！
”，我仔细了解了梁军的面试过程，发现首先是薪资要求偏高，梁军的综合素质虽然不错，但是做过的项目跟同行相比，不算多，尤其是在两家企业做项目时，行业完全不同，所以积累不丰。
此次跳槽，因企业经营困难，拖欠工资，梁军有一定的经济压力，急于找份能发按时发工资的工作是主要的，所以，应当调整自己的期望，薪资上不能要求太高。
我跟他说，首轮顺利通过，说明其沟通和表达能力被认可，但是到了后面，企业的中高层出面，那些老道的面试官很容易看出项目经验不足，如果事先准备不充分，印象自然不好。
比如，梁军面试一家知名企业的项目经理，都过了5论，最后一轮，企业要求他讲一个PPT，介绍他熟悉的项目管理流程，具体提要求的是位管行政的副总，应该说，梁军还是有一些经验的，事先了解会有什么人来听，他们关注什么，他本来以为最多也就是部门经理来听听，没想到去的是4个高层，却要求介绍需求挖掘和需求控制等需求管理的内容，梁军有些紧张，只好解释了材料准备不对的缘由，并将准备好的PPT过了一遍，但是自己都感觉底气不足，没什么效果。
这个面试过程可能并不常见，但确实反映出梁军作为项目经理的一些缺陷，比如：
首先，发现自己准备的材料不是人家想要的时候，没必要过多解释缘由；其次，与其浪费时间讲人家不感兴趣的，不如坦诚沟通，问清楚面试官的考察目的，如果是考察方案讲解能力，那么，可以花些时间讲解准备好的PPT，但无须从头讲到尾，如果面试官感兴趣的是需求管理本身，那么，不如就谈谈自己对这方面的认识和理解，想必面试官不是要听他做培训，只是想了解他是如何做需求管理的吧。
三、总结
当然，如果自己的能力确实达不到企业的要求，也不必强求，否则，依靠面试技巧，即便过了关，将来在企业里生存下来也是满困难的。
（刘羚）
较大型项目的产品开发工作心得
近期做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。
从中得到的一些关于设计较大型产品的心得，拿出来跟大家分享。
一、立项前：
1、统一元素设计需考虑周全
也许是初创团队的缘故，我不得不感叹团队对产品经理要求之严格之缜密，项目全程只有一个人负责，所以大到产品线对接，小到一句提示的位置和展示形式都需要一一推敲。
哪些元素应该做到统一？
A、图片方面：
调取图片的统一尺寸;如果是上传图片类的操作，需要考虑周全全站的调取情况，以及考虑是否统一预览图的尺寸等。
B、文字方面：
是否有统一的段落前“·”号;统一的链接状态;统一的字体、间距、行高等。
C、提示方面：
统一的操作成功/失败提示;统一的弹窗形式;提示语言采用较统一的句型;为空情况的友好提醒;溢出情况的友好提醒;表单实时验证的提醒形式等。
D、细节交互：
未激活功能的按钮做“灰色”处理（例如用户没有勾选信息时批量删除按钮不可使用）;按钮点击的状态统一（例如增加“提交中”的按钮状态，以防止网速慢用户狂点某一按钮的情况）;特殊控件的统一等。
也许会有朋友说，上面有些是交互设计师需要做的事，但我一直认为作为一个产品经理考虑周全一些，没坏处。
这些“统一”同样可以用在验收阶段，要知道，即使一个像素也可以改变整个产品的感觉。
2、原有功能的去留
我一直觉得升级已有产品比开发新产品难一些。
这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。
改进已有产品常常需要面对一个最棘手的问题：
原有功能是去是留？
A、原功能去掉的话是不是会影响部分用户使用？
是否需要通过公告、站内信、界面引导等方式友好地告知用户？
怎样把对用户的伤害降至最低？
B、原功能留下的话是不是可以优化完善？
听到了什么用户群怎样的声音？
是否要在这次升级中做调整？
这些问题当接到项目的时候，产品经理就应该考虑周全了。
特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到PRD说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是Ta摘的，别把将来最能结果的枝干给砍了。
3、产品线上下游的对接
昨天有跟朋友聊起淘宝强势之处，就是产品与产品紧密捏合，线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基，无可撼动。
所以把握产品线上下游和产品周边很重要，即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心，甚至是访问统计、数据需求的变更。
这要求在产品设计开始前，需要把该产品“连根拔起”，仔细梳理相关脉络，如果产品线够长，一个清晰的产品线结构图很有必要。
二、项目中：
1、项目期间来自相关产品线调整的影响
项目期间相关产品线的调整是我最不愿意遇到的情况，这就像你在通往目的地的道路上高速行驶，就快要到达终点了，突然一个人告诉你：
你走错路了。
项目里有一个通用模块，产品设计到一半，这个通用模块改了;项目里有一个流程，产品做到一半，这个流程废弃了;最要命的是已经立项开发了，你不得不硬着头皮跟程序员说：
“因为一些不可抗拒原因，这个需求咱不做了。
”
对于一个耗时较长的项目来说，这种情况难以避免，事出原因私自总结有三：
A、严重体验性问题：
例如某个流程遭到大量用户的不满，为防止用户流失，不得不做临时调整，而倒霉的是，你也在用这个流程。
B、相关项目的影响：
包括并行项目和新项目。
例如你的同事在设计另一个产品，你们的产品相互牵扯较多，所以需求分析时做过很多沟通，但有一天，同事告诉你，Ta的一个需求做临时调整了会影响到你，怎么办？
C、老板的突然决定：
不举例。
最终的解决的方法不外乎三种：
立即调整、延期调整、不调整。
个人的处理原则一般是对A种情况进行立即调整，对B、C情况讨论并选择性延期。
为什么这么做呢？
A情况是必须要改的，时间早晚问题，长痛不如短痛，B、C两种情况必须坐下来细细讨论。
需了解这个需求为什么要改？
是长期对策还是临时决定？
能否延期，记录需求等下一版本再开发？
如果B、C情况提出来的需求没过两天又有改变，那与你配合的前端和程序员也太没有安全感了。
这个时代能耐心阅读完2000枚汉字的人越来越少，较大型项目的产品工作心得［下］未完待续，欢迎交流。
（作者：
水宿鸟）
升级会员 