作者 内容
 村落残云  如果控制软件项目的进度？
制定了计划以后，控制软件项目的进度是一个大的问题。那么如何来做呢？如果发生了进度跟不上计划或者质量没有达到预定的标准，该如何调整呢？
 02/01/25 11:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 iamcrying  回复: 如果控制软件项目的进度？
偶觉得控制软件项目的进度是一个梦，尤其是应用软件项目，有客户不断“重在参与”的情况下简直就是噩梦。
 02/01/25 16:18 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zhongshouke  回复: 如果控制软件项目的进度？
你这个问题实际上需要由建立变更管理流程来决定。
 02/01/27 11:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 candy_lin   回复: 如果控制软件项目的进度？
你想控制进度，首先要控制好这个工程的范围、边界，控制客户的需求。然后定时检查人员的工作情况，在时间、人员、任务之间做负载平衡。在制订项目进度时要留有处理突发事件的时间，如果安排的太满了（每个人已经是加班加点干活），那就没法控制进度了。
 02/01/28 14:13 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 overflight   那对于下面程序员的工作如何控制呢？
有时候项目太大，做为pm or sa很难有经历去逐个考虑每个人的工作细节问题；

按计划是某某程序员在若干天之内完成某个功能模块的实现，但项目期限已到，他还没有完成，说是遇到很棘手的技术困扰，做为领导的你又能把他给怎么着...

所以，对于程序员工作的控制，是以具体功能模块来衡量？还是以源码的行数来衡量？

相信这个问题也在困扰大多数同仁，请高手不吝赐教。谢谢~!
 02/01/28 14:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 candy_lin   回复: 那对于下面程序员的工作如何控制呢？
每个星期的例会是不可省略的，要不你怎么知道每个人的工作情况。工作细节不应该去抓，而且也没法抓，你只要知道结果就行了。项目组中应该有质量控制人员，组员的工作质量如何可以从质量控制人员处得到。如果发现遇到技术困扰，可在会上讨论，一人计短两人计长嘛。况且在项目立项时就应该有一个技术评估，找出项目的技术难点，技术上可行了才实施这个方案。项目期限已到？说明你没有做风险评估，将一切都想的太理想了。好多东西都很难说，总之实际情况实际分析，随机应变吧。
 02/01/28 15:48 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 overflight   我的一些观点~~
"每个星期的例会是不可省略的，要不你怎么知道每个人的工作情况。工作细节不应该去抓，而且也没法抓，你只要知道结果就行了。项目组中应该有质量控制人员，组员的工作质量如何可以从质量控制人员处得到。如果发现遇到技术困扰，可在会上讨论，一人计短两人计长嘛。"""""""

这个办法很好~!

我们公司也曾经采用过此种方法，在会上讨论技术疑点，并据此分派工作

这样做看起来很好，但是谁也不会想到在实际的项目开发过程中还会遇到种种困扰！！如果不去关注程序员的工作细节，问题来了，项目没法按预期完成。他的理由：当时对于技术细节的他析不够深入，这会儿又遇到了没预计到的问题，是不巧？还是当初的技术分析与任务指派不全面？？这都是问题，以至到最后项目的拖延....等等等等~~~要是再遇到个指手画脚的客户，需求再跟着变，项目就更能控制了。。。。或许我的想法有点消极，但这确是偶工作的公司中实际遇到的问题。

在国内，尤其是现在工程化还没有很好的实现的今天，对于程序员的一些工作真的是很难控制，愈大愈难控制，愈易导致项目的失败。
 02/01/28 16:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 candy_lin   回复: 我的一些观点~~
在没做过相同项目之前，谁也没法准确计算出项目到底要花多长时间，还有什么技术难点没考虑，所以项目有风险，进度控制只不过是为了能够尽快地按质量地完成一个项目。进度管理是一个手段，不是目的，进度管理所设定的期限也不是一定完成的最后期限，只是一个预计的期限，目标，大家都跟着这个目标去走。所以制订进度一定要保留未知因素要花费的时间。遇到指手画脚的客户？那你就要做好需求变更的管理了，哪些可以在这个进度内做，哪些可以下一阶段做，哪些要拒绝。要看你的公关能力了。
我觉得一个项目就是在有限的时间里用有限的人力做相等的功能。注意一定要控制项目边界，否则项目永远都无法如期完成，只会越做越糟。
 02/01/28 16:18 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 overflight   ok,那您指的项目边界的真正含义是什么？具体规范还是什么?
有时候不排除，需求变更对项目进程产生很大的影响，这与需求阶段的工作存在弊端有着极大的关系！

不过往往在实际中，抛开公关能力差、能力有问题，但也有可能因为对于需求管理的控制达不到尽善尽美...而使进程难以控制。

其中包括stakeholder成员的变动：开发人员、管理者在项目开发过程中的变动是时有发生的，这就使整个的项目过程很难控制。
 02/01/28 16:39 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 candy_lin   回复: ok,那您指的项目边界的真正含义是什么？具体规范还是什么?
可能我表达的不好，项目边界指你要完成的这个项目的范围。即开发工作的任务清单。
 02/01/28 17:43 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 overflight   //nod
ok,是类似于Mirsoft Project2000所做出的项目计划了?

这个东东倒是有用，呵呵~~
 02/01/28 17:47 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首