【相关分析】(9个分析) |
|
时间:2006-08-31
题目:建议换项目经理。
分析:建议去函系统开发的单位要求更换项目经理,没什么好客气的。
|
|
时间:2006-08-04
题目:提什么要求并不重要
分析: 向项目经理提什么要求并不重要(兵无常势,水无常形,不同的项目执行起来会有不同的要求),重要的是让对方派什么样的项目经理。另外,贵公司自己也有问题,在项目实施前为什么不明确项目范围和验收标准?这是你们两家都存在的一个问题。
|
|
时间:2006-08-04
题目:过程监理,做好验收
分析:1、用户方应该派出业务方面的专家,协助开发方进行需求整理,对整理出的需求规格说明书进行评审、确认,以次作为验收的标准; 2、具体的开发工作交给开发方处理,至于开发方的团队管理,也应是其内部问题,用户不应做干涉。如果,因开发方的管理,造成进度延迟、产品质量问题,那就需要与开发方高层领导沟通解决,不是找项目经理; 3、用户在产品开发过程中,可以聘请第三方监理,帮助管理。如无第三方监理,至少应该有自己的项目跟进人员,随时了解项目进展情况,召集协调会议,不一定只针对项目组进行协调,必要时可以进行高层领导之间的沟通。 4、系统上线前,用户应派出业务专家和一线操作人员进行需求确认测试,检验需求实现情况,做好验收。
|
|
时间:2006-08-01
题目:非正规建议,仅供参考
分析:建议如下: 1.按照合同规范要求开发商; 2.挖取该公司项目开发组的主要人力,组件自有的开发和维护团队(等项目逐步完善后在做打算);不好意思,好像有点卑鄙!!:)
|
|
时间:2006-07-13
题目:明确交付成果,严格验收
分析:1 一定要拿到强势的主动权,让厂方明确是你方说了算. 2 双方细化标准,明确交付成果,严格验收. 3 管理问题要求厂方高层拿出具体措施限期解决.甚至需面对面沟通.
|
|
时间:2006-06-30
题目:确定自己明白的就要坚持,否则不要干涉
分析:很多情况是用户方出人配合开发方进行开发,用户方是业务专家而不是开发专家, 软件部分交给项目经理去做,用户方需要做的就是,协助明确需求,准确地描述工作流程和期望结果。而不要去考虑软件实现方法,最好也不要去指责对方人员。 需求确认时候逐句逐字读明白了认为正确了没有歧义了在签字。 做了该做的就等着收获吧。 项目完不成,或者有其他问题,有合同呢。
|
|
时间:2006-06-20
题目:补充一些
分析:项目过程应该有监控和验收的环节,建议应该加强这两个环节(应该以甲方为主导,或第三方机构),项目经理的意图肯定代表着乙方的一些想法,建议应该明确你们的目标,不要给对方太多幻想。 项目经理代表的是乙方,但这个项目,乙方不应该由这么一个项目经理负责,应该尝试的与乙方面对面的沟通,解决这个问题。项目经理的好坏不是甲方来评价,甲方只需要评价当前的成果就够了。如果是店大欺客,那也就另当别论了。 合同很重要,应该仔细研究一下。
|
|
时间:2006-06-20
题目:瓶颈问题
分析:软件公司为减少成本及周期而在现有产品基础上修整来完成项目,往往通过关系作用使项目勉强混过,这种投机行为是当今软件项目普遍问题,也从而导致软件应用缺陷。 通常解决这种问题应该有几个原则:一、以客户为中心 二、以需求分析为基础 三、以解决方案为依据 四、以应用为验证。 这个案例问题出在一和三上,开发必须以需求为中心,项目经理过于盲目自信而忽视真正需求导致项目遇到瓶颈,要解决问题必须回归到解决方案,并且要根据试运行时用户需要修改,不合适的管理者立即撤掉。
|
|
时间:2006-06-19
题目:以产品满足项目,以需求适应解决方案的项目
分析:这是典型的以产品满足项目、以需求满足解决方案,本末颠倒的做法,需要让开发商改正过来,开发商能完成产品,但是不可能就说项目管理就好,技术不能代替管理。 客户方的需求,例如招标文件、合同都是对开发商要在一定条件下满足的,双方对这些关键的具有法律意义的文本没有得到充分的重视,到最后只能是双输的结果。 不会开会,不会沟通。 另外,对于甲乙双方的这种开发,主导的是开发方的项目经理,开发方的项目经理有义务满足用户的需求,但是一定不能把主导方的地位颠倒了,否则必定出大乱。 对PMBOK来说,只有采购一章是写给甲方的(客户,对本项目而言),其他各章节都是针对乙方(开发方)来写的,且切不可把关系颠倒了
|
|