标签：
在互联网企业中，一定会有多个项目组成一个产品线。每一个项目，都会经历发起、迅速壮大、稳定的过程。稳定一段时间之后，会面临几种可能的方向：
1、 有了新的发展方向，继续壮大。
2、 保持稳定，承担这个项目应有的功能，但暂时没有新的发展方向。
3、 逐渐放弃，因为没有达到预期目标或者不符合企业新的发展战略了。
作为技术团队，当项目趋于稳定后，必定会有部分人员的分流，或者调到其他产品线，或者离职。对于坚守项目的团队成员，不可避免会有心理失落期：一是不再有全力发展时的激情，二是不可避免会暴露一些曾经被忽视的矛盾。
这时候，这个团队怎么办？是继续不痛不痒的完成安排的工作，还是做一些内部调整，让团队继续保持战斗力？
沉沦下去，这绝不是老板们希望看到的结果，更不是团队成员希望看到的结果。马斯洛需求层次告诉我们，当满足基本的温饱需求之后，我们会有更高层次的需求，希望实现自己的价值，希望得到别人的认可。
首先，我们需要明确项目在整个产品线中的定位。
做这个工作的目的有两个：
1、 让团队成员对公司整个产品线有更明确的了解，而不是仅仅将目光局限在这一个项目中。
2、 明确项目在产品线中的定位，它应该是产品线必不可少的一个环节，而不是随时会被抛弃的一个鸡肋。
项目已经趋于稳定，但并不是没什么可做。在同产品团队的沟通中，明确项目的发展目标。在小团队模式下，项目可以从几个环节进行突破：
1、 服务化。当前项目已经实现了相应的接口，供其它产品调用。受限于当时的时间和资源压力，可能不是很完善。随着其他产品和技术的发展，项目可以提供更完美的服务化解决方案，应对将来的大并发调用需求。
2、 数据分片。随着业务的增加，业务数据将会量级增长，很快单数据库将会面临压力，需要更好的分库分表解决方案。有了技术方案后，还需要分析数据，从数据的哪些维度入手进行拆分，尽量避免多库多表的联合查询。
项目的设计，定位于大数据大并发，将项目分为多个分布式节点，每个节点配置两三位同事共同负责。在大团队模式下，这种工作模式非常有效。但在小团队模式下，如果还沿用这种方式，可能会有一些问题。
1、 人力分配捉襟见肘。每个模块平均一个人都很难达到了，势必有人需要同时负责两三个模块。
2、 开发任务不均衡，有的模块短期有较大的开发任务，有的模块可能相对更稳定很长时间都没有大的开发工作量。
这时候可以考虑削弱模块之间的职责划分，尽量做到每个同事对每个模块都比较熟悉，都能够根据需要参与这个项目的维护和开发。这样做有几个好处：
1、 便于应对可能的人员流动。任何人员的流动不会对相应的模块工作造成大的影响，因为有其他同事能够随时接手。
2、 大家能够增加对整个系统设计的理解。不再局限于某一个模块的理解，全盘理解系统架构师当初对系统的设计，逐渐提高每位团队成员的设计能力。
在第二个环节中，我们的目标是让每个成员都能了解整个项目中的每个模块。但这不是一蹴而就的，也不是把代码扔给大家自行去研究。
以模块为单位进行技术交流。可以由对这个模块最熟悉的成员进行主要介绍，也可以是希望了解这个模块的成员。
介绍的内容可以分几个部分：
1、 模块在项目中的定位，模块在项目中的拓扑图。
2、 模块内部各个单元的分工和协作，拓扑图。
3、 代码的层级设计。
这样的交流，负责介绍的成员能够加深对该模块的认识，听众也能更快的熟悉这个模块。
公司产品线很广，这个项目中碰到过的问题，其他项目也会碰到。可以组织从技术实现的角度方面的技术交流机会。
这样的交流有几个好处：
1、 提供给成员交流锻炼的机会，不仅会做，更会说。
2、 为其他项目提供技术实现的参考。
3、 让整个公司了解本团队成员的能力，在他们的项目碰到瓶颈时，能够立刻想到从我们团队寻求最有效的帮助。
标签：
原文地址：http://www.cnblogs.com/codestory/p/5641387.html
