技术能力分析报告总结（精选2篇）

技术能力分析报告总结 篇1

一、职业成长回顾

还没有来得及揣摩自己在这一年中的所有得失，20xx年已经领近尾声，细细回首这一年走过的路，虽然没有轰轰烈烈的成绩和战果，但是也经历了一些不平凡的考验和磨砺。我想，20xx年是我工作旅程中的转折一年，在这一年中，我在自己的岗位上迎来了更多的历练和思考。我想，这是喜悦和汗水并存的一年，也是充满了机遇和挑战的一年。

来到已经一年光景，作为一名项目工程售前的技术工程师，承蒙公司领导与部门同事的批评指导，在履行自己职责的同时，也逐渐看到了自己距离优秀员工所具备的全面素质要求还有一段需要努力弥补和完善的差距。空闲的时候我也时常扪心自问，是否拥有足够的资格去享受”售前工程师”这样责任重大的称谓？

自从担任公司项目工程售前技术工程师以来，我的主要工作是为行业部门以及其他业务部门的同事编写项目设计方案、项目施工组织方案，以及就公司现有资源产品整合起来编写解决方案。记得过去一年最开始独立接受项目派单时，我几乎不太能够理解项目售前的含义，更不了解应该如何去把项目售前的工作开展实施，而是过多的依赖于抄袭现场的方案，在一些项目关键点部分处理得不够理想，过于理论化，导致与实际脱节。通过几次不太成功的案例锻炼之后，慢慢的我也开始形成一套适用于自己成长的思维模式，并摸索出一些相似领域、固定产品的处理办法。但是回过头来看，那段时期的方案编写也存在许多的不足，体现在对于项目建设的需求经常只顾眼前的形势直奔主题，阐述完功能产品的适用性，能够如何满足客户需求即可，但是却忽略了未来客户发展所带来的变化与扩展，对项目的把握不够全面，毕竟系统集成涉及的领域众多，涵盖的技术面较广，这种着眼现在直奔主题的处理方式也折射出了自己知识面狭小的事实。

好在公司的领导及同事通过单独技术指导以及对整个部门进行的项目经验分享指导，也让我逐渐明白在进行系统集成项目时宏观了解，全局设计的重要，对用户的需求必须要深入的分析，了解客户的企业规模、事务处理流程以及发展规划之后，从全局的角度来进行方案设计，再突出眼前的局部建设构想，这样才能真正把系统集成方案写好，才能真正让客户满意，而我也必须在具备这样全局把控的思维能力，再加上知识的不断积累，才能成长为一名合格的售前工程师。

二、工作开展回顾

在过去的一年，我对涉足不同行业的系统集成需求也进行了一些回顾总结，其中视频监控项目与网络项目占到了所处理案件的70%，在这些项目中，我所要承担的任务主要包括：项目需求了解、项目设计方案编写、项目跟踪等。而相对来说，项目方案设计又占到了很高的精力付出比例，但是如何提供解决方案完成工作，亦经历了两个时期的成长。

第一阶段：

从产品到方案。将公司的产品资料（如海康威视、华为等常用设备）修改成针对用户的解决方案，这一类售前支持不在少数，处于对公司内部代理的产品比较熟悉，再加上有一定的技术功底，所以这个时期在编写方案的时候从完成速度上来说比较快速，但不能站在客户价值角度来理解产品。

第二阶段：

从需求到方案。通过总结问题以及对项目的不断理解，有了自己的知识体系和工作方法，能站在管理咨询的角度采用各种方法去了解客户业务、分析用户需求，并提供解决方案。

三、个人职业展望

通过这一年时间的摸索与观察，对于现在各大行业客户，越来越不满足于单一产品的建设需要，他们往往希望单位或企业内部的各个应用子系统能够兼容整合，并且所有的管理能够在统一的平台下进行。也就是说，对于未来客户系统集成需求我们可以理解或者影响客户往应用系统集成方向发展，而不是单一的提供产品集成，在激烈的行业竞争中，我们需要提供客户耳目一新的亮点方案。

