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

这是我亲身经历的项目，并且是项目负责人，该项目只有10个左右核心页面，七人，一个半月。
而几年前，我做过的两个项目，技术难度比这大，功能模块比这多，却只需要一个人，一个月。

问题在哪里？大家一起来分析一下。
先描述一下这两个成功的项目。

项目一 南开BT联盟(简称：BT)
项目背景 南开BT联盟是我03年底在校内部署的一个BT网站，采用一个免费的BT服务器(PHP)。半年后，也就是04年秋，发展成南开校园内几乎最热门的下载站点，我爱南开BBS的BT版成为年度十大热门板块(网站运营是另外一帮哥们，我只负责幕后技术)。因为校内注册用户超过5000，并且种子数超过1万，于是出现了定制化开发的需求。但是，该BT服务器是免费闭源，PHP是加密过的，没法改。于是，05年年初，也就是寒假那一个月，我没有回老家，从零开始，一个月写了一个Java版的BT服务器，开学后，就替换了原来的，运行一个月后，反应良好，晚上高峰期，上千人同时下载，五年前的截图。

功能模块
内核：BT客户端和Server端通信(编码解码器)，torrent种子文件解析，种子状态更新、下载流量统计。
附加约8模块：种子列表、详细，站内信，简易BBS，种子上传、管理，用户管理，用户注册登录，排行榜、求种、系统管理等。

开发技术：JavaBean+Servlet+JSP(eclipse3.0+Tomcat5.0)
代码量：50多个JSP，约三万行Java代码


项目二 报表展现（简称：Report）
项目背景 该网站约有两百个复杂报表，现在，因为整个大系统统一用Java开发，所以主要是技术升级。项目经理估算是10个人月，所以把活丢给我就没管了，慢慢开发吧。我分析了两天后，告诉他，我可以两周出一个版本，他大吃一惊，很有信心，就不过问我了。

我根据需求，自己开发了一套适合报表的框架（定制化的MVC框架）。另外，将sql统一到几个配置文件，以便将报表查询和程序分开(DBA和开发人员分开)。说实话，真正有难度的是sql，反正我看不懂。

开发了一个月后(两人，一个月)，交工，客户很满意(50万合同额)。后来有近两个月的维护期，基本一周花半天就可以了，反正那段时间我特闲，专心啃技术。

实际情况是，我两周开发框架，两周开发业务。

项目三和四 当前的项目(简称：新B2C)？
项目背景 该项目(老B2C)04年，一个程序员一个美工，一个来月就上线了。其后几年，每年几十万的毛利。但项目几年没维护，页面陈旧，内容过时，当然，产品和价格总在更新。
于是准备改版，核心页面总共10个左右，如首页、频道首页，产品详细页，预订表单。

技术5人，业务2人(负责网站内容)。技术人员中，一个(我)负责需求和原型，一个负责后台(另外一个辅助)，一个负责前台，一个设计师。其中有技术高手，比如我，却搁浅搞业务，一个电子科大的技术牛人，一个原来开发老版本的开发人员。

花了一个半月，约8人月。
技术：前台JSP+JavaBean+WebWork，后台用Flex+Hibernate+Spring。前台让开发人员选用自己的熟练地技术，后台技术也是熟练的，基本上进度阻力并不在技术。

改版后，Google统计数据和实际订单量表明，并不成功。

--------------------------------------------------------------------------------------------------------------------------------------------

问题在哪里？
下面是我的分析和比较，但我认为项目的决定性因素总是那些方面，只不过哪一方面突出些。

1、原型开发(需求分析)
BT：基本没有，因为业务非常简单，主要是老版本技术升级。
Report：基本没有
老B2C：有，主要是抄袭，业务简单。另外，两个人，一拍即合。
新B2C：开发完原型后，给业务人员确认，修改，反反复复。老板当时不看，过几天会突然提出修改命令(小企业，老板没那么多事)。

最后确定下来的，是第三个版本，已经花掉了约两周。

