一个项目失败的总结

总成本花费100W的失败项目的小反思大中小这个项目到几个月前基本暂停，总共花费了大约100人的月，总成本也大约为100W吧。几个月收获的产品只有一个中间代码。 当然，参与成员已经取得了一些技术进步。让我们把项目总结一下。 认为伤痕不好而忘记痛苦，需要总结经验，无论成功还是失败，成功都是模式(失败是逆模式)。没有开始，是噩梦的开始前期无固定严格的项目可行性分析；上司在打哪里，即使上司模糊的感觉，部下也只能全力以赴。 这在我们这样的企业里应该很普遍。 回顾一下，这100W探讨了可行性。使用风险管理，特别是新的/先进的/未知的技术，使用未知的技术，无论声称风险非常多，多么先进。如果项目初期不进行风险管理探讨，最后，这些风险无故消失，一部分出来，Block你的项目毁了你面前的工作，最后毁了你的项目。没有需求、愿景和界限项目远行时，需求看似无限。 经验丰富的领导终于想起了界限定义。没有边界，需求就无法完成，满天麻雀，都想抓住，团队人力物力非常有限，对于一个产品来说市场也不等待，必须在规定的时间内出来的软件，有可能成为成功的软件。需求，远离用户需求当需求仅仅是推测性的需求时，人类的想象力总是超出我们所能做到的，所以自然会感到无限。 但是，这带来的可能性，不仅没有终点，而且脱离了用户的需求，仿佛在练习屠龙的绝技。 精炼的没有市场。需求，隔靴搔痒的需求如果软件的最终用户接受培训并积极配合软件开发过程，那么该软件的成功概率将提高几成。 不幸的是，我看到的许多部分并非如此。 (由于项目本身还没有控制进程，所以要求用户代表做什么？) 我看到的是，用户的代表最初似乎在等待检查软件，不想参加详细的需求制定，大部分是需求收集员的预想，预计与实际相差甚远，通常像牙膏一样从用户那里得到提示，只能得到语言的判断。 往往来来往往，需求在雾中看花。 需求收集者在麻烦中失去耐心，更是天马推测，不再给用户添麻烦。去陌生行业/领域需要勇气和资源去陌生的行业/领域，就像很多企业的多样性之路，有时也是必要的。 不巧，和许多企业的多元化道路一样，软件也是想进入陌生行业的痛苦之路。 需要的不仅是勇气，还需要机会，什么是东风。 然而，还需要资源来支持。 低估困难可能低估所需资源。 没有必要的资源，你可能走了90%的路。 我不能走剩下的路。 从沙漠中央步行到离沙漠边界只有几英里远的边界。 没有最后补给，就离不开沙漠。 无论什么风吹草，都可能成为压碎你的最后稻草。无止境的终结没有人承认失败，尤其是没有人要求你这么多。 我们的项目也几乎没有人说项目失败了。 虽然听说了延期、暂停、取消等形容词，但实际上必须承认有失败的项目。过程，没有过程，没有积累从开始到结束，从未开始到未结束，所有过程都留在我们的头脑中，还有一些缺少的需求文档和不可用的中间代码。不久，所有的记忆可能都会从我们头上消失。 特别是像这样失败的记忆，我们自然会选择性的记忆丧失。 但是，我们不应该吸取教训，不应该花钱买教训。 有过程的记录的话，也许就能知道哪条路线不通了。 我们没必要走失败的老路。项目成功与否变量多，有技术，有管理，有关系，有自己的，有客户的，只要我们能控制，至少这个项目成功了一半。项目需求的变化是肯定的，而且变化通常是频繁的，我们如何确保不会随着客户需求的变化而变化。 首先，要进行前期的需求调查，尽量为用户着想，使功能品质的满足最大化。 需求调查前期的目标与范围和需求调查末期的功能规格说明书必须和客户签字确认。 这保证我们了解的需求是客户的要求，在项目末期与客户检查时有依据。 根据我自己做项目的经验，客户一般对计算机不太了解，如果和他们交流使用我们的行业，他们完全不了解。 对于文档来说，我们了解得越多，就越难写出需求，文档越多，客户就会感到厌烦，不直观。 给客户看看，就知道这是他们想要的。 我个人认为最好的方法是制作系统的原型。 系统的原型应该在需求分析时由开发人员在分析师的指导下完成在实际环境下的开发，当然开发只是界面的功能模拟，没有基础代码的实现。 这样做的目的有三个优点。 一是客户如何看待他们的系统，如何操作他们，二是这些开发成果可以二次利用，三是能够更好地发挥客户的需求。 项目中期经常发生需求变更，经常进行需求变更管理流程。 需求变更表，小变更自己掌握，顾客要求的变更由开发人员和设计人员协商提交给项目经理，项目经理估计变更损失工程时间，在一定阶段提交给顾客，大变更直接提交给顾客，通知顾客需求变更对项目的影响对需求进行分类和评估，以确保重要部分不能改变(例如，系统体系结构等于从头开始改变)。 同时完成客户签字确认，能把这部分写在合同的细节上就好了，但国内合同在订货时似乎已经接受了，没有细节，合同签订后才发现问题。 但是，签订合同也是一项很高的技术，可以明确记载需求变更哪个等级、需求变更多少等，建议将系统的边界、功能范围和解决方案与合同一起签名，可以保留客户提出的新功能。 当然，这需要项目经理很高的经验和技术，不仅仅是学习就能掌握。结合我的项目开发经验，说明项目开发中失败的原因一、在需求调查阶段我们做的不够，调查时大约半天，收集一些报告，不了解用户的需求。二、不重视客户现有系统的分析和研究。 我们开发的系统是客户现有的系统，他们已经使用多年，在使用过程中他们已经形成了自己的习惯。 并且他们的旧系统也有他存在的优点，在使用过程中逐渐完善，但我们在开发过程中完全忽略了旧系统的存在。三、签订合同也非常重要，具体内容已经说明。没有四，功能规格说明书，这是我们项目中最大的失误，后来客人的变更使我们被动。 功能规格说明书反映了客户提出的所有需求功能，我们也是根据功能规格说明书开发的。 后期客户变化可与功能规格说明书进行比较。 具体如何变更将遵循我们的变更过程。 经验教训： 功 能规格说明书作为产品需求的最终成果，应包括所有需求。 开发者和顾客不能做出任何假设。 如果软件需求规范中未写入预期功能或非功能需求，则不会显示在产品中，而不是合同的一部分。 注意完整性、准确性、可行性、必要性、优先级、无模糊性、可验证性、一致性、可修改性和可跟踪性五、上期项目开发人员投入过少，项目周期越长，对我方越不利。 主要有以下几点时间越长，客户的需求越多，变化越多，我们的风险就越大。从长远来看，交易方接受的变动等政局变动很多。项目周期过长，容易导致人员流动扩大和工作效率下降。经验教训：前期投入大量人才，尽快完成，降低我方风险。六、项目管理人员是项目成败的关键人员，尤其是我们这类公司对项目经理的要求更高，对这一地位人员的综合素质要求非常高。 为什么这么说，首先从我们公司项目经理的工作开始，我们公司项目经理承担项目前期调查、需求分析、结构设计、质量保证、计划执行与跟踪、业界知识掌握、人员管理、技术支持、风险预测、数据库设计等工作在大型软件公司，这些工作至少由有3年以上专业经验的2人进行。 项目经理和软件架构师。 如果一个项目是前期的这些工作错误的话，后来有更强大的开发团队也是没有用的。 我们还是年轻的团队，需要这样的人才，公司要培养。 遇到项目，雇人担任这样的工作，风险可以预料。 而且，这样的人员肯定是从项目实战中成长起来的。 不是没有软件项目管理经验的人和市场上的人都可以转身，而是可以参加书籍和培训学习。七、一味快速开发，追求时间进度。 我所在的很多公司都想尽早完成项目。 我知道我们公司也一样，但不是朋友。 项目和孕妇怀孕一样，没有捷径，必须一步一个脚印走。 公司往往为了加快进度，省去了一些工作，结果节省了几倍的时间成本来弥补，更严重的是浪费了前期的工作，用语言表达了“投鼠器”。 项目有时间，功能，资源这样不变的黄金三角规则。 他们永远相互联系，互相排斥。 如何平衡他们，需要我们根据实际项目情况进行分析和解决。 作为开发者也不想在一个项目上花费太多时间，他们也想快点结束项目。 开发人员在项目中时间过长，他们非常焦躁，工作效率也下降，最严重的风险是他们离开自己。 那么如何解决这个问题，我个人的意见在我们的实力上是以正常的步伐做的。 如果项目功能、时间和资源一定，10月份必须完成，我们必须在5个月内完成，就等于孕妇怀孕5个月生孩子。八、系统边界尚未确定。 系统边界是指我们所在的项目应该做什么，以及这些功能点应该具体做什么。 这些不确定或者用户不清楚的话，今后我们将永远做不完的工作，用户将不断提出新的需求和新的功能，我们将无法控制。九、重视前期调查和设计还不够。 包括数据库等的设计在内，我们曾经在我们公司的项目中，我们总是畏惧顾客的要求，总是更深入地挖掘顾客的要求，害怕我们的工作量增加，结果开发后，对顾客说：“这是我们需要的很少将时间投入到代码和数据库的设计中，这些工作原本就很抽象，需要不断的研究和推敲，但是由于时间的进度，我们很快就出来了，结果是客户的小需求变动，我们的设计不好，所以前期的工作浪费了。十、顾客意见的一致性，我们在调查时过于相信领导，我们所做的项目的真正用户不是领导，而是广泛的员工，领导只是看数据。 我们的调查对象主要是最终用户，特别是在大规模的项目中，领导者很多，各有各的想法和意见，到底谁错了，其实这并没有错。 我们吃亏的是他们领导发表意见时不在一起，他们也没有开