祭奠逝去的青春-记YY项目失败总结

Luo Weifeng 2011-5-21

时间过得真快，距上次做项目都快半年了，也是时候总结一下经验教训了。

首先，介绍下大背景。哈尔滨工业大学（威海）不算是很出名的学校，即使在我们自己看来都有点名不正言不顺的意思，虽然是校区，但还没有被普遍的承认和认识。但是学校还是很争气的，虽然扯淡的三方共建基本等于无经费来源，但学校还是把自己放在了所谓好大学的位置。课程安排还是比较紧的，尤其是软院，课程安排那个紧的也难以想象。没5月1，没10月1，好像从来不曾有假期这个说法。

上面基本扯谈，下面进入正题。进入大三的第一学期（也就上个学期）很荣幸的转战到XX实验室，而XX实验室和YY公司有合作，所以做起了YY公司的一个项目，这也是整个故事的开始。
项目很大，但在我们这群毛孩子面前就好像是天上掉下的机遇。项目被划分为四个小组，三个前端，一个后台，而我，有幸参与后台并作为组长。
正如你所意料的那样，三个前端很成功，他们做的的确很棒。而我们后台，你可以想象IBM360当年的尴尬境地。不像失败，也丝毫没有成功的说法。接下来我做个个人的检讨，也是目前为止我们公认的项目失败的一些原因，只为后来者做出一些借鉴，也为自己的那个半年画上一个句号。

失败因素一： 接口标准的频繁更改，或者说没有标准。这个问题可以说是项目进展中最最突出的问题，一类是我们的客户端-服务器通信协议。我们客户端服务器通信协议在短短一个月内出现了11个版本。而且很多都不兼容前面版本。指定协议的时候只顾及了协议本身的优化，即使一个字段对业务没有任何影响，也被接下来的协议立刻替代。造成的后果可想而知，四个团队在不停的更改代码以适应新的标准，造成了大量人月的浪费。后台内部也是一样，数据库设计从无到有，从第一个版本到后期很多版本，一直在变动，自始至终没有一套可以拍板的标准，而这方面，我个人对我的团队以及项目表示深深歉意。

经验一：时刻保证有一个被大家共识和遵守的一个标准（接口），在不危及项目成败的情况下，所有对标准的更改被维护在一个单独的标准（接口）开发树上。所有项目部分均按照这个既定的标准来执行，这个标准必须被大家所承认。所有开发过程中关于标准的异议和突发奇想在不影响项目正常进展的情况下都被加载到开发版标准（接口）树上。

失败因素二： 人月安排。人月是个古老的问题，也是最考验Team Leader的一个东西，而我就在这里翻了跟头。对于人月的安排我同样对项目组表示愧疚。后台小组四个人开发，我们算是有明确的分工。在开发前期，我过多的投入到了客户端-服务器通信接口的讨论中，以至于半个月后我们后台还像没有开始一样，数据库的设计又走了标准频繁变更的这个老路子。还有个更致命的地方就是：我作为小组的team leader竟然都我所依赖的组员的能力并不是很了解，有的时候竟然错误的估计了他们的生产能力。这个问题就好像：能否根据博尔特9秒58的100米记录推测人类可以在100个9秒58里拿下万米记录。还有一个问题就是，正确估量可用时间，因为前面背景里边说了，大三的孩子都是很忙的。

经验二： Team
Leader应该能够很清楚的了解各个组员的能力，项目复杂度，做好恰当的人月安排。项目结束后我尝试过去使用像project等管理软件，然而真实的问题并不像project软件那样来的简单。大二在zz实验室的时候那个project图够标准正规了，可是真正做下来的时候，发现实际问题有时候竟然比这个复杂好几倍甚至几十倍。比如说，你考虑没考虑过哪天一位或几位同志感冒了，女同志孕产，谁女朋友过来了等等这些问题。
而这个正考验team leader的东西，没有经验可供借鉴，而这方面我做的很失败，在此向我的组员表示歉意。

