一个项目失败的总结

1、.：.；一个总本钱破费100W的失败工程的小小反省 HYPERLINK javascript:; 大 HYPERLINK javascript:; 中 HYPERLINK javascript:; 小这个工程开场到几个月前根本暂停，总共差不多破费100人月，总本钱应该也差不多是100W吧。在几个月收获的产品只需一堆中间代码。当然，参与成员对某些技术还是有提高的。我略微对工程作一些总结吧。要想不好了伤疤忘了疼，需求总结阅历，不论是胜利还是失败的阅历，胜利是一个方式，失败就是反方式。没有开场的开场,一个噩梦的开场前期没有任何固定的严厉工程可行性分析老板指哪儿打哪儿，就算是老板一种模糊的觉得，下属只

2、能全力以赴了。这在我们这类企业里面应该算是很普遍的。当一次回头看，这100W算是做了一个可行性的讨论。风险管理，尤其当他运用一个有新的/先进/陌生的技术，运用一个陌生技术，风险是很多的，不论声称它有多先进。假设在工程初期没有进展风险的管理讨论，最后，这些风险不会凭空消逝，一部分会出来，Block他的工程，毁了他前面做的任务，最后毁了他的工程。需求，没有远景，没有边境当工程走了很远的时候，当需求好似无穷无尽的时候。阅历丰富的指点总算想起要做一个边境定义了。假设没有一个边境，需求是做不完的，满天的麻雀，都想要抓，团队的人力物力是非常有限的，对于一个产品来说，市场也是不会等人的，必需求在规定的时间内

3、出来的 HYPERLINK portal.vsharing/industry/1593.html t _blank 软件，才有能够成为一个胜利的软件。需求，脱离用户的需求当需求只是凭空猜测的需求，自然会让人觉得无穷尽，由于人类想象力总还是比我们能做到的要多的。但是，这带来的能够不仅仅是没有尽头，脱离用户的需求，仿佛就是在修炼屠龙绝技。修炼出来是没有市场的。需求，隔靴搔痒的需求假设软件的最终用户是经过培训、积极配合软件开发过程的，这个软件的胜利机率大约可以提高好几成。惋惜的是，我所看到的很多一部分都不是这样的。工程本人尚且对过程没有什么控制，谈何对用户代表做出要求呢。我所见到的是，用户代表往往仿

4、佛一开场就是等着验收软件，不想参与详细需求的制定，大部分都是靠需求采集人员的猜测，猜测往往和实践有差距，往往只能像挤牙膏那样从用户那里得到一些提示，或者片言只语的判别。往往是经过无数次的往返交流，需求还是雾里看花。需求采集人员在繁琐中失去耐心，索性天马行空猜测一番了事，不再去费事用户。走到一个陌生的行业/领域，需求勇气和资源走到一个陌生的行业/领域，有时候是必需的，就像众多企业的多元化之路。非常不巧的是，也是众多企业的多元化之路一样，软件要想进入一个陌生的行业领域，也是一条艰苦之路。需求的不仅仅是勇气，还需求机遇，所谓东风是也。但是还需求资源作为支持。假设低估了艰苦程度，能够就低估里所需的资源

5、。没有必要的资源，也许他走了90%的路了，他要走不完剩下的路，也许他从沙漠中央走到了离沙漠边境只需数里之遥的边境，没有了那最后的补给，他还是出不了沙漠。任何风吹草动都能够成为压垮他的最后稻草。没有终了的终了没有人会成认失败，尤其当没有人要求他这么多的时候。我们的工程也是，我们几乎听不到有人出来说 HYPERLINK portal.vsharing/k/others/2021-9/525215.html t _blank 工程失败了，我们听到的是延期、暂停、取消等等描画词，但是其实，我们其实应该成认，我们有做了一个失败的工程。过程，没有过程，没有积累从开场到终了，没有开场的开场到没有终了的终了，

