随着项目的进展，代码量的积累，代码质量的问题逐渐暴露了出来，这一阶段的session主要针对代码质量和软件设计，Home Ideas团队推出了“软件设计检讨会”系列session。起初，代码问题较多的团队成员检查自己的代码，并且和其他人一起讨论代码设计或重构方案，每周做一次到两次；并且把需要重构的问题专门记录在一个共享文档里，以便跟踪；不用太长时间，这些人的代码设计能力逐步成长到能够发现整个团队的代码设计问题，并且由主讲人变成了组织者，带动其他团队成员讨论代码问题。经过这一阶段，团队成员的软件设计能力和项目的代码质量都明显提高。

下来一个阶段的session主要关注特定功能和问题的解决方案和特定技术的专项提高，比如在实现了与第三方系统的集成后，主要参与设计和实现的项目成员做了这部分工作从实现方案，到使用的技术，到具体代码设计的全套session。此外，code jam也是常用的专项技术能力提升的方式。比如团队中的前端开发人员连续组织多次CSS专项提高练习，他每次都会根据主题设计一系列小练习，层层深入，覆盖所有的知识点。

“一人一技”

项目用到的技术和知识挺多，想要所有团队成员同时研究这些技术和知识，从资源利用和效率的角度来讲都是不可取的。相反，让每个人选择其中一项技术进行重点研究，对这个人着重培养这方面的技能，并且集中优势资源给予支持，而后再进行知识传递，效果往往更好。Home Ideas团队将此命名为“一人一技”，并进行了实践。比如一个团队成员专攻DevOps，团队把他送到客户现场加入客户的DevOps团队六周一起工作；另一个团队成员的主要目标是成为UI开发人员，团队从别的办公室邀请来的前端开发人员和他结对，客户来访时，也让他和客户的前端开发人员结对编程，并且在平时的工作中让他多做和前端直接相关的工作；还有一个团队成员研究BDD和端到端测试，当这方面的技术专家来西安出差时，让他们结对编程，还专门让这个团队成员去客户现场和客户那边的QA Lead探讨端到端测试的问题，等等。

实际效果是，两三个月的时间可以将一个人打造成团队内部某个特定技术的专家，再假以时日，甚至可以成为业界这个领域的佼佼者，比如那个研究DevOps的团队成员此后不久去InfoQ做过关于DevOps的主题演讲。

试想，如果让所有人都去研究某个技术，我们会得到怎样的效果？要么我们不可能送所有人都去客户现场加入他们的DevOps团队，要么到西安出差的技术专家要在一两周时间内和所有人结对工作，收效微乎其微。需要特别注意的是，“一人一技”的实践终是否成功，取决于知识传递是否充分，良好的知识分享的机制和氛围是“一人一技”的重要前提。如果没有将重点培养形成的单个团队成员的技术积累传递出去，对项目的运行也是有潜在的风险。

成长计划

我们常说要不断拓展个人的舒适区，在一个项目团队中如何来实现呢？团队有责任和每一个团队成员进行沟通，帮助其设立个人的成长目标；而每一个团队的成员，都应该不断思考自己的成长计划，并努力实现。