在学习交流中我发现，数据集中与云计算将是未来发展的技术方向，所谓数据集中，就是把企业所有日常办公产生的数据集中在机房管理端，确保数据的安全有效管理，杜绝一些潜在或已知的泄密危险；而云计算通俗来说既是虚拟化服务，包括应用虚拟化、桌面虚拟化和服务器虚拟化，这样的技术发展将越来越降低对客户终端的硬件要求，转而提升系统应用的灵活性和高可用性。

除了对技术方面的发展追求，在职业规划中我也有一些为自己客观定位的要求。在过去的工作开展中，接受客户案件的时候，我想自己可能过多的是处在一种被动的状态下，按照客户提出的需求进行分析，了解客户一时期内的发展状况，然后提出可行的办法。但是我想这样远不能够树立自己在客户心目中理想方案解决者的形象地位，我更倾向于为客户树立一种可靠可信的咨询师的身份角色。不单单对客户的需求进行分析，还要对客户所在行业进行一些必要的了解，清楚行业发展趋势以及新兴技术的应用案例，从硬件和软件结合的角度出发来进行整体解决方案设计，提供给客户综合应用解决方案。

明确了个人的发展方向与职业角色定位，这就要求自己仍然需要不断的知识积累，尤其在数据集中所涉及的存储、备份、数据恢复以及云服务涉及的虚拟化技术上投入一些精力，结合项目实施者成功经验的分享，总结出适合自己在新的一年工作中处理项目的办法。

技术能力分析报告总结 篇2

总想着每天、每个月、乃至每年都有点进步。，对我来说，是起伏不定的一年，也是收获颇丰的一年。当然，大的收获是有了一个可爱的女儿。：-）

在这一年，我跳了两次槽，是自愿的，还有是被迫的。我目睹了一些公司从盛到衰的过程，也看到了一些脚踏实地的公司。

离开x1公司，是因为我觉得x1公司不是在做软件，所谓的印度模式，我想，绝对不是这么做的。理想不合，不想浪费时间，也只能背负跳槽的恶名，挂冠而去。去x2公司，是因为看到他是美国独资公司，做外包软件，能够接触美国的客户和技术，希望能够有所收获，何况，职位也不错。的确很想好好做，也跳累了，只想稳定发展，毕竟，是做父亲的人了。没有想到的是，竟然让我目睹了一场资产争夺的好戏。公司易主，流言满天，诽谤四起，官司大战，这种平常只有在电视和电影里看到的情节，我实实在在的亲身经历了，也算是人生的重要一课吧，至少，让我看到了人性阴暗和恶毒的一面。自然，是做不下去了，只能又走。

也看到了一些踏踏实实做事情的公司。园区的瑞博软件就是一个。很少看到如此踏实做事的公司。若干年后，只要他能够存活，必定是一个成功的公司。虽然老板对我也很有诚意，只是，对于教育软件，我实在没有太大的兴趣，何况，如果想做教育，我何不选择安博呢？毕竟，安博给于我很多。回头想想，在其他公司，我都是在奉献，只有在安博，是学习了很多。

说起跳槽，其实，看看那些公司，有多少是在踏踏实实做事情的？老板本不懂软件，都是看着软件行业能赚钱，想来捞一票，结果把中国的软件行业做坏了，也害苦了中国的程序员。自己不好好做事，怎么怪别人跳槽？同工作经历的坎坷相比，，在个人能力方面，今年的进步是非常大的。今年上半年，我的进步集中在技术领域。我更加深入研究了设计模式、ejb体系和.net平台，还有uml建模，终于有所突破，设计了一套自己的基于.net平台的系统架构和开发工具，并且得到了应用的证实。在网上也陆续发表了一些文章，受到比较好的欢迎，还上了赛迪网的开发之星。

下半年，在软件工程方面收获是很多的。

看到网上对于印度模式从吹捧到批驳的吵闹，也看到x1公司学习印度的失败，加上自己从开始就对那些记者的怀疑，决定好好学习软件工程。我一向认为，任何东西，不能道听途说，只有自己好好深入研究，才能得其精髓。同时，软件工程绝对不能只看印度的，毕竟，美国才是软件业发达的国度。

列举一些学习的参考资料：《rup软件工程过程》、《msf微软解决方案》、《xp极限编程》、《cmm实践应用infosys公司的软件项目执行过程》、《人月神话》、《软件需求》、《软件工程java语言实现》。每本书，我都仔细研读了，颇有体会。