6、整个过程一切都在我们脑海中，剩下几个残缺的需求文档和无法投入运用的中间代码。或许过不了多久，一切的记忆都会从我们脑海消逝，尤其像这种失败的记忆，我们会自然选择一种选择性失忆。只不过，我们并没有得到该有教训，花了钱，还是没有买到教训。假设我们有过程记录，也许我们可以知道，哪一条途径是走不通的。我们不需求走一条失败的老路。 工程的成败是变数多多，既有技术的，也有管理的，也有关系的，既有本身的，也有客户的，但是只需我们把我们可以控制的做好了，至少这个工程胜利了一半。 工程的需求变化是一定有的，而且变化普通都很频繁，我们怎样应对客户的这种需求变化呢，以不变应万变。首先在前期的需求调研要做好，尽能够的替

7、用户思索，到达功能质量满足最大化。需求调研前期的和需求调研末期的都要跟客户签字确认，这样既能保证我们所了解的需求就是客户所要的，也使得工程末期跟客户验收时有据可依。根据我本人做工程的阅历，由于客户普通对计算机不是很了解，和他们交流用我们行业的话，他们根本就不懂，假设用文档也很难把需求写的那么明白，而且文档很多的话，客户都看烦了，很不直观。假设让客户一看就可以看出这个就是他们想要的，我个人以为最好的方式就是做系统原形。系统原形应该在需求分析的时候开发人员在分析师的指点下完成真实环境中的开发，当然开发只是界面的功能模拟，没有底层代码的实现。这样做的目的有三个益处，一是客户很直观的看到他们的系统是什

8、么样子的以及怎样操作，二是这些开发的成果是可以二次利用的，三是可以更好的激发客户的需求。 在工程中期是发生需求变卦是很常见的，这时要做好需求变卦管理流程。需求变卦表，小的变卦本人掌握，客户要求的变卦有开发人员和设计人员共同商讨后提交 HYPERLINK portal.vsharing/module/645.html t _blank 工程经理，工程经理预估变卦损耗工程时间，在一定阶段一同提交给客户，大的变卦直接提交客户，并且要把需求变卦对工程产生的影响让客户知道，把球尽能够的踢给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进展分类评级，关键部分不能改动的做特别确认如系统架构等，

9、假设改动等于从头再来。同时完成客户签字确认，当然假设能将这部分写成合同细节中去是最好，但国内的合同好似都是在打单时是根本上都承诺，也不会到细节，在合同签署后启动后才发现问题。但合同中可以写明假设需求变卦什么级别的怎样样，多少钱等;签署合同也是一个很高的技巧，建议把系统的边境及功能范围和处理方案与合同一同签署，这样客户提出的新功能就可以暂且搁置。当然这就需求工程经理很高的阅历和技巧了，不是光经过学习就能掌握的。 下面我结合我的工程开发阅历说下在工程开发中的失败缘由： 一、需求调研阶段我们做的不够细，调研的时候几乎是一个单位半天的时间，搜集一些报表，根本就没有了解用户的需求。 二、对客户现有系统分

10、析和研讨注重不够，我们开发的系统是客户已有的系统，他们曾经用了多年，在运用的过程中他们已构成了本人的习惯。而且他们的老系统也有他存在的优点，也是在运用的过程中逐渐完善的，可是我们在开发过程中完全忽略了老系统的存在。 三、签署合同也是非常重要的，详细内容我在上面已说过了。 四、没有，这个是我们工程中最大的失误，致使后来客户的改动让我们很被动。 反映了客户提出的一切需求功能，我们也是按照来开发的。后期 客户的变化都可以和对比，详细怎样变卦按照我们的变卦流程来做。阅历教训：作为产品需求的最终成果必需具有综合性：必需包括一切的需求。开发者和客户不能作任 何假设。假设任何所期望的功能或非功能需求未写入

