有一次，一个大老板分享了他组建技术团队的经验。当时我问他一个问题：你组建的团队是项目型组织还是职能型组织？但是大哥对这个问题似乎没有特别直接的答案，所以在这篇博客里，我想和大家探讨一下这个问题。 　　

　　00-1010职能组织和项目组织真的很容易混淆。虽然两者都是为实现某个目标而相互合作的个体组成的群体，但项目型组织侧重于短期任务的实现，而职能型组织是长期存在的。 　　

　　在职能组织中，团队共享一个或多个具有固定组织结构的项目。团队成员是一个相对稳定的组织单元，可以充分发挥职能组织的资源集中优势，轻松依托组织内的专家资源，实现资源共享和知识体系传承，既能保证项目的快速推进，也有利于公司的长远发展。当然，职能型组织也容易形成内部小团队。当跨组织的任务需要共同完成时，由于权力和利益的划分，很容易陷入各自为政的局面。 　　

　　项目组织是所有工作都围绕项目进行，价值通过项目创造。组织是一个专业化的组织，它的唯一价值就是完成项目。其优点是目标明确，任务单一，基于现有资源最大限度响应需求。其缺点是成本低(因为一个项目的唯一价值就是不择手段的完成项目，有时可能会导致项目成本和资源的浪费)，项目之间缺乏知识和信息交流，因为需要大量的时间积累知识，可能会对项目的进度产生不利影响。 　　

　　在项目组织中，根据项目经理对项目资源的控制能力，有强矩阵、弱矩阵和平衡矩阵。但是，强矩阵虽然是项目经理最舒服的管理形式，但也是最容易浪费资源的形式。 　　

　　这两种架构各有利弊。例如，职能组织可以重用资源和共享知识。如果能加上项目机构优秀的执行能力，显然是一剂良方。 　　

　　00-1010众所周知，软件开发模式有三种：瀑布式、迭代式、增量式。虽然这只是三种软件开发模式，但似乎不会影响R & ampd技术团队，但实际上他们已经无形中深入人心，像康威定律一样，默默改变着一个小团队的系统架构。 　　

　　例如，在瀑布项目团队中，团队倾向于通过文档进行交流。当遇到问题时，首先想到的是优化文档或流程，这似乎是组织之间低效沟通的表现。敏捷项目有助于打破项目团队对文档的依赖。单从这个角度来说，它可以给团队带来一个很好的生态系统。 　　

　　当然，无论哪种模式都不一定正确，比如精密航天技术的研发，如果敏捷的话，估计就完了，但是互联网项目的开发实践，用瀑布模型，似乎反应太慢了。 　　

　　虽然技术经理很容易把团队管理和项目管理混为一谈，但必须承认，在一些常规的软件开发过程中，灵活应用敏捷项目管理带来的一些方法，可以有效地促进团队之间的进一步和谐，从而建立一个更加自我驱动的项目团队。 　　

一）职能型组织和项目型组织

　　工作软件高于详细的文档。 　　

也就是说，尽管右项有其价值，
我们更重视左项的价值。

而敏捷宣言所提倡的这几点，都是有利于推动团队构建的实践手段。

1、站会

在敏捷项目管理过程中，站会是一种最基础的实践，团队成员每天早上围着白板站成一个圈，然后再依次回答三个问题：

1、我完成了什么。

2、遇到了什么问题。

3、今天计划完成什么。

展会的主要特点是改变了传统项目管理中由项目经理控制整体项目的模式，改成由团队成员共同参与，在这种情境下，每个人都独立的承担其一部分职责，虽然有Scrum Master或产品负责人组织，但实际上团队成员并未向任何人汇报。

2、敏捷卡牌

传统项目管理模式中，工作量的估算一般都是由主要开发者拍脑袋、或项目经理拍脑袋，而采用了敏捷卡牌，则使工作量的估算多了许多群体决策。

在敏捷卡牌实战中，大家采取这样的实践手段：

1、首先使用某个比较易于评判的功能，作为评估标准.

2、用该标准去评估其他功能的工作量。

3、通过团队群体决策，判断其他任务的工作量，如果多个人评估的结果相差较大，则说明需求未澄清，则澄清需求点，继续评估。

这种实践有助于打破团队间的信息障碍，使得功能点的执行更加易于开展。

3、反思回顾会

在项目过程中最难的大概就是经验知识的传承。而在敏捷项目迭代完成后举行的反思回顾会，也恰好是这样一种有利的手段。在反思回顾会上，大家讨论我们上一迭代有哪些事情做得好，希望继续保持，哪些事情做得不好，希望改善，有何改进计划。

对程序员来说，普遍不善于交流，而反思会则给了大家“吐槽”的机会。当然，在实际召开过程中，项目组织者可以尽量减少发言，尽量让团队成员多发言的方式，让团队成员能够自发的提出问题和对应的改进建议，而不是成为个体的一言堂。

四、结语

对于团队而言，最重要的莫过于打破沟通障碍，让团队的成员都能获得尽可能多的表现机会，而依托敏捷项目管理提供的许多框架，则可以成为这样的利器，为构建团队带来便利。