- 相关推荐
技术管理者个人总结
技术人员是个特殊的群体，我接触过的HR人都这样讲，都来问我这样一个技术出身的管理者一个问题“技术人员拿么难沟通，他们到底在想什么”，对技术人员的离职就更是丈二和尚摸不着头脑，并且有个普遍的特色，技术人员的离职，对直接处理和主责的几个部门或主管，几乎没人能得到真实的信息和答案，即使有些原因被广为传颂，它可能仍然是不真实的，这一点提醒各级管理者，千万不要被猪油蒙住了双眼。我在整个与技术人员打交道的多年经历中，把经过的、经历的、处理的离职事件的原由一一列举，供参考并制定应对之策，请注意，很多是我事后，因个人朋友的身份才得到的，我自己都曾经被蒙蔽了很久。
1.薪酬
首要的因素是薪酬。不知道哪个天杀的进行了统计，还煞有介事的发表出来，说因薪酬离职的比例很低，占30%不到。真不知道他们的调查如何设计的？问卷题目如何设计的？陈水-扁的“入联公投”民调结果是70%支持，第三方民调结果是30%多，题目有很大差别。按我的经历来看，因薪酬离职不是第一位的因素，也是排名很靠前的因素。薪酬主要是对个人市场价值的公平性，有些传统行业百思不得其解，我和对手比工资不低啊，为什么还是有人离职，别忘了，您在和整个社会环境竞争，不是所有人都信奉“女不乱嫁郎，男不瞎换行”的，他完全可以换到别的高收入行业去，虽然最后大都是他自己受伤，但杀敌一千自残八百，你也没办法。我就接收过手机行业到医疗器械的员工，也有员工跳到手机行业的，在手机行业 4,000元月薪的人在医疗器械行业也就是3,000元薪酬的水平。
2.心理感觉
技术人员重心理感受，所以他们的心灵是不能轻易被伤害的，不能不被尊重的，不能被他感觉到管理者对他无足轻重的那种感觉，从小企业做大的老板，有些是这样的作派，所以他只能做非技术性行业，介入高科技，不学会尊重人是做不起来的。心理感觉的内容有很多种，下面有些因素和这一条有点重复，心理感受是个总括，涉及很多具体的细节。
3.公平的感觉
这一点被很多文章经常提及，说很多人因此离职，但我的实践体会对此不太苟同。不公平的感觉，在薪酬处于感觉不公平的人的心理底线的时候，会导致离职，但离职的本质不是公平与否，而是第一条的薪酬竞争力的问题，凡是做过几年的技术人员其实也不傻，1万多的月薪，就是实际上有些不公平，那又怎样，毕竟不是满大街都能给这么高的薪酬，一般他都会忍着干下去。所以离职不应该把此作为太核心的要素，除非贵公司的薪酬都是按照员工的底线设置的，那就要特别小心了，公平将成为压垮骆驼的最后一根稻草。
但较有竞争力的薪酬时，不公平虽不会导致离职，但会导致积极性不高，这也蛮可怕的，需要特别警惕。我有一些解决内部执行力差、精神状态不佳的原因诊断和解决方法的案子，但不是本文的主题就略过了。
4.伤心
技术人员一般心思缜密、自尊心强、强调心理感觉，第二条里已有描述。所以技术人员中会产生极富忠诚度的人，都说学历越高忠诚度越低，这一点在技术人员中不是很适用，技术人员会有士为知己者死的心理，千万不要用销售人员的伎俩和技术人员耍小聪明，很多销售出身的高管或老板经常犯这种自以为得意实则愚蠢至极的错误。技术人员一旦感觉你的真诚，肝脑涂地在所不辞。没有技术背景的销售人员做到这点比较难。
一旦技术人员伤心失望，他对其他的诱-惑是视而不见的，“杀敌一千，自损八百”的事技术人员会干，所以说，正常情况下的技术人员是理智的，而伤心的技术人员，其感性程度不亚于水泊梁山的李逵。解决此题的唯一一点就是发自内心的真诚，真诚发自内心地为对方考虑下的任何作为，只要让他感觉到，伤心就会避免。
发生这种事情最常见的是老板或高管有太强的心理成就感，似乎是皇帝了，凛然不可侵犯，对待下属像演戏，读到此文的老板也许对此嗤之以鼻，似乎技术人员迂腐透顶，却上几个天塌不了，离职不可怕，怕的是身在曹营心在汉，在职不在心，这样的事还少吗？可惜有几个老板真正反思过自己的做人。
5. 无所事事
这一般发生在小公司，或者大公司新建部门、改编的部门，在没有理顺的时候，或者部门首脑比较无能，不知何处下手开展工作的时候，会发生首脑没有方向，员工无聊，就担心自己的水平不提升，持续下去会丧失竞争力，所以离职。
解决办法比较简单，第一是换首脑，找有思路的人来领导，或送出去培训，请顾问专家近来指导工作，把工作开展起来，对员工最大的激励是发展你的组织和业务；第二是先找些杂事给员工干着，哪怕暂时和工作不直接相关或者安排学习，华为批量进人几千人消化不了的时候，就采用带薪培训的方式，长的有一年，就是这个解决办法。
这里面有个情况特别注意下，就是对新毕业的大学生研究生，安排了个岗位，其实有很多的事情要做，但他不知道要做什么，这是比较要命的，企业不愿意招新人，这是主要的一点，新人不知道自己不知道什么，讲了吧他还不理解，还很自恃，这是员工的问题居多。可怜之人必有可恨之处，大学生找不到工作值得同情，但他们的岗位表现确实差强人意，唉，庆幸阿，当年的我可能也这样，但感谢航天给了我几年的磨练，当我明白过来的时候却开始了不为航天事业的打拼，至今为憾。扯远了，解决之道是培训点具体知识，不要弄些励志类的培训，让员工热血沸腾，茫然无措。
6.领导差劲
领导无能瞎指挥，人品差、业务能力差、脾气坏，都会导致员工不在此混了。文章说员工离职 80%和直接上司相关，也不知道他们在哪针对什么人做的调查，比例绝没那么高。这个事比较复杂，基层经理毕竟也要为公司考虑，很多时候也是代人受过，公司政策问题，经理们解释做坏人也是无奈，出于职业规范，还得打落门牙肚里咽。解决之道比较简单，自己去想喽。技术人员不服气他看不起的上司，尤其是充内行的上司。作为上司即使真内行，也要慎重，下属和你观点不同时，他就认为你未必真内行。
7.压力太大
这个主题与本文主题有些偏差，别的都是探讨离职因素，但这一条不是离职因素，反而是不离职的因素，技术人员喜欢挑战，他觉得被安排有困难的任务是受重视，心里感觉很好。另一个没人愿意当逃兵被人瞧不起，技术人员尤其看重这个名誉。反而是长期没压力时倒要小心可能会离职了。
8. 不能认清自己
我们都知道，不是一个好的技术人员就适合当经理，可惜当事人未必这么以为，即使他真管很不好，别人都觉得，他自己却未必这样觉得，这时候，换人他就会离职，不换人就得由着他糟蹋团队，这时候才真的难。很多培训上说，建立双轨道晋升机制，让资深技术人员可以享受经理的待遇，说这话的人不知道是哪学校毕业的，按我的实践体会，就是有很多的技术人员不追求钱，就是想要权管管人。人想要什么，他越没有的越想要，所以真正平淡对待管理职位的，反而是些很有管理天赋的人，他们在任何场合都是组织者，就有经常享受管理组织的机会和心理感受，对办公室的经理岗位反而看淡，不适合作管理的人，在非正式组织中不能脱颖而出，恰恰追求这一点。
不适合当经理，又不能认清和说服自己，在这个公司得不到，那个公司给个title，就跳了。解决办法就是对这类专家得玩点政治手腕，谁让他没自知之明，你也不能启齿呢。具体办法嘛，很多很多，私下交流吧，万一本文被这类专家看到，你的技巧被看穿，反而适得其反，对你的工作不好。
9.没原因，就是想跳
这是一类人的特征，没有原因，就像吉普赛人，他们的思维活跃，聪明，在社会上是很好的朋友，可就是在一个机构里呆不住。没好的解决办法，这类人就是自己做老板都容易烦。干脆就放弃算了。这类人的特征是喜欢一个人旅游，工作能力较强，喜欢被安排“黑盒子”的任务。
10.对未来的忧虑
而对于企业的个体来说，人的精力和体力都是有限的，如果把最黄金的年华给了企业，而后半辈子却得不到保障，则每个个体无论如何是不能安心工作的。这种情况对企业较资深的老人和高级职位者比较常见，天花板也碰到了，生计问题也解决完了，未来自己怎么办，这些人一般比较有追求，有独立的经营能力，曾经和一位高管交流过，“技术人员或销售人员一旦考虑战略问题，那离独立的时间就不远了”。
这个现象比较普遍，怎么解决我也不知道，有些企业给期权，金手铐一拴，有些企业投资参股，是人才的企业成为公司的左膀右臂，上下游优质资源而不至于成为竞争对手，也有的设置绊子打压，有的用保密协议旁敲侧击……
解决之道是给股份，但也难解决，毕竟股份给少了，他们也没兴趣，给多了人多也麻烦，我想唯一的办法就是建立不怕资深人员流动的机制，让每一个人都不是公司这个大厦的顶梁柱，但这样人力成本会高些。也有些出卖智慧的公司采取“合伙人”制，搞连锁的采取特许加盟，都是有效结盟，笼络核心资源的方式，我没研究好，不敢乱发言了。
以上离职原因在技术人员中比较多见，尤其有些因素是有争议的，是不同于别人的看法，我不敢确定这是真理，虽然我有技术人员的实际体验感觉，但求百花齐放百家争鸣，让天下的老板和管理者们心如明镜，高枕无忧，技术团队卖命冲锋，企业业绩蒸蒸日上。
最后用一句话结尾：美国的创业者中技术人员远多于销售人员，随着中国经济的发展，销售人员主导创业的浪潮终将退去，技术人员主导创业的浪潮终将到来，所以技术人员的离职因素从现在开始就重视，对企业将百利而无一弊，因为技术人员将面临更多的机会和诱-惑，前面姗姗而来的正是技术创业者的春天。
外包这几年的技术和管理经验总结
技术篇：
这些年主要一直在做同一个项目，某个业务发放网关管理系统（这里简称SPXX），主要是用于管理所有的BOSS系统和组网内所有网元，组网之间采用的是Webservice技术进行数据通信，大概结构如下。
营业厅BOSS（多个）<—>SPXX（一个）<—>网元（多个）
一、组网说明：一个SPXX系统北向支持320个营业厅BOSS同时在线发放，南向支持64个网元版本和实例。
二、系统结构：该分布式系统有6↑个进程，支持添加扩展板负荷分担，进程之间是通过Mina和Jms进行数据通信，标配主备双活两块板，支持倒换，支持扩展，主要涉及Java、C++、Shell、Python、VB、Xslt等语言，大概结构如下。
1）业务发放进程（进程间都是使用Mian进行数据通信）
营业厅BOSS（多个）
↓↑Webservice调用（ACL/用户名密码鉴权）
——SPXX——————————————————————————–
DPU4N（北端业务分发进程，监听SOAP、TL1、MML等消息端口，支持并发320连接）
↓↑Mina
SPU（消息处理进程，有多个，支持随时扩展，DPU4N轮选）
↓↑Mina
DPU4S（南向汇聚）
—–SPXX———————————————————————————-
↓↑Webservice调用
网元（多个）
2）配置管理进程（进程间都是使用JMS进行数据通信）
PMU（Tomcat进程）、CMU（数据持久化进程）、OMA（配置管理进程）、JMX（进程监控进程）、Common（非进程，公共代码工程）
三、工作原理：采用MyEclipse作为开发工具，总共有8个工程，该系统是在SUSE版本的Linux系统上部署，标配主备双活两块板、支持倒换、支持扩展、升级等操作。
1）该系统有Web管理界面，主要是用于业务和配置管理，包含系统用户、BOSS用户、角色权限、日志、网元版本、网元实例、业务流管理、用户策略管理、分权分域管理、Batch/Bulk批处理等等功能。
a、系统北端是采用Webservice调用，配置管理主要是给北向BOSS配置ACL和用户名密码鉴权信息，只有通过鉴权的消息才允许发放到网元；
b、系统可以为每个BOSS用户指定业务发放权限和分权分域权限，也就是限制某些用户只能开户或者换号、某些用户只能设置139号段等等；
d、SPXX系统本身没有任何业务，只做网关管理，主要是由网元提供wsdl接口。SPXX系统南向有十几个网元，每个网元都是用SPXX系统提供的模板工具，生成接口包（该包包含wsdl接口文件），然后把该包加载到SPXX系统上，再添加一个实例对象（该对象包含网元IP/端口/服务名），SPXX系统会根据网元加载的接口包自动生成业务发放界面（wsdl接口文件里面本身包含命令和参数类型、参数范围等信息），该自动生成的界面只用于维护，BOSS需要拿接口包中的wsdl接口进行二次开发，这样就起到屏蔽BOSS直接对接十几个网元，只要对接一个SPXX系统，由SPXX系统来管理所有网元，避免接口混乱的局面；
c、该系统支持业务定制功能，内部有一个业务流解析引擎，支持封装多个网元命令，主要原理是通过XML编写一套业务流程文件和wsdl接口，然后将该业务流加载到SPXX系统中，再把该wsdl接口发布给BOSS系统，当BOSS系统下发该命令到SPXX系统，系统通过机制判断该消息是个业务流，再通过命名空间路径+命令找到该XML脚本，解析里面定义的原子命令，把原子命令分解发送到各个网元，再把各个网元的返回结果根据XML脚本定义规则组装返回给BOSS系统，这样就解决一个开户十几条命令对BOSS呈现只需要一条命令搞定。另外该业务流脚本支持定义变量、循环、条件分支判断、失败回滚等操作，说白了就是SPXX系统提供了一套自己的编程语言和语言解析器。
d、该系统还提供了批量发放功能，类似市面上那种充值卡、直接开好的手机卡都是通过批量开户完成的，支持步长累加批处理和多个命令放到文件内的批处理。
2）分布式进程主备是双活的，这里双活的概念是部署到两套单板，都是活动状态，一块单板挂了不会影响业务发放，如果进程挂掉JMX会对故障进程进行自动修复，多次修复不成功会就行倒换操作，支持升级、补丁。
3）其他进程功能和工具工作原理这里不细讲，后续博文再输出。
管理篇：
这里必须植入一个背景，早期我们团队由于管理计划不明确，人员技能过于单一，再加上系统过于复杂，由简单的WEB系统改造成多进程的分布式系统，涉及技术非常多技能要求也比较搞。导致版本转测试延迟和Bug改不对、修改不全的问题非常严重，经常被客户投诉。我进项目半年内，项目经理、区域经理迫于压力相继离职，每天加班加点老员工也陆续离开，项目已经濒临要黄掉的地步。历时半年勉强交付一个版本，客户要求我带一批人驻场交付。
合作模式：每个版本需求包分成两份，客户+合作方共同开发，合入同一个SVN库，双方投入比例3：7。
独立运作：我们开发模式是敏捷开发，一般2周左右一个迭代，整个开发阶段有4到5个迭代，一个版本大概有4.5万行代码量。
1、任务分配：客户PM跟我划分交付特性，然后我跟骨干员工一起把每个需求划分责任人，这里主要是每个人认领制，也会根据重要程度进行划分;
2、计划制定：我们内部制定了完备的开发流程，所有成员可以根据该流程特性属性2天左右就可以给出交付计划；
3、任务跟踪：采用早会站立会议，每个成员讲述自己的计划完成情况和下一步计划，反馈风险和求助。我主要解决风险和求助，纠正计划偏差；
4、流程保障：我们有专门的SVN目录用于归档开发和日常规范的流程规范文档，有迭代开发流程规范、特性串讲&答辩流程规范、检视格式规范、编码规范（这个包含客户要求的规范）、转测试CheckList规范等等。统一项目人员的操作规范和输出规范，保障交付结果。我也因为有这一系列流程保障，每天投入管理的工作时间可以缩短到2个小时左右，其余时间跟组内成员一起写代码，处处以身作则，迁移组内成员保障流程；
5、技能提升：项目各个模块采用代码责任田制，总共19个模块都有田主和副田主，每人至少有2块以上的田，我们定期进行代码互检挖掘历史版本问题、知识点文档写作，根据知识点文档每周两次下午茶培训，人员技能增长效果非常明显。多个模块都有专家，面对一线紧急问题定位，田主基本都轻松应对；
6、团队活动：我们采取两两一组，每个月组织一次活动，目前已经爬遍深圳各大名山、穿越、烧烤、骑车等等，至今三年以上的老员工占8成；
工作成果：
1、工作1年以上的员工都具备独立开发能力。我们的迭代开发流程：从特性熟悉、概要设计、串讲、模块设计、模块答辩、BBIT用例写作、编码、用例测试、VT、转测试都是有一个开发人员单独完成。涉及到安装、升级、前端等都由特性-交付责任人全流程完成开发，而且效率和质量都符合客户要求；
2、项目再次离岸交付。通过一年多驻场改造，我们的交付能力已经跟客户员工基本对等，实现再次离岸交付；
心得：一个团队制定合理的流程规则非常重要，通常一个管理者耗费太多时间和精力在人员管理和任务跟踪上，而团队成员则把时间浪费在琐事上。
1、我们项目管理者在项目前期制定好交付计划，跟客户约定任务下发和反馈机制，维护好跟客户的需求列表，不能让团队成员干了活没地方体现。
2、每天早会把握好计划是否正常进行，解决每个成员当前的困难和求助，让成员都能专心写代码，周边沟通和求助是每个程序员的通病，尤其是外包公司，不要让他们把时间浪费在这个上面。
3、尊重每个成员的想法，培养他们自己计划自己的工作任务能力，我们管理者只需要评估计划的合理性，是否在效率允许和可承受风险范围内，这样才能让团队成员迅速成长，一两年后你的团队不缺乏骨干成员。
【技术管理者个人总结】相关文章：
管理者工作总结05-24
技术人员个人总结05-01
电力技师个人技术总结04-03
护士技术考核个人总结05-19
个人专业技术总结05-17
公司基层管理者度总结04-30
信息技术教学个人总结05-29
技术个人工作总结05-29
技术员个人总结范文06-06
个人专业技术总结范文04-04