为部门的组织结构，最近有点烦。
简单的背景：部门几十号人，一般的项目都是以定制开发为主。
以前部门的组织结构主要是职能型+弱矩阵的结构，有不同的职能小组，有项目时临时组建项目组，一般项目不大，同一个人可能同时在不同的项目组中，为这个干点活儿，为那个干点活儿。这么搞最大的优点就是，人力资源比较容易安排，有活儿来了，看谁闲着就派给谁，工作量自然容易平衡，平衡的结果就是提高了整个部门的工作效率，如果再结合一些多面手的培养，那么会让整个部门都处于一个良好的正常运转状态。但是，这样子的缺点也很明显，就是不太容易激发成员对项目的责任感，不容易发挥成员的主观能动性。容易发生这种情况，项目经理急得火急火燎，成员却不慌不忙，因为他手头可能有好多项目的事情，这个项目的任务对他来说可能只是微不足道的一部分，他认为他有更重要的工作需要完成。
让团队成员的工作有成就感，实现自己的价值，这是我的管理思想中的第一原则。有一段时间，成天就在琢磨，怎么才能让大家的工作有成就感能？做的第一步就是，将工作标准化，将每项研发任务，无论是新功能开发，还是需求变更，都核算标准工时，而相关的岗位可以通过工时系数计算相对应的工时，希望让大家从完成的标准工时中获得成就感。有一件事很清楚，这种方式并不适合研究性的工作，一定是生产性的工作，没有什么技术难度，如果是研究性的工作，由于未来的不确定性，很明显，这种方式是行不通的。
一段时间后，明显看到大家的工作热情都不一样了。以前觉得闲着挺好，现在觉得没活儿干就有些心中发空，一般闲下来都会立即找主管，要求分配任务。
如果只是机械地接受任务，完成就算万事大吉，我想这种工作方式带来的成就感，自我实现感非常有限，如果员工干活没有成就感，就很难有对自己出产的成品的自豪感，又怎么可能会给客户带来满足感。
决定从成立小团队入手，大概实行一种弱职能+强矩阵的方式。
3~7人，成立小团队。这几个人总是在一起工作，一段时间后养成团队的默契，大家彼此心气相通，时间既久，是不是就会达到心有灵犀的境界呢？到了这种境界，不言而喻，工作自然很容易带来愉悦感。几个人同时为了这个团队的绩效负责，大家一起琢磨怎么让客户满意，如果客户不满意，大家一起自责，关键是，当客户喜欢自己的产品时，当自己的产品被越来越多的客户使用时，大家一起获得成就感，这是不可多得的，嘿，想到这种感受，我自己都会赶到兴奋。
但是，成立小团队，并不是那么容易做到的事情。
首先，这个小团队的成员怎么组成呢？于是，我们先要考虑下工作节拍的问题。团队中，项目经理、需求、研发、测试、服务，这些人怎么组合呢？如果以实施为主，研发人员就少点，服务类人员就要多点，如果以产品开发为主，研发人员就要多点，服务类人员就要少点。随着业务的发展，可能会随着产品的成熟，研发人员的比重会越来越小，实施服务人员的比重会越来越大，那么，团队成员也需要根据业务的发展而变化。一句话，岗位的人数设置需要跟上其他岗位的工作节拍。不能让某个岗位太忙或者太闲。当然，人不是机器，项目管理本来就充满了不确定性，完全符合工作节奏的事情是流水线，不是项目组。这时，建议在小团队中培养一两个多面手，可以有效解决特定时候工作不合节拍的问题。
其次，怎么安排这小团队的任务呢？最理想的是，每个小团队有固定的产品，只做一个产品，这个产品成功，这个团队就成功，这个产品失败，这个团队就失败。这样，可以在团队中收到同仇敌忾之效，而且长期做一个产品，从技术上到行业上也会越做越专，活儿肯定会越来越漂亮。然而，遗憾的是，我们现在还不能达到这个境界，我们还没有哪一个产品足够让一个团队专职做下去。所以，我现在的思路是，先给团队定一些主攻业务方向，一旦某个产品做大，就逐渐在团队中淘汰其它产品，最终由项目组做成产品组。
再次，遇到大项目怎么样？有时候会遇到大项目，小团队的资源有限，明显无法达到客户的交期要求，这怎么办呢？这个问题解决不了，最终这种体系一定会无法生存。我的解决方案是，在几个小团对之外，另外成立了一个组叫支撑组，顾名思义，就是支撑其它团队向前冲，从而更好地服务客户的团队。一旦某个团队资源不足，可以向支撑组要求支持，支撑组派人配合。一般新人来了也是在支撑组培训，小团队中人员变动，也是从支撑组中补充。
最后，要看到这种组织方式的风险所在。最大的风险，就是容易形成“诸侯割据”效应，形成自己独特的流程，甚至技术也另起炉灶，一旦有人离职，这一摊子事几乎崩溃。这有点让人想到唐宋时期的军队制度，唐朝搞节度使，战斗力强悍，但逐渐朝廷就难以控制，宋朝接收教训，加强控制，但战斗力非常弱。要应对这种风险，主要要加强规范的管理、开发流程控制，按要求出不同步骤的文档，技术使用必须符合公司的平台框架等，这种职能性的要求不能放松。