11、HYPERLINK portal.vsharing/industry/1593.html t _blank 软件需求规格阐明那么它将不能作为协议的一部分并 且不能在产品中出现。并且留意以下几点：完好性、正确性、 可行性、必要性、划分优先级、无二义性、 可验证性、一致性、可修正性和可跟踪性 五、前期工程开发人员投入过少，工程周期越长，对我方越是不利。主要有以下几点：1、时间越长，客户的需求越多，变化也越多，我们的风险就越大。 2、在长周期中往往会有政局的变动，例如客户领到的变动等。 3、工程周期太长容易呵斥人员流动的扩展以及任务效率的降低。 阅历教训：前期多投入人力，尽早完工，降低我方的风险。

12、六、 HYPERLINK pm.vsharing/ t _blank 工程管理人员是工程成败的关键人员，尤其是我们的这样的公司，对工程经理的要求更高，对这个职位的人员的综合素质要求非常高。为什么这么说呢，首先从我们公司工程经理所做的任务说起，在我们公司中工程经理要承当工程的前期调研、需求分析、架构设计、质量的保证、方案的安排执行和跟踪、掌握行业知识、人员的管理、技术支持、风险的预测以及数据库的设计等等任务。而在大型软件公司中这些任务至少是有3年以上本专业阅历的2人来做，一个工程经理和一个软件架构设计师。一个工程在前期的这些任务就是一个错误的话，后面有再强大的开发团队也是白搭。我们还是一个年轻的

13、团队，很需求这样的人才，需求公司来培育，假设遇到工程，再招人员来担当这样的任务，风险是可想而知的。而且这样的人员一定是从工程实战中生长起来的，不是有非软件工程管理阅历的人员或者市场人员转过来就可以做好的，更不是从书本或者参与某些培训就可以学到的。 七、一味的追求快速开发，时间进度。在我所去的公司中好多都是想把工程尽快做完，我们公司也是一样，但是我知道 HYPERLINK vsharing/ufida t _blank 用友不是的。做工程和孕妇怀孕一样，没有捷径可以走的，必需一步一个脚印走。公司往往为了赶进度，省略了某些任务，最终结果是后面付出几倍省了那些时间的代价去弥补，更严重的是前期的任务白

14、做了，用个成语描画就是“投鼠忌器。工程中有个不变的金三角法那么，即时间、功能和资源。他们永远是相互联络和相斥的。怎样去平衡他们，需求我们根据实践工程的情况去分析处理。作为开发人员也不情愿在一个工程中有过多的时间，他们也想早点终了工程。开发人员在一个工程中的时间太长，他们会变得非常的焦躁，任务效率也会降低，最严重的风险是他们选择走人来解脱本人。那么怎样处理这个问题呢，我个人的意见是用我们的实践才干按照一个正常的进度去做，假设一个工程在功能、时间和资源一定的情况下，需求10月才干完成的情况下，假设我们一定要在5个月完成，那和一个孕妇怀孕5个月生个孩子的后果是一个样的。 八、没有确定系统的边境，所谓

15、系统边境就是我们做的工程究竟要做哪些功能点，以及这些功能点详细要做的什么程度。这些不确定或者和用户不说清楚，以后我们就是永远做不完的任务，用户会不断的提出新的需求和新的功能，我们曾经无法控制。 九、对前期的调研和设计注重还是不够，包括数据库等的设计，从我在我们公司所做的工程中我领会到，我们总是害怕客户提出需求，总是不敢去更深的去发掘客户的需求，害怕我们的任务量增大，后果是在开发好后，给客户一看说：“这不是我们需求的，我们想要的是这样的。在代码和数据库设计中时间投入很少，这些任务本来就是比较笼统的，需求不断的研讨和琢磨才干设计好的，但是我们为了时间进度，很快就出来了，后果是客户的一些小的需求变动，由于我们的设计不好，导致前期的任务白作了。十、客户意见的一致性，我们在调研的时候过分置信指点，我们做的工程真正的运用者不是指点，而且宽广的员工，指点只是看数据的。我们的调研对象主要是最终用户，尤其是在大型工程中，可以说是指点很多，各有各的想法和意见，究竟他们谁的是对于错呢，其实这个根