打包工具是如何失败的

    曾因项目的迫切需要计划开发一打包软件,最终却夭折。现在回想多有遗撼。不得不令我反思当中的教训。
    我认为要想开发一个成功的软件两个大的环境是必不可少的，一个是外部环境，包括公司的支持，领导的鼓励和拥有一个稳定的，成熟的项目团队，相对稳定的用户群体。还有一个是对软件本身的规划，包括对需求的明确，系统的架构，工作量的评估，明确的项目计划和有序的计划执行。
     打包工具的失败就是一个印证。
     打包工具的构想是源于项目中，繁锁的，重复的人工打包操作，包括从配置库一下代码，编译，打包，上传FTP等操作，由于打包后进行问题验证时又时常出问题，所以该过程不得反复多次执行。执行过程中又难免出现放错文件，漏打文件等不必要的错误从而严重影响项目进度。
打包工具就是为解决打包过程中的繁锁操作，提供可视化界面，为打包提供一键式操作。一开始构想时好的。但是一开始也是错的，因为打包工具一开始就缺乏一个可供运作的外部环境。公司不知道有这个项目的存在，或许还称不上是一个项目，因为它只是我个人提出的一个优化项目流程的简单方案。但是也由于这个问题，为项目的失败埋下了一个定时炸弹。
开始对项目进行简单的规划后，包括简单的需求分析，系统的架构。没有正式的文档，也没有对文档进行评审和风险评估。就开始着手开发了。开发过程中不断的变更架构（因为一开始就没有一个好的架构），不断的变更需求（虽然需求是自己做的），没改一个地方，对代码都是翻天覆地的变化，当中的辛酸或许只有我自己才能体会。先抛开架构不说，为什么自己做的需求，自己开发，需求都还会变呢？那是因为在开发过程中，你站在用户的角度一想，发现那样做确实不当，得改。这就告诉我们问题越早发现，就越容易被解决。想想如果该需求是在需求文档中详细体现出来，在需求评审的时候被发现，那改改文档也就了事了，等到了开发时才发现这个问题，想想那个时候去改那又会有多大的改动。这也告诉我们好的文档不仅能有效的指导开发，提高质量。也能更及时的发现问题，避免不必要的改动。更是后期维护升级的一个依据。
当然这些变化还不足以让一个项目夭折。打包工具一开始规划其中一部份包含了对开发人员的代码进行检视等功能，但由于公司推出了一个工具已经具备这一功能，使得打包工具的这一需求已不在具备这一用户群体。所以稳定的用户群体在一个软件开发过程中也是一个不可忽视的环节。
      在项目开发到中期，我被分配到一个实际项目中，由于没有多余的时间来做这个不被重视的工具，打包工具开始慢慢夭折。从这个事分析，我个人其实也算是这个项目的一个稳定项目团队。我被分配到其它项目中就算是为这个稳定的团队带来了不稳定因素。结果导致项目夭折。可见一个稳定的，成熟的项目团队在项目中的重要性。
这个项目虽然失败了，但我从中吸取了很多教训。如果再给我一次机会来做这个项目，有几个事情我必须得做。
     1,向公司审请，将该项目作为公司内部项目正式立项。确保有一个稳定的外部环境。
     2,向广大用户(开发人员)收集需求，整理形成软件的基本规格。
     3,明确制定项目计划，有组织，有目地的进行研发。
     4,根据基本规格编写需求文档，明确功能点，进行大众评审，及时发现问题。
     5,制定详细的架构规划。进行评审。
     6,协调有扎实功底的开发人员，确保技术难题被攻破
     7,协调有丰富经验的测试人没，保证版本质量