[探讨] 记一个失败的软件开发项目，请大家一起分析原因 [dorothy 修改于 2004/9/15] 状态 开放帖 精华贴 浏览量 15573 |
 Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[compasspower 修改于 2005/5/27]
|
这样做肯定不行，
１。本身对项目需求不明确，概要设计没做好，架构也不清楚，人员分工没有分好。
２．在编码开始之前，跟项目有关都要定义好！
３。根据需求分析、概要设计、详细设计分工。
４。任务分解
５。开发周期都要定好！
项目经理应该跟踪开发过程！及时了解项目进展情况！
对于开发过程的变更可以暂时不管！
这只是我个人意见！
|
|
|
|
25楼
 compasspower
职务 无
军衔 无军衔
来自 江西
发帖 4篇
注册 2005/5/27
PM币 30
经验 
 
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/1]
|
|
软件工程中 针对软件系统整体过程中 需求分析是很重要，分析不够，不彻底，那之后的事情都是事倍功半！ 软件构架得时刻在开发过程提醒！分工要明确，接口要规范！
|
|
|
|
26楼
lilozhao
职务 无
军衔 中士
来自 浙江
发帖 81篇
注册 2007/6/7
PM币 615
经验
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/24]
|
|
你们的这所有交谈总算看完了，觉得感触比较多，感觉就好像是在分析我做项目经理以来的第一个项目一样，情形很像，唯一不同的是技术架构是由我这里控制的，设计由我这里控制。声明：我是由开发人员转向做项目管理工作的。
|
|
|
|
27楼
afei8u8
职务 无
军衔 二等兵
来自 上海
发帖 43篇
注册 2005/6/19
PM币 235
经验
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/24]
|
感想：
分析问题： 1. 项目经理的职责：项目的4个要素，范围、进度、成本、客户满意度 如何做到控制范围，首先对项目需求的了解，需求的控制，需求变更的控制 进度的控制：如何做好进度控制，跟踪并收集有关实际绩效的资料和把变更内容修订进项目计划中去 成本：主要是人类成本，如何保证在成本之内按时高质量的完成项目 客户满意度 2. 缺乏变更流程 目前所有变更过程都仅仅是停留在个人主观意识上，缺乏度量数据 （没数据没说话权） 3. 注意项目启动阶段所要完成的工作（主要） a. 选定软件的开发生命周期 b. 确定技术架构
|
|
|
|
28楼
afei8u8
职务 无
军衔 二等兵
来自 上海
发帖 43篇
注册 2005/6/19
PM币 235
经验
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/27]
|
|
偶觉得，作为一个项目，一开始就要明确项目组成员所扮演的角色和职责范围，确定项目的影响范围和时间跨度以及确保项目取得成功的各项保障措施。项目的施行过程大部分是按照项目组的进度计划去执行，对执行过程中出现的影响到项目进度的关键因素，要及时在项目组成员当中进行沟通，解决。
|
|
|
|
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/27]
|
|
听起来似乎好象项目经理是多余的！他什么也没控制
|
|
|
|
30楼
long002
职务 无
军衔 三等兵
来自 湖北
发帖 12篇
注册 2005/6/23
PM币 67
经验
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/29]
|
呵呵，我的意见是：事实上，没有太大的必要，给这种微小型的团队，配备专职的项目经理，如果说协调，我不太相信一个如此少人员的项目的协调和沟通需要花费那么长的时间；而且在实际操作过程中，任务的分配，各种技术层面的变更根本控制不住。那么还不如现实一些。
一般来说，对于如此微小的项目团队，我的建议是配备一个沟通能力较好的技术人员担任项目管理职责就可以了，顺便也可以锻炼一下这个技术人员。事实上，在实际操作中，专职项目经理需要平行控制2-3个项目，或者承担一个中大型项目的协调，管理职责，他的工作才能落实下来。而不是空谈什么成本管理，人力资源管理，范围管理，时间管理等等；对于微小型团队来说，这种工作量根本没有多少。
这个项目经理根本就是多余的，这不是项目经理本身的错误，而是组建团队的时候，就犯了错误。
|
|
|
|
31楼
zhf_karen
职务 无
军衔 少尉
来自 北京市
发帖 469篇
注册 2005/6/13
PM币 1929
经验
|
|
Re:[探讨] 记一个失败的软件开发项目，请大家一起分析原因
[回复于 2005/6/29]
|
至于技术人员不打招呼，就变更设计，这一点是不允许的。但是说到不允许技术人员变更计划，这就有点过份了。
事实上，在IT领域，计划是一回事情，但是具体落实下来又是另外一回事情。如果某个技术人员提出计划的变更，我是会很认真听听他所希望说的内容，并且考虑风险和成本是否可以接受。事实上，在研发过程中，很多对于计划的变更都是技术人员做出的。特别是预研性质的项目，更是如此。
至于变更流程，对于这种微小团队来说，没有太大必要进行非常严格的控制。变更流程主要是为了防止变更不能被项目组全体所了解、以及变更以后造成的成本、风险、时间上的问题。所以，对于微小型团队来说，即使团队沟通水平一般，他们也能使得内部知道变更了什么。而至于对于项目要素的变化，那么通过项目经理和相关人员协调即可。进行严格的变更流程，在这种微小团队中，往往不能推行起来，因为和收益相比，成本过于高昂。
|
|
|
|
32楼
zhf_karen
职务 无
军衔 少尉
来自 北京市
发帖 469篇
注册 2005/6/13
PM币 1929
经验
|
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
