软件项目经理工作总结

【#实用文# #软件项目经理工作总结范例#】日子在弹指一挥间就毫无声息的流逝，回顾这一年来的工作生活，想必大家收获不少吧，来总结过去的一年，展望充满期望的下一年吧。如何输出一份打动人心的年终总结呢？以下是好查范文网小编帮大家整理的软件项目经理年终工作总结范文，欢迎大家分享。

软件项目经理工作总结 篇1

通过一年学习实践，在以下技能上面有了较大进步：

1)对研发、生产各项环节的更清晰认识。经过2x2Triplexer、ECANCNU、ECANCLT几个案子的历练，增进了对设计预研，设计验证，设计导入生产等环节的熟悉程度；同时，更多参与与各部门间的交流，沟通能力得到锻炼，增加了处理各种问题的经验。对产品的研发历程和成本产生等有了一个比较完整的认识。

2)对网络的更深认识。年初花了不少时间对Tripleplay相关技术的规格，以及实现方案做了很多调研工作。在实现方案调研过程中，查漏补缺，让我对网络的认识更加的完善。硬件上主要有，对OSI七层网络结构模型的更深认识，对PON网络结构有较清晰了解，Ethernet产品的一般实现方案有较深了解，知道了一些路由及交换产品的一般实现方案，还了解到VoIP产品的构成及实现方案等等；软件上主要有，对Linux系统的更深认识，对SIP协议的细节认识，对Router软件实现的认识的加深，以及SIP服务器的移植、使用等。

3)对产品可靠度设计的更深刻认识。包括de-rating，ESD，Hi-pot等设计考虑的.深入学习。

4)对硬件基本调试方法的更深刻认识。包括使用万用表，示波器，网络分析仪等设备对产品各参数的测量，并bugshooting等。

5)一些基本的PCBLayout常识学习。对如SignalIntegrity，DesigneForManufacturing，PCBFabrication，PCB过流能力考虑等等，都有了一个初步的认识。

6)对一些元件的更认可认识。在制作采规及元件选用时，及时对各种器件的基本知识做了整理，对电阻、电容、二极管、PowerIC等元件有了更加全面的认识。

硬件方面：

1)学习硬件调试、维修。增加数字电路调试经验，单片机常用外围单元调试、设计经验等。

2)继续完善各种元件的基本知识。

3)增加PCBLayout经验

Linux编程方面：

4)LinuxMakefile编程、及shell编程继续学习，以提高工作效率。

5)Linux应用编程继续练习。争取明年一年能熟练Linux应用编程!

6)继续熟悉Linux系统，可简单进行移植，裁剪，驱动编程。

以上，结合公司project，重点进行强化。

嵌入式技术应用广泛，比如，可作为设备的控制模块，CATV编解码终端中的应用，各种网络设备中的核心控制器模块。嵌入式技术在增加产品附加价值，如易用性、界面友好性等方面表现突出；同时，嵌入式技术又可以快速集成现有技术，IC，或IP以形成新产品，来满足市场需求。

综合公司业务范围，嵌入式技术优势，以及个人所学专业知识，未来2~3年内，定位为嵌入式工程师，努力学习相关知识

软件项目经理工作总结 篇2

合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。

以下我从几个方面描述一下我认为比较合理的模式.

1.需求获取

在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。

软件项目可以大致分为专用软件和通用软件两大类。

对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。

但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。

对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。

为了比较好地与用户进行交流，使用一些工具是很有好处的。

为了讨论用户界面，可以用VB，delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)

为了讨论软件运行的流程，可以采用UML的UseCase图。

2.需求分析

在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。

这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系，可能需要不断修改而形成一份分析文档。

我想强调几个问题。

一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的.格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。

二是需求获取与需求分析的关系。

用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。

例如当初采用UseCase来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。

三是分析与设计过程的衔接。

分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。

对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。

对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。

现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。

3.设计过程

设计阶段的工作包括:

对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。

定义界面部分、数据访问(数据库)部分。

由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。

4.编码

进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。

5.测试

如前所述，即使是小项目，也应该严格地进行测试。

软件项目经理工作总结 篇3

这一年的工作结束了，我们部门在工作当中也是取得了一些成绩，确实是有进步的，细细回顾过去的一年还是取得了一定的成绩，在工作当中，大家都在认真负责的做好分内的事情，作为一程序员，我感觉自己在工作当中还是有一定的成长的，也就过去的一年我总结一下。