2、内容建设
BT：不需要内容，只做平台。
Report：不需要内容，主要是处理数据
老B2C：内容抄袭，美工、开发人员一起抄。
新B2C：内容重新整理，只要出结果就行。
不过，出哪些内容，也就是一级大纲我出，包括原型上要求的内容，我都要截图出规范，配合很死板。小团队协作，通过文档规范来解决，已经是下下策了，但没办法，已经没法推进了。

3、界面开发
前三个项目，界面都很简单，直接Dreamweaver开发。
新B2C，一位高级设计师，新来的。因为原型中已经大体确定了布局，另外，可能我对界面干涉较多，所以他来后极不适应，因为以前做网站都是自己一人说了算，经常是到下班六点，就开始做自己的个人网站，不把工作放在心上。后来差不多做完，就离开公司了。
界面开发了约一个月，其中首页开发了半个月，后半个月都是赶，所以质量很差。因为界面设计都是先PS做效果图，后切片做HTML，工作量大。

我的问题：交互设计师(我)和界面设计师的职责不明确，导致设计师失去热情。后来我想到解决方案：1、设计前先给设计师仔细讲解业务，为什么我这么布局；2、界面风格的评审留给业务员。
但我本身对交互设计和界面设计有较好的基础，我更接近客户，还是业务员？我接触业务已经一两年了。

4、决策
前三个项目，基本上是个人决策，执行力很高
新B2C：因为涉及到产品经理(我)、业务员、老板三方，谁都想争取决策，闹得非常僵，项目几乎无法展开。第三个版本，修改建议主要是听业务员的，但大家已经彼此失去合作热情，导致后期的原型确认和内容建设进度很慢，三方都在耗。

5、协作
前三个项目，基本都是单双人，很顺畅。
新B2C项目，涉及7人，技术团队内部协作对进度影响可能只有10%(除了当时那位设计师，都服我)，但部门间协作非常困难，因为没有利益制衡。虽然没有剑拔弩张，但已经是很机械、被动的合作。

6、激情/热情(最根本的问题)
BT：强烈的学习动机，一定的责任和荣誉感。那时候我每天写代码到晚上3点，睡一觉后接着写。
Report：强烈的技术爱好，领导的信任和支持，没有进度压力。那时候我路上思考，吃饭时思考，睡在床上也思考。