我开始就想，印度软件工程绝对不会象那些记者所说的那么简单，所谓的高中生编程说。所以，我必须实际看看印度的软件工程。《cmm实践应用infosys公司的软件项目执行过程》，是印度大的软件公司infosys公司的分管质量的副总裁写的，介绍他们的cmm4的软件工程，果然不同凡响。这是我了解印度软件工程的主要窗口。

首先，同原来的想法不同的，也可能同大多数人（尤其是受那些软件记者影响很深的“专业”和非专业人士）想法不同的是，软件工程实际上不仅仅只是管理，而是一门涉及很广的交叉学科。在软件工程中，大约一半的内容是专业性很强的，涉及到软件分析、设计甚至编码的技术。所谓的结构化、面向对象，都在软件工程的范畴内，同样是软件开发和组织的重要内容，也是软件质量保证的重要内容。至于软件开发的管理部分，只能算是软件工程中软件工程过程的部分，或者说项目管理部分。脱离管理来开发软件是绝对不可行的，同样，抛弃技术基础，空谈管理出效益，便如无源之水、无本之木。诚如《软件工程java语言实现》中所说：“软件工程范围极为广泛。软件工程的某些方面属于数学或计算机科学，其他方面可归入经济学、管理学或心理学中。”在这里，我强调了软件工程中的技术部分，并非轻视管理，只想在软件工程的概念上做一些拨乱反正，也希望多一些人来关心软件的核心技术，而不要空喊口号和概念。毕竟，中国的软件太缺乏核心技术了。

其次，对管理要求的严格不说（这个谁都知道），实际上，不管是美国的软件工程，还是印度的软件工程，都是比较灵活的。即便是印度这样的所谓“软件工厂”模式，对于软件工程过程管理极为严格，也有一个部分是专门讲述过程剪裁的。整个软件工程过程是非常庞大和繁复的，然而，由于项目具体情况不同，如项目的规模，参与人员的数量、素质等的不同，对于软件过程的每个部分，不是都必须的，可以根据具体情况来进行剪裁。这个部分对于我的启发是很大的。以前做什么iso9000等，开始做了一个以为很好的规范，但是，到具体项目，总是对不起来，到处有问题，现在想想，便是少了这个变通的部分。不过，话说回来，这cmm也是老美想出来的，而不是印度。

第三，对于开发人员的选用，我发现，美国人是非常注重选用优秀的开发人员的。martinfowler曾经开玩笑的说，如果给他一批水平不高的开发项目，他会考虑全部解雇，重新招聘。《人月神话》中也说，如果200人开发一个项目，其中25个人能干，那么会考虑解雇其余的175个人，让项目经理来编程（当然，后面还有一些抉择分析，这里断章取义了）。其结论的基础是基于以下研究结果：优秀的开发人员和差的开发人员，其效率之差可以达到数量级。另外，从管理的角度来说，只有人多了，才会有管理问题，当团队规模控制在一定的范围内时，便不会有太大的管理问题。

对于软件来说，很难实现同传统产业一样的工厂化生产，这是由软件开发的本质决定的。软件的复杂性是软件的本质属性，在这个属性没有改变之前，软件便不会实现同传统产业一样的工厂化生产。至于印度的所谓“软件工厂”，实际上，只是完成了软件代码的编写工作，并不是实现了整个软件研发工作，而代码编写工作，恰恰是软件开发中简单的一环。至于印度是否真的有很多高中生程序员，印度人的书上没有说，记者到说了不少，我也无从考证。所以，软件的开发，还是需要选用优秀的人的。除非，公司只想帮别人编写代码，而不希望有自己的产品和技术。

第四，软件开发中，重要的还是团队合作和交流。这个是我目前深切的感受。具体的，大家都知道，也用不着多说。

后，对于软件开发来说，公司老板的想法是重要的。如果老板说“no”，那便是水平再高，管理再好，也终归无用。年龄渐长，也做父亲了，却总是在漂泊，没有一个可以稳定发展的地方。希望目前的公司能够有这个机会。不想总是跳槽。