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

我不觉得我的开发流程不适合互联网应用。
你说的对，客户有非常大的选择权。所以我认为在互联网应用方面用户体验更加重要。现在能提供信息和产品的网站太多了，如果使用不方便，那么换一家就是。除非你有独一无二的产品，大家必须买且必须在你这里买，不然你不重视使用体验就不能成功。互联网的用户体验现在已经是一门独立的学科了，有很多人专门从生理、心理、社会等各个方面去研究它。
企业开发中虽然用户体验非常重要，但是在重要性上不如互联网应用。我这里不是说企业系统的用户体验不重要，只是比互联网系统的重要性稍微低一些。因为员工必须使用这个系统来完成日常的工作，不是他可以选择的，除非辞职。所以就是体验差，抱怨多，那么也不得不用。企业系统操作复杂易出错，还可以用规章制度来补充，互联网应用难道给用户定制度，不按规矩来就罚款？企业系统体验差，可能造成员工不愿意用、效率低、易出错，但是马上倒闭绝对不止于。而互联网应用体验差，可能撑不到1个月就关门了。
“项目负责人我，对旅游电子商务实践过两年，站在用户角度，对这种大众需求，我有能力开发原型，只需要向业务员做适当的调研。”从这句话就看出来，你还是没有搞清楚你的位置。你已经不是一个纯粹的开发人员了，而是一个项目的管理者。也许你还有一些开发任务，但是你第一位要做的是管理。而且你毕竟不是每天做业务的，怎么能保证比一线人员更清楚呢？熟悉业务能让你更容易理解需求，但是很难让你的业务水平超过一线的业务员。我要是业务超过业务员，那么我也去做业务好了。互联网应用既然面对网民，那么就应该想想如何收集网民的需求，而不是闭门造车。
“网站成败和产品价格、客服专业程度关系非常大”，但并不是说和体验关系不大。你控制不了别的，但是你起码可以把自己能控制的尽量做好。可惜你对你唯一能控制的客户体验并不重视。
业务不愿意协助你们。这个责任在公司的管理层。说白了就是公司其实心里并不重视业务准备的东西。不然为什么不记录绩效，为什么没有对应的酬劳？接单是工作，写网站内容就不是工作？业务不但工作要加码，还要背负奖金损失，搁着谁谁也不干。
最后还有测试。你对于测试的认识仍然错误。你和业务做的确实是体验测试。这个主要是测试主观上的需求是否正确。比如网页看着是否舒服、颜色搭配是否合理、操作是否符合人的习惯。而且你们多长时间测试一次？从头到尾测试一次需要多少时间？没有最起码的应用测试你们怎么保证代码的BUG在可接受范围内？“就几个展现页面嘛”。真就几个页面？几个页面就折腾8、9个人一个半月？为了这几个页面你们产生了多少代码？这不是开发人员说的话，只有对开发什么都不懂的人才这么说。
我是没有提到内容建设。因为这个主要是企业日常运营的问题而不是项目开发的问题。我觉得不是在项目管理中讨论的问题。

再次看到，楼主的图片换了啊，正好体现你的心情了，呵呵，好的团队建设不容易啊

你是一个猛将，但不是大将...

可能是我没特别强调，我的时间70%都是做这些事情：
1、研究同行网站和客户需求，开发原型，和业务员沟通原型
2、推进业务人员内容建设
3、给设计师讲解原型和用户体验

关于第三点，比方说首页的讲解：

• 1、首页是网站最核心页面，客人在打开网站的头5秒，决定用户是否继续浏览或是关闭窗口
• 2、我们的用户主要来自白天上班的办公室白领(google统计数据)，他们的浏览器一般是1024*768，IE6为主，我们首页设计要特别强调页面第一屏，也就是页面高度的600左右(减去菜单和工具条)。
• 3、首页的导航栏下的左上角是用户视线焦点，该部分的产品促销一定要有亮点。
• 4、用户是扫视我们的页面，所以区块化要明显，尽量控制描述性文字的堆叠，大胆的留白
• 5、首页杜绝闪动华丽的广告栏，用户看到广告就恶心

...........................................


以前我负责过多媒体网络课程类的项目，这类项目最核心就是内容质量和内容脚本编写，开发流程基本没法用企业应用一般的流程。
互联网项目这类界面驱动，和企业应用的流程或数据驱动的项目，差别真的太大。

LZ对自己要求严格了，其实8个人月是小case，在1个半月内完成改版升级，应该不慢，只是你自己希望能够分析出一些问题出来。

如果硬要做分析，那么是否可以先想想，你对这个项目的目标，是否当初没有定义得很清晰，怎么来界定这个项目是否成功？1、按时上线；2、控制在多少人月内；3、上线后平均无故障时间百分比，这些QCD指标你已经达成，那么可以判定这个项目就是成功了。而LZ你的目标不是这些，是“Google统计数据和实际订单量表明，并不成功”，也就是你希望项目成功的目标是业务的改善，那么这个就不是你开发团队做过程改善能解决的。

学无止境嘛，谁一开始就什么都会。
我有学习、提升自己的勇气，有自信，才敢在这儿丢丑。

不知道为什么很多人给这个帖子投隐藏，我想：这第一手的、没有经过修饰的项目经历，应该还值得参考(网上不好找，并且，这类文章只能是亲身经历过才能写，记者编辑是没法写的)。而且我相信肯定会有比我经历丰富的人，一起帮我思考这个问题，你们自然就受益了。

另外，我想通过我的两个成功项目，警醒我自己，也告诉大家我是如何的不牛。

如果这个项目经历写在我的简历上，我应该不会这么写。
如果你看《IT经理世界》，你就会发现有那么多企业成功实施了信息化。其实，这类杂志绝不会告诉你，原来有更多的企业，信息化失败。而失败的项目案例，往往更容易让你避免失败，让你走向成功。

举个例子吧，普元的EOS，在各媒体，如《IT经理世界》，都是明星项目，吹到了天堂。这个平台，特别是开发工具，我们项目组当时专门研究过，竞争对手嘛。如果你搜搜JavaEye开发人员对它的评价，包括我们自己的使用体会：简直就是地狱，用它开发慢得像蜗牛。当然，站在更高的角度，普元确实是一个很优秀的企业。

如果一个项目成功了，往往是十个核心方面都做好了，只要一个没做好就是失败。所以我有时想，失败是必然，成功才是偶然。

另外，我也是想告诫哪些技术大牛们，千万不高估了自己曾经单打独斗的成功经历，当你在一个团队或带领团队时，可能会失效，而不要拿它证明自己有多牛。商业社会，往往“商”是最大的项目驱动力，所以很多时候项目成功，并不是因为技术取胜。

做事和管事要求的能力确实不一样。

我确实对自己要求很严，也许是我天生的完美性格导致。
这个项目上线后，业务人员一直不停地提需求，然后我们改(当然一定程度也在于老网站撤了，她们出于自保)，但公司员工整体反应用户体验加强了。以前的很多部门间矛盾不知不觉就化解了。

看了这几点很有启发
都说到点子上了，起码我就是用以上几点来看待一个网页的，如果看到上面的，基本上就会close
csdn就是这样的阿，太长了，内容还有左中右乱七八糟，现在一个月只会去一次两次了

人也不是方方面面都是完美的，代码写得好不一定项目就能管理得好。

发现自己的不足，寻求别人来弥补，木桶理论嘛``

前台JSP+JavaBean+WebWork，后台用Flex+Hibernate+Spring

我对 你说的 flex 是后台 前台是 webwork 这个 很感兴趣

能解释一下吗

在我的理解里 好像 flex 都是做前台的多啊