新B2C：毫无激情(一周有效时间三天都不到），下班和周末就彻底不想思考。
我：有责任，但无权和利。权：无法推进业务员的内容建设， 利：作为合伙人，只拿基本生活费2k(五年前月薪的1/3)。
我的期望：老板把网站业务这块抓起来，另外花点时间在用户体验上，而不是想起来就催进度，提需求，而从来不关心导致进度迟缓的原因，并且一起办法。
管理的本质是利益的制衡，对于我们三方，我、老板和业务员均无制衡。

事后我想到的解决方案
以信任和激励为核心(激励的本质是满足人性的需求：比如我最看重士气和团队凝聚力，做事本身的快乐，而不是利润)。
一切问题，都是人的问题。
如果说业务人员不配合、缺乏动力，是我引起的只有30%，因为我们是物理上分开的两个环境，两种文化。

如何激励？

• 老板解决内容质量和内容推进，不规定进度，而是期望进度(没有进度压力，往往开发得更快，进度我心里有分寸)。
• 原型决策权：在我，我会征询大家的建议，协商一致后，业务部必须达成。
• 界面风格决策权：在设计师(因为我吸取了以前的教训，新设计师热情很高，我的建议基本上就是她的决策)，其它任何人只有建议权。
• 薪水：在我强烈要求下，已经涨了1k，基本够业余时间消遣。

上面的措施，主要是解决我(负责人)和设计师的激励。如果说管理的本质原则是：责权利的平衡，那么有权和利做支撑，我的责任感也会来，我也想把事情做好。
不过，我的期望似乎太理想了，去改变老板太难。

如果能够解决团队协作和士气问题，我认为可以达成如下目标：整体进度提前50%，约15工作日(三周)，也就是将内耗省下来。界面设计速度、代码开发速度可能快不了，但原型开发速度、内容建设速度可能提高60%。

因为公司有好几个子网站要改版，目前这个子网站，我把负责人的位子交出来了，离开成都来大连(和老婆团聚一段时间)，我只专注于原型和界面评审，也就是用户看到的那部分。因为，我确实不想这样内耗，或许那位做老网站的员工和业务员、老板处容易些(企业基因啊，我是外来基因)。

大家看到这样的案例后，对团队协作和单人作战，以及项目开发过程(需求、原型、开发、内容)与进度的关系，有什么新的看法？如果这样一个项目，你是负责人，你会怎么做？

评论

20 楼 魔力猫咪 2010-05-23  

旭少版 写道

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

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

能解释一下吗

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

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

19 楼 旭少版 2010-05-22  

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

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

能解释一下吗

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

18 楼 seele 2010-05-22  

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

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

17 楼 skzr.org 2010-05-22  

zwchen 写道

魔力猫咪 写道

“网站成败和产品价格、客服专业程度关系非常大”，但并不是说和体验关系不大。你控制不了别的，但是你起码可以把自己能控制的尽量做好。可惜你对你唯一能控制的客户体验并不重视。

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

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

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

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


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

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

16 楼 zwchen 2010-05-21  

一蓑烟雨任平生 写道

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

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

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

15 楼 zwchen 2010-05-21  

seele 写道

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

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

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

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

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

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

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

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

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

14 楼 一蓑烟雨任平生 2010-05-21  

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

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

13 楼 zwchen 2010-05-21  

魔力猫咪 写道

“网站成败和产品价格、客服专业程度关系非常大”，但并不是说和体验关系不大。你控制不了别的，但是你起码可以把自己能控制的尽量做好。可惜你对你唯一能控制的客户体验并不重视。

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

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

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

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


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

12 楼 seele 2010-05-21  

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

11 楼 skzr.org 2010-05-21  

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

10 楼 魔力猫咪 2010-05-21  

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

9 楼 seeckt 2010-05-21  

老板、技术人员 中间要隔一个经理的角色
作为技术人员，不能同时兼顾经理的角色的话
那么剩下2种选择
要么自己当经理
对产品只提比较粗的要求，控制关键里程碑，对外负责协调沟通
要么自己当技术人员
找个经理来让自己安心工作

不然争权夺利外加各种会议，一顿忙下来以后，很难再有心思想技术问题
做管理和做技术都很出色的牛人有不少
但同时做管理和做技术都很出色的人就少见了

8 楼 crazy.j 2010-05-21  

前两个事可以不用提了，一个人干事怎么都好说，人一多了就难办事，群龙还得有首呢，我感觉领导阶层的威信非常重要，全都民主了，跟台湾的政局就没有什么差别了，都自己想自己的，自己干自己的，人与人的思维方式存在很大差异，各种客观原因都可能致使你的项目被拖延。

7 楼 zwchen 2010-05-21  

项目中有很多特殊情况，比如人：
老板和我是亲兄弟关系，他是生意人出身，两人做事习惯差别太大，我算过来帮忙

特别是设计师：

• 从上海工作三年刚回成都，我们是他第一个落脚的地方
• 当初我给他承诺薪水他比较满意，后来和老板面谈时，竟然薪水被压倒80%(离职时我才知道)。而他准备进来时，薪水我已经和老板达成了一致
• 他来我们这儿近两周后，和一家大公司签了，那家公司就在他住的附近，但到辞职时才告诉我。因为没有设计师，我们后来项目有一个月的延期
• 他因为刚来成都，住在成都周边的一个镇，每天上下班时间要三四个小时
• 因为他上下班困难，基本上是10点来公司，还很累，并且准点下班，不过我没有任何怨言，但这对项目进度和界面质量影响很大。

他走后，我请他吃饭，聊了聊，我们对彼此的人品并没有什么看法，但合作确实困难。后来他给我们另外一个网站设计了一套界面，虽然最后没有采用。

6 楼 make_miracles 2010-05-21  

很简单，大家都是按月拿工资的。要是按活拿工资，比如这个项目多少钱包给你们这几个人做，要是实施成本比较低你们自己就把这些钱分了，这样的话做起来就快了。

5 楼 zwchen 2010-05-21  

To魔力猫咪，看来你是一个很务实的人。我认为你们最大的问题就是团队的建设问题，我很认同。

这个项目的细节我没有过多透露，因为我希望找到一种半通用的软件过程和项目管理方法。对于你的解决方案，我感觉它主要适合企业应用(用户是企业员工)，而不是互联网应用(用户是大众)。

我们做的是旅游电子商务B2C网站(可以理解为携程网ctrip的mini版)，这个项目的特定环境：

• 1、用户是陌生群体，用户有绝对的选择权；不像企业应用，员工只能用它，所以用户体验非常重要。
• 2、网站有一半的工作量在内容，就是产品及价格信息，产品图片，帮助信息，公司信息等，这类资料都是业务员编写。可以说，内容为王。
• 3、项目负责人我，对旅游电子商务实践过两年，站在用户角度，对这种大众需求，我有能力开发原型，只需要向业务员做适当的调研。提示：后台业务系统去年开发完了，暂时变动很小。
• 4、网站成败和产品价格、客服专业程度关系非常大

你不看重利润非常错误，企业中不能创造利润=没有价值。我很认同，我的意思是，当项目的成功只决定于执行力的时候(内容建设、界面、代码开发)，执行的效率主要由士气和团队凝聚力决定(有较好的流程)。

关于你提高的团队情况，我说明一下：

• 我们的项目自始至终没有加班，一周五天，40小时
• IT人员薪酬符合期望值(我可以决定)，办公室氛围很轻松，业务人员薪酬也是合理的，并且薪酬和业绩关系很大。
• 业务人员对网站的被动，主要是因为暂时看不到收益前景，并且她们对内容的建设，没有和业绩挂钩，也就是似乎给IT部白干。另外，给网站准备资料，影响她们接单。

所以，在这样的环境下，你的项目管理方案可能需要变更。
另外，人员安排，可能达不到你的要求，也没有必要。

• UI设计只有一位，不可能再招
• 开发人员两名，一前台一后台就够了，因为他们水平都很牛，基本不形成瓶颈
• 测试人员主要是我和业务员，因为我们是用户体验测试，不是功能测试，就几个展现页面嘛。

你没有提到内容建设，而这是项目最难推进也是工作量最大的一块。比如帮助类文章纯写一篇可能要一上午，抄袭带编辑可能一小时，要保证质量，除非业务人员自律和高度责任感，或者业务人员的上级严格把关。

顺便说一下，一个电子商务网站的成功，有七大方面，按顺序：

• 1、战略：最开始的方向错了，下面几道流程再怎么做，项目基本上完蛋，比如做一个better QQ
• 2、需求和原型开发：界面基本可以反映需求，比如豆瓣网
• 3、界面设计和代码开发：界面美观度和用户体验对订单转化率影响很大
• 4、内容建设：抄袭和错别字等极大降低用户信任度
• 5、SEO和营销：没人问津，做得再漂亮也没有
• 6、销售和客服：客服对客人发火，电话占线等服务质量问题
• 7、运营管理：产品价格更新不及时，比竞争对手高，也没法留住客人

有这样一个限定环境，该如何进行项目管理？

4 楼 firebody 2010-05-21  

看了一遍，想说几句：

管理主要在两个方面： 人 和 事 。

要想做成功，无论管人还是管事，都能做到“运筹帷幄”，“全盘把握”，“事无巨细均了如指掌” 。

项目小，一个人或许可以扛下来，项目大了，人 和 事 分别由其能负责的人来管。

从这点来看，你的项目的曲折 千错万错， 作为项目管理者的你错最大 。

协调做不好，人管不好，事也没把握住， 我要是老板，第一个要“开导”的就是你，当然你上进心不错的话值得培养的话， 那第一个要重点提高的就是你。  

无论做什么事情，都要打有把握之战，这个把握 一个在你，一个在你的兵 。 你的兵不行那就得靠你，你还不行，那就只能靠天了。

3 楼 魔力猫咪 2010-05-21  

很明显，前2个系统，其实是你单打独斗。
BT系统纯粹是从需求到维护你一个人包了，没有任何交流问题。因为纯粹出于激情和成就感，也没有任何利益纠葛。
报表系统和BT系统有类似情况。你需要的需求是已经确定、无变更的，而具体报表不用你关心。
而最后的B2C则是一个非常典型的混乱团队开发。人员职责划分不合理、需求管理混乱、交流不通畅、没有协调机制。至于你认为最后还是成功的，对此我表示怀疑。我认为项目的目标根本没达到，你们项目的价值基本是0，项目花了多少亏损就有多少。你所谓的目标其实根本不是项目的真正目标。
项目为什么要做呢？是因为老网站已经不能适应公司业务发展，购物体验不好。真正目标是提高客户购买体验，带来业务提升。而你最后也说了，从后来的统计来说，改完了和没改差不多。那么也就是说钱白花了。如果事前能预知，老板绝对不会启动这个项目。
我认为你们最大的问题就是团队的建设问题。你在项目中的角色是什么？是团队开发的一员？掌控项目的项目经理？还是负责业务分析以提出需求？我可以看到你在需求、设计等多方面出击。但是又和同样负责这些的团队成员产生冲突。

以信任和激励为核心不错。只有看到项目有好的前景，大家都可以从中获得收益才会积极应对。不过你不看重利润非常错误，企业中不能创造利润=没有价值。而且我也没看到你在团队中“最看重士气和团队凝聚力”，你和业务人员与界面设计相处得都不好。“原型决策权”为什么要在你呢？如果你是负责需求，对项目成败负责，那么你确实有这个权利。如果不是，那么你没有权利。“界面风格决策权”同样，只有负责需求，对项目成败负责的人才有决策权。设计师只是根据需求进行设计。如果设计不能符合需求，那么就必须纠正。薪水我不知道你们现在拿的是否合适，不发表意见。
至于如果把团队建设好，能取得多少进步，实在很难说。因为你们成果的好坏，要市场来检验。我只能说，新系统带来的业务越多、节约的成本越多，你们的项目越成功。哪怕仍然是和现在一样的失败，那么你们至少可以减损和止损，少赔点。

如果我是项目经理，我该如何呢？
我不知道你们当时的工作情况，比如是否有非常严重的加班等等。如果有加班，那么你给出的工时其实并不准确。还有，你们没有任何测试人员。那么是否有可能项目中很多功能其实是半成品呢？所以我只能按照我自己想的情况模拟。

项目情况：B2C项目。参考老系统并结合新需求，开发新的B2C销售平台。
项目目标：提升用户购买体验，以达到增加流量和订单的目标。
项目人数：准备和你的一样。
项目时间：初步规划1个月试运行，2个月内正式运行。如果需求不断增加，则对应延期。

我觉得应该在启动时就选择合适的软件开发流程。如果可以，我希望选择敏捷流程，至少也是增量开发流程。开发必须迭代进行。因为项目较小，我认为1星期迭代比较合适。进度方面我认为2个迭代发布一个可用的alpha版本。也就是说理论上半个月可以开始初步试运行。4个迭代至少发布出Beta版。
老板+业务员负责提出需求，检验成果。需求只能在迭代开始时提出，除非有非常特别的原因。不能在迭代中途加需求。迭代完成，进行审查，看成果是否符合需求。然后根据这次审查结果，准备下次迭代的需求。
我负责掌控项目进度、协调需求方和团队、帮助解决团队开发中遇到的困难，整理会议记录和项目文档。
团队人数上如果按照你的人数，我希望有1-2名GUI设计、4-6名开发、1-2名测试。团队负责根据需求进行设计和开发，GUI设计负责页面和图片、开发人员编码并进行单元测试、测试人员编写测试案例并尽快启动测试。

2 楼 royaki 2010-05-21  

楼主，我非常倾佩你的技术，我是初学者，对你1L说的BT服务器很感兴趣，能分享一下代码或者说一下原理么？
我想搞一个试试。谢谢！

1 楼 zwchen 2010-05-20  

补充几点：
1、项目并没有失败，只是没有达到我预期的目标，快(比目标提高半个月)、省(人力少)、好(质量高)。
2、我很希望老板、业务人员和我齐心协力，而实际上合作成了交易，讨价还价，干得很不爽。
3、可能是我要求太高，目前不过做得很平淡罢了。