对于刚完成的一个项目的一些总结

        项目是个电信类的项目（其实是一个产品）， 30 来个人做了 13 个月，前后经历了不少人员变动，包括 PM 和技术总监。我在该 team 里担任一个开发小组的组长。下面就以自己的认识总结一下这个项目吧：
        1 、首先说一下人员构成情况。
        team 里，一个 PM ，两个副的（其中一个是技术总监，另外一个是分析设计人员）， PM 在项目做了几个月的时候离职，后上来的 PM 在管理风格上比较强势（呵呵） ；技术总监（架构师）在原来的 PM 离开后离职。原来是 PM 对项目总体把握，开发工作一般由技术总监部署，后来的 PM 统领 全局，控制所有工作。我个人观点，第一个 PM 那种工作划分相对合理，他懂业务懂管理，就多负责内外沟通、协调管理上；技术总监技术功底深厚，有很好的 架构设计能力，同时开发管理经验丰富，应担任一个开发经理角色。

  PM 下面，有几个分析设计人员和开发小组组长（按功能模块划分）。分析设计人员熟悉业务对技术懂的不多，开发小组组长做详细设计并参与概要设计，同时写核心代码，下面的开发人员由本公司的员工（新员工较多）和外包人员构成，负责编码。我比 较认同分析、设计职责分开的做法，懂业务的不一定懂设计，设计是技术描述业务的过程，不懂技术做出的设计很难让开发人员开展工作。分析人员可以不懂技术，他们只负责把需求整理出来提交给设计人员。
       2 、开发过程。
        原来的技术总监在时，尝试敏捷开发 ，按模块划分的各小组进行迭代。个人观点：其实这个项目是个很大的项目，用 RUP 结合 XP 会更好，对项目整体用 RUP ，同时采用迭代和测试驱动，这 样难度虽然大些，但对以后的开发很有利。该技术总监离开后，后面的开发基本采用领导分任务模式，后来用 CC 实施了 daily build 。项目开发中期，一部分人到另外一个地方做开发，但还是同一个项目，这样便有了异地集成（用的版本管理是 VSS ），两边的 team 里便要单独找出人来负责两边代码的同步，这项工作增加了成本，中后期两边的测试人员开始工作，常会出现代码同步问题产生的 BUG 。我暂时想不出有什么好的办法解决异地开发的合代码问题，只能总结些教训，如果没有其他办法解决异地开发的代码同步，就在两边的 team 里各找出一人合代码与文档（类似一个 Facade 吧）。有一个版本控制 管理员更好，该人直接对 PM负责，其他人员不能插手该工作。在项目中出现过两边多接口的情况，影响了 team member 的团结与工作效率。没有使用过 CVS 异地开发，不敢妄加评论。
        D aily build ，对于有 N 多个模块的系统， daily build 是好事， build 的周期却不一定是 daily ，它的决定因素应该考虑项目组的开发能力、系统开发进展等。 daily build 是双刃剑，用不好对开发人员测试人员都是一种折磨 。我不敢说daily build 在这个项目的使用是成功的，因为所有的开发人员和测试人员由于它的存在而不得不拼命加班，每天到深夜是正常现象，但它对项目的成功起了一定的作用。
       team 中原来有几个专门的技术人员人做技术研究与验证 ，主要解决开发过程中普遍存在的技术问题、研究新的技术或写出公用代码或工具来提高整个 team 的开发效率。对于大的 project ，这些人的存在有一定的意义。
       3 、内部的管理。
       首先说一下公司的发展倾向，原来公司是产品＋项目，有专门的部门做研发，现在公司对人员整合，不再有研发部门，按项目划分人员 。我所在的公司说大不大说小不小，带有国企性质，近年来业绩在下滑 ，从公司现状看按项目划分未尝不是好事，不过从长远考虑，对于要求有技术要求的公司，专门的研发部门不可少。按项目划分同时使一种现象强化，即重业务轻技术，公司搞电信软件开发与系统集成，对于懂电信业务的人员很重视，项目经理都是搞业务出身的，而且 team 的中级管理人员也是搞业务的，这样形成了一种业务人员带着一帮技术熟练工工作的现状，技术人员很容易有不满情绪。对于行业软件公司，这种情况很普遍， 对于公司，如何构造一个”和谐“而又”竞争“的工作环境是个大课题。
       管理有一种情况也许跟不少其他公司很相似，现在的 team 是 PM 一人负责制（个人认为矩阵式管理管理成本较高，但其更具稳定性）， 项目组由PM一手抓 ，这对 PM 的要求很高，PM的业务能力（行业领域的知识与经验） 、沟通、组织协调影响着项目的成败。
       在team 中，人员职责划分要明确的道理都懂，人们大都知道自己做什么，但不作什么同样需要 Manager 明确。对于一个大的 team ，管理需要严谨，需要层次， member 之间的沟通应遵循一定的原则。看到现在的 team ，想到以前的一家日本公司（不要鄙视我），那家公司的管理让人佩服，尽管他们用的技术并不先进。
        还有一点，也算是一种经验吧。 team 里总有一些人技术业务能力不突出，但沟通能力强，呵呵，这类人的存在应该很普遍，他们容易得到领导的青睐，记得公司里 PM 培训文档中列出的 PM 能力中，沟通能力 最重要 。这些人被 PM 以及上层领导视为人才，综合能力很重要。
      以上便是自己在这个项目过程中的一写体会吧。作为一名技术人员，有一点现在自己不得不接受：不要沉迷于技术，比技术重要的东西很多，比如沟通：你能把你的技术观点很好的向你的同事推销并让他们采纳吗？ 你能让怀有抵触情绪的客户满意你的工作成果吗？ 能够两耳不闻窗外事，一心只研究技术的人毕竟是少数。

评论

1 楼 senvenfoot 2008-08-30  

总结的很好，我也有了这样的经历，想总结一下，可总是不想下笔，以后向你学习，多做总结