IT同学们来摆一摆你经历过的失败/成功的项目吧.

典

经常看到一些文章说IT project只有多少多少的成功率，觉得应该成功的还是大多数吧。。
大家不妨来聊聊你经历过的项目里失败的占多少比例？
失败的为什么会失败？ / 成功的为什么成功？

我做的项目都不大，早期经历过几个不成功的。
最近n年因为做公司内部的项目，都是很成功的( 时间/范围/预算）

不成功的一个的ERP项目，我在里边只是小小兵，感觉原因有三，一是那个公司本来就没有ready,二是选用的产品平台不太好(走下坡路的一个产品），三是team技术不强，包括甲方乙方

还做过一个CRM项目，主要是我做的，也不成功。主要原因是:1) 那家公司太小，4~5个sales, 上这种MS CRM真的不是很合适，2) 我的技术不到家，当时也是边学边干 3)那个老板要求太多，比如坚持所有的报表要用excel文件等,
虽然他们后来一直用，但我感到很guilty, 里边的东西被我改得太多，几乎不能升级/不能维护。

[ 本帖最后由 典 于 2011-10-7 13:32 编辑 ]

winsome

成不成功跟技术的关系真的不大，只要你能把东西捣鼓出来，基本功能实现，谁也不care你的技术细节

决定project是否成功的更重要的是市场和客户需求

ddwwhhkk

原帖由 winsome 于 2011-10-7 15:48 发表
成不成功跟技术的关系真的不大，只要你能把东西捣鼓出来，基本功能实现，谁也不care你的技术细节

决定project是否成功的更重要的是市场和客户需求

说的有道理

rumcoke

我做过一个跟你那个CRM的经历很类似的j2ee项目. 只有我一个人在开发 而且是在一个他们公司自己写的系统上做二次开发 他们的老板也是要求了一火车的东西 再根据实际情况和难易程度慢慢trim, 最后要求的功能勉强可以无错运行 但是我也觉得比较guilty, 那时候技术不是很过关 customize了很多东西只是为了实现一些特定要求 以后基本没什么升级的可能性了

Limitless

失败项目基本是老板把你当奴隶使的那种，一个项目几百块钱，要求一大堆，不干了……

superblue

大半夜调域名控制器，结果整个域全完蛋鸟。。。。项目失败，大老板管客户叫亲爹也没用鸟。。。。

racecar

这要从不同角度来看，老板说："赚钱的项目 就是成功，否则为失败。 烧的可以钱～" 。 技术员说："在此项目上，无论从使用者界面方面，还是安全级别上都用了最新技术，与时共进了。成功的~"

收路费

一般统计里对“失败”的定义是 不单最后没做完的算失败 凡超预算 超时 或者 原定features没有做全都都算失败 所以比率肯定高
对于CxO 们来说 这样的定义伤不起 所以但凡能最后投产的都是“成功”的 也不管对business有没有真正的帮助（减低成本了吗？增加收入了吗？有合理的投入产出比吗？）不管受众用户满意度如何 不管ops 是否对系统运作焦头烂额 不管未来maintenance还要有多少投入 ... 等等
所以这个讨论要看你对IT project 怎么定义“成功”与“失败”

Fernando

原帖由 superblue 于 2011-10-7 21:04 发表
大半夜调域名控制器，结果整个域全完蛋鸟。。。。项目失败，大老板管客户叫亲爹也没用鸟。。。。

然后呢？还有然后么？ 呵呵

典

楼上的同学们说得对，看起来失败的定义很难界定，

也许对提供开发服务的一方来说，只要钱到手了就算成功，客户能不能用无所谓。
让我想到我们最近的一个外包项目，我们的项目主管私下里表示简直就是蒙，里里外外上上下下大家都蒙，先蒙过去了再说，以后多半是不能用的，因为不是公司的关键系统，就算不能用也无所谓。 所以这个项目对有人来说将是成功的(就算不能用)。

僚人乐土

我觉得这个问题要分两个层面来说才比较清楚：一个是项目，一个是这个项目所要完成的任务/产品。
就项目而言，over budget, over time, or defective in function upon completion就算是失败的了。所以IT项目失败率才会那么高——很多项目，最加了钱和时间，最终的任务/产品是不错的，但就原来的项目而言是失败的。
上面说的一些例子，可能不能算项目失败，只能说是产品不够优秀。

我经历的一个失败的项目，是一家电力公司，投入超过400万澳元开发的一个停电维护计划系统。我在这个项目里是architect并参与开发。从工期、代码质量、预算来看，都很不错。但是，虽然期间经过几次小的功能增加，最终上线用户却不满意，原因是业务管理/数据模型的不适用和部分功能的缺失——这导致用户使用系统来完成他们的日常业务不方便。这直接导致这家公司一年多后，以升级的名誉，整合了另一个系统，从新开发（这时就代码而言，数据是移植了的）。我带领旧部，历经一年，终于成功完成。
总的感觉是：一个成功的项目，一个合格的需求提供者非常重要！这时项目成功的基础。作为佐证，说说我听到的一个失败例子：一个政府财务部门投了不少钱搞了一个系统，由该部门经理主管（提供需求），结果系统上线根本没法用（功能不对），该经理挺不住压力自杀身亡。

