怎样编辑网站,谷歌seo排名公司,电子商务网站建设与维护期末考试,php wordpress 备份数据库tom_lt: 遇到的失败项目比较多#xff01;让人郁闷#xff01;#xff01; 仔细分析原因#xff0c;主要在于#xff1a; 1.项目开始需求不明确。领导决定动手#xff0c;就开始启动项目#xff0c;造成和客户需要差距太大#xff0c;导致失败#xff1b; 2.需求变更没…tom_lt: 遇到的失败项目比较多让人郁闷 仔细分析原因主要在于 1.项目开始需求不明确。领导决定动手就开始启动项目造成和客户需要差距太大导致失败 2.需求变更没有控制。客户提出新的需求或者改变原来的需求没有一个好的控制流程没有人把关程序员也可以接受客户的要求导致功能越来越复杂进度和质量严重失控被客户赶走 3.自己太随意。开发人员自作聪明认为客户会需要某个功能未和客户协商就增加了一些额外的功能导致进度拖延客户不满意。 4.用户原因。用户提出了需求功能很多要求你在不可能的时间内完成我们只能加班加点最初还能坚持时间一长工作效率和精神状态都低了下来进度拖延得更多。 Jinq0123: 如果说超时是失败那我就没成功过除了一些一个月之内的超小型项目。 主要是计划太雄心勃勃。 我的一个朋友说计划应该有点挑战性。 但我现在的体会是需要历史项目的统计数据才能订出合理的计划。 sythree: 和大家差不多。 有一个是市场部对客户承诺太多需求变更太厉害了。 还有一个内部转包的项目比较可惜开始不太重视后来技术高层屈服于管理高层对设计做了较大的更改没有验证结果出了几个大的性能错误。当是就感到很窝囊一气之下换了个部门。 komantian: 失败的定义用户拒绝接受 成功的定义按时交货客户接受 我的第一个日本项目状态编程可以不懂日语程序员身份当时这个团队都很厉害美誉为梦之队最后项目重做投入了5倍于原定计划的人月数也就是作了25个人月项目无法联合调试可以运行了毛病百出别说客户我自己都不想要事后总结公司因为其它项目的原因我们更换了3个项目负责人导致指挥和仕样理解都有偏差公司为了造成没有更换项目负责人假象要后来的项目负责人一直使用前任的邮件帐号造成客户不知情对后来人的提出问题很生气认为已经讲过了造成沟通效果越来越差程序员因为语言问题只能了解自己的问题不清楚全局的要求因为项目负责人的更换内部要重新磨合交流了解最后每个人都完成了却无法联合调试。公司的负责人应当负责。我作为程序员也因为其它项目原因在这个项目组3进3出当然我的责任现在想起来也不好受我没有坚持自己的要求盲目服从上级在第二次更换项目负责人的时候我应该挺身而出但我没有。 至少在半年时间里我的情绪都没有恢复。 失败会给你很多经验从此我做项目都非常谨慎反复推演各种情况避免重蹈覆辙。我对项目中的BAD SMELL现在很敏感发现一点不对头立刻行动起来坚决的解决它再前进。 值得庆幸的是这是我的目前唯一的一个失败的项目我后来做到项目经理大小也作了7、8个项目有的也很大在全国部署的项目从失败中我获益匪浅。 ntchengl: 欧当作程序员参与的项目就算是输了关系也不大。 欧主持的两个项目最后都算是成功了但是都很坎坷。 这两个项目是这样的 第一个项目是半道接手的前任已经做过了需求分析。说实在的只是去调研过了需求分析的成果我基本没有看到。但是时间仓促最后扭转乾坤了。虽然这个项目托了3-4个月但是责任不在我。第一我不熟悉业务有个熟悉的过程第二原先的需求调研不充分错误地估计了工期。说实在的我只算是延误了2个月。 第二个项目是香港的做了10个月。这个项目算是输了但是不算我输了。项目初期调研的时候欧去不了香港去了一个不懂业务的人调研调的还不如半吊子。我没看到合同条款公司就签合同了。只是从香港的客户那里看到了合同而且不是最终合同。这个合同的附件只有两页我们写的是广告宣传上面的牛B话客户的要求也是模棱两可。我真不想做这个项目可是没办法。这个项目我也是重新调研质量完成得还算可以吧客户的要求太高了我们的合同签的我哑口无言。最后完成了原计划3个月实际做了10个月。最重要的原因是市场部不调研就错误地认为3个月才能完成。 这两个项目都是差在需求分析上面都不是我做的。说实在的最终能做出来还多亏了我呢。 我做的需求分析自己主持的项目都是比较小的基本没问题。 clamp_chen: 成功和失败只是简单的二分法很多时候都是介于两者之间的既不是完全 的成功也不是完全的失败。 影响的因素不单是技术层面的还有管理层面的市场层面的。 说不定一个开发的很差的系统却赚了不少钱而一个开发的很好的系统却 利润很薄。哪个项目比较成功呢 我最近有这样一个想法就是软件系统要引入质量等级的概念就象传统 制造业一样有一级品、二级品、三级品等等。 我曾经做过两个项目第一个项目的时候经验不是很足一开始需求就做 的很不仔细也不知道如何控制客户需求人手也只有两个技术人员但 是还有一个市场人员支持不过那时很有热情紧赶慢赶了两个月就交付 了然后就是根据客户需求不断地调整调整了大半年才基本稳定了。 从技术层面评估这个系统很差无论是可重用性还是易用性都很差如果 换个人接手肯定气死了我们后来也一直有把它重新架构的考虑但由于 种种原因一直没有实现。 但是如果换个角度评判这个项目其实很不错。 第一客户满意度很高。支持的市场人员很会拉关系而且客户原来的 操作确实很烦琐我们的系统虽然不太好用但是还是为他节省了大量的 时间另外我们的响应很及时经常是一个电话就到现场直接改掉。 因此无论是客户的领导还是实际的操作者都比较满意后来还给了我们公 司一个更大的项目 第二公司利润很好。因为只有两个人成本很低……而且拉来了后 面的项目好处很多 后来有一个项目经验比以前增加了很多对软件工程也知道了不少。 客户方面也比较严谨有专门的懂技术的用户代表配合。整个开发团队 也很齐整设计、开发、测试都有应该说人力还是很充分的。 任务是将原来的一个系统升级并附加一些新的功能原来的系统其实 很类似于我上面提到的项目架构很差在不断的往里面塞功能以后现 在再也塞不进去了因此必须重做。 从技术层面上来说这个项目还是完成的不错基本上按质按量完成了 但是总体上来说做的很辛苦客户层面的满意度也比较一般因为主要 是改善了内部架构对于用户看到的是只增加了部分扩展功能而且由 于架构的差别原先用户熟悉的界面和操作习惯难免有改变虽然我们 已经充分考虑了这一点但是不改是不可能的。 所以结果如下 第一客户满意度一般。对于领导来说只是一个系统的升级增加 了一些功能而已对于操作者来说需要花费时间来重新熟悉新的系统 而且由于我们的质量控制比较严格用户变更都需要讨论通过签字确 认然后再开发发布新的版本导致周期比较长。所以给实际操作人 员的印象是我们还不如原来的开发者 第二公司利润很薄。客户方的用户代表比较懂技术因此对于一些 细节的地方把关很严而这些地方耗的人力往往比主要功能还要多。而 整个系统的报价对于升级的功能模块报的比较低对于新开发的模块报 的稍高一些。但是由于原有系统数据导入等问题实际上是对原有功能 模块的重新开发更花费时间。虽然用户代表比较了解但是他也只能帮 我们说说好话不可能多发钱给我们。 做软件做到这个份上实在是很郁闷啊 ezlz: 一个数据仓库的项目 集成方、客户方、合作伙伴方 整个团队二百多号人呢 去年四月份做需求分析 三方人员做事都很卖力 十月份项目启动 一切步骤都有条不紊的进行着 但十二月底项目被宣布无限期终止 致使集成方和合作方共有NN多人失业 这是一个很很特殊的原因 因为客户高高高层的人事变动 这个上几亿的要持续五年的案子就此不了了之了。 有意思吗 w102272: 我说一个失败的项目吧不同的是我们是作为甲方的面目出现的 去年10月份该项目启动共投资300万计划在3个月完成产品雏形5个月稳定化6-7月产品化。我负责技术。 但高层实际投入不足150万RMB.总经理被迫在各方面严格控制成本。在开发部门我们采用了自己设计开发外包不建立大规模团队的方式来压缩成本。 需求和设计都很成功但不幸的是外包方是由总经理直接指定的而总经理本人对技术并不了解多少。 大约出于利益面子合作方屏蔽了我们一切对项目监控的努力。拒绝提供开发人员名单拒绝我们和任何开发人员直接沟通设计和需求。拒绝我们参与程序测试和模块设计过程。甚至拒绝了我们愿意保持原合同费用不变由我们这方付费派开发人员参与他们开发过程的请求。只是不断对我们说我们一直在努力靠 而我们制订的计划需求设计进度控制等就在不知不觉中变成了废纸。 在开发到1.5月3个月的时候我们向公司两次提议更换合作方但这个提议和计划无人理睬。最终随着时间流逝无人再有兴趣和胆敢提出这样的建议了。作为开发方的软件公司固然有自己的困难但甲方是孙子乙方变成了爷这种事情大家没怎么遇到过吧呵呵。 在历时10个月的的漫长谈判和拉锯战后对方终于提交了一个很不稳定bug成批的产品。将原来的35个月开发时间拉长到了10个月并在这个过程中不断提出追加开发费用的要求极度延误的开发周期最终影响了产品第一季度的销售。 在11个月后我终于得到了这个产品的源程序并开始着手组织人重新改写。按目前的进展看事实上合理组织下2.5×3人月足以开发出这个产品来。 项目本身目前还不算失败但带来的潜在损失无疑是极其惨重的。我们失去了市场先机浪费了大量的精力和时间没有得到一个理想中满意的产品。 最终没有人是满意的 市场部门不断反馈产品的错误并开始在客户服务方面不断花费成本 投资者开始少花钱的得意洋洋慢慢转变为更多对经营的参与控制和不满 总经理的经营能力被置疑并蒙受了资方巨大的压力尽管目前情况在好转 外包方在10个月漫长开发中也最终没有得到他们满意的开发费用而且显而易见本来3-5个月的开发有很多的赢利并可以进一步谈判分享市场的事情变成了漫长的开发过程中耗尽了开发费用亏损和开发团队的分崩离析据我后期的了解 公司负责项目进度策划和质量保证的MBA在种种不规范的打击下辞职而去 技术部门则在慢慢收拾这个烂摊子并在承受各方合理不合理的置疑软件设计肯定有问题写得肯定有问题(事实上是外包方)开发计划肯定有问题管理肯定有问题(事实上老板和总经理直接操纵了整个事情)。若不是为了整个经营团队的利益也包含我个人在内不至于丧失殆尽以及认为事情还可以补救恐怕我这里的技术团队能保留多少还很难说。 高层的无知30% 项目经理的无能50% 程序员20%需求及详细分析不够缺乏时间和人才等等我认为均不是导致该项目失败的关键因素。你果真以为高层无知吗而作为投资者或管理者而不是专业人员要求他们事事都象你那样明白也没有道理。 失败的原因是我们不懂软件工程个人不够优秀计划和产品不合理 利益不均衡决策不规范组织和权力架构混乱各方缺乏足够的诚信等才是导致问题的根源。 回首这些事情唯一能作的只是叹叹气而已作过这么多项目对这些风险早都不陌生了。只是又想起了英国首相丘吉尔说过一句名言没有永恒的朋友没有永恒的敌人只有永恒的利益。这不是伦理而是规律。任何公司的态度和行动都是从自身利益最大化的角度出发的而不是从良心、利他、合作、双赢、诚信角度出发的。 软件工程哎真是无能而脆弱的软件工程呀。 或许还有一种可能性就是软件产品只是项目总投资的一小部分大约只占300万投资的30%左右换算实际投资150万RMB的(50万左右按最终7个月得到最终产品的周期看最小开发开支应该是3人*7月*每开发人员平均1万RMB21万)加上我方和对方的设计成本管理成本不可预测费用应该是刚刚好。但开发方错误估计了这里的含金量也不相信未来的合作能带来更大的收益因此把所有的精力都用在和我们讨价还价宁愿项目失败也要拼命先捞一把 又或许外包方开发公司只是一个无能之辈或皮包公司并没有动用有效的开发力量来开发产品。 又或许项目背后充满了我所不了解的暗箱操纵 这恐怕是我很难再搞明白的事情了。哎... ziwuxian: 一、不能产品化。大多数软件公司都是小作坊很难针对某一方面形成强势产品只能由客户摆布提取需求不专业。上一个项目积累的知识往往很少能用到下一个项目。 二、一个人担任太多角色。让编代码的做系统分析做编码做测试让测试人员编代码做系统分析做测试让系统分析员做分析做市场做编码让市场人员写需求等等。即是让一方面的专家做多方面的工作而其他方面他是一知半解或者根本不会。 三、时间问题。估计80或者更高的项目不能按时完成在我们公司估计是99.99不能按时完成甚至很多是原定的2倍。原因有很多方面。 四、公司管理太差。没有形成上下共享资源沟通的作用。高层毫无计划地不断往下扔任务总经理接到就往项目经理上扔项目经理往程序员上扔造成 下级不断的接任务毫无喘气的时候很快一栋楼的根基压断了接着后果可想而知。 五、没形成规范。过了CMM又如何只是撑撑门面。项目根本没按着CMM走。高层说现在竞争激烈管不了那么多。软件工程也只是挂在嘴边而已。 .... 实在太多没空说了说了好像起的用处也不大。反正提了意见领导也不见 得就听取说不定摆你一刀说我管理不行不怕我炒了你....#$%# mis98ZB: 感觉就像是在说我们现在这个项目一样。 当然有一点不同是我这个部分的人员基础比较差。 我们这个项目是一个对日软件外包项目 规模比较大 就我负责的这一部分的手写代码量就达到了87,000行。 而我负责这个部分不到总体的十分之一。 就这么大一个项目 小日本居然使用瀑布模型进行开发 大开形式化的软件评审会 并且充分的向我们展示文档过度的一切特征…… 由于不是构架优先 重要的基础性代码不能及早的提交给我们 我们提交的局部的构架也不受日方的重视 而由于工期的要求 我们就在空中楼阁中做出一大堆无根草一样的程序。 直到UT开始 早期埋下的火药开始被接二连三的点着了…… 一个月之内 我负责这部分的共通函数的仕样书从1.0版狂飙至2.9版 每个0.1的增长都是影响着87,000行代码的大地震…… 三十多个至关重要的输入record也是改的天翻地覆…… 而大量的附属文档也是疯狂地修改…… 地狱啊 想想两个月之前 我还在开玩笑说项目失败的五大特征已经有三个浮现了我们的项目快要及格了 没想到今天马上就要成为现实了。 redguardtoo: 我也来说说我的经历也是给小日本开发的。 首先楼上的原文引用 由于不是构架优先 重要的基础性代码不能及早的提交给我们 我们提交的局部的构架也不受日方的重视 而由于工期的要求 我们就在空中楼阁中做出一大堆无根草一样的程序。 同样的毛病我就不多说了。 不过由于我能力比较强和我联系的那个日本人比较弱而且从一开始的设计都是我做的所以这还不是个问题。 至于代码质量由于我一开始就坚持了人盯人战术每个人都要白盒测试测试要给我review并记录的原则。所以代码的质量还是可靠的也按时完成了编码。 麻烦的是小日本要我自己把这个库集成到那个系统中但是不给我系统的文档只有一大堆系统源代码而且那堆系统代码竟然编译失败了而小日本也不清楚为什么失败而且也说不准集成在哪里天哪 然后是日本人要结婚我要度一个假期电话联系听不清对方讲什么。email联系也在捣浆糊。 最后日本人在我的反复劝说下装上了MSN messenger每天实时遥控我我去钻研那堆该死的代码。总算集成进去了工作也算完成了。 当日本人通过Msn Messenger告诉我“xx我现在才明白communication是很重要的....(因为在开始项目前我给他大讲了一通communication的重要他很不以为然事实上我当然不是空穴来风” 我听着那个小日本的长篇大论心里明白我在这家公司肯定是呆不长了我心里想你是明白了这个道理但是我可付出了巨大的代价。 gu_gth: :不明确的需求分析项目经理为了讨好客户对客户提出的需求言听必从但对这改动将要对哪禧模块将会产生影响那系模块将要发生变动客户的需求是否合理不重视对需求变动的控制太少力度不够客户的需求是否合理不重视随软件过程中需求的不断变更构架越来越脆弱。 2分析设计工作的欠缺不说分析设计的方法很少有公司对公用函数专用函数清晰的函数接口各模块各函数件的调用关系模块间的依赖关系做出明确的划分对于小的项目如果程序员还能记得会从通用函数库里调用如果不记得或程序员是个新人不辛发生了他又重写了另外一个函数出现了2个副本 漫漫的但代码重的逻辑错误是很难看的为性能、编码质量、可维护性打下隐患 3项目的风险不可否认每个项目都有一些未使用过的技术对新技术没做过原形测试等到了那个阶段是发生了瓶紧整个项目都停了或是先做出一些垃圾等有经验后再推倒重干 4管理上的问题向莫过程中以来程序员间的交流但程序员间的交流往往造成信息的损失导致产品质量问题编码的风格统一 ylg007: 经历过两个项目. 1、半途接手一个项目项目已有一年有余可是却没有一份像样的需求分析甚至连业务流程图也不见踪影。拿着一套不能并不成熟的产品到客户哪里实施。可想而知在没有进行调研的情况下修修补补最终不了了知。经历的第一个项目失败告终。经验开发模式的项目没有精确完整正确的需求是没法完成一个项目的。 2、第二个项目已完成。按照上楼的说法我做为客户方认为项目是三等品.基本满足我们的要求。开发方对供应链系统有成熟的产品并对企业做了一次管理思想的培训叫业务重组bpr吧。开发方不是调研我们在正做什么而是以老师的身份告诉我们如何管理一个像我们这样的企业。可想而知开发方对业务的熟悉程度。项目实施过程中程序的问题很少但是为项目却是三等品。因我公司高层在开发费用方面的原因不合理的缩短了项目时间。致使一些模块没有得到使用。本应完美的项目却只能评及格。影响项目品质的原因还有关键业务部门的人员素质公司本身的企业管理现状。因关键业务部门不积极配合基础资料的准备就占了项目三分之二的时间。
