项目管理的教训与反省

做公司技术部主管也有半年多了吧，因为公司是创业型公司，采用的开发模式也是作坊式的开发——一人一个项目，所以主管的实际工作实际上也只是一些杂项的管理以及开发过程中的某些决策权（外加小小的虚荣心和小小的福利，呵呵）。

在我们以前的开发过程中，一直没遇到什么大的问题，第一是因为项目比较小，第二我个人做事比较负责，一直编写的是内核以及接口供别人使用，我想只要核心稳定了，外围简单的应用系统就算有问题也不会差到哪去，直到今年的一个项目，改变了我的看法。

今天的3月份，公司新招聘了一位新员工，这位同事以前在一家网络公司做，每天的任务就是不停的写网页，面试了以后，觉得技术熟练度还是不错，再加上要价不高，就录用了。经过半个月左右一些杂事的测试后，就给了他一个新项目做，围绕接口编写一个检索WEB应用（我们公司做全文检索）。

接口实际上已经和SQL Helper一样简单了，而且经过实际使用，也很稳定，但一个月过后，web基本开发完了，这位同事的网页是bug一堆，而且测都测不完，经常会发现新的bug，整个给老板的感觉是不稳定，老板去演示软件时，也会时不时的报错，给客户安装更是麻烦。两个月这样的过程反复折腾后，这位同事也累了，就辞职走了。留下的代码我简单看了下，太乱了，单说一个问题：两个有相似度95%的页面，也要分开写两遍，代码还不一样。我叹了口气，也没敢继续交给下位开发者维护，建议老板新开发一个，老板同意后，我安排另一位水平较低的毕业生来做（人员储备不足，人员技术水平有限，每个小公司都有这种的困难），这位同事虽然刚毕业，但是代码倒写的干净利落，同样是采用粗放式的开发管理，我只是经常去看看他的任务进度，没关心过具体实现，我也有任务在身，没过多的时间去管别人。结果可想而知，又一次重蹈覆辙。

这两次的事情给了老板和我深刻的打击，我停下了接口和内核的开发，自己又重新写了web，没用原来一行代码。代码很简单，我也不会为了技术的完美，去做简单的事情复杂化这样的蠢事，完成后，安排测试员仔细测过几遍，改完几个小bug就给一个新客户上线了，我有自信它会很稳定。

现在回头来总结今年一年的开发，终于体会到了作坊式开发的危害，软件开发完了，除了注释，一点文档都没留下。包括代码的组织架构等等，都是凭个人经验在编写，我自己的代码也是这样，没有文档，没有UML，没有一切，唯一有的只是注释和一颗负责任的心。想到以后代码规模会继续变大，内核和外围的应用会继续扩展，我渐渐的感到不寒而栗，也感到自己逐渐在失去代码的掌控力度。我想改变，不想看到下一次等内核的代码也失去控制时，整个产品线的崩溃，这是一个程序员的悲哀啊。

现在开始恶补软件管理了，回头去翻翻软件工程，觉得很多以前觉得无用的东西，现在都像机场高速一样，快速高效的通往目的地，而且没有岔路。

相信我遇到的问题很多在中国小公司做软件开发的朋友都会遇到，希望大家能更早的引进标准的开发流程给公司，绝对有百利而无一害！

 

今天跟大家分享刚学到的一点知识：

以前我一直以为技术第一，有了技术就有了一切，昨天在读《IT企业研发管理——问题、方法和工具》这本书时，发现里面写的4条能力很有趣：

敏锐的商业头脑

丰富的产品开发经验

较强的管理能力

不错的技术才能 

重要性从下至上，依次更加重要。在这四条里面，对于项目经理来说,技术是最不重要的能力（当然，还是要拥有不错的技术，才能让兄弟们信服）。

 

希望对大家有帮助。