失败因素三： 严重缺少交流。口乃心之门户，一个成功的项目是需要很多交流的，而我们的项目中却吧交流错误的梦想着用“详尽的文档”来代替。诚然，这是可以替代的，然而，风险是很大的，因为你无法保证文档本身的可用性和权威性。而且，交流可以发现项目早期的路线错误，比如说，我在项目总结的时候才跟一个哥们交流了下，他就很清楚的告诉我，标准（接口）问题对项目的困扰，要是我能在一开始就这样交流就可能避免这样低级的问题了。

经验三： 永远要想着跟团队打成一片，要融入他们。Team
leader不能高傲的活着，交流的第一步便是成员关系，你没有成员关系谁跟你用心交流，剩下的事就一切扯淡。

失败因素四： 追求完美，过早的优化。 我借用一句csdn上某人的话“将神的恩赐发挥到极致”。本来这句话是很有善意的，但是把它放在软件工程中却是致命的。因为追求完美，所以过早的去优化，无论文档或程序，过早的优化都是灾难性的。

经验四：时刻准备开发第二个版本，在不影响项目成败的情况下坚决不提前优化或增加功能。 把所有对项目次要的东西都不要一次性往工程里边加，越微小的东西到最后越是灾难性的，这个也就是所谓的软件项目范围控制。就那这个工程来说，直到完成这个工程，我们这边做的东西确实他妈的正规，文档齐全，工程等都很规范，但是deadline的时候我们还不能运行起来。而BB团队跟我们并行开发，他们的代码确实很糟糕，文档很少，功能不如我们多，但是他们能跑起来了，可能一定意义上能运行了，我们这边的开发像个臃肿的大胖子，往前走一步都很困难，以至于后边的很多组员干脆都不来实验室了。

失败因素五： Team
Leader对组员的过分干预。
这个可能大部分是我的原因，因为很多代码我会去review，而且本身又是个极其追求完美的人。比如说，根据设计状态吗应该是通过逻辑操作来检验的，可是有大哥就直接枚举了，而我很不镇定的要求按照我的思路做。现在想来真的很幼稚，可以这么比喻：你觉得一个项目的成败重要还是实现的方法重要？

失败因素六： 太过注重文档本身。要知道的一点是，why 文档？
为什么要做文档，这个是很关键的，整个项目开发过程中我们有接近10M的手写文档。我们错误的把文档至上话了，而忽视了交流。文档是规范，他一方面是部分交流的替代，另一方面是留与后人的参见。我们把简单的问题文档了老多老多，其实这些简单的问题本可以在开发过程中很轻易的搞定。我们把自己的工程搞的跟IBM360一样，企图用文档来减少交流，而那些所谓的软件工程权威在很多情况下都是不适用的。

经验五： 敏捷开发。首先声明，敏捷开发不是没有文档。还有，我不是敏捷开发方面的专家，有时间我会专程的学习这个东西。
我们都知道，软件行业在近半个世纪才突然降临世间，而这以前，汽车工程，电子工程等领域关于工程的理论已经趋于完善，还有一点，最初搞软件的那帮牛人也大都出自这些领域。造成的结果是，人们开始用已有的工程控制理论来走软件工程。他们被清晰的划分成部分，阶段，像我们所熟悉的需求分析，设计，编码等。然而，“没有银弹”似乎在告诉我们，这条路不通。尽管“没有银弹”的本意不是这样的，随着软件行业的发展，人们越来越认识到软件工程有别于传统工程控制的地方，于是敏捷就诞生了。在此我不再细说下去，因为我本人对这个还没有细致的研究，可它让我看到希望。

一口气写了这么多东西。一来，在此，我向我的团队深深道歉。二来为一些像我一样的人提供借鉴，同时，留此纪念，以慰那些年华。

                                                      
2011-5-21 10:44