关于项目进度慢的思考----如何提高整体开发效率

　　我们都是软件行业是世界所有的行业中，失败率最高的。进度最没有办法度量的，通常会拖，一拖再拖，而且人员都扑上去了，可是还是慢。

　　为什么？

　　多少年，多少人，更有很多的专业公司都在分析这里面的原因。为什么我们的人员都在加班了，没有人偷懒，都很努力，效率却上不去？

　　据我分析和思考，认为可以从下面两个角度看这个问题：业务和技术。究其原因的话，有下面几个常见的原因：

• 　　业务混乱。业务是软件的基础，软件是为业务服务的，这尤其在应用软件开发中是最常见的。可是很多时候我们太急于出界面了，忽略了业务的分析和梳理。往往有个需求，就要求尽快开始开发工作，尽快的完成功能，尽快的见到界面，可以操作，可以进行测试。其实，这时候的业务流程往往由于没有梳理清楚，存在很多的漏洞，看起来整体是没有问题的，是流畅的。可是，里面的细节，抠一下的话，会发现仅是绊子，到处都是陷阱。这样的业务作出的设计，写出来的代码，后面很有可能会需要推倒重来。这时候开发人员的开发体验就很不好，情绪受到很大的影响，效率自然也搞不到哪里去？反而，由于屡次的推到，很有可能会降下来。
• 　　技术基本功不足。就算是业务分析清楚了，也梳理好了，也画了很多的图，表述也达到了统一的程度。还是有点慢呢？还是没有达到预期的速率呢？那就是业务分析人员完成了他们工作，架构师设计了软件架构，该到程序员开始编码了。可是，每个程序员的水平是不一致的，有的时候会在一些技术点遇到问题，导致了开发时间超出预期范围。基本功包括：小到方法的设计，参数的设计，算法的应用，大到类的设计，设计模式的应用，对架构师给出的软件架构的理解，都存在各方面的问题。

　　对于第一个原因，业务的原因。我认为需要从业务的角度解决，需要在分析业务的时候，深入的思考，深入到业务的细节部分。对整个流程中的细节最好有梳理，每一步分析梳理都要有结果，文字和图例。不要草率的开工，不要只是分析一点点就可以了。可以参考程序的业务流程，分析适合自己的业务流程。

　　还有就是需要领导在这个问题上有正确的认识，不要基于要求开工，技术人员这时候可以做一些技术的积累和基础工作。例如公共类库的整理和编写，架构师可以进行系统的架构，是否要分布式，是否需要物理分层，是否有可以用的类库。还有一些cross-cutting的关注点，这时候都可以进行开发和设计，进行技术的探讨也是不错的。对于后期的开发也是很有帮助的。

　　对于第二个原因，就需要企业和开发人员两者都要有深入的认识。

　　首先，企业方面要有公司的类库，有自己的积累。对于一些公共的类库，一些非功能的模块，例如：日志、异常处理、数据合法性验证、用户验证、数据访问、缓存等等。

　　其次，公司要有统一的开发标准，开发规范，这样的话，大家可以互相帮忙，例如在一个人较慢的情况下，有人可以帮助他编写一部分的功能，加快整体的速度。因为大家的标准的一样的，所以接手起来也不会太困难，否则接手很困难的话，对整体进度就没有帮助了。

　　再次，对于开发人员需要有培训，培训每个人的基本功。尤其是关注那些新人，提升大家的基本功。使得大家在进行模块设计和开发的时候不至于牵绊太多，可以顺利进行。而且做出来的东西，从质量角度来讲也可以更高，减少返工的几率。这方面园子里面也有人提出了很多不错的建议面向对象思想的头脑风暴（一）   面向对象思想的头脑风暴（二）—— 详解继承与组合的优缺点  面向对象思想的头脑风暴(三)-使用接口进行解耦  等。其实就是提高我们的面向对象能力，因为我们大多使用的是面向对象的编程语言，但是开发的时候我们除了写了类，就什么都没有了。这方面可以用头脑风暴的方式，花一个下午或者是一天，大家一起针对一个问题进行分析、设计、编写，让新人参与进来，可以学习成熟的代码编写方式和技术，可以统一大家的认识高度。虽然不可能通过几次的培训和做几个小题就有实质性的提高，但是可以锻炼思考能力，最终的提高还是要靠个人在实战的开发中总结和应用，还有就是多花工夫思考和联系。师傅领进门，修行靠个人。<!--end: searchItemTitle -->

　　最后，技术上面要有人来把控。至少有一个人是具有丰富经验的，可以把握整体的方向，整体的风格，可以对新人进行培训。而且公司也可以充分授权这个人，充分这个人，也可以较为放心的进行开发管理。

　　个人观点，难免偏颇。欢迎大家一起讨论。