| 【相关分析】（9个分析） |
|
|
时间：2008-04-25
题目： 不专业的分析
分析：存在的问题：
老高承接的是一个信息系统开发项目的管理工作，他为了提高项目进度采取了工作细分的方式。从个各部分分别测试的效果来说，还不能确定在管理上是否出现问题，各部分集成以后问题就凸现出来了。从管理的整个过程说，我们有理由相信老高对这个工作并不是非常熟悉，也许他只是一个负责人，执行组织和协调的工作。因为对项目缺乏必要的了解，虽然他在工作细分的管理上做得很好，但还是达不到目的。至于出现越来越乱的问题，主要不是技术方面的原因，而是心理方面有着过大的压力。
问题总结：
1、老高对此项目的认知度不是很高（侧面反应招标不是很成功）。
2、项目成员中缺少组织过相关项目的人。
3、投资者对项目进度要求过高或老高急于完成项目。
4、项目成员之间缺乏有效的沟通。
5、项目开始前没有对问题进行全面的考虑。
6、因为信息系统本身要求的逻辑性和精确性很高，有可能是在某一环节小小的失误使项目功亏一篑。
以上是可能存在的问题。
解决方法：
1、在招标投标环节处理得更慎重一些。
2、老高选择项目中能力和经验比较好的成员协助自己的组织工作。
3、加强团队成员之间的沟通，阶段性的对项目的相容性进行讨论。
4、问题出现时，稳定自己和团队成员，冷静地思考和分析，尽最大的努力完成集成工作。
5、关键时刻邀请专家指导，以最大的可能完成任务。
|
|
|
时间：2008-04-21
题目：分析
分析：存在的问题：
1、项目经理没有负起管理的责任，缺乏沟通，每个成员单打独斗，没有团队协作；
2、没有专门的测试人员做集成测试，项目经理没有对项目做全局的分析和认识；
补救措施：
1、回到开发现场，先做集成测试；
2、项目经理要理清项目存在的问题，根据每个问题寻求解决办法；
|
|
|
时间：2008-04-08
题目：荒诞
分析：同意楼上一位所讲，根本就没有项目管理，连基本流程都大有问题，何谈项目管理整体管理~这种案例的出现实在是有些荒诞~
|
|
|
时间：2008-03-17
题目：典型的"天鹅梭子鱼和虾"
分析：有个寓言说,动物拉车,天鹅拼命地往上拉,虾则往后拖,梭子鱼则往旁边的池塘里拽，结果车纹丝不动。都各自进行好本职工作有什么用？因为工作间的接口及业务衔接出现了问题。
这时木桶原理又体现了：项目的成功不在一个或几个部门的水平高，而在于最低水平的那个部门。同时，成君忆先生的定理也相当适用：木桶装水的多少还取决于桶板间的接合程度（即相互间的接口与衔接程度）。
方向上的问题，应该从早期解决，否则，越到后来越难处理，直到后来项目失败，补救的办法就是推倒重来。
|
|
|
时间：2008-03-12
题目：这也叫项目管理？
分析：没有项目管理为什么还叫项目管理？真是扯蛋的事情，这样扯蛋的做法还能把项目做成更是扯蛋了。
有什么必要补救吗？失败的项目多了去了，不稀罕再失败一个
|
|
|
时间：2008-03-10
题目：缺少集成管理
分析：这种情况我遇到过。大概6、7年前，我以前公司在开发一个分布式系统时也采用了类型的方法。大家自测都很好，然后头要求我们在多少时间内完成集成测试。但是，时间过去了，我们还是没有完成。 我给老板的建议是，这种集成测试是需要非常密切的配合才可能完成的。所以必须要有一个专门的人来负责集成测试。需要制定详细的集成测试计划。 注意：
这种测试和测试部门的测试还不一样。实际上还是一个开发部的自测。不同的是，这不是模块内自测，是系统内自测，是模块间的联调。
|
|
|
时间：2008-03-10
题目：领导者的领导力
分析：管理者没有尽到管理责任布置任务不明确
目标不一致
协调沟通应提前
不能等到问题出现后
建立信息沟通平台
|
|
|
时间：2008-03-07
题目：整体管理漏洞
分析：出现的问题：
1.在制定项目管理计划的时候应该制定相应配置管理计划，在配置管理计划中应该提出基线的建立
2.由于在设计时，采用分工并行方式，在需求到概设的阶段就应该拟定集成计划。
3.集成应该在内部集成，避免现场集成，原因是集成本来就会出很多问题，会带给客户对系统的不信任感，同时自己也会受影响。而且开发环境和现场环境对集成也会有差别，如果到现场集成，集成是问题一旦多了，就搞不清是环境影响还是软件本身问题。
补救措施：
对各部分工作的最终版本设立基线，根据业务逻辑进行俩俩集成，最好分清是环境问题还是软件本身问题。给客户提交各模块的测试报告说明出现的问题原因不是软件本身，告诉客户这是模块集成的必经阶段，让客户放心并且对软件本身抱有信心。最后提交集成测试报告给客户
|
|
|
时间：2008-03-07
题目：WBS+Flow+Risk
分析：WBS 不合理。
流程有致命漏洞。
作为经理，缺乏项目经验和风险管理能力。
WBS, 要求测试部门独立，并可以对设计人员起到监督，产生矛盾冲突的作用。
流程：没有系统整合测试。即便独立的模块都是对的，整合在一起，说不定由于代码格式的不一致，或者某些意外，造成错误。就这样，就敢让客户验收。这不是砸自己招牌吗？
作为项目经理，这种问题需要有经验才能看得到，失职。作为识别风险依据的WBS，更是没有认为是问题。
补救？快速解决WBS,成立专家组成的测试部门，回到独自测试的阶段开始。或者宣布放弃。
|
|