rumcoke

原帖由 僚人乐土 于 2011-10-8 23:47 发表
我觉得这个问题要分两个层面来说才比较清楚：一个是项目，一个是这个项目所要完成的任务/产品。
就项目而言，over budget, over time, or defective in function upon completion就算是失败的了。所以IT项目失败率才会那么 ...

同意用户需求一定要从实际中来 所谓的系统最终是跟end user打交道的 但是经常直接跟项目开发成员打交道的不是end user

racecar

Good job,400 million，How much labors?

fly050505

原帖由 僚人乐土 于 2011-10-8 23:47 发表
我觉得这个问题要分两个层面来说才比较清楚：一个是项目，一个是这个项目所要完成的任务/产品。
就项目而言，over budget, over time, or defective in function upon completion就算是失败的了。所以IT项目失败率才会那么 ...

我个人的经验： 这个项目的管理有问题，尤其是在需求管理部分。
为什么没有使用快速迭代方式？能分享一下吗？

Fernando

原帖由 僚人乐土 于 2011-10-8 22:47 发表
我觉得这个问题要分两个层面来说才比较清楚：一个是项目，一个是这个项目所要完成的任务/产品。
就项目而言，over budget, over time, or defective in function upon completion就算是失败的了。所以IT项目失败率才会那么 ...

哈哈，这就是现在做项目最大的问题，很多项目最大的障碍是客户，自己不了解自己的需求，又对IT没有理解能力，更讨厌的是需求3天一变。IT不知道business的需求很正常，他们自己提出来怎么做就怎么做，做出来不满意，那本来应该是business的责任，IT只要保证output和客户提出的需求一致就算合格了。很多consulting公司做项目的同时一边要帮助客户发掘自己的需求，一边要把他们需求引导到购买更多的技术产品和服务，这种客户就是典型的欠教育

僚人乐土

原帖由 racecar 于 2011-10-9 00:16 发表
Good job,400 million，How much labors?

是4 million。其中开发公司拿了2m出头吧。这些投入不包含硬件和维护费用。

月亮

成不成功主要看budget够不够

僚人乐土

原帖由 fly050505 于 2011-10-9 10:11 发表


我个人的经验： 这个项目的管理有问题，尤其是在需求管理部分。
为什么没有使用快速迭代方式？能分享一下吗？

我们是采用SCRUM，项目分为大约12个迭代(iteration/Sprint)，其中，还分为两个阶段，第一阶段结束就上线使用。第二阶段增加额外的功能。而且，我们都是在现场开发，我们（包括开发人员）和最终用户（他们叫system administrator，负责提供需求，我们有BA再落实成文档）有直接沟通。最终竟然还是需求问题，我真的挺意外。
在我们完成第二个版本，该部门总经理才告诉我们，第一个版本结束时，由不少用户排他的们抱怨，而个版本有人就完成业务的角度作了比较，觉得改进很大，最后老总请我们吃饭。
有时候完成业务的方法有好几种，有个高效并能兼顾不同变化，有的则不然。就像我们设计系统，不同方法的优劣不经实际考验，往往很难分清孰优孰劣，这里面包含有设计者的一种预见性。

greanbean

项目成功与否怎么定义

hornsay

N年前曾试着把现成的two tier application 该成 three tier, 试了一小部分，最后放弃了。

主要还是对three tier架构不熟悉，test时 老是randonly出现系统错误, 搞不清错误是在server端还是在client端。另外速度也明显没有two tier快，再加上three tier的support会更麻烦，最后只是玩了一下，自我安慰，算是做过three tier了。

hornsay

有时候是BA对客户的业务知识不够，又不愿意放下架子去问清楚。

我们3年前曾经接了一个case, 就是为澳洲的一个Courier增加一个功能。这个case给了我们足够长的时间来做，我让我们的BA去把问题再问清楚，但他就是老是拖阿拖，最后在交货时还不清楚我所提的问题该如何解决，只是随便给了个solution, 当时就觉得不合理。碰巧这时我自己的business想用这个Courier, 于是顺便问了一下他们的操作流程。一问才知道我们的solution根本不是人家所要的。 于是赶紧根据人家的要求再重做。

事后发了e-mail给BA, 告诉他们information collect上面有问题，人家还要狡辩，说所有的information是客户的IT部门给的，说我们只是按照他们给的去做，但为什么不愿多问这么一句话呢？

很幸运，我们现在已经成为这家Courier的软件提供商，我想这么简单的一句话还是有一定作用的，否则做出的东西真的要被人贻笑大方了。

superblue

原帖由 Fernando 于 2011-10-8 18:56 发表

然后呢？还有然后么？ 呵呵

然后没有鸟。。。赫赫

典

原帖由 僚人乐土 于 2011-10-9 20:49 发表


我们是采用SCRUM，项目分为大约12个迭代(iteration/Sprint)，其中，还分为两个阶段，第一阶段结束就上线使用。第二阶段增加额外的功能。而且，我们都是在现场开发，我们（包括开发人员）和最终用户（他们叫system administrator，负责 ...

