今天口试老师问了一道很无耻的问题（软件项目管理）

corba

开始还好，技术部分对答如流。后来问出一道很无耻的问题，说一个项目前期规划都做好了，人员也配备好了，初期一切ok.然后现在本来要10个月后结束的项目，客户现在要3个月后交付。问有什么方法可以解决这个问题，还要控制成本？

想了想根本是不可能完成的任务，不过既然问了，硬着头皮答吧。说减小项目规模，老师摇了摇头不能这样。说采用framework，老师说这不是重点。说中期加开发人员吧，老师又扯到了kosten，废话做schulung当然要钱啊，我心里想等新人的schulung做完，估计咱这项目也黄了。很想直接跟老师说，咱们这个项目干脆拉倒算了，反正也搞不定，还可以省那份钱，做点有意义的事情。。。可惜说不出口。最后东扯西扯了事。

不知道这里的高人对这个问题有什么独到的见解？谢过。

[ 本帖最后由 corba 于 2008-2-22 19:35 编辑 ]

mymy365

看是什么项目了，如果不是很独特性的项目，购买其他公司的解决方案或外包，跳过开发，或简单的二次开发，3个月，足够了

ourgame

层层转包其实比较实际。再艰巨的任务再少的钱，也有人做的……
或许还可以考虑先做的粗糙点，只要满足要求，能用就是了。然后再谈之后的维护和bug修复。

[ 本帖最后由 ourgame 于 2008-2-22 21:29 编辑 ]

corba

不错，确实没有想到过转包和二次开发的方法。

只是想既然项目都已经开始了，那就是自己的项目呗，应该想尽办法从开发入手搞定它吧。

david1983

可以找其他公司做二次承包，project management里面介绍的

t98

xp吧，用用户需求来绑住用户，规划iteration，推出阶段性release。。。。
呵呵

康猪

客户严重违约 !

删减精炼vision doc里主要use cases

三个月后提交prototype。

外包，加man power都只会拖延项目！

$ok$ $送花$

cmh

外包可能3个月刚谈完价钱。

通常做法是先发布一个阶段性的Release，把客户的最主要功能实现，先搞一部分钱过来，拖住他，然后慢慢磨。不过碰上很牛气的客户就没办法了，去年收到过一个BMW的Auftrag，时间短，工作量大，要求交付当天测试，通过就给钱，通不过一分没有，想了2分钟就拒了，天知道这种Auftrag被多少公司拒了才到我手里...

logoscope

这道题的重点不是技术上怎么实现， 是怎么和客户周旋的问题，

软件说明书写好了没有，写好了， 就算是客户违约， 没有写好就看怎么和客户讨价还价了。

lovely1234

我也说一说我的看法。
首先把前提再重点的提一提，如果我对前提理解错了，下面的分析就不用看了。
1。 课程是软件项目管理，那这里应该是希望提出一个从管理角度切实可行的方案
2。原本计划10个月。之所以原本能够做一个10个月计划，就是说明当初对方提出的时间要求应该是比较充裕的。正是基于这个充裕的时间基础，对客户的需求进行了分析和制定了详细的规划。假设一开始10个月是一个正常的项目管理分析得出的结论。那么这里面肯定包含了一定富余量，从软件项目管理的角度来讲，我们要考虑中间可能存在的任何风险，要给定足够的预算时间。如果我们把完成一个项目的时间分为三级的话，那就是 最长可能需要的时间， 正常需要的时间，和最理想状况的时间。一般在用户给定充裕时间的情况下，我们以最长可能需要时间计算。
另外，在时间充裕的情况下，我们对项目的要求应该略大于客户需求，这样才能保证客户的满意度而留住客户。所以，这上面我们又会增加一些Features的实施时间。从公司发展角度来讲，每一个客户项目都应该积累一些针对于公司后期发展有用的经验或者产品，那么我们就会在做这个项目的时候做更加灵活的分析，以保证中间产品的通用化和标准化。这些也都需要额外的时间。还有一些我就不一一例举了。废话了这么多就是说明，这10个月对于这个项目来说有压缩空间。
3。现在要减为3个月交任务。这个里面有两层含义，第一，客户的计划改变，3个月之内需要产品。一般改变不会毫无理由，从这个角度来讲，就需要和客户进一步沟通，对原始需求进行优先级确认，以保证有限的时间内客户的满意度最大。第二，实施时间大量减少。这就需要我们重新计划。要做到这一点，不能再原计划基础上压缩。因为那样会影响产品的质量。暂时放弃原计划，以三个月为基础，重新考虑全新的计划。这个重新考虑的基础就是就是基于这三点前提条件。
重新考虑的重点也会相应的发生变化：

原计划视角重点(时间足够的情况下)：
1。产品的新功能和客户的满意度
2。产品的通用性和可重复利用性
3。。。

新计划应该从新的视角出发：
1。项目阶段的调整(保证优先级高，对其他开发影响大的部分优先)
2。项目开发的并行性(尽可能减少开发人员的依赖关系，使每位开发人员尽可能无等待时间，从而提高开发的效率)
3。采用新的团队合作方法(比如Extreme Programming方法等等)

打一个简单的比方：
原先基于10个月项目管理，前一个月或者更长时间可能我们就先讨论如何实施这个产品会对我们将来其他类似产品有更大的帮助，如果将这个产品做得通用化，结构化，模块化等等，如何通过做这个产品的机会来改善我们的Framework，改善我们的Develop Environment，增进Team协作意识，也许还顺便锻炼几个新人等等。实际上这些东西对于客户来说是丝毫不感兴趣的，客户需要的只是一个性能稳定，功能健全的产品，充其量对他来说你做的可扩展一点，保证我们随时提要求。。。那么现在时间减少为3个月了，我们就得抛开上面一些从自己公司利益考虑的想法，着重分析如何尽快实现用户的功能。当然，这里面不应该以牺牲质量为代价，因为那样会得不偿失。相信有经验的人应该知道，对于同一个东西，仅仅实现也许只要3天，但要做得通用化，结构化等等，也需要花上10天或者更多。因为后者涉及到更多的Architecture和Structure的东西，需要我们去抽象。

当然以上这些点还不够，还需要很多其他的方式来提高效率。另外有时候为了项目的进度可以牺牲产品组件的通用性和整理设计的合理性。但决不能牺牲产品的质量。我不是很赞成以牺牲质量为代价的方案。Features可以变少，但质量不能下降。否则就不是成功的项目管理。

至于是否能保证3个月能否一定交付，这就需要具体情况具体分析了。如果前10个月计划本身就已经非常非常紧凑，就已经是公司最大的能力了，那要解决这个问题公司就只能带着大家去看一场电影然后回来再考虑解决方法了。这场电影的名字叫 Mission Impossible

[ 本帖最后由 lovely1234 于 2008-2-26 22:57 编辑 ]