如何建立小团队？这个问题困扰我很久了。
带的部门有三十多号人，接的任务一般都是小项目，不说上亿上千万了，上百万的项目都很少，一般是十万二十万甚至几万的小项目。已经有了一些产品，但大部分项目还是需要大量的定制化开发工作。
部门的岗位主要包括项目经理、需求分析师、软件工程师、测试、客服专员这些。公司另外有专业平台研发团队，这是我们的技术后盾，有了什么技术问题都可以找他们的高手帮忙解决，一般来说，我们这个部门做的活儿都是没有什么重大技术难度的，我把部门的性质定义为生产性部门，类似于制造型企业的制造部吧。
由于部门内部对技术的要求并不高，因此对某一项目而言，最重要的人物无疑是项目经理了。部门内的项目经理主要负责几方面的工作，一是实施，一是售前，一是策划产品，有时人员安排不下来时，项目经理也负责一些需求分析的工作。由于项目经理这个角色对项目的成败，部门的发展非常重要，因此，我们对项目经理的考核措施也是比较严格，通过对项目经理的售前签单成绩、项目验收成绩、汇款成绩综合考虑。而对其他岗位（研发、需求、测试、客服），都是根据核定工时来考核的。
通过这种体系，很明显，比较容易调动项目经理的积极性，也比较容易体现出项目经理对公司的贡献，但是，非常不幸的是，不太容易调动项目组成员对一个项目的同仇敌忾之心，往往容易形成项目经理急死，项目组的相关成员不紧不慢，觉得项目死活跟自己关系不大的局面。前面说过，我们的项目一般都是比较小的项目，项目组都是临时成立（项目启动前，由部门经理安排需求分析人员、客服人员，启动后，研发经理安排开发人员），一个人可能会同时做几个项目的任务。不能不承认，在这种情况，很难形成自己对所属项目的归宿感。如果是大项目，几个人一起窝在项目组成年累月，自然容易形成团队意识。小项目临时安排的人员，几周甚至几天，一个项目的事情就差不多了，分分合合，聚聚散散，自然很难形成几个人的团队意识。虽然对他们的考核也决定了如果不认真工作，慢慢就会体现出来，但却难以形成团队的默契。
最近，逐渐形成了组成小团队的想法，这些日子一直在琢磨，思路很简单，但有些在推行过程中可能会遇到的困难却一直没有想明白，今天整理一下，也算是给自己理理思路。
大概的总体思路是这样的：组成若干4-6人的小团队，大概包括项目经理1人，需求分析师1人，测试1人，开发2人，客服1人。不管接到什么项目，这个团队的人总是一起工作，他们共同对团队的绩效成绩负责。对于部门管理来说，要奖要罚都是针对整个团队而言，要罚大家一起罚，要奖大家一起奖。团队内的考核由项目经理负责。
最终，一段考核期后，根据团队所有完成的项目获得的收益的百分比计算团队应得奖金，团队内部的分配方案由项目经理自己决定。团队的大小一定要控制，不能超过6个人，我认为，团队成员不超过6个人，有吃大锅饭思想的人就很难立足，因为这么小的团队，每个人的表现大家都能看得一清二楚，要不他改变自己，要不就会被踢出团队。尽力发挥每个人的主观能动性，是管理者的追求。
我坚信，一旦使用这种方法，经过几个月或一年的磨合，团队的人工作精神面貌会完全不同，也非常容易解决以前经常会发生的，项目经理一个人干着急其他成员一点不急的情况。
但是，不能不承认，可能出现的问题也会有一大堆吧。下面来理理可能会出现什么问题。
问题一，工作量均衡问题。以前，相同岗位的人员统一管理，一旦有人闲下来，接下来的工作自然优先安排给他，不大容易出现有些人闲着，有些人忙死的状态。如果采用上面所述的小团队方式，就很难避免忙闲不一致的情况，可能这个组的人非常忙，另一个组的人非常闲，也有可能因不同项目的特点，同一组里，这个岗位的人忙死，另一个岗位的人闲死。
应对方案：一般组跟组之间尽量避免工作交叉，来不及尽量自己组挖掘潜力。但特殊情况下，可以把一些任务要求别的组帮忙完成，由项目总监或者研发经理确定工作量，内部记账，用类似外包采购的方式解决两组的绩效问题。这个思路貌似可行，具体实施过程就不在这里讨论了，总之，未必需要什么系统，Excel应该就可以解决。
问题二，产品问题。部门已经有一些成熟产品，做出好的产品无疑是我们的追求。采用小团队后，怎么处理产品问题呢？比较容易的情形是，各个组做自己的产品，你做出来的产品你实施，你的产品做得越好，你的团队绩效成绩越高，收益也越高。但是，问题来了，有可能某些产品，因为适合某个大环境，或者公司市场运动式强推，导致这个组不可能承担得了那么多的项目同时实施。这种情况下，自然会想到，产品是产品，实施是实施，可以将同一产品下的项目分给不同的组实施。然后，棘手的问题来了，对产品的定制化开发怎么处理？没有定制当然搞不了实施，不同的组，对产品、客户需求的把握不一样，怎么才能保证定制既能满足客户要求又能吸收进产品，不断完善产品呢？
应对方案：每个产品任命产品经理。不管哪个组实施，关于产品的定制化，都需要产品经理同意，由产品经理决定要不要定制，怎么定制。产品经理可能不属于项目组，也可能是某个项目组的项目经理。
问题三，规范问题。一旦有了小团队后，大家一起工作一段时间后，容易忽视工作规范，逐渐弄成小作坊的开发方式，优先考虑怎么应付当前的麻烦，不去考虑以后的长远利益。项目做了一个又一个，关于项目的一切都在团队成员脑子里，一旦有人员变动，别人进去时摸不着头脑，没有任何可以参考的文档，晕晕乎乎需要好长时间才能接手。
应对方案：推行部门工作规范化，虽然是不同的项目组，但对于工作流程、交付物、文档撰写的要求一样。定期对部门的规范化工作进行检查，团队所有成员对部门的规范工作要求负责，一荣俱荣一损俱损。通过严格的规范化要求，达到小团队合在一起就是大团队的目标。
问题四，风险问题。一个小团队，在一起工作久了，容易生成诸侯割据的感觉，轻者可能对部门、公司的管理规章制度置之不理，重者可能为了一点小事情集体离职，这确实是个不能不考虑的致命问题。这个问题让我权衡过好久，实在没有什么好的方法防范这种风险，这好像是双刃剑的感觉，你要这种团队的默契，就需要承担这种风险，你不想承担这种风险，就别这么搞小团队。当然，我也相信，通过这种小团队的建立，大家工作更有激情，心情更愉快了，应该是可以降低离职的可能性的。
应对方案：听天由命？或者，可以一段时间（例如一年）做下人员调整，重新组织团队？说不清。