同意需求管理真的太关键了。

我们的CRM系统是内部开发，采用类似的迭代过程，不同的是因为我们是内部，所以可以直接作交叉求证，一开始找公司NSW分部的业务员/经理采集需求，初样出来后，找VIC的人员讨论，下一阶段则找WA的人测试，这些被找的人有时候在他们的team里自己开会讨论，再来回答我们的问题。对功能有争议的时候甚至做民调，所以出来的产品总是能集中大多数人的智慧，没有一个人说半个不字。如果单从用户满意度来说，我们做的东西是非常成功的。

stevenbian

做CRM容易失败，特别是业务流程还没有就先做系统，拍脑袋想出来的东西基本不实用。

righttang

我做的教育平台开发，需求是教育部里的人，老师，还有一些Lead User，根据他们的反馈，不停的改进这个平台的各种功能。

怎么说呢，成功和失败很难讲，只要有经费，这个平台就一直存在着，就好比myschool这样的网站。然后教育部就会鼓励师生去继续使用，那样我们就会继续有需求。很多需求，做不出来了，和客户搞搞关系，让他们放弃，或者换个别的做，有时候他们也会同意。

日子就过一天混一天，反正只要有政府拨款，项目就还算成功咯

[ 本帖最后由 righttang 于 2011-10-10 10:12 编辑 ]

yangwulong1978

你们都比我幸运多了。。。。

我们做网上的ACCOUNTING SOFTWARE，， 就是和MYOB 是一摸一样的功能。。

我一个人初始化项目，，又自己做BA和会计联系，，又是学会计，又是做程序，，，
又是帮公司在中国成立公司，注册公司，，又是研究劳动法，，又是管理PROGRAMMERS， 又是测试，，做好了功能又要求爷爷告奶奶的找会计，看做的功能是不是他要的，他还没时间看，，，问他会计方面的知识他也很多不明白，，害的我天天还抱着会计的书看。。做好了项目，还要做美工，还要做MARKETING

哪有什么需求管理，，什么信息采集，，，什么文档，，什么分阶段MILESTONE，，什么项目管理，， 小公司根本不管那些，也没人听你的，，，，，，， 好歹我也在中软，微软做了那么多年。

需求改了N次，每次做之前问是不是要这功能，说是，做到一半SCREEN 做好了，让看一眼，，，确认一下，，不看，，，最后最完了，，，已经和其他的模块集成，会计老人家一句话，，不行，这不是我想要的，，我问那你要什么，，，他也不知道，，他就说知道这不是他想要的。。。。。坑爹。。。。。还的陪着笑脸。   

软件做好了，我说公司的我们自己要测试一下，他们会计不测，说要让客户测试，如果客户有问题了会告诉我们，，，

跟他们说了不行，没有用，什么分阶段测试，，没用，，，，最后做好了，让他们测试都不测试，，，，，，信了邪。。
是秀才遇到兵有理说不清，没办法，谁叫他们有钱，，也不在乎钱，，，就在那折腾，，，，，，，

我也差钱，所以，就陪他们折腾。。
还好，，项目都差不多做完了，，，，，，

[ 本帖最后由 yangwulong1978 于 2011-10-10 10:23 编辑 ]

linkspeed

>就说知道这不是他想要的。。。。。

我最喜欢这样的，可以一直charge钱。。

jerryclark

有NDA，不能讲

夜游神

我年初领导完成了一个网络项目，我之前有3批人做过，花了将近3年的时间没有能够完成最基本的第一步--site survey
我接手后，直接跟大佬要了特权，踢飞了project management, 踢飞了change control team~~~

花了差不多2个多礼拜做site survey,全面理解整个旧的系统。不光光是网络的，基本上从建筑planning一直到key applications,还有人和团队~~~
最后发现之前的图纸全部都是错的，遗漏了不知道多少细节~~~

然后有了visibility,后面就是顺水顺风的做下来了，roll out new design, creating build materials list, fighting for bugdge……………………之后到了实际部署，动用6个人一共只花了2个小时就搞定了~~

后来震惊了党中央，上面派人下来问我怎么弄得这么顺，我就说：It is all about visibility and I am the only one got this visibility that's why I know what I should I plan for and how am I going to do. The less bullshiting "PM" & "RC" involved the faster you can make the achievement.

做项目，我的体会是整体上的大局观+细节理解+权利+沟通~~~缺一不可~~~

目前来看，很多项目失败是失败在没有完全理解
1 现在是什么情况
2 什么是客户要求
3 根绝现在的情况以及客户的要求，什么样子的方案是最合适的

弄清楚以上三点之后，再继续搞七搞八的开会~~否则都是白搭~~~
还有就是别浪费太多时间和非专业人士（PM&RC）开会，一般90%都是浪费时间~~~绝对的实时的视觉，保证绝对的实时的零风险，保证绝对的实时的正确决定和预期

[ 本帖最后由 夜游神 于 2011-10-10 16:48 编辑 ]

JerryWu

righttang 在redfern做事？