Dian团队
提升心中的热度
最近与刘老师聊天，在交流一些看法的时候谈到了“心中的热度”这个问题，觉得确实可以深思。
心中的热度代表着什么？我觉得这代表着对待一件事、一群人或一整个团队的态度和行动。热度高的表现是愿意思考看似与自己无关的问题，主动承担一些额外的责任；热度低的表现则是独善其身，特立独行，甚至桀骜不驯。心中的热度是与个人的能力完全无关的。
对于团队而言，心中的热度是衡量一位同学是否真的融入团队的重要标准。如果仅仅想在团队里找到最精最新的技术，那么心会是冷的，终究会被慢慢边缘化、甚至退出；如果要成为组长，就一定要有勇气跳出纯技术的圈子，对整个项目、所有组员负责，对项目中的方方面面热心快肠；如果要成为真正的核心，则一定要主动承担项目之外的工作，愿意为团队的奉献出自己宝贵的时间。心中的热度以及表现出来的态度和行动，决定了一个人在团队中发挥的作用，自然也决定了他/她在团队中的地位。
我们衡量一个人可以用“热度”这个标准，那么培养一个人是否也应该朝“给心升温”的方向发展呢？当然应该是这样。我们之前进行的团队文化培训、组织的各种文化活动、宣扬的各种理念，都是为了这个目的而开展；刘老师每次面对面的促膝长谈，都是希望用自己烈日般的热度促使心中加温；项目组中的摸爬滚打，也是为了在真刀真枪中凝练队伍，集聚热量。我们以前都是这么做的，但是缺少总结，没看到这一件件事情之间包含的共性问题。
好了，既然“心中的热度”那么重要，我是不是应该开发一套评价的手段呢？应该，但是我实在想不出！那么这个“热度”岂不是和简单的评价“好”与“坏”没什么区别了？不，区别还是很明显的。我们常说，道德第一、作风第二、技术第三，评价一个人应该按照这个顺序进行，换成通俗易懂的说法（但并不是非常精确），应该是甘愿付出第一、严于律己第二、技术领悟力第三，其中，“甘愿付出”与心中的热度有着密不可分的联系，而热度本身还有跟多更大的内涵。心中热度越高，也更愿意付出，也更愿意与对方融合，更可贵的是，这些都会出自于内心，绝非造作——就像男女的爱情。衡量热度也如衡量爱情，任何的细节都会暴露自己真正的心意，恐怕很少有人能够将自己始终伪装得很好，通过观察总能看到事实。这样的衡量方法避免我们用简单而孤立的几件事情来观察人，使得评价有了自己长期的逻辑。
心中的热度会变，而且既会升温，又会降温。我们应该努力让每个人都在升温，降温绝对不是好事情。
当心中的热度足够高时，他/她就具有成为核心队员的基本资格，但还不是充分条件。或者更加明确地说，核心队员必须是团队中热度最高的人，同时还应该具有某一方面的权威。如果核心队员因为种种事情降低了自己的热度，甚至有些变冷，那就失去成为核心队员的基本条件，也就失去成为核心的资格。核心队员绝对不是一个终身荣誉，而是对心中热度和团队责任的一种肯定。
我们应该尽可能的去提升心中的热度，这是融入团队的方法和手段。那么提升心中的热度究竟会对自己有什么好处呢？很显然，在团队中承担更多的职责就会带来更多的收获，千万不要把Dian团队看做成一个简单的技术团队，我们除了项目，还有非常多的锻炼组织、架构、协调、沟通等能力的机会，这些都是未来必备的软技能和硬通货。
最后，怎么做才能提升心中的热度呢？最近的团庆活动就是一个这样的机会，在其中服务的同学想必都还有所感触吧！看着满校都是橙色的队服，听着雄壮的团队之歌，品着全校对我们的盛赞，那种“将团队建设得更好的”愿望是否在心中浮现？如果是这样，恭喜你，你的心中正在慢慢升温。一种感激、一种依恋，真的就像爱情一般，我们会喜欢这种感觉，也会因此而赢得更多机会和挑战。
分享/收藏
Dian团队的软件之殇
谈到任何一件事情最忌讳的就是上纲上线、自以为是，所以我要避免犯这种错误。不过谈到Dian团队的软件人才储备，我觉得自己应该提出一点自己的担忧，为今后团队持续发展多留下一点自己的看法。
无论是从前还是现在，Dian团队都很重视寻找软件方面的人才，特别是我作为招新组负责人以来，更是对此非常重视。我们常说，硬件方面的人才培养周期很长，但是软件人才何尝不是呢。不管大家怎么看待软件的“低起点、低投入”的特性，也不管大家怎么评论软件开发更新换代的速度，真正厉害的软件人才还是不多，甚至于显得有些匮乏。
试问，软件人才究竟门槛在何处？我个人觉得在于“编程思想”。这是一种很“玄乎”的东西，不容易被初学者和妄自尊大者理解，于是形成了一个令人难以捉摸的门槛。很难说这个门槛有多高，恐怕需要看看编程所使用的工具和语言，如果使用一种很容易使用的程序语言进行开发，或许由于其自身框架的完好，程序员的负担很少，不用怎么思考就可以达到很好的效果；如果不幸遇到一种很高深的程序语言，同时也没有太多现有框架或接口，那么程序员将会十分辛苦，同时也需要拥有更多更好的编程思想，不过这种情况相对较少。由于软件发展速度迅猛，方便易用的软件框架层出不穷，因此，“软件门槛低”的说法就渐渐流传开，成为大家都知道的秘密。
相比软件，硬件开发往往缺乏很好的见解易用的应用框架，这使得门槛自然而然的提高，于是学习硬件的人似乎地位很高，感觉总比软件要“尊贵”一些，也好像自己所学的知识更加保值一些。没错，Data Sheet的确比软件的各种教材更加深奥，硬件的更新换代也比软件慢许多，还有就是硬件总那么实在，那些拿在手里的东西比摸不着的软件有分量多了。可是，Dian团队中绝大多数硬件开发者忘记了一个重要的东西，那就是编程思想。
有谁的电路是完全自己设计出来的呢？在芯片普及的年代，大家更多处于嵌入式软件开发这个层次，对于其中的原理知之甚少。电路参考开发板，程序参考各种入门书籍，之后，功能就可以随心所欲的实现了——我这样简单的描述当然有些不切实际，其中难度还是很大的，但Dian团队中不少嵌入式软件的开发者也只是处于这个层次。说白了，这些嵌入式软件开发者与我这样的PC软件开发者一样，都是做软件的，不同的只是他们用硬件的护甲遮住了缺少“编程思想”带来的空洞。
我见过“不会写C程序”的嵌入式开发者，其实他非常明白C语言怎么回事，在芯片上用的也都是C语言，但他就是不懂得怎么在PC上用C语言设计和实现一个简单的算法——他甚至对函数调用的概念都有些模糊了。我觉得这真是十分可怜！我也见过对嵌入式软件没有感觉的同学被安排去写上位机（PC）接口软件，组长大概觉得PC软件更加简单，也许组长也并不在意PC软件的开发质量——我们是做硬件的。这真的非常令人惋惜。
Dian团队立志于培养与社会无缝接轨的精英人才，我们的目标当然不仅仅是培养一个只懂皮毛的门外汉，而是真正触及开发真谛的“牛人”，所以软件编程思想的缺失已经不能够回避。不光是PC软件，嵌入式软件编程也要产生思想，这绝对不是言过其实。随着嵌入式芯片价格不断降低、性能不断增强，未来的嵌入式开发或许会更多的在嵌入式操作系统上开发，届时，嵌入式的门槛也将不断降低，新型的应用框架（例如Java和.Net在嵌入式上的广泛应用）将会让嵌入式开发与PC开发逐渐融合，老的开发者将面临从PC领域转轨而来的新的挑战者的强力竞争，能否幸存恐怕就在于“编程思想”了。就算是嵌入式开发能够保住自己的低端芯片开发领域，那么对于开发者自己能否从一个简单的实现者转变为一个应用级开发的高层人才，“编程思想”这个核心内容也不可忽视。
Dian团队的软件之殇就在于身为软件开发却没有注意培养灵魂，从而限制了自身发展，要想打破这样的症结方法肯定不唯一，我这里有一个建议：希望Dian团队的嵌入式软件开发程序员们多看看计算机上讲编程思想的好书，甚至于包括《设计模式》、“重构”、SOA、AOP等等高层软件应用的编程思想，都应该在有余力的时候涉猎一番，开拓眼界会大大有利于自己思考。
分享/收藏
Dian团队组长培训活动总结
2007年的1月13日到1月14日，Dian团队第一次举办了针对组长及未来组长人选的培训活动，主要目的是增强未来组长的团队文化素养、提升项目管理能力、重塑项目流程概念、暴露自身各种问题等。应该说，经过这两天的培训活动，未来组长们还是能够从中得到一些经验和教训，特别是总结会上各个组代表的发言，确实都有所得、有所悟。因此，我觉得从形式上来说，这次培训达到了它的效果。
在这里，我主要从组织者的角度出发，重新来审视这次培训的过程，以期望在未来举办类似活动时进一步提升效果。
一、培训内容组织上的经验教训
培训从内容上主要分为三个部分：团队文化培训、Tiny Project和组长必读的学习。其中，Tiny Project演练占据了绝大多数时间，从最开始的流程概述到需求分析，再接着走完一个典型的项目流程全过程，甚至于最终将生成可用的代码并要求现场演示。这个项目虽小，但是绝对是五脏六腑一应俱全。这样安排的主要理由是：希望首先通过文化培训增进未来组长们的团队认同感，然后用这个实际动手的Tiny Project来增进未来组长们的团结协作的精神，最后在实践上升为理论，解读组长必读中所谈到的各种组长必须了解的知识或具备的素质，加深印象。这样的循序渐进的搭配应该起到了应有的作用，起码在解读组长必读时我可以看出来，大家会结合培训中遇到的问题来分析自己的问题，与这个文档中的某些内容产生共鸣。
不过培训内容之间衔接的还是不够好，这一点今后应该尽力避免，这与我们准备太晚有关。在组长培训的前一天，我们还在修改文化培训的PPT，这使得文化培训的内容并没有经过很好的审核和演练。Tiny Project前面的流程讲解与后续的Tiny Project活动PPT是两个独立的文档，之前也并没有互相呼应，所以做Tiny Project的过程中也忘记去回顾流程中规定的输出和活动的内容，没有注意实时的从理论上进行提高。TIny Project中的各种文档本应该提供一个范本进行参考，并应该严格要求文档的规范性，可惜并没有这样做，使得输出的文档风格迥异，不能直接应用于实际。组长必读的解读过程完全是照着Word文档来浏览，并没有进一步提取必读中的必读，恐怕收效会比较有限，实在遗憾。
二、培训时间安排上的经验教训
培训原先的计划安排如下：
1月13日活动安排
09:00~09:20：组长培训欢迎词
09:20~10:10：Dian团队文化培训
10:30~11:30：Tiny Project：介绍典型项目流程
14:00~14:45：Tiny Project：需求分析
14:45~15:15：Tiny Project：系统测试用例
15:15~16:00：Tiny Project：输入评审会
16:00~17:30：Tiny Project：设计程序框架
19:00~22:00：Tiny Project：实现程序代码
1月14日活动安排
09:00~11:00：Tiny Project：输出评审会
11:00~11:30：Tiny Project：评审点评
14:00~15:00：组长必读
15:15~16:15：活动总结
16:30~17:30：自由讨论
实际过程则有些变化：
1月13日活动安排
09:00~09:20：组长培训欢迎词
09:20~10:20：Dian团队文化培训
10:30~11:30：Tiny Project：介绍典型项目流程
14:00~14:55：Tiny Project：需求分析
14:55~15:15：Tiny Project：系统测试用例
15:15~16:20：Tiny Project：输入评审会
16:20~17:30：Tiny Project：设计程序框架
19:00~22:30：Tiny Project：实现程序代码
1月14日活动安排
09:00~09:45：Tiny Project：实现程序代码
09:45~11:10：Tiny Project：输出评审会
11:10~11:30：Tiny Project：评审点评
14:00~15:00：组长必读
15:15~17:20：活动总结
在活动安排中变化较大的是“活动总结”这一项，由于总结的时间花的比较就，所以直接就把最后的“自由讨论”给取消了——本来这个自由讨论就比较虚，属于灵活使用的时间。另外，“实现程序代码”则比预计要花的时间多，所有组都没能在第一天的晚上完成编码。不过我并不认为这个程序会花如此多的工作量，毕竟第二天做的是“输出评审”，而非“结题评审”，所以对软件个方面的健壮性、功能的完备性等都没有太多要求，一些无关痛痒的需求就算还没有实现，只要解释得当就可以不做——所有组的同学都没有体会到如何权衡和估计实现各种功能需要占用的时间，也没有主动的去裁减一些优先级较低的需求。
所以总体来说，培训的各项时间估计还比较准确，只要继续更新Tiny Project中具体的Project题目，这样的培训还是可以不断重复举行的——不过参加过的同学再次参加似乎也没有什么意思，所以具体何时再做一次、选择哪些培训人员等，都是值得讨论的问题。
在这样一个过程中，比较令人头疼的是对各个Tiny Project培训时间点的把握。我在操作时时时刻刻都拿着手机，确保时间在可控范围内，但这样做也难免在有些环节上超时，于是我只能将某些内容略过或从某些讲解环节里面挤时间。这一方面需要培训的主持人对Tiny Project十分熟悉，甚至于可以对其进行临场发挥，另一方面需要主持人具有一定魄力，及时终止一些耗时过长的活动，希望未来的主持人能真正在这两方面都做好。
三、典型项目流程简介的经验和教训
这个环节应该是本次培训的特色环节，应该说是其中最能称得上精华的几个点之一。xbull给大家准备的流程简介是他在年终总结中仔细思考得到的宝贵经验，要知道，他是Dian团队里参加项目类型最多的同学，软硬通吃，经历过各种磨难和考验，随着团队分工愈发明确，他这样的人才恐怕是再也难见。
不过遗憾就在于，讲解的过程并没有穿插互动，所以同学们最后印象并不深刻——从最后的回顾活动可以看出，新讲的东西并没有被大家接受的很好。而且，一开始就讲解ISO 9000与CMM4之间的差异似乎不妥，毕竟在听的队员大部分既不知道ISO 9000也不知道CMM4，更不谈如何去对比它们了，这样子的安排或许有点过于拔高。
四、Tiny Project活动过程的经验和教训
Tiny Project培训在整个培训过程中属于最难以操作的部分，不过由于在预备队已经成功举行过三次类似活动，而且对我个人来说，更有上十次类似培训的经历，所以我反而不会觉得很麻烦。整体来说，这个培训从时间把握和内容调配上来看还算正常，并没有出很大的问题。
不过其中最大的问题是：没有和其他的培训内容有机的结合起来。前面说过，没有有机结合的一个重要原因是准备过于仓促，没有预先演练，甚至于有些PPT在培训前一天晚上还在改，很有问题。另外还有一个原因，主要因为我自己过于习惯于已经约定俗成的思路，不想改变，所以这个Tiny Project只是预备队培训的延长版或者完整版而已，并没有很好的切合组长培训这个特殊的目的。具体来说，我本应该在每个阶段流程开始之前回顾这个阶段需要输出的内容和需要进行的活动，不过我没有做；我本应该提示未来的组长们在活动中需要注意的问题，例如组长常会犯的错误、组长的责任等，不过因为我并没有在这方面与其他参加组织培训的同学讨论，所以也没有做；还有，“项目计划”和“进度管理”这两方面的讲解和演练缺失，实在非常遗憾。此外，Tiny Project中固有的一些问题我还是没有真正的解决好，比方说各个环节的评分标准等，这一次依然还是在看感觉酌情给分，尽量平衡每个组的得分，不太好让后来者继承。
对于Tiny Project的模拟项目选题我也有一些担忧。这次做的“D语言代码信息统计工具”实际上与H3 Mini Project中那个“C语言代码信息统计工具”很类似，当然，我设计的需求更为复杂，要求完成的时间却更短。这个题目如何设计才算是好呢？恐怕很难有一个定论。从2005年开始，我培训的题目先是一个“C语言代码分析器”，可以分析C语言的词法、语法等，非常复杂，到后来的统计C语言注释率信息的小工具，非常简单，再到增强版的C语言注释率，有些复杂，最后是这个D语言代码信息统计工具，难度进一步增加。这样的变化，虽说难度有升有降，但选题其实都是一样，并没有太多创新，所以经历过其中任何一次培训的同学，到后来如果再次参加就会有似曾相识的感觉，甚至能提前猜到我的底牌，这样当然就不好了。我们需要不断地在题目上进行一定的创新，通过把选题这个“汤”换掉，来吸引同学不断来吃我们的“药”，达到持续培训的目的，这就最好了。
因此，今后一个很重要的目标就是：多准备几套培训方案，希望能够在达到同样效果的前提下创造出更多更吸引人的形式来。
五、组长必读讲解的经验和教训
组长必读主要是xbull在Dian团队这三年多来的智慧结晶，特别是一些实用的管理经验和案例，令人深省。原先我的想法是从中再提取出“组长必读”的“必读”，用最精要的语言点破其中的精华内容，将好几十页的文档先压缩成几十句话，再通过展开解读来加深理解。不过因为xbull太忙了，所以这个环节并没有采用这种形式，而是直接对着Word文档来解读。
解读的过程中，通过结合讲解Word文档里面附带的例子，应该已经达到基本目的。不过也通过这次解读，发现文档中存在的问题，需要今后继续修订。希望各位未来的组长都去FTP上下载这个文档，然后自行修改，寄给刘老师、xbull或我。
六、其他的经验和教训
在所有活动中，我发现最后两个小时的总结非常有用。总结的最开始是我来组织大家回顾这一天多以来讲解过的所有重点内容，通过回顾，做到前后呼应，加深印象。之后，是各个组的组长和各个组分别选出来的一位组员进行活动总结发言。这个总结发言不同于一般，因为我所要求的是结合组长培训的内容，站在组长的角度来总结这一天多以来的所有经验教训，当然以教训为主。在这里，所有上台来的同学，包括组员，也要站在组长的角度来思考和总结问题，特别是上台的组员，必须指出组长存在的问题，以及如果是自己来做组长会如何改进。通过听大家的总结，我甚至能发现自己的不足，我觉得，大家其实都是从项目中成长起来的，其经历和不足都会有些类似，但如果有机会这样开诚布公的自我批评，真的可以警醒很多人，使得大家不会犯同样的错误。
所以，我发现这个总结活动成了所有活动里面最为精彩的部分，也是最为精化的部分，我也毫不犹豫的砍掉了最后的自由讨论，让同学们有更多时间来自由发挥。
在活动的后勤准备上则有很大的教训。首先是电脑软件的安装和配置上，虽然我们事先调查过所有电脑安装软件的情况，但是的确忘记实际使用一下，保证一切正常。这个巨大的疏忽使培训中发生了好几起软件不能正常使用、甚至于不能联网的重大问题，也直接导致xp.ED小组只能靠U盘来互相拷贝代码和文档，严重影响了他们的发挥。以后做类似的活动，一定需要充分验证每一台电脑的可用性，千万不能再草率行事。
七、总结
组长培训活动整体来说是顺利的，我非常地欣慰，但我更希望这个活动会有第二次，并且能够不断延续下去。
我或许应该花更多时间来写下自己的想法、经验和教训，让这些宝贵的财富随着Dian团队发展而不断变得丰富多彩。
分享/收藏
组长培训和生日Party倒计时——我的倒计时
明天，就是1月13日啦，Dian团队的组长培训和生日Party都将在那一天开始。这两个活动都是非常具有开创意义的，前者是Dian团队管理&技术的升华，后者是团队文化的进一步人性化，这一切的变化都会让团队黏性更强、更能够吸引和培养学校的精英人才。
不过，这个倒计时同时也是为我自己而设。
我想，这应该会是我为Dian团队引进的最后两项活动了，下学期起，培训部的重担就要交给gump来承担了，他会来做主要负责人，我只负责出谋划策就成——嗯，Dian团队的这种工作流程需要可靠的传承下去，我不应该继续引入任何不确定的东西了。可不要让我失望啊，gump！
虽然担心gump会忙不过来，但我从来不担心Dian团队的未来，这个团队的发展早就不会因一两个人的离开而改变。
有同学会悲观的说，我们这一级毕业了以后，Dian团队就会从此缺少重量级人物，会因此而倒退——这个观点是可笑的。的确，我们这一级，包括即将毕业的上一级学长们，至今为止都给人一种无法超越的感觉，但Dian团队的确不是因为我们存在而壮大、成长，却是因为我们的力量已经完全注入团队、和团队方方面面融为一体之后才强大。无论是团队三大部门的分工还是未来的技术方向，这些东西都绝对不是我们的私有财产，不会轻易流失。
如果要说倒退，那恐怕只可能发生在技术上。我个人觉得，这种境况无法避免，也无须担心。
总有一些强的一塌糊涂的人加入团队，他们也总有一天会毕业、会离开，于是，某方面的技术或许就因此而倒退了。团队初期人才非常匮乏的时候，曾有一次所有C++的牛人都同时毕业或暂时退出，造成一时间的真空，我们还不是依然可以维持这个方向的继续运转——其诀窍便是在前人的思想下继承发展。C++在语法上并不会如何的难，工程应用中也不会用到很生僻的东西，所以难的是设计，当设计拿不定把握时，参照并继承已有的设计是最好的选择。现在，团队更加注重“传承”，再也不会出现某一方面断档的情况，那么，少几个牛人又如何？
新的核心队员已经在慢慢成长，半年以后，他们会变成Dian团队新的栋梁。我们，作为即将离开的人，就算再遗憾、再留恋，也必须懂得放手，让自己慢慢淡出，慢慢让贤。我很希望看到新的栋梁能够真的撑起整片天空，这样我也能放心的挥别这个积聚会议的地方。
倒计时，一刻都没有停止，就算再舍不得，沙漏也有流尽细沙的时刻。我静静等待着一刻。
分享/收藏
Dian团队组长培训活动预告
Dian团队的同学如何发展？
我们一直以来都说：除了培养技术力，我们还培养高尚的道德情操和扎实的工作作风，而且这两点是放在技术之前的。那么，这样两点如何体现呢，没有高尚的道德情操和扎实的工作作风，对团队同学有什么影响呢？
如果这两者缺少其一，那么这位同学恐怕就很难在团队中转正了，也就是不能获得永久编号；而这两者做的只是差强人意，比较平庸，那么这位同学恐怕就很难成为一名组长了。组长，在Dian团队中处于中流砥柱的作用，他们撑起了团队的未来，是团队真正的支柱。我觉得，每一位Dian团队的同学都应该将自己的目标定位成为组长，成长为这样的栋梁之材。
可惜长久以来，组长的培养缺乏足够的规律，我们常说“战火当中成长”，也就是通过“干中学”来摸索着掌握组长之“道”，这是非常不好的。这样成长起来的组长或许更具有活力，但是缺乏一定的指引，可能造成某些看法的偏颇，所以，我们继续创造这种孵化组长的战场的同时，还需要这样一个大家认可的正规培训来解决所有未来组长遇到的问题。
因此，就有了这个即将举行的组长培训。
这个培训将在1月13日和14日举行，将会利用两个整天的时间做培训，主要涉及团队文化、项目流程介绍、Tiny Project实战演练、组长的必知必会等内容，希望能够全方位的提升组长的文化素养、流程概念、设计及管理能力、管理理念等实用的内容。
现在Dian团队有充足的教室资源供使用，这真的是太爽了，要是一年前，这种事情想都不能想呢！所以，团队的持续发展将会进一步推动各种正规化过程，于是产生一种非常好的良性循环。这应该就是我和其他所有核心层都乐意看到的事情了。
分享/收藏
Dian团队要给大家办生日Party啦！
原本只是想Dian团队同学过生日那天发短信祝贺、送神秘小礼物的，不过不知是谁提议（是leavy还是刘老师？），我们就决定把这些简单的祝福和礼品变成一个月一次的生日Party。我们的目标是：让大家在那一天玩得开心，并在娱乐中认识更多朋友，促进团队内的交流。
马上，就在这个星期六的晚上8点起，我们将举行第一次团队生日Party，届时，除了常规的生日蛋糕以外，还有不少好玩的游戏、神秘大奖等着大家来参与！嗯，天机先不泄漏，把计划都说出来就不好玩了。
第一次组织这样的活动，还是不太确信是否会达到我们的目标，希望大家都来积极配合吧。我们将要邀请Dian团队中所有一月份过生日的同学参加活动，到那时，大家忘掉各自的身份，全身心的投入这场娱乐盛会中去吧！祝即将或刚刚已经过了生日的同学生日快乐，玩得开心！
最后，我来一个简单的Q&A，回答常见的问题（大家可以继续提问，我不断更新）：
Q：生日Party一般什么时候举行？
A：暂定为每月的第二个星期六的晚上8点举行，如果有节假日或考试冲突，我们会根据具体情况择日举行。具体时间我们会至少提前两天通知。
Q：生日Party一般会多久？
A：我们打算控制在2小时以内，原则是先让大家累到觉得饿，在开始分蛋糕，哈哈。
Q：我需要为生日Party准备什么？
A：什么都不需要，只需要准备时间！这是一个放松自己和认识新朋友的好时机，千万不要错过！
Q：如果万一那天我有急事错过了Party怎么办……？
A：如果错过的同学比较多，我们可以考虑再安排个时间，一月做两次。当然，最常见的应该还是顺延，反正好事肯定不会拉下你啦！
Q：我……不太喜欢热闹的场合……怎么办？
A：希望要尽力改变自己哦！未来的世界是不允许封闭的人存在的，这就是挑战自我的好机会啦。
分享/收藏
第一次接受参访，贴一下稿件beta版
第一次接受这样的正规的采访呢，还是蛮有意思的。 记者Chen Li很不错，下面是她写的稿，我改了下~
引用内容
要关心自己做了什么，而不是兴趣是什么
——访成功签约微软的05级毕业生杜欢
“面试官最关心的是你自己做了什么，而不是你的兴趣是什么。”杜欢，在经历微软公司一次笔试、七次面试的“轰炸”之后，深有感触地说。 杜欢，华中科技大学电子与信息工程系通信与信息系统专业05级硕士研究生，电子与信息工程系电子信息专业2000级本科生，现已成功签约微软亚洲工程院。从2004年起，杜欢组织过7次校内大型活动，参与完成7个工程项目，并有两次在华为3Com技术有限公司实习的经历。
微软，一直向往的地方 微软，一直是杜欢非常向往的地方，本科时他就想进去，但真正到了大四却发现自己根本就没有足够的能力，于是选择考研。尽管他并没有将微软作为自己的奋斗目标，但还是希望通过不断积累，争取在研究生毕业时进入软件方面的知名企业。经过研究生阶段的炼造，他开始朝自己最初的愿望逐步迈进。 签约微软的过程是漫长的。杜欢先通过微软公司在武汉的一次笔试、一次面试，然后奔赴北京，在微软中国总部经历了一天六小时六轮的高强度面试——上午三轮、下午两轮 ，中午午餐时间，还以边吃边聊的方式被面试官“审判”了一番。一路过关斩将，杜欢终于成功签约微软亚洲工程院并获得项目经理职位（Program Manager）。 回忆签约之路，他感触颇深。他觉得，公司更看重一个应聘者动手做过什么、经历过什么，而对感兴趣但缺乏真实经验的东西倒并不是很在意，甚至“视而不见”。这就要求应聘者必须更重视实践，用实实在在的成果说话。 [...]
种子杯程序PK大赛决赛回顾
种子杯程序PK大赛的决赛好几天前（12月10日）就结束了，不过一直没有写一点小结性质的文章，遗憾。现在来补上。
决赛的程序题目是实现“贪食蛇”游戏的AI。这个游戏想必大多数人已经耳熟能详，这次我们给各个队提供的程序框架已经实现除了AI以外大部分的事情，这样各个队就可以集中思考如何模拟人的智能来一步一步的控制这条蛇前进。此外，为了增加程序的难度，我们还特别引入了一个“钥匙”和“门”的互动元素。也就是说，地图上散布着零个到多个钥匙，如果有钥匙并且吃到，那么所有的门就会消失，多余的钥匙也会消失。这样，如果苹果不幸被门封锁起来，那么贪食蛇就必须去吃最近的钥匙；如果打开门会让路径大大缩短，那么吃钥匙也是一个明智之举。
可以看到，每个队的同学都非常的努力，下午的四个小时很快过去，同学们大多有不错的成果，每个队都有自己的想法和策略，同学们真的很不错。这里特别赞一下学生会那位mm，下午硬是没闲着，为了能够保证晚上的人气到处打电话找人，真是非常辛苦！
晚上的公开报告分为三部分，首先是各个队的同学进行答辩，每队15分钟，其中自己陈述10分钟，评委提问5分钟；接着是评委退场评分，换上Dian团队的xbull和fw跟05级的同学进行经验交流；最后是点评和颁奖。
答辩的亮点并不多，没有任何组能实现可用的最佳路径搜索算法，虽然大家都口头说想到了。同时我还注意到，有的组（应该是xxbull组）还写了“需求分析”之类的Word文档，实在是没有领会我们对文档的真正要求，嗯，也许我们确实在最开始也没有充分说明吧……
第二个环节由于评分去了，我没有听全，比较可惜。fw的PPT不知道做成什么样了，或许应该很精彩吧，不过貌似xbull的那部分反应更为强烈一些啊，这个我倒没错过。xbull的演讲技巧的确值得赞赏，在活泼的气氛当中蕴含了很多的道理。生活是丰富多彩的，成功也是没有唯一定义的，每个人可以选择自己成功的道路，不过有一点，时光不应该被虚度，只要有目标并且坚持做下去，挖掘自己的潜能，这样便可获得成功。嗯，我就不自己随意揣测xbull的意思了，还是看看他的官方解释吧：http://www.blogcn.com/u/91/82/cawk/blog/48390737.html
不过我突然想到，如果这个演讲让我来讲会怎么样呢？我的本质是孤傲的，或许不会给大家一些合理的建议吧……起码我不会认为成功是没有定义的，我会觉得只有把自己参与的事情都做好才是真正的成功，甚至于有一种“修行”的意思在里面：眼前的事情都是一些磨难，用最完美的方式战胜它们才能算数。所以我会在所有事情上较劲，也会做出一些让其他人不太理解的举动，要么不做，要么就做到最好。算了，这或许不适合大多数同学吧。但是或许有一点还是值得说的：不要给自己定太遥远的目标，踏踏实实走好就行。我追求完美，所以可能没有时间抬头看路，可我不觉得不好。毕竟，我发现自己因为踏实而获得了更多的锻炼，我只愿意钻研一个自己有把握做好的方向，不贪也不泛，这或许很好。
接下来就是最后一项，颁奖。不过比较让我欣慰的是，joe主动要求讲算法，而且他在台上面对上百名观众表达自如，感觉非常老练的样子，实在是很不错！其实这个种子杯一方面是发掘05级的好苗子，另一方面也是想锻炼一下joe，相信通过这次疯狂的编程，他也一定对设计一个可用的应用程序有了很多自己的想法吧，起码会比半年前那个为了好用把类成员全部写成public的joe要强很多吧，嘿嘿。
第一名是Kerberos。他们能夺冠本来应该是比较理所当然的，不过因为我们在计分时出了点问题，差一点就把雨点评成第一了呢！这个bug还要归功于joe，如果不是他首先质疑计分的正确性，恐怕就没有这么快定位问题了吧！
所以，种子杯有惊无险的结束了，预期达到的效果应该一样没少，而且应该好于上届，这我就比较满足了。至于教训，当然有，我暂时不总结了，还是睡先……
分享/收藏
Dian团队招新模式解密（六）——条条大路通Dian团队
前面说到的都是普通的招新流程，所谓普通，是因为面向全校每一个同学，我们会无差别的对待。但是这并不意味着Dian团队只有这一种入口，其实还有很多的方式能够更快速的进入我们的视线。不过首先说明，无论是如何进入Dian团队，在进来之前都需要填写报名表（在http://2006hr.dian.org.cn下载），发到diangroup@gmail.com中，这是必要步骤。
下面就说说有哪些其他的方式。
参加电信系的程序PK大赛。这个大赛由Dian团队出资举办，目的是激发大二的学生编程热情，从中发掘出令人瞩目的新星。对于其中进入最终决赛的同学我们会免试（准确说是免技术面试）进入团队，这可以说是一条捷径。不过程序PK大赛并不会做成Dian团队的选秀会，因为毕竟是由学生会操办，其中有一半的评委并非Dian团队成员，我们不能也不想搞得变味。嗯，顺便说说，Dian团队这边的负责人又是我，所以我这样说还是能够代表官方意见的。
内部推荐。我们鼓励内部推荐，毕竟有一个证明人会让我们觉得放心很多，也能够弥补短暂的面试造成的偏差。
在创新基地获奖。不要怀疑，在创新基地获奖也能进入Dian团队！而且如果确实是十分优秀的同学，我们甚至会找上门。Dian团队中曾有多名队员都是全国电赛拿到一等奖的同学，甚至于我们的quickmouse老师还曾是电赛的指导老师，自己拿过一等奖，也指导过其他人拿到一等奖。我们对拿过奖的同学还是很有好感的。所以说，如果在报名表中写入曾获得的奖项，我们会非常的重视，当然也就容易脱颖而出。
主要就是这样了。
分享/收藏
Dian团队招新模式解密（五）——什么是技术面试
通过了素质面试，后面跟着的是技术面试，一般而言，这是最后一道关卡。
就正常的招聘流程来说，技术面试应该是刷人最多的地方，但我们的技术面试似乎不是。对于能够通过素质面试的同学，在我们看来其实是已经具有进入Dian团队的基本能力的，也就是说，只要有合适的岗位则应该可以被招进来了。在技术面试被刷一般是因为报的岗位过于热门，竞争者太多，而自己又不愿意主动调节，或者是自己放弃的。
在这个环节，我们希望互相之间有一个双向的了解。人员需求来自真正的项目，相应的技术要求也是项目中的实际问题，每一个都是很好的学习和探索过程，所以技术是否“精通”我们并不在乎，关键是解决问题的能力。同时，我们也会关心大家的投入时间，毕竟我们是学生，还有课程需要完成，不能每天只想着做项目，但也不能因为担心成绩而突然失踪好长一段时间，我们希望大家能自己协调好项目和学习之间的关系，稳定而有效的投入。
如果在这个环节中觉得自己报的项目并非想象中那么好玩，我们也不反对大家了解其他相关项目的情况。我们这里就有原来报C++相关项目的同学转到嵌入式软件开发的例子，结果是非常的成功，他因此而发挥出自己的实力，同时还是其他一些例子，都证明所谓的“调剂”并不是一件坏事，而是充分了解自己的结果。所以说，盯着一个目标不放是一种精神，但是也不一定要绝对如此。
通过技术面试的同学一般来说就会进入Dian团队并有了所在小组，随后就可以参加Dian团队的活动。这就是Dian团队的一般招新流程的全部了。同时，我们还有其他的招新方式也很希望大家能够参加，只是这些招新方式往往面对的人群较小，并不是每个同学都有机会。
更多的招新信息可以在这里留言问我，也可以写信到diangroup@gmail.com，Dian团队从来不愿放弃任何一个适合加入的同学。
分享/收藏
