2012年终总结

从时间段来划分，今年做了3大块的项目管理相关工作，包括

第一季度主要是业务管理部的项目管理和部门管理

    这个季度对我个人和对我的工作任务来说只可以用两个字来形容，那就是“变化”；因为周围环境发生了改变，之前的管理模式也有很多变化的地方，可以说是满怀希望；

经过大概在不到半月的样子，公司对部门进行了改编，我们形成了矩阵式管理模式（暂时是弱矩阵式），从部门和项目两条线开展研发和管理，对于我来说，主要是相关项目管理的，虽然项目管理并不是很擅长，也没什么实际经验，不过一直以来都是做软件项目，还有前期的总结和主管的支持，我还是蛮有信心的。于其说之前做的项目不是项目管理人员，但是在项目团队中，也一直在盯着项目前进，很多流程对项目最终交付还是很至关重要的。所以对项目管理还是比较熟悉的，也并没有什么负担。接下来就开展工作了，我负责的主要是项目流程制定，以及相关oa流程制定，还有部门和项目之间的协调；部门的季度规划，部门的工作责任制定以及评审会议召开等，总的来说总感觉像是测试的黑盒测试，了解的是系统外部的功能，包括重点功能和后台，但是系统内部代码，逻辑等还是了解不够透彻。

总结本季度最大的收获就是熟悉部门管理人员，尤其是对各个部门管理人员的工作情况和沟通方式有了深的了解。其次就是工作重心转移，从测试管理转到了项目管理，也真正认识到了多项目管理的难处。同时也坚定了继续深入项目管理的决心和信心。还有一点是在工作中我们的项目管理没有深刻的了解项目实际的情况，然后去管理项目其实是非常被动的，在加上权限所限，基本上没有进行实质的管理，只是对部门主管提出一些项目流程要求，同时也给项目做了一些零散的突发事宜，对项目起到一定的促进作用，所以在工作中，我申请调任进入到项目内部，深入参与项目其中来进行项目管理操作。

第二季度是进入到项目组进行实际的项目管理

    本季度通过工作安排接手交易系统项目和视频加密项目；视频加密属于外包项目，基本是和客户澄清需求的工作，以及验收程序。其中交流的内容比较多，虽然软件功能实现了，但是并不是很理想，因为涉及到了平板电脑，这个硬件的问题。硬件并不是我们擅长的一块，但是既然接了这样的项目还是和客户进行了提前沟通确认，在硬件和软件的兼容性问题上遇到不少挫折，其中必须要总结的是关于跨行业的问题，大家在一个不熟悉的行业做嵌入式系统，经验不足是最重要的，不过今后在遇到类似项目应该得心应手了。

    接下来主要是交易系统的工作，交易系统是公司重点的项目，用户也比较多，问题也比较多。与之前不同的是，现在的项目管理工作重点进入到了项目中，可以实际的了解到项目内部运行，并对季度项目计划进行安排，任务的分工，把项目管理做到了一定的规模，最起码我有的所有项目管理知识都可以运用在本季度管理过程中开展相关关注的工作，比如熟悉了visio和project项目管理工具，给项目带入了迭代早会制度并进行管理，对项目任务的责任进行了每天的跟踪和了解。 做计划时让开发人员自己定任务工作量，基本上没有出现太多的工作延期，过程中的项目风险也可以及时的得到分析和解决。从同时抱着学习的心态和技术部主管学习和整理未来的项目进度5.X的任务，从 需求收集，到需求 oa评审，在进行迭代开发，测试。进行的很是井井有条，而且任务都在计划中完成，

总结这个季度亲自带项目深刻的体会到了项目管理的过程，工作强度也比较大，总的来说是收获颇多，同时最大的感悟就是项目管理不是执行，而在于协调调动和推动。单于此同时有最大的一点没有做好，就是项目质量，每个版本发布之后，开发和设计都比较流畅，发布版本之后总是没有测试对版本的评价，这让我很是费解，难道只有客户才能发现系统的问题吗？不过还好通过一个月的指导和规范要求，项目流程已经基本固化下来，和设计,开发以及部门主管都达成了统一的项目过程控制。大家每次的迭代工作都做的比较满意。

第三，四季度开展程序化交易系统项目相关工作和测试管理以及产品市场推广和运维工作。

     下半年，终于回到了熟悉的程序化交易系统项目，这个项目是之前做了两年多的一个大项目，而且市场前景很不错，从项目立项时，就在做测试的工作，一直到后来做产品设计，以及测试管理和质量管理，对项目背景和项目成员非常了解。当然对项目存在的问题也很清楚，不过我也深知，项目质量管理任重而道远，改变一些流程和工作习惯是需要时间的考验的。所以开始进行了尽然有序的分工，目前情况的项目管理对我来说，最大的缺陷在与没有开发的经验，对开发进度和开发遇到的困难没有足够的预测和解决，

随着工作重心的转移，为了产品正式对外发布的那一天，项目组的同事们都在为这个项目努力着，从大家时不时的问版本什么时候给客户用就可以发现，大家都对产品上市充满期待。项目迭代安排也是紧急，实盘团队的建设，编写策略的培训，用户手册的编写，软件操作视频，运维方案和执行，测试流程的建设和责任的划分。版本的控制，文档的管理，需求管理，但同时，在我看来项目缺存在很大的流程问题和质量隐患。首先，需求管理；项目的需求来源主要是老板自己，产品经理和试用客户。项目组需要对这些需求进行收集和整理，然后在迭代之前开会评审这些需求，从而确定哪些做，哪些不做，或者大概在哪个迭代做，以及做的时间和人力成本和风险因素等。然而迭代需求评审例会并没有按时开，而且并没安排测试人员参与，这样直接导致需求不及时，需求不明确，测试人员因不了解需求，无法快速完全的完成测试任务。第二就是文档管理，很多时候，有需求，但是只有一句话，两句话，产品设计文档还没输出，迭代开发任务已经安排了，大部分功能需求都是一边开发，一边写文档，或者已经开发完之后，在补充文档。这样的文档对项目作用并不是很大。第三，产品的缺陷库缺陷太多，解决bug时会遇到很多问题或者问题连连相扣，也不难想象，毕竟开发过程中没考虑周全所致。我一直认为，产品的质量是项目组过程控制和过程改进的结果，而并非是大家想的测试人员测试的结果，在加上需求的变更频繁，也没及时知会相关模块和部门，导致一系列的管理问题出现，几次的迭代总结谈话，大家都认为管理存在很大的问题，作为算是项目管理成员，感到压力无比之大，怎么改变现状是当前面临的重大思考问题。但是首先是决策权，做任何一件事尤其稍微大点的事情，都没有把关的人，有时候责任不清晰，也是导致问题存在的一个普遍现象。就像是测试一样，我们有个测试标准，这样工作流程和工作目标就很明确了，现在看起来比较模糊，还需要分析现状，总结经验，改进目前的不足。

下一步目标计划；

我们项目需要加大需求源头的文档输出，提前给开发人员了解和熟悉需求功能。                           加大需求评审力度，制定对开发人员有用的设计文档。提高项目成员的业务技能和严格编码规范，从而提高输出版本的质量。

个人收获：

1.对项目运行情况熟悉，在实际中深刻体会到了过程控制项目的重要性。 
2.熟悉项目管理过程中重要点的控制和关键因素的影响，也对应总结了一套解决办法。 
3.对测试管理和运维管理能力的掌握和提高，对项目质量管理有了新的认识和总结。 
4.沟通能力逐步提高，协同开发经理对整个项目进行管理，包括开发人员设计人员。 
5.项目质量管理方面迈进一大步。