对此我也是抱着非常大的信心，我也知道新的一年工作结束了，这对我也是一个非常大的提高，我也一定会坚持做的更好一点的，在过去的`一年里我参与了两个项目，陆陆续续都是完成了，感觉特别的充实，对我个人能力也是一个不错的提高，也希望以后这些可以继续去做好，充实自己，作为一名程序员我按时的完成好工作，每天都认真的处理好相关的职责，在这个过程当中，我还是希望把项目做的更好一点，在这方面我也是坚持做好了这些，这一年来在工作当中，我也是端正好了自己的心态，在这方面我也是养成了良好的心态，我一直都能够体会到这一点，在这方面，我真切的体会到了这些细节。

尽管过去一年在工作当中，做的不是很好，但是我还是对自己很有信心的，我非常清楚这一点，有的时候也会加班到很晚，可是每一次解决完问题后的那种喜悦是很好，让我很有成就感，做好一个项目不是一件容易的事情，现在在这项目的工作当中，我还是有很多值得去提倡做好的地方，我也很清楚在工作当中，我应该要去进一步维持下去的，这一年来经过工作的洗礼，在抗压能力上面我是有很多进步的，作为一名程序员有的时候一个项目需要不断的改，确实在这方面我还是感触很深刻的，我深刻的体会到了这一点，现在我当然是清楚自己接下来应该往什么方向努力，做好这份在的前提是提高个人综合素养。

新的一年开始，我一定会在这方面，进一的维持下去，搞好每一个项目，做到让客户满意，按照客户的要求去搞好工作，这一点是非常重要的，需要继续维持下去的，工作是自己分内的事情，这一点不容忽视，对自身的要求高一点，虽然新的一年当中取得了不错的成绩，但是在未来的工作方面这些是需要做出成绩来的，提高业务能力的，坚决不能忽视掉，一年的时间虽然结束了，可是这个过程让我很充实，也让我能够做的更好更加优秀，接下来认真做出一个好的成绩。

软件项目经理工作总结 篇4

这一年来的工作已经结束了，我知道这对我而言是有很大的提高，作为一名程序员我坚定的认为自己是可以做的更好，在未来的学习当中我还是深有体会的，以后在学习当中，在这一点上面我希望自己可以做的更加的到位，作为一名技术人员，我还是做的非常不错的，希望自己在这一年来的工作当中我可以继续维持好的状态。

这一年来的工作当中，我现在还是希望可以做的更好，公司对我的培养还是比较多的，在这方面我是坚定的体会到了这一点，在未来的工作当中，我是坚持的做好了很多的事情的，年终之际我回顾起来确实是获得了很多，我也希望自己在以后的学习当中，我深刻的意识到了这一点，过去一年来我也是独完成了很多的工作，也和公司的同事一起合作了一些项目，在这个过程当中，我也确实是深刻的意识到了这一点，我知道在这方面我是维持了一个好的状态，现在回顾起来我清楚的意识到了这一点，通过这次的项目我还是深有体会。

我绝得工作能力是需要不断的去落实，对于这一点我是感觉非常有意义的，年终之际，在这个过程当中，我清楚的意识到了这些细节是可以做的更加到位，我觉得以后还会有更多的事情可以做好，这一年来的'工作结束了我也是希望自己可以把工作做的更好，想要把工作做的更好，我还是深有体会，在一些事情上面，我确实感觉很有意义，在工作当中我进一步的调整好了自己各个方面的职责，公司对我个人能力还是做出了很多的判断，我相信在这一点上面我知道自己各个方面是非常有意义的，在公司做好自己分内的职责，当然我也是意识到了自身的努力还是值得的`，我也想要为公司争取更多的价值。

我也是清楚的意识到了自己的不足，虽然每天的工作很充实，但是在一些项目上面，还是做的不够好，出现了一些细节的问题，这也确实是我应该要去调整好的，我会改正自己的不足之处，在以后的学习当中，我会继续做好自己分内的职责，在程序工作方面应该要更加的细心，我会让自己做的更好的，感激公司领导的关照，以后我也一定会让自己做出更好努力，努力提高自己的工作能力，做技术工作让我感觉很有意义，新的一年我一定会认真做好工作。

软件项目经理工作总结 篇5

一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。

一、小项目的特点

大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:

1.项目功能相对较少

2.开发人员较少

3.开发周期较短

另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.

二、小项目开发中常犯的错误

小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:

1、开发之前没有认真地进行项目可行性和工作量的估计。　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。

2、没有真正的设计过程

开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的`几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。

这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。

第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。

3、不经过单元测试而直接进入系统测试

造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。

殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。