我首先觉得这是一个伪命题，不太可能有种方法能衡量决策的价值。决策有时效性，过了这个时间，决策的价值就发生变化，无法衡量。此外，决策也没有绝对的好或不好，往往都是各方权衡的结果。相对来说，决策的过程比较容易衡量，如果每次能按照最合理的过程来进行决策，决策本身就应该具有最大的价值。就能从侧面衡量决策本身的价值。

我认为合理的决策过程是：找到所有决策相关的人，推动大家在合适的时间达成一致。Find out stake-holders, and push them to reach a consensus at right time.

这句话非常的tricky，里面暗含很多意思。比如谁去负责push、stake-holders如何定义、right time究竟是什么时候等。

如果我是决策的最终负责人，那么负责push的人就应该是我，这个最容易回答。

要界定stake-holders就要看这个决策一旦制定该如何实施，所有在实施过程中会涉及到的关键人物都应该算作stake-holders，决策的过程应该是所有stake-holders buy in整个决策的过程。比如要决定一个feature是否应该做，首先可以假设要做，然后就可以知道需要有PM来决定feature细节、要dev决定如何实现、要team lead决定如何将这个插入项目计划之中，等等，这样就要引入相关的负责人来进行评估。此外，这个例子里面暗含一个角色，这个feature的提出者，他/她有可能是一个dev、客服甚至公司外的用户，他/她应该也以某种形式参与进来，直接参与或者由某个人（PM）代理。集齐所有stake-holders，每个人buy in这个决策的后果（该干活的干活、该承担风险的承担风险等），就可以让这个决策通过，否则，修改决策本身，继续讨论。

要确定right time非常困难，但可以有几个简单的衡量标准，比如要做出决策的各方面条件是否满足、决策本身是否依赖于某些时间相关的因素等，总的来说是一个仁者见仁的过程，需要决策的最终负责人来给出right time的预期。需要注意避免把right time看做是deadline，任何schedule都会遇到意外，而right time则不能出意外，deadline一定要早于right time，这样才能使得这个觉得真的right。此外，right time也不是ASAP（as soon as possible），过于草率的决策往往结果不会太好。

“如何做决策”是一个需要长期积累的技术活，我现在经验尚少，只有这些肤浅的认识，欢迎所有读者过来批评指导。 :)

关于Scrum运行当中常见问题及解决方法，我曾写过一个slides，在公司内部分享，现在重新整理了以后共享在这里：近距离接触Scrum

关于Scrum，最常见的误解是Scrum master == team lead，这是不对的。Scrum master可以是任何人，不需要担当任何管理职责，在Scrum中只是一个推动者。

除了Scrum过程本身，还需要整个team共同遵守一些游戏规则。这些规则可以根据实际情况来制定，不过尽量不要超过3项，毕竟人能同时记住的事情一 般不超过4项，还得留1项给当前的工作。

例如，可以制定以下规则：

1. No suprise：大家都有义务保持信息通畅，及时有效的将stakeholders关心的消息传递给他们，尽量不要让任何人对结果产生suprise。对于不紧急的沟通，可以选择在daily scrum的时候将信息传递出来，尽量不打断其他人的日常工作。
2. Focus on one thing：很少有人能够快速的在多个任务之间切换还不影响效率，集中精力干好一件事情是提高效率的最简单的做法。要做到这一点，必须懂得如何对手头工作进行排序，最简单的就是focus on high priority work，这也就是Scrum过程中安排work item并对它们排序的意义。

无论如何，Scrum过程只是一个工具，而非目的，任何事情还是以delivery为重，流程本身执行是否合乎规范完全是次要的。

心中的热度代表着什么？我觉得这代表着对待一件事、一群人或一整个团队的态度和行动。热度高的表现是愿意思考看似与自己无关的问题，主动承担一些额外的责任；热度低的表现则是独善其身，特立独行，甚至桀骜不驯。心中的热度是与个人的能力完全无关的。

对于团队而言，心中的热度是衡量一位同学是否真的融入团队的重要标准。如果仅仅想在团队里找到最精最新的技术，那么心会是冷的，终究会被慢慢边缘化、甚至退出；如果要成为组长，就一定要有勇气跳出纯技术的圈子，对整个项目、所有组员负责，对项目中的方方面面热心快肠；如果要成为真正的核心，则一定要主动承担项目之外的工作，愿意为团队的奉献出自己宝贵的时间。心中的热度以及表现出来的态度和行动，决定了一个人在团队中发挥的作用，自然也决定了他/她在团队中的地位。

