我的项目经历及分析：为什么一个小项目要花掉8个人月？

楼主的前台是指面向互联网的网站。后台是面向内部员工的管理网站的管理界面。这两个前台实际上不是一个东西。咱们平时说Flex做前台，是指展示层使用Flex。这里他是用Flex作为管理系统的展示层。

其实到最后还是人的问题，人员责任划分不明确，没有一个有效的决策机制，沟通和协作效率地下，最终导致大把的时间都耗在沟通协调决策问题上了。

1那个观点不是抛的
2MS: firebody
3PS:我的看法是,管理失败,

由于在一个小项目中塞入了太多的人.
画一下网络逻辑图就知道
他的最短path
用四条线就是极限了.
再多加人不过是在捣乱而已

例子参考....人月神化....
网络计划图 可以参考土木工程课本

To抛同学：
你说的Critical Path确实在我们项目比较严重，设计师决定了我们项目进度，比如我们首页设计了两周，改了三个版本。
IT和业务团队的利益关系一直没处理好，导致合作困难。

1、从技术上看是一个小项目，但从商业角度看，就不小了，反正以前的年营业额是几百万。

2、因为是大众用户，所以对用户体验要求非常高，程序员做不了。另外，原型设计美工也做不好，因为必须深入理解业务。设计师很难做到页面重点突出、层次分明。她可以做得好看，但难做到好用。

3、原型设计一位、设计师一位、开发人员一两位、业务人员一两位，这是必须的。在一般的企业应用开发，是不把业务员考虑在内的，我们是运营型项目，需要每天去维护价格、产品。只有做专做深，我们才可能从红海到蓝海。

4、站在员工角度，我想任何人都不希望自己像打杂，都希望专注做一件事情，考虑到他们的感受和职业忧虑，分工明确是一个必须。我认为，员工满意和客户满意、公司满意都很重要。

应该是 由2个系统组成的  ，这个没有问题。

1.你抱怨花了太多的人月,我不认为你的项目失败.
2.关键路线只是说最佳.不拖时间.拖时间那是必然,加入的人越多拖的时间越多.没别的意思 ,你需要什么样的人,那是必需的.
3.必要的冗余是有必要的(我不得不说,你的冗余是我见过的项目中最多的)
4..........

我不同意，原型开发、项目管理、部门间沟通、测试是我一人身兼。如果你认为冗余，谁可以砍掉？实际开发人员两位，设计师一位。

开一个麦当劳店，最少恐怕得五位：店长、收银员、厨师、清洁工、洗碗工，而且几乎是1责n人(n>=1)，24小时店还要考虑冗余(类似于RAID 1)，难道它应该采取街边夫妻店模式？

只是我见过的项目而已(当然我忘记把对日外包当作项目来看)

PS:项目管理与QA要分开.
他们是并行的同一个人运行会减低效率

实际开发与原型开发可以合并.他们不能并行.

如果你的美工开发水平高那么他与开发可以并行,

如果水平很一般.则不能与开发并行.但可以与设计并行.

这只是理论上可能性....无关实际

不够敏捷，合作 重于 合同

应该庆幸仅仅经历了一个项目的曲折而让你做如此多的反思。
本来不想多说了，偶然看到你发的这句话“原型开发、项目管理、部门间沟通、测试是我一人身兼” ，如果说“原型开发、项目管理、部门间沟通”让你一人承担，我感觉 风险点在你身上， 你卡住了，所有的都卡住。 当然，你能力很强，这些仅仅让你更“疯狂”的工作，那很好，项目还是没太大困难，但是如果说“测试也由你来负责”，那只能说“庆幸”你还没碰到大一些的项目。

原型开发、项目管理和协调、测试三个无一不是项目成功的关键，你一人掌握这三个关键。 从一方面说是你的能力，当从另外一方面来说，你和你的老板都不知道该如何掌控和开展大一些的项目。

小项目，你可以一帆风顺无往不利，但是碰到协调难的，技术有难度的，需求比较复杂的诸如此类等等加大项目风险的东西，加多一个风险，你的项目曲折度就会增加一倍， 再增加一个 ，按照你所说的团队结构，失败那是板上钉钉的事情。

由 无往不利 到 曲折 再到失败 ，总归是一个过程 。
从管理角度，管人和用人 是非常关键的东西。