又到一年写总结的时候后。工作这些年，年年雷打不动一篇总结让初初参加工作的这一天刻在我的脑海中。到现在我已经记不得恋爱纪念日了，却依然知道在冬天到来的第一天敲下过去一年工作的点点滴滴。
?
似乎在每个总结开篇都会说，我不是个努力上进的人，太多的随遇而安让我的工作起伏并不大。我妈总是在电话里唠叨让我去大城市，进大公司，对此我只能沉默。这篇总结对于那些初出茅庐打算成就一番事业的同学们是个反面教材。另外现在的心境也是工作多年后才有的，并不合适刚参加工作的同学们，你们看我前几年的总结比较有共鸣。
?
今年在工作上有些人事变动，我的工作也有点点转型。这篇总结分为个人工作，团队管理两方面。
?
1。个人工作
去年年末，我被分配了一个很棘手的项目。这个模块要说不工作吧它基本符合设计要求，要说工作吧用的不怎么顺手。我的任务就是把它”调”成用的顺手的功能模块。这个”调”听起来很简单，但是一看模块内部的构造，各个函数间的关系我就傻了，这一”调”可是伤筋动骨阿。很倒霉的是，这种任务如果做好了功劳不是很大，因为不懂技术的人都觉得是小调整；要是做不好麻烦就大了，本来模块可以完成功能的。这一改要是引入新的bug不就是做无用功了么。
对于这种任务除了自认倒霉之外，只能加倍小心了。老话说”不破不立”，我改原有代码改的恶心了一狠心推倒重来。好在年底时间上没有那么紧，完工的质量也还好。
?
真正进入2010后我的个人工作比较零碎，大部分是基础的搭建。比如一些设计数据库，写公共函数，还有就是在原有设计上面的优化。要说这些东西多考验一个人的技术我个人认为还真没有，但是非常考验技术人员对于业务流程的熟悉度和对于需求的前瞻能力，这些都是经年累月的经验积累分不开的。
?
另外今年占我个人工作比重非常大的一部分就是写文档。我的文档本来还可以给自己看或者同组人员还都算是清晰明了的。但是今年的很多文档是面对售前和售后的，对于语言结构的要求都高了很多。我需要写的文档包括阅读售前的商业需求，翻译拓展为技术需求；在功能实现后写描述总结类的文档给售后和售前。本来这个任务不落在我身上的，但是很不幸我遇到了个对产品不熟悉且不给力的经理。于是我光荣的承接了”笔头子”工程，在不断的锻炼以及被别人咬文嚼字的挑剔后提高了不少。目前虽然还会信心不足，但没有刚开始那样惨了。
?
面对win7 64bit的快速普及以及我们用到的一些软件的更新换代，我明年的主要任务就是为我们产品全面更新到.net搭一个比较坚持的基础。然后带领团队对产品进行全面重组升级。也许就是所谓的架构吧。OO思想我是有的，但是架构没有什么理论基础。欢迎各位看官介绍架构类的书籍和工具
?
2.团队管理
年初的时候人事变动，我的职责范围除了开发之外还兼代一个三人小团队。
我这个三个伙伴都是男人，比我大(最大的已经40好几了),比我有经验。面对这三个个性人材，如何确立威信是个难题。最简单的方式是经理帮我立威信，但是我经理这人初为领导恨不得把我们几个组长的管理权都收归己有根本指不上。
在那几个月我就觉得自己腹背受敌。组员领了任务就没了下文，我不说话他们比我还沉默。没辙，我只能更积极的跟他们更新情况，经常询问进度，询问是否需要帮忙，提醒一下他们可能想不到的关联问题等等。我们每两周开个进度会议，讨论一下”过去时”，”现在时”，”将来时”。听组员发发牢骚，抱怨一下上面管理松散的问题。除此之外还可以把开发上的困难来小组讨论一下，在技术上面他们三个经验丰富经常能给我带来灵感，受益匪浅。在流程上，他们各有各的习惯但是既然是一个整体就要步调一致，团队的操作流程在慢慢改进中更符合整体的开发习惯。
大概经历了3个月吧，在组员面前我算是站住脚了。我们之间的交流，和开发节奏配合的不错了。我分配的任务，做出的决定可以被理解和接受，出现的问题也可以及时讨论。
总结一下做小组长这类费力不讨好的工作大概就要秉着”为人民服务”的宗旨，组员需要的信息我及时提供，遇到的困难及时支援，不理解的事情耐心开解。让他们觉得可以从我这里得到理解和支持然后专心致志地投入到代码的汪洋大海中去。我觉得我是幸运的因为我所付出的这些，他们也在回报给我。比如我们提的建议需要写报告去汇报，我写好后组员都会认真阅读并补充自己的意见，让报告更容易被通过等等。现在我们是一个合作愉快，高效运转的开发小组。
?
对我来说有个不给力的经理最大的困扰就是信息流到他那里就断了，需要传递给其他部门的信息传不出去；需要的需求和反馈到不了我们这里。为此在年初的几个月我经常和另一个组长互相发牢骚(我们经理手下就三个组长). 那段时间我觉得我就是个被负面情绪吹起来的气球，直到有一天气球爆炸了。我看到天高云扩，老天给我这么好的锻炼机会就被这些负面情绪搅得看不清未来。我咬牙跺脚调整工作态度。
既然经理不给力，咱自己发力吧。于是我开始直接给售前写邮件，当然这些都邮件都要抄送经理一份，不然在他心里该留下阴影了。和售前接上头才发现他们那边也着急，因为客户也不知道自己要什么，贪心的客户恨不得我们的系统一上马他们那马上就裁员一半。这，怎么可能呢。售前那里传来的需求就好像高考的考纲一样简练，我就是日读千遍也读不出个鸟来。只能按照自己的理解结合对产品和客户的熟悉程度一点点把大的需求切割划分成小的可操作的需求，然后做成样品，写好报告反馈给售前。那段时间每周四不管自己陷在代码里面多深都得把自己拔出来阅读”考纲”，主谓宾，定状补的分析客户隐藏在短短词句背后的意图。每周五都是一周 “成果展示”，把进度预测等等写好发到售前。很长一段时间我的工作是正常工作时间内写代码配合其他组员完成任务，加班时间写文档。有的时候邮件发到售前那边石沉大海，那只能再下一周发邮件的时候提一下，要是还没回音就打电话过去，跟个催命大妈一样。要说一下我们售前是两个大哥也是刚加入对于产品了解不足，有的时候我写了一堆报告配上屏幕截图他们都不一定能彻底明白，只能通过电话，远程等等手段。这种情况在我们不断的改进交流方式下慢慢变得好起来了。幸运的是我对于”考纲”的理解和判断在大多数情况下还算准确，没有返工的情况发生。
?
通过种种我觉得作技术的和非技术人员说的不是一套语言，我们拿一个需求看到的就是类，模块，函数等等扒皮剔骨的分析，他们看到的更是业务流程，增值效益等等有血有肉的活动体。后来我就去学习了一下工程管理，脱离技术层面的笼统的工程管理，比如工程周期，工程进度，资源分配等等。这些虽然和我的日常工作联系不大，但是跟非技术人员打交道上面帮助还是非常大的。因为我能够更加理解在一个软件产品或者解决方案中他们关注的信息是什么，我们作为技术人员用什么方式传达这些信息才更有效。
这样说太笼统了，举个例子比如某个功能的改进，在这个改进未实施的时候作为技术部门我们一般都会说技术上可以实现，希望了解到这个改进具体在哪些方面帮助到客户那些哪些操作流程。然后阐述一下这个改进在可执行上面大概的预算(人力+时间)，预计什么困难。最终以什么形式呈现在客户面前，同样的改进是否在其他相关功能上实现，如果出现困难我们需要什么样的后备方案等等。这些还可以进入到很多深入讨论。
?
今年可算是我工作以来最纠结的年头了，在寻找有效沟通方式上我不断尝试新的方法，有意识的根据不同的人说不同的话。再不是当初刚参加工作那个随性而为的小丫头了。参加很多的会议，跟不同的人打交道让我看到了职场上那些微妙的关系。见识了部门间表面合作实则互相推诿，见识了跟上面大包大揽反过头压榨自己员工的领导，见识了见好处就上见困难就躲的虚伪。我也更加小心翼翼的保护好自己(估计还是没保护好我还是太直率)和我的小组。这一年我也妥协了很多，有的时候虽然不是自己的责任但是如果自己多做一点可以给整个团队带来更多的利益我也会牺牲自己的时间去做。不会为一些事情争论而是相对平心静气的寻找一种平衡利益的解决方法。也许这就叫做成熟吧。
?
虽然这些种种写下来就让观者觉得好多无奈，但置身其中调整好心态，把每一个无奈都当作一个考验；把别人的不作为当作锻炼自己的机会；把和每一个人沟通当作一种积极的尝试。工作还是挺美好的，更何况我有那么有趣的同事一起战斗。
?
工作之外，我今年的生活算是最平淡得了吧。单位和家两点一线，还没去过太远的地方。没买过什么大件商品
今年冬天去趟西藏，圆我一个小小的愿望(12月23—30在西藏，求被拣，站短联系)
?
最后还是那句话
低头做事，抬头做人
过幸福的小日子?????????? :)?
本文来自张雅琪博客：http://blog.csdn.net/clear_zero/archive/2010/11/07/5992747.aspx
相关文章![[转]分享一个thinkphp提示页面代码](/Upload/SmallIMG/2012070921/F72EEFA831388BCD.jpg)