我们衡量一个人可以用“热度”这个标准，那么培养一个人是否也应该朝“给心升温”的方向发展呢？当然应该是这样。我们之前进行的团队文化培训、组织的各种文化活动、宣扬的各种理念，都是为了这个目的而开展；刘老师每次面对面的促膝长谈，都是希望用自己烈日般的热度促使心中加温；项目组中的摸爬滚打，也是为了在真刀真枪中凝练队伍，集聚热量。我们以前都是这么做的，但是缺少总结，没看到这一件件事情之间包含的共性问题。

好了，既然“心中的热度”那么重要，我是不是应该开发一套评价的手段呢？应该，但是我实在想不出！那么这个“热度”岂不是和简单的评价“好”与“坏”没什么区别了？不，区别还是很明显的。我们常说，道德第一、作风第二、技术第三，评价一个人应该按照这个顺序进行，换成通俗易懂的说法（但并不是非常精确），应该是甘愿付出第一、严于律己第二、技术领悟力第三，其中，“甘愿付出”与心中的热度有着密不可分的联系，而热度本身还有跟多更大的内涵。心中热度越高，也更愿意付出，也更愿意与对方融合，更可贵的是，这些都会出自于内心，绝非造作——就像男女的爱情。衡量热度也如衡量爱情，任何的细节都会暴露自己真正的心意，恐怕很少有人能够将自己始终伪装得很好，通过观察总能看到事实。这样的衡量方法避免我们用简单而孤立的几件事情来观察人，使得评价有了自己长期的逻辑。

心中的热度会变，而且既会升温，又会降温。我们应该努力让每个人都在升温，降温绝对不是好事情。

当心中的热度足够高时，他/她就具有成为核心队员的基本资格，但还不是充分条件。或者更加明确地说，核心队员必须是团队中热度最高的人，同时还应该具有某一方面的权威。如果核心队员因为种种事情降低了自己的热度，甚至有些变冷，那就失去成为核心队员的基本条件，也就失去成为核心的资格。核心队员绝对不是一个终身荣誉，而是对心中热度和团队责任的一种肯定。

我们应该尽可能的去提升心中的热度，这是融入团队的方法和手段。那么提升心中的热度究竟会对自己有什么好处呢？很显然，在团队中承担更多的职责就会带来更多的收获，千万不要把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等等高层软件应用的编程思想，都应该在有余力的时候涉猎一番，开拓眼界会大大有利于自己思考。

在这里，我主要从组织者的角度出发，重新来审视这次培训的过程，以期望在未来举办类似活动时进一步提升效果。

一、培训内容组织上的经验教训

培训从内容上主要分为三个部分：团队文化培训、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团队发展而不断变得丰富多彩。

不过，这个倒计时同时也是为我自己而设。

我想，这应该会是我为Dian团队引进的最后两项活动了，下学期起，培训部的重担就要交给gump来承担了，他会来做主要负责人，我只负责出谋划策就成——嗯，Dian团队的这种工作流程需要可靠的传承下去，我不应该继续引入任何不确定的东西了。可不要让我失望啊，gump！

虽然担心gump会忙不过来，但我从来不担心Dian团队的未来，这个团队的发展早就不会因一两个人的离开而改变。

有同学会悲观的说，我们这一级毕业了以后，Dian团队就会从此缺少重量级人物，会因此而倒退——这个观点是可笑的。的确，我们这一级，包括即将毕业的上一级学长们，至今为止都给人一种无法超越的感觉，但Dian团队的确不是因为我们存在而壮大、成长，却是因为我们的力量已经完全注入团队、和团队方方面面融为一体之后才强大。无论是团队三大部门的分工还是未来的技术方向，这些东西都绝对不是我们的私有财产，不会轻易流失。

如果要说倒退，那恐怕只可能发生在技术上。我个人觉得，这种境况无法避免，也无须担心。

