你的位置:首页 > ASP.net教程

[ASP.net教程]团队规模缩减时怎么保持战斗力


在互联网企业中,一定会有多个项目组成一个产品线。每一个项目,都会经历发起、迅速壮大、稳定的过程。稳定一段时间之后,会面临几种可能的方向:

1、 有了新的发展方向,继续壮大。

2、 保持稳定,承担这个项目应有的功能,但暂时没有新的发展方向。

3、 逐渐放弃,因为没有达到预期目标或者不符合企业新的发展战略了。

作为技术团队,当项目趋于稳定后,必定会有部分人员的分流,或者调到其他产品线,或者离职。对于坚守项目的团队成员,不可避免会有心理失落期:一是不再有全力发展时的激情,二是不可避免会暴露一些曾经被忽视的矛盾。

这时候,这个团队怎么办?是继续不痛不痒的完成安排的工作,还是做一些内部调整,让团队继续保持战斗力?

沉沦下去,这绝不是老板们希望看到的结果,更不是团队成员希望看到的结果。马斯洛需求层次告诉我们,当满足基本的温饱需求之后,我们会有更高层次的需求,希望实现自己的价值,希望得到别人的认可。

1 重新梳理项目的位置


首先,我们需要明确项目在整个产品线中的定位。

1.1 项目在整个产品线中的位置

做这个工作的目的有两个:

1、 让团队成员对公司整个产品线有更明确的了解,而不是仅仅将目光局限在这一个项目中。

2、 明确项目在产品线中的定位,它应该是产品线必不可少的一个环节,而不是随时会被抛弃的一个鸡肋。

1.2 项目在小团队模式下的发展目标

项目已经趋于稳定,但并不是没什么可做。在同产品团队的沟通中,明确项目的发展目标。在小团队模式下,项目可以从几个环节进行突破:

1、 服务化。当前项目已经实现了相应的接口,供其它产品调用。受限于当时的时间和资源压力,可能不是很完善。随着其他产品和技术的发展,项目可以提供更完美的服务化解决方案,应对将来的大并发调用需求。

2、 数据分片。随着业务的增加,业务数据将会量级增长,很快单数据库将会面临压力,需要更好的分库分表解决方案。有了技术方案后,还需要分析数据,从数据的哪些维度入手进行拆分,尽量避免多库多表的联合查询。

2 优化团队内部工作安排


项目的设计,定位于大数据大并发,将项目分为多个分布式节点,每个节点配置两三位同事共同负责。在大团队模式下,这种工作模式非常有效。但在小团队模式下,如果还沿用这种方式,可能会有一些问题。

1、 人力分配捉襟见肘。每个模块平均一个人都很难达到了,势必有人需要同时负责两三个模块。

2、 开发任务不均衡,有的模块短期有较大的开发任务,有的模块可能相对更稳定很长时间都没有大的开发工作量。

这时候可以考虑削弱模块之间的职责划分,尽量做到每个同事对每个模块都比较熟悉,都能够根据需要参与这个项目的维护和开发。这样做有几个好处:

1、 便于应对可能的人员流动。任何人员的流动不会对相应的模块工作造成大的影响,因为有其他同事能够随时接手。

2、 大家能够增加对整个系统设计的理解。不再局限于某一个模块的理解,全盘理解系统架构师当初对系统的设计,逐渐提高每位团队成员的设计能力。

3 加强团队内外的技术交流


在第二个环节中,我们的目标是让每个成员都能了解整个项目中的每个模块。但这不是一蹴而就的,也不是把代码扔给大家自行去研究。

3.1 团队内部交流

以模块为单位进行技术交流。可以由对这个模块最熟悉的成员进行主要介绍,也可以是希望了解这个模块的成员。

介绍的内容可以分几个部分:

1、 模块在项目中的定位,模块在项目中的拓扑图。

2、 模块内部各个单元的分工和协作,拓扑图。

3、 代码的层级设计。

这样的交流,负责介绍的成员能够加深对该模块的认识,听众也能更快的熟悉这个模块。

3.1 团队成员提供外部交流机会

公司产品线很广,这个项目中碰到过的问题,其他项目也会碰到。可以组织从技术实现的角度方面的技术交流机会。

这样的交流有几个好处:

1、 提供给成员交流锻炼的机会,不仅会做,更会说。

2、 为其他项目提供技术实现的参考。

3、 让整个公司了解本团队成员的能力,在他们的项目碰到瓶颈时,能够立刻想到从我们团队寻求最有效的帮助。