【项目总结】：如何做一个牛逼的Team leader？

        

        随着ITOO高校云平台3.1项目的结束，我们各种各样的总结也被提上了日程。Java版本的所有开发人员和Donet版本的所有开发人员坐在一起进行了关于项目开发管理的头脑风暴，虽然我只是Donet开发组的一个子系统——考评系统的模块开发人员，但是对于项目开发管理也有自己的一些思考和看法。

        众所周知，作为一个Teamleader，是要考虑很多很多事情的，如何调动团队成员的积极性，如何统筹安排团队成员分工合作，使工作效率达到最佳，如何根据开发人员的技术水平、经验以及个人性格等诸多因素为他们分配任务，以使总体的项目开发效率达到最优等等，都是我们要去认真思考，从而给出可行的解决方案。

        但是，我今天要谈的不是这些，而是我作为一个开发人员在做项目的过程中所遇到的种种问题和切身体会去考虑如何做一个更好的Team leader。

        首先第一个问题是：如何让新人快速的上手项目，顺利的进行开发工作？

        这是一个我个人体会比较深的问题，因为我就是所谓的新人。在项目的初期，需要我们去了解项目开发所使用的系统框架，还有更为重要的是待开发系统的业务需求，这个是我认为比较难搞的。你可能会觉得奇怪，不懂需求，看2.0的需求文档啊。

        这又牵扯出另一个管理上的问题，那就是项目文档管理问题，说实话比较乱，因此很多人都选择不看文档，直接看原型图然后咨询2.0版本的开发人员业务逻辑，再加上自己的琢磨，一点一点的去理解和实现。如果我们的需求文档和各种开发文档写的比较规范，整理的条理清晰，那么我们的开发人员就可以按部就班的去做自己的那块的开发。

        其次，在开发过程中，我遇到了很多的问题，这些问题让我对开发管理进行了思考，如何才能让水平参差不齐的一线开发人员高效率的进行代码开发？首先我们要明确一个观点：真正的项目开发目的不是学习，而是产品。我们没有那么多的时间去研究我们的项目中使用了哪些技术，为什么用反射？WCF的好处是什么等等。如果你心存疑惑，去找资料进行了解和学习，那么我们的项目工期肯定要被耽误。

        因此我的想法是，将项目开发所用的各种工具，比如VS，DBMS以及各种工具类软件和插件等都放在一起，并附上一份开发环境搭建手册，然后将项目所使用的框架纯净版做好，并将在开发中所要用到的各种类库版本统一，也随框架放在一起，并附上一份系统框架使用说明，把这些东西放在一起，共享给所有开发人员，这样一来，我们能够很顺利的开始做开发，而且可以规避在项目中引用不同版本类库造成的错误，比如我在项目开发中不小心把EF版本更新到了6.0，导致我的服务端代码彻底混乱，最后不得不将SVN上的解决方案删除重新上传备份。

        另一个比较让人头痛的问题是——代码调试，这个我个人认为是我们开发过程中最耗时的事情。由于每个人的水平不一样，遇到bug到解决bug的时间也不同，这样会造成一种现象，那就是调试高手会不停的在各个位置上轮转，给这个调完了又被那个叫去了，如此一来，光忙着到处调试了，自己的开发也会被耽搁。对于开发过程中遇到的各种Bug，我的想法是建立Bug和解决办法映射管理机制，就是我们把错误管理起来，当我们的开发人员遇到自己无法搞定的bug时，先去bug库中寻找是否有对应的解决办法，若没有则请人帮忙调试，解决之后将错误原因和对应的解决办法写入Bug库，这样我们的错误管理库会越来越完善，到开发的后期，几乎就没有什么问题能够让我们耗上半天甚至一两天的时间去解决了。

        同时，我们也可以组建所谓的“平台组”，由各种技术人员组成，比如框架的设计者，UI设计和调试高手，以及各种技术的研究者，比如熟悉WCF、EF、WF等各种技术的人员还有Jenkins集成的高手等等，由他们组成机动组，负责所有开发人员在开发过程中遇到的各种问题，这样集思广益式的解决方案比较适合我们现在的情况。因为我们不是分层开发的，是按照业务逻辑线进行开发的。当然我们也可以尝试一下分层开发模式。

        可能我写的有些太细节化了，并没有在网上看到的很多文章那样，说一些高大上的什么原则啦，规范啦等等，这是我作为一个一线开发人员，从我自身看到的问题和现象去思考如何做一个牛逼的Team leader。当然要真正的做一个牛逼的Team leader，还需要很多很多的东西去总结去学习。先说到这里，未完待续……