总有一些强的一塌糊涂的人加入团队，他们也总有一天会毕业、会离开，于是，某方面的技术或许就因此而倒退了。团队初期人才非常匮乏的时候，曾有一次所有C++的牛人都同时毕业或暂时退出，造成一时间的真空，我们还不是依然可以维持这个方向的继续运转——其诀窍便是在前人的思想下继承发展。C++在语法上并不会如何的难，工程应用中也不会用到很生僻的东西，所以难的是设计，当设计拿不定把握时，参照并继承已有的设计是最好的选择。现在，团队更加注重“传承”，再也不会出现某一方面断档的情况，那么，少几个牛人又如何？

新的核心队员已经在慢慢成长，半年以后，他们会变成Dian团队新的栋梁。我们，作为即将离开的人，就算再遗憾、再留恋，也必须懂得放手，让自己慢慢淡出，慢慢让贤。我很希望看到新的栋梁能够真的撑起整片天空，这样我也能放心的挥别这个积聚会议的地方。

倒计时，一刻都没有停止，就算再舍不得，沙漏也有流尽细沙的时刻。我静静等待着一刻。

我们一直以来都说：除了培养技术力，我们还培养高尚的道德情操和扎实的工作作风，而且这两点是放在技术之前的。那么，这样两点如何体现呢，没有高尚的道德情操和扎实的工作作风，对团队同学有什么影响呢？

如果这两者缺少其一，那么这位同学恐怕就很难在团队中转正了，也就是不能获得永久编号；而这两者做的只是差强人意，比较平庸，那么这位同学恐怕就很难成为一名组长了。组长，在Dian团队中处于中流砥柱的作用，他们撑起了团队的未来，是团队真正的支柱。我觉得，每一位Dian团队的同学都应该将自己的目标定位成为组长，成长为这样的栋梁之材。

可惜长久以来，组长的培养缺乏足够的规律，我们常说“战火当中成长”，也就是通过“干中学”来摸索着掌握组长之“道”，这是非常不好的。这样成长起来的组长或许更具有活力，但是缺乏一定的指引，可能造成某些看法的偏颇，所以，我们继续创造这种孵化组长的战场的同时，还需要这样一个大家认可的正规培训来解决所有未来组长遇到的问题。

因此，就有了这个即将举行的组长培训。

这个培训将在1月13日和14日举行，将会利用两个整天的时间做培训，主要涉及团队文化、项目流程介绍、Tiny Project实战演练、组长的必知必会等内容，希望能够全方位的提升组长的文化素养、流程概念、设计及管理能力、管理理念等实用的内容。

现在Dian团队有充足的教室资源供使用，这真的是太爽了，要是一年前，这种事情想都不能想呢！所以，团队的持续发展将会进一步推动各种正规化过程，于是产生一种非常好的良性循环。这应该就是我和其他所有核心层都乐意看到的事情了。

马上，就在这个星期六的晚上8点起，我们将举行第一次团队生日Party，届时，除了常规的生日蛋糕以外，还有不少好玩的游戏、神秘大奖等着大家来参与！嗯，天机先不泄漏，把计划都说出来就不好玩了。

第一次组织这样的活动，还是不太确信是否会达到我们的目标，希望大家都来积极配合吧。我们将要邀请Dian团队中所有一月份过生日的同学参加活动，到那时，大家忘掉各自的身份，全身心的投入这场娱乐盛会中去吧！祝即将或刚刚已经过了生日的同学生日快乐，玩得开心！

最后，我来一个简单的Q&A，回答常见的问题（大家可以继续提问，我不断更新）：

Q：生日Party一般什么时候举行？
A：暂定为每月的第二个星期六的晚上8点举行，如果有节假日或考试冲突，我们会根据具体情况择日举行。具体时间我们会至少提前两天通知。

Q：生日Party一般会多久？
A：我们打算控制在2小时以内，原则是先让大家累到觉得饿，在开始分蛋糕，哈哈。

Q：我需要为生日Party准备什么？
A：什么都不需要，只需要准备时间！这是一个放松自己和认识新朋友的好时机，千万不要错过！

Q：如果万一那天我有急事错过了Party怎么办……？
A：如果错过的同学比较多，我们可以考虑再安排个时间，一月做两次。当然，最常见的应该还是顺延，反正好事肯定不会拉下你啦！

Q：我……不太喜欢热闹的场合……怎么办？
A：希望要尽力改变自己哦！未来的世界是不允许封闭的人存在的，这就是挑战自我的好机会啦。