04年回顾

        又快过年了，孤身一人在外地，虽然是家乡但毕竟没有回家，还是蛮想家的。
        项目进行一年了，其实实际进行很久了，从商务洽谈开始到需求调研，然后总体设计到详细设计一共都三年了，但是实际我们接手这个项目才一年的时间，正是从去年过年时分开始的。以前的一幕幕好像就在眼前，也就是在去年春节回公司后，任务就分派下来，要开始这个项目了。
        这个项目不是我们自己做的，而是和一个很有名的大公司合作的，这个大公司承包了整个项目，从硬件到软件，然后将软件部分外包出去，这年头大家都知道做软件不挣钱，或者说风险很大，当然把容易挣钱的硬件抓在手里，把其他转包出去了。虽然是转包，但是大公司毕竟重视自己的名声，生怕我们这些名不见经传的小公司把项目搞砸了，时时刻刻都要盯着，另外在客户面前还得显示是他们在做这个系统，所以整个项目一直在别人的监控之中。。。
        项目也不是一番风顺，从需求调研到详细设计，据前辈们说已经换了三拨人马了，需求调研是一批人马，总体设计又是一批，直到详细设计和实现才轮到我们这里，其中有利益纠纷也有实力体现，一言难尽，但是总而言之，就是项目落到我们的手里了，哇卡卡卡
        看官问说，为何发笑，其实也就是因为这个项目我当上了所谓项目负责人一职，负责这个项目的实施。但是这个负责人不是好当的，我最无助的在于不会编程，主要工作在于项目管理和软件测试，当然这也正是我的爱好所在。其中有一个很大的问题在此：负责管理工作是否一定要会编程，这个问题我一直在考虑，很多前辈们的看法认为，作为软件公司的管理者，特别是研发部门的管理者，一定要懂得编程，否则无法形成自己的技术威望，约束和管辖下属。诚然，研发部门的技术人员们都是一行代码一行代码垒出江山，互相之间也明白彼此的技术水平，心中都有一杠称，排出个前后左右来。如果没有一定的技术实力，特别在一个新的环境里不容易服众也无法了解到核心的技术或者业务，无法成功管理他人。但是我听过看过微软和其他一些大型软件公司的人员进行报告中提及，微软中有一种人员为PM（Project Manager），他的职责不是只负责软件开发，而更多的在于同需求调研人员，产品支持人员沟通，提炼用户真正需求，将需求转化为软件功能，撰写软件概要设计，然后同总体构架工程师沟通，一同进行软件的详细设计，然后制订详细的软件开发计划，督促计划的进行，并根据实际情况调整计划或软件功能，以确保软件产品的按期完成。
        我想我的职责更类似于后面一种，我的优势在于已经很熟悉实际业务，对已有产品的各个功能十分了解，同时有一定的文档表达能力和现场用户培训和支持能力。因此我的角色说的好听一点是项目负责人，负责整个项目的进程，同外部沟通，确保项目的完成；说得不好听就是一打杂的，除了编程以外的事情都归我来做，从项目设计文档到计划制订，从每周的周报到问题的说明，从现场的讲演到用户的培训，都由我一担挑了。当然，做为一个小的软件公司，一人多用是无可避免的，既然一个人可以发挥多种功效，压榨出更多剩余价值，那又何必多请人多发钱呢，老板的帐算得叭叭响，下头人的日子就不好过了，呵呵，题外话，扯远了。回来接着说，以前还看过一种理论，说对于一个企业来说，最重要的人员是销售人员，因为他们是拿钱回来的，次重要的是研发人员，因为拿回来的钱要靠还过得去的东西换得，其他的人员就是最不重要的罗，比如人事行政之流，这里并没有看不起人事行政的意思，实际上我认为一个公司能否录用到需要的人才，能否留住需要的人才，人事和行政起到非常大的作用，因为很多时候她们代表的是公司的形象。（又扯远了，想到哪写到哪，看官莫怪，呵呵。）在软件企业中有一类人介于销售人员和研发人员之间，那就是研发负责人了。对于很多小型软件企业，在项目前期，研发负责人要充当售前工程师协助销售人员介绍项目规划，鼓动用户的购买热情，从销售人员中得到新的粗略的用户需求，然后在实际调研中将起转化为确切的软件功能，然后根据功能的大小制订软件的开发计划，督促研发人员的进程，确保软件的完成。以前公司有个很厉害的老总就是负责这个工作的，他以前也编过程序，但是自从升到老总的职位后，就不再编写程序了，而是主要在于同用户进行交流，编写标书或工作计划，以至于配置计算机时，手下同他开玩笑说老总就不必配好机器了，反正也不编程，只要个286能看word文档就可以了。
        由上面的叙述也可以看出，作为软件测试工程师出身的我，没有实际编写过程序的话，如果想继续向管理者的方向努力，那么缺乏的一是对软件功能的估量，基于对已有产品的了解，我可以判别出改动是微小的还是有一定工作量的，也能对如何进行改动以便能更贴近用户需求而自身的改动最小提出合理的建议，但是一旦判别出属于较大的改动，我无法判别出改动所需的工作量大小，这需要对程序本身有很多了解的人员来进行估计，当然我相信随着时间的推移，经验的增长，这方面会得到一定的改善，但是不甚了解编程仍是一种障碍。另外，还缺乏的是对项目的整体掌控能力，虽然以前做过好几个项目，但是都是专注于测试方面，很少从负责人的角度考虑整个项目的进程和管理，所谓的不在其位不谋其政，但是也说明自己的积累不够，凡事还是应多看多听多想，年轻人最宝贵的就是自己的时间了，一定要为以后的发展多些积累。对项目的掌控上，这个项目又不同于以前的项目，以前的项目都是直接和客户打交道，但是这个项目有那个大公司做前端工作，他们有专门的现场经理同客户交流，我们提交的文档也都是先提交给他们，然后由他们提交给客户，客户的反馈也是经过他们然后到达我们这里，这样当然有一定的好处，那就是同客户的交流都有文档记录，各类文档十分完善，文档的激增也导致我去年一年的很多时间都消耗在文档上了，最高记录是一天写了5个文档。但是，由此带来的缺点就是，不能很有效地推动用户，推动整个项目的进展，就像隔山打牛一样，一掌推过去是十分力，到用户身上只剩了八分，用户也有一整套的机制，从联络人到信息小组再到负责人最后到实际操作人员，只剩最后两分力了，于是稍稍往前挪一点，而且现场不是由我们掌握进度，很大程度上要看用户的配合情况和现场经理的推动情况，行政部门的官老爷作风是不到火烧眉毛不着急，整体的进展情况一直不是很理想。
         私下来说，进展不是特别快的好处也不是没有，对于我们人员的要求就不是很高，小公司的人员本来就少，为了完成销售目标，销售人员一再接来项目，研发部门不得不拆了东墙补西墙，那边着急就扑向那边，于是我们项目的一个成员已经被永久性地划走了。。。其他主力人员也被时不时地被其他项目抽调，经理时常笑眯眯地问我“你们这边暂时不着急吧？那么XXX先做YYY项目好不好？一切为了回款嘛。。。”我只好说“对吧好吧，大局为重嘛。。。”唉，木办法啊~~~（借用一下《天下无贼》，hoho）
         回顾2004这一年，收益还是很多，在对项目管理和软件工程的理解上又有了一定的进步，发表了一篇小论文，考过了数据库管理工程师，明年希望能够顺利毕业，考上希望的学校，通过希分，最好还是能在编程上有所改善，加油